On Jun 9, 2009, at 2:38 PM, Sylvain Hellegouarch wrote:
There is only one must-understand signaling mechanism in AtomPub
and that is app:accept.
I don't remember seeing that "must-understand", could you reference
it please?
ยง 8.3.4 of RFC 5023 states
[[
The media range specifies a type of
representation that can be POSTed to a Collection.
The app:accept element is similar to the HTTP Accept request-header
[RFC2616]. Media type parameters are allowed within app:accept
]]
I interpret this to mean that app:accept is a kind of must-understand.
However, a client may still attempt to POST however unsuccessfully. Of
course, there is no hard "must-understand" in AtomPub.
If a media type parameter is used in app:accept that cannot be
understood by its receiver, the receiver has no choice but to cease
communications with the server.
What does that mean? What does "cease communication" actually mean
in HTTP?
IIUC, AtomPub clients will not POST to a server entries that don't
conform to one of the acceptable content types for the collection, as
advertised in an app:collection element through app:accept. This is
what I meant. Of course, anything is possible in HTTP, but my
commentary was limited to conforming AtomPub clients.
Since almost every AtomPub-style "API" introduces its own set of
requirements for what constitutes an entry the server is willing to
accept.
For example, Google Finance API in its protocol reference states
that an entry posted as a new portfolio must include a
"gf:portfolioData" element inside an atom:entry [3]. CMIS servers
may require the presence of a type identifier as extended entry
metadata in order to accept an entry posted to a collection [4].
Yes, those are foreign elements which is accepted by the spec. I
don't follow your point.
Point being that if you were to submit a valid Atom entry which did
not have the foreign markup, the server would simply decline the
request, even though it may advertise
<app:accept>application/atom+xml;type=entry</app:accept>
We had a pretty detailed discussion of this topic on atom-protocol,
which you may wish to review [1]
It seems quite reasonable to establish a single media type
parameter and allow every such API to define their own acceptable
values for this purpose. This approach provides fair warning and
enables AtomPub niches to legally exist, and even interoperate.
How do they interoperate if they aren't known by others?
Can you specify "they"? Interoperation is only possible because the
parties to it understand the meaning of the value of a special Atom
media type parameter.
The second case can probably benefit from a media type parameter,
but it is not clear what the semantics of that parameter would be.
Specifically:
1. Do Atom processors fail if, when processing Content-Type header,
they encounter a media type parameter they don't know about or a
value in a known media type parameter that they don't
understand.
Client side or server side?
Why should it matter? This question is addressed to atom-syntax and
intends to question what RFC4287 calls Atom Processors.
Nikunj
http://o-micron.blogspot.com
[1] http://www.imc.org/atom-protocol/mail-archive/msg11398.html
