-----BEGIN PGP SIGNED MESSAGE-----
From: "Werner Koch" <wk(_at_)gnupg(_dot_)org>
On 23 Aug 2001 19:39:39 +0200, Florian Weimer said:
You could use new packet lengths to create a stream of packets...
Well, this is actually done except when the packet is a compressed
one. Then we use the old PGP 2.6 method which is a little bit
faster. The RFC allows for this.
It's not clear to me what the RFC really allows. (It is clear that
indeterminate encodings are not *recommended* at any time.)
The RFC first says:
"If the packet is in a file, this means that the packet
extends until the end of the file."
It then goes on to say "where the end of the data will be
clear from the context", which is a little more liberal.
I suppose you could interpret "in a file" as "is an
entire file".
In this context, the end is only clear because an *outer*
packet had a hard length. Using a hard length there seems
inconsistent -- if you're generating output as you go,
you wouldn't know the outer size either.
Werner said earlier:
Sure, there is no other way to do this when you don't know the length of
the text in advanced. This is very common for Unix tools and that
feature is one of the great advantages of OpenPGP.
I agree that the ability to structure as a "filter" is an advantage.
The partial-body packet encoding achieves this, without having to rely
on some external container (file, or an outer packet) bounding the
length.
If anything, having a truly indeterminate packet inside another packet
makes it harder to use a filter-like implementation for parsing.
Derek Atkins asked:
Have you looked into why it is faster?
A partial-body encoding requires a power-of-two sized buffer be
repeatedly filled (completely, or until end-of-input), and then copied
to the output stream. An indeterminate encoding has no length
information whatsoever, and so requires no buffering or copying.
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3
iQEVAwUBO4XKkGNDnIII+QUHAQGvTgf9F9RR/IcEu9BrTt4gsnVnlnaMYhJlMj3u
GlzZrm8B1+RqcBo2hoRMIbE7MSxWP8sR2wotDjbMXTx9MJ99gbaZv5O18C5xCgNb
Q6Sv0dUPtR+qN9LGS7gJrIo5rxEAY2pEg35H0wYM3HbekqXH7+9hR5iGlAnHXD2r
MBkhSw6Vn4rfDSPb+L9LyVaSptfeniIH2Ahk5aZPGJAOWCgm8HRKgRMcihHbIe2V
xqnu+0xQjkj3qy7im07s2d7tSNuhhYuwKF20sHsF+uqosX5u8o0r/m45j2pUKqxU
1oW4Cd3RjLsb877tvS1jLNxsiXBwDcqc/Ir5HFjkInL1HxAqyo7BxQ==
=0LAZ
-----END PGP SIGNATURE-----