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.
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.
Hal Finney
Network Associates