[ntar-workers] Use of the application-specific blocks in the pcap-ng file specification

[Guy Harris]

On May 10, 2006, at 9:12 PM, Gianluca Varenni wrote:

> We discussed a bit about possible solutions, and basically it seems  
> that the best way to solve this issue is to
> 1. deprecate the use of app-specific blocks (in the sense that  
> applications should not create their own block type values, if they  
> want to create a portable pcap-ng file)
> 2. create some sort of unique repository of block type values. If  
> an app needs to define a new block, it just needs to ask a new  
> block code value to the repository. The LINKTYPE/DLT values for  
> libpcap (and the future LINKTYPE values for pcap-ng) work in this  
> same way.
>
> This approach seems to be the most straightforward, at the expense  
> (of course) of maintaining a public and centralized repository for  
> the block type codes.

Note that if the developers of an app want to define a proprietary,  
private block type, they could do so, even with a public repository  
for the block type codes.  The repository merely needs to allow app  
developers to request a block type code without specifying anything  
other than, perhaps, their name, and that block type code would be  
marked as "reserved for XXX".  The DNS-SD registry of service types:

	http://www.dns-sd.org/ServiceTypes.html

allows that, as does tcpdump.org's registry of DLT_ types (and the  
latter registry has some private types of that sort registered  
already).  The registry could even, I guess, allow the name of the  
requester to be kept secret, if that's really necessary.

This would make the app-specific block types similar to the DLT_USERn  
types in the tcpdump.org registry - no guarantee can be made that a  
file using an app-specific block type can be read safely and  
correctly by any apps other than apps specifically written to  
interpret that block type in the fashion in which it's used by the  
file, just as no guarantee can be made that a libpcap file using a  
DLT_USERn link-layer type can be read safely and correctly by any  
apps other than apps specifically written (or configured) to  
interpret that DLT_ value in the fashion in which it's used by the file.

In other words, if you want to use app-specific block types  
internally, with some internally-developed tool, and never provide to  
anybody files using them if you don't know whether they'll try to  
read them with their own internally-developed tools (and don't ever  
expect tcpdump, Ethereal, etc. to interpret them in the right fashion  
for your file), you can use them.  Otherwise, request a standard  
block type.