-----BEGIN PGP SIGNED MESSAGE-----
On Tue, 20 Jul 1999 hal(_at_)finney(_dot_)org wrote:
Tony Mione, <mione(_at_)hardees(_dot_)Rutgers(_dot_)EDU>, writes:
I agreed to take on a couple of work items at the OpenPGP meeting in Oslo,
Norway. One of those work items was to enumerate the MUSTS in RFC2440 in
order to help vendors begin conformance testing.
Following is the list I came up with (anyone with some spare time, please
check me on the list). I also plan on forwarding SHOULDS, MAYS, SHOULD
NOTS, etc. hopefully within the next week.
This is a good start, but just searching for occurances of MUST/SHOULD
in the document will not be enough to promote interoperability, in my
opinion. Unfortunately there are many sections where we do not clearly
describe which features must/should be supported.
I understand that. I was asked to do this by John Noerenberg as a starting
point to help implementors. That is why I suggested adding the other lists
and actually writing an informational RFC. I know that Jon Callas is
interested in helping and I was told I could contact an NAI PGP developer
(I think the name was Mike Elkins?) who would probably have a lot of good
info to add.
For example, section 3.6.1 describes three kinds of string-to-key
specifiers. We do not say whether any of them must be supported.
In 3.6.2 we say implementations "SHOULD use" two of them. But I
think we meant that for creation purposes, and probably they should
also be able to read the third one.
In section 4 we document packet headers, including a variety of packet
length specifiers. We do have some rules in 4.2.3 which put restrictions
on how they are used. But we do not say that you must or should support
all these packet length formats. Without supporting at least some of
them you won't be able to parse any OpenPGP messages.
In section 5 we enumerate all the packet types. But we never say which
packets must or should be supported.
We also describe ascii armor and clearsigning without clearly saying
whether these are MUST, SHOULD, or MAY.
Overall there is much left unspecified about what is required and what
is not. I would suggest that all features documented are implicitly
SHOULD except when indicated otherwise. We documented them with the
intention that people would use these features, although in particular
circumstances an implementor can make the decision not to do so. That
seems compatible with the definition of SHOULD.
Thanks for the comments. I will collect all responses and take them into
consideration as I am rereading RFC2440.
Hal Finney
Network Associates
Tony Mione, RUCS/TD, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
mione(_at_)noc(_dot_)rutgers(_dot_)edu W3:
http://noc.rutgers.edu/~mione/
PGPFP:D4EEA987E870277C 24AAE6E9E6ABD088 ***** Important: Rom 10:9-11 *****
Author of 'CDE and Motif : A Practical Primer', Prentice-Hall PTR
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by mkpgp2.1, a Pine/PGP interface.
iQCVAwUBN5Tx2AfNcGHdn+zRAQFbRwQAs0zID6JTKFPafRcTz8jgYSwmqaHjg5fb
BKRvrYEcTlly8edoiuZMPt0T/vEQilYROkUK5N9YlnaDEbF4iJvY8dQVmDzE/gfE
11etrbjF/U0OOTXC2YG8213C+aVwxgFH7Jko6gFiJsM3BPkDBsU29JetSbZD56Mk
5Iav0OSSR2c=
=kj1m
-----END PGP SIGNATURE-----