At 1:07 PM -0600 5/12/05, Antone Roundy wrote:
On Thursday, May 12, 2005, at 12:32 PM, Julian Reschke wrote:Paul Hoffman wrote:a) ...and MUST NOT have more than oneAt 7:16 PM +0200 5/12/05, Julian Reschke wrote: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):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".
# Atom 1.0 RFC says entries MUST have exactly one atom:foo1
# Atom 1.0 RFC says entries SHOULD have one atom:foo2b) ...and MUST NOT have more than one# Atom 1.0 RFC says entries MAY have one atom:foo3c) ...if it existsScan 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.d) ...if it exists
Paul, I presume a, b, c and d are what you intended?
Yes, thank you. See why I'm not a developer? :-)
So if our charter says that we should support title-only feeds, we can't make the presence of summary or content a SHOULD, right???
So what we're discussing here is whether:
"If you find more than one atom:foo2, fail. Process the atom:foo2 if it exists."
...should be this instead:
"If you find more than one atom:foo2, fail. If you don't find an atom:foo2, you are allowed to fail and still call yourself Atom compliant. Process the atom:foo2 if it exists."
RFC 2119 isn't explicit on this point. Here's all it says about SHOULD:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
Perhaps the best we can do from that document is to attempt to divine from what it says about MAY, what it means about SHOULD, but I don't know whether this is valid or not.
5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)
So, if atom:summary is a MAY, then applications MUST be able to deal with feeds whether they have it or not. The text for SHOULD does not call out any such requirements. This omission suggests to me that the intent of SHOULD is to NOT REQUIRE implementations to interoperate with implementations that don't follow the recommendation. Otherwise, would that not have been spelled out? What are "the full implications", if not the possibility of failed interoperability? Reduced functionality? I don't think so, because that is what MAY is about.
You are reading *way* too much into 2119; this is a normal thing to do.
The problem we have, as I pointed out earlier on the thread, is that we do not specify whether senders and receivers have the same SHOULD. I made one assumption, and Rob pointed out that I had made one different than he did.
The way I read 2119 is that if a sender MAY or SHOULD include something, the receiver MUST NOT fall over if it is in what they receive, and MUST NOT fall over if it is not in what they receive. Does that clarify where I got to on this thread?
--Paul Hoffman, Director --Internet Mail Consortium
