Subject: RESEND: On SHOULD, MUST, and semantics

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 Apr 2005 09:46:49 -0700

[[ Bad content error in my first draft; resending ]]

A few brief notes for the WG to chew on.

- Literal interpretation of 2119 for a document format such as Atom 
would make nearly every element of an entry a MAY. It is a tad 
dishonest to say "why is element Xyz even a SHOULD?" when we have a 
*long* list of MUSTs already. It is no wonder that people are 
changing their opinion of any particular element from MUST to MAY to 
SHOULD and around again.

- The format document, like many IETF Applications Area specs, is 
steeped in hidden semantics. If I suggested that atom:title go from 
MUST to MAY, there would be outrage. The reason is that most of us 
think of entries as having some semantics that include a title. We 
don't say in the format document why we made atom:title a MUST: it's 
just "obvious".

- Differentiating the importance of the semantics of various elements 
is really, really hard, and people's opinions change over time. I 
strongly suspect that many of the less-vocal-but-still-active members 
of this list have changed their view of the importance of 
atom:category at least once.

- We have, unfortunately, linked the semantics of two or more 
elements together. atom:content and atom:summary are linked because 
of their semantics (if you don't have a readable content, you 
MUST/SHOULD/MAY have a summary). This is the hardest one to align 
with making a simple-to implement spec. The fewer cross-element links 
we have, the easier it will be for an implementer.

- We have, fortunately, not required linked semantics for extensions. 
If I came out with hoffman:content-plus-plus, I can't assume that 
whatever linkage there is between atom:summary and atom:content will 
apply to my extension. But, of course, if someone considers 
hoffman:content-plus-plus to be like atom:content, they may *want* 
the same linkages.

- Every SHOULD, by definition, adds logic into the software that 
creates a message in the spec'd format. In the long history of the 
IETF, this also tends to prevent interop, because it gives two 
differing parties a soapbox to argue from.

- Person A may think that an optional element that is missing means 
W. Person B may think that an optional element that is present but 
null means X. Person C may think that W == X, Person D may think that 
W != X. Person C and Person D will probably code very differently.

Proposal for thinking about: to simplify the spec, "atom:summary" 
should either be a MUST in all cases or a MAY in all cases. If it is 
just semantic like "atom:category", it should be a MAY. If it is 
inherently valuable like "atom:title", it should be a MUST.

--Paul Hoffman, Director
--Internet Mail Consortium