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

[Fulvio Risso]

Guy Harris wrote:
> 
> 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.

This was exactly my intention when we defined application-specific blocks.
Probably this kind of blocks might be renamed in "private blocks" or something 
like that. They should be used when someone needs to define a new block that 
will never go public, hence it needs an (hopefully) unique code for identifying 
the new block. If your application goes public and it needs to define a block 
for its purposes, it should ask for a new "public" block code.

By the way, this is how local MAC addresses work.

Cheers,

	fulvio