"I'm blogging this"
thanks Sam.
cheers
Bill
Sam Ruby wrote:
James M Snell wrote:
Should.
I'll note that Joe asked MUST/SHOULD.
I'm sure that I will get a lecture as I have some aspect of this wrong
(IETF folks tend to be rightfully pedantic about things like RFC 2119),
but here goes:
A bit of background. First the definition of MAY:
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.)
Now, for contrast, 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.
Note what is NOT said in the definition of SHOULD. To put a not-so fine
point on it, if an implementation ignores a MAY, it still has every
reason to expect that it will interoperate with other implementations.
On the other hand, if an implementation ignores a SHOULD, it needs to be
aware that that it can't rely on ANY such guarantees.
MUSTs, and even SHOULDs increase interop, at the expense of flexibility.
The questions that need to be asked are:
1) Is it possible for implementations to outright fail to operate as
epxected if this constraint is not satisfied?
If NO, consider MAY. Avoid making additional judgement calls. Accept
the additional complexity and interopability issues that this creates.
If YES, ask yourself if there still are reasons why an implementation
might rightfully and willfully chose to ignore this. If so, chose
SHOULD. Else chose MUST.
Joe Gregorio wrote:
So, to summarize, a server can return any status code
when receiving a POST to create a new collection
member. A Location: header may or may not be returned
with the response.
If the Location: header *is* returned, MUST/SHOULD it
appear in the collection feed document?
-joe
- Sam Ruby
P.S. Yes, I'm aware that it generally is easier to get a group
consensus around a word like "Should". To counter balance that natural
tendency, I'd like to challenge anybody who proposes such to justify
that the extra complexity and n**2 interop issues are vital to the
success of this protocol.
