At 7:16 PM +0200 5/12/05, Julian Reschke wrote:
A receiving implementation must be able to handle all defined elements, regardless if they are defined as MAY sent, SHOULD send, or MUST send, so I'm not sure what you mean by "interoperate".
Must a receiving implementation handle missing elements? I don't think as long as we say "sender SHOULD include the element".
Bare with me here; I'm not an implementer. What kind of pseudocode are you envisioning on the receiver side? My picture (which could easily be wrong is):
# Atom 1.0 RFC says entries MUST have exactly one atom:foo1 # Atom 1.0 RFC says entries SHOULD have one atom:foo2 # Atom 1.0 RFC says entries MAY have one atom:foo3
Scan the entry.
If you don't find an atom:foo1, fail. If you find more than one atom:foo1, fail. Process the atom:foo1.
If you find more than one atom:foo2, fail. Process the atom:foo2.
If you find more than one atom:foo3, fail. Process the atom:foo3.
At 1:18 PM -0400 5/12/05, Robert Sayre wrote:
On 5/12/05, Paul Hoffman <[EMAIL PROTECTED]> wrote:
> > At 11:38 AM -0400 5/11/05, Robert Sayre wrote:>Remember, if we say SHOULD, that means >implementations don't have to interoperate ......snip... > elements, regardless if they are defined as MAY sent, SHOULD send, orMUST send, so I'm not sure what you mean by "interoperate".
That sentence seems to apply to the conformance level known as MAY.
Similar to MAY, yes. Senders may or may not send depending on the reason given; receivers must be ready to accept with it present or not.
At 1:20 PM -0400 5/12/05, Robert Sayre wrote:
On 5/12/05, Paul Hoffman <[EMAIL PROTECTED]> wrote: > Thus spake RFC 2119:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there...snip... > you are applying your interpretation to. Please be specific: is itthe current draft, a particular Pace, or a particular group of Paces?
PaceTextShouldBeProvided.
Thank you. That Pace, in essence, adds a bunch of "SHOULD NOT be empty" statements without saying when it is or is not acceptable to be empty.
I understood those additional SHOULD NOTs to be for sending implementations, not for receiving implementations. However, that understanding came from the mailing list, not the spec itself.
If your issue was that you saw them as relevant for both senders and receivers, that's a valid concern. The Pace should be written to be clearer who the SHOULD applies to.
Separately, I would like to see the Pace specify in case what scenarios empty values would be allowed.
I trust you'll apply a similar standard of specifity to other members of this working group.
Don't put your trust in fools.
--Paul Hoffman, Director --Internet Mail Consortium
