Hi,
"Rachel Willmer" <rwillmer(_at_)gmail(_dot_)com> writes:
I think the spec does define this. It defines all of those items that
you mention in the grammar in section 11.3. Any OpenPGP-compliant
application should be able to write such a message in such a way that
any other OpenPGP-complaint application can read it, or one or both of
the implementations aren't OpenPGP compliant.
What the spec doesn't define is whether an application must process an
"OpenPGP Message, OpenPGP Message" -- two messages concatenated
together. There is an assumption in the spec that a single stream
contains a single message,
If that is intended, it should be explicitly stated, IMHO.
I do not agree. rfc2440 is about the OpenPGP Message, not about
framing OpenPGP messages or about how you can store multiple
OpenPGP messages.
And if that is the case, then ok, I can get back to writing test
cases, and forget about writing RFCs.
If it is stated somewhere and I've missed it, can you point me at the
reference please?
Basically, 2440bis defines the message formats. It does not (nor does
it need to) define the process of carrying or storing those messages.
Therefore, the question of "message == file" is out of scope for
2440bis and various implementations may choose to implement it
however they choose.
So, no, I don't think it is stated explicitly, but I do believe that
it is implicit that OpenPGP messages are "atomic", and how your
implementation deals with multiple messages is implementation
dependent.
I'll note for the record (as an implementor, not as chair) that the
parser implementation I wrote (many many MANY moons ago) allows
multiple ASCII Armored messages in a single file, but only a single
non-armored OpenPGP message in a single "file". If you have a
"stream" then you need an "out of band" mechanism to separate the
OpenPGP messages.
Personally I think there's no additional draft needed unless you have
a specific application in mind and want to define how to frame
multiple OpenPGP messages within your application communication
stream.
Good Luck,
ta
Rachel
-derek
--
Derek Atkins 617-623-3745
derek(_at_)ihtfp(_dot_)com www.ihtfp.com
Computer and Internet Security Consultant