On Jun 8, 2006, at 1:06 PM, Mark Baker wrote:
-1 because of the "MUST" for an Atom response to the POST request. In addition to violating Web architecture (sorry, Tim! 8-) by licensing APP clients to ignore the authoritative Content-Type header, MUST is normally reserved for use when interoperability depends on it, and that isn't the case here AFAICT.
You're entitled to dislike the MUST here, but the appeal to Web Architecture is unfounded. The proposal stipulates that IF you return a body to the post, then it has to be an Atom Entry. If a server were to return the Atom Entry with the wrong media type, or return something else with the Atom media type, that would be an architectural sin.
There is a substantial body of opinion on the WG that having a MUST here would be a plus to interoperability; I'm not going to rehash those arguments. If that opinion gains enough critical mass to fall within the IETF definition of "consensus", then a MUST is entirely appropriate.
I just can't see a good justification for profiling HTTP in this way. It severely restricts extensibility, possibilities for interfacing with existing agents (e.g. HTML responses), and certainly other scenarios that don't come immediately to mind.
This is a much better argument. I happen to disagree with it, because I can see an excellent case for profiling HTTP to meet the special requirements of our core use case: reducing the friction from the process of adding to the Web. -Tim
