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?
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?
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.
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?
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?
- Sylvain
