disastry(_at_)saiknes(_dot_)lv writes:
rfc2440b03>4.2.1. Old-Format Packet Lengths
rfc2440b03>[snip]
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
packet
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
implementation
rfc2440b03> SHOULD NOT use indeterminate length packets except where
theend
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>[snip]
rfc2440b03> An implementation MAY use Partial Body Lengths for data
packets,be
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
rfc2440b03> they literal, compressed, or encrypted. The first partial length
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
rfc2440b03> MUST be at least 512 octets long. Partial Body Lengths MUST NOT
be
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
wholeheartedly.
Peter.