[Top] [All Lists]

Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?)

2001-11-08 11:02:49

disastry(_at_)saiknes(_dot_)lv writes:

rfc2440b03>4.2.1. Old-Format Packet Lengths
rfc2440b03>   The meaning of the length-type in old-format packets is:
rfc2440b03>   3 - The packet is of indeterminate length.  The header is 1 octet
rfc2440b03>       long, and the implementation must determine how long the 
rfc2440b03>       is. If the packet is in a file, this means that the packet
rfc2440b03>       extends until the end of the file. In general, an 
rfc2440b03>       SHOULD NOT use indeterminate length packets except where 
rfc2440b03>       of the data will be clear from the context,

it does not talks about compression, so I think it should be the same for any
packet type

In general indefinite-length packets are a pain, you can avoid them in all
cases except compressed-data where you don't know the length in advance (and
maybe a few oddball streaming applications).  Although the standard doesn't say
it, common sense would dictate using the definite-length encoding for all but
compressed data.

rfc2440b03>4.2.3. Packet Length Examples
rfc2440b03>   An implementation MAY use Partial Body Lengths for data 
rfc2440b03>   they literal, compressed, or encrypted. The first partial length
rfc2440b03>   MUST be at least 512 octets long. Partial Body Lengths MUST NOT 
rfc2440b03>   used for any other packet types.

so it is ok for all data packets..

Urgh, I hope no-one interprets it that way.  The partial-length encoding is
incredibly painful to use with its silly power-of-two restriction (you can't
just say "This is what I've got so far, the next lot starts here" but have to
chop it up into little power-of-two length pieces just to fit the *&#^$&#*
length-encoding mechanism).  GPG uses the definite-length format where it can
and 0xA3 where it can't (compressed data), something I agree with