On 6/14/06, Robert Sayre <[EMAIL PROTECTED]> wrote:
Tim Bray wrote: > I.e. in the first case, we're saying "Client: don't do this." In the > second "Server: if the client stupidly requests this, ignore it." NO. -1. Do not design requirements for servers you know nothing about. Servers: send an error if a client sends a request you can't deal with. Do not silently "correct" the request. This is how HTTP works, it's a normative reference, don't rewrite some busted version in Atom Protocol. OK?
FWIW, this (Robert's interpretation) is the behavior we've opted for the GData APP implementation. If a client sends us extension elements we don't persist with an entry (for example), we reject it with a Bad Request http error. We intend to have some GData stores that will supported client-defined extensibility (i.e. will except arbitrary XML extensions in certain locations with some basic constraints, like well-formedness, maximum size limitations, etc), but again would reject anything that didn't meet those constraints. Our design was based upon the the belief that if building a store then accepting MOST of the client's data wasn't good enough. It was all or nothing. Our definition of "correct" doesn't include silent data loss. There may be real world use cases beyond ours that justify this behavior, but I'm not sure I've heard them yet, mostly it sems like arguments based upon interpretations of various other specs. I'd like to understand the reasoning behind the needed flexibility, particularly in the context of extension elements. -- Kyle
