[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-atompub-protocol-14.txt
On Mar 17, 2007, at 11:27 AM, A. Pagaltzis wrote:
* Elliotte Harold <elharo@xxxxxxxxxxxxxxx> [2007-03-17 18:05]:
In the interest of communication, I suggest that people
indicate precisely which sentence of RFC2616 is violated when
they object to APP behavior:
The PUT method requests that the enclosed entity be stored
under the supplied Request-URI.
There you go. First sentence. The entity the client sends is
stored under the supplied request URI. A different entity is
not stored. An amalgam of multiple entities is not stored. The
"enclosed entity" is stored, no other.
It says “requests that it be stored.” In other words, this is the
intention of the client. There is not SHOULD or MUST that
obligates the server to anything in that sentence.
Once again, people are confusing individual server functionality
with interoperable protocol communication. An interface protocol
is always expressed (when done right) as a set of desires, since
any requirements placed on server state changes would be a violation
of the information hiding behind those interfaces, which in turn
would lead to unnecessary coupling, wrong assumptions about that
state between requests, and a gradual breakdown of the system over
An AtomPP protocol exchange may result in all kinds of funky
behavior on the server, none of which matters to AtomPP. Just
like HTTP. And yes, it was designed that way *on purpose*, in spite
of the fact that some people have very different notions of what
makes a good application protocol.
It is only when we talk about specific applications of AtomPP,
such as an authoring interface to a corporate blog, that we can
say anything about the anticipated state change on the server.
SUCH INFORMATION DOES NOT NEED TO BE IN THE PROTOCOL SPECIFICATION.
Is that clear? Maybe someone needs to write an application guide
for transparent authoring via Atom, and maybe that guide should be
very prescriptive in terms of what content needs to be preserved
on any given PUT in order to be acceptable by users who are
expecting transparent behavior. Maybe it will be the topic of
several books. It is not, however, the only application of AtomPP,
and therefore is not part of the AtomPP standard requirements.
At best it could be described in an appendix.
Hence, no spec changes are necessary, the sky is not falling, and
AtomPP implementations will interoperate just fine even when
the purpose of the server was completely unanticipated by the
person implementing the client. Serendipity, by design.
That does not stop people from producing test suites that
check for transparent server behavior and complain when it is
not found, since that is what *they* are interested in testing.