On Mar 10, 2007, at 9:48 AM, Elliotte Harold wrote:
Different APP servers are going to have completely different responses. Some may just pick up the change to the title and summary, ignoring allof the other changes. Some may replace the entire entry. Some may reject the new entry entirely because they might not support HTML summaries.I see what you're saying, but this is quite surprising to me; and I find no support for it in either the HTTP or APP specs. If this is indeed the consensus of the WG, then it should be spelled out much more clearly in the spec.
On this one, I'm with Elliotte. Check http://bitworking.org/projects/ atom/draft-ietf-atompub-protocol-14.html#update-via-PUT
My feeling is that the semantics of APP are the semantics of HTTP except as we very specifically constrain and extend them. Thus, if I'm implementing an APP server and someone sends me a PUT on an existing resource, I assume that PUT is a Representation and I'll take that as a request to modify the existing resource to reflect that representation. That is to say, if the PUT includes a title but no content, by default I'd nuke the content in the online version. If any other behavior can reasonably be expected by implementors, that's a radical departure from HTTP semantics and the spec needs to say so explicitly. I do not detect, nor do I expect, the WG to develop consensus to make that kind of radical change.
James Snell's remarks about the server being free to interpret/censor/ rephrase the representation in the PUT are of course correct, which is why Lisa wanted us to be clear about this up-front. But Elliotte is right: In HTTP, PUT == replace.
-Tim