It would help if you can clarify which of these two requirements you
wish to address by introducing a new media type parameter and its
consequences. In short, we would benefit if the I-D addresses my
questions below.
Nikunj
http://o-micron.blogspot.com
On Jun 9, 2009, at 3:24 PM, James M Snell wrote:
I've already started working up an I-D for a new profile media type
parameter. I should be able to get it published by tomorrow end-of-day
Example:
application/atom+xml;profile="http://example.org/profile/foo";
The profile parameter value is a URI that identifies a logical
profile to which the Atom document conforms. Only a single profile
value is allowed for now.
- James
Nikunj R. Mehta wrote:
Several recent discussions suggest the need for sub-typing Atom
documents. There are two major requirements for sub-typing Atom
documents:
1. In Atom Publishing Protocol, signaling the requirement for an
Atom extension (whether blessed by IETF or not) to be present in
accepted content [1]. To illustrate the requirement by example, one
would see:
<app:accept>application/atom+xml;type=entry;extension=token</
app:accept>
2. Establishing an expectation on an Atom processor for the media
type of a linked resource, e.g., whether the representation in-
lines a complete hierarchy of Atom entries and feeds [2]. Once
again to illustrate the requirement by example, one would see:
<atom:link rel="down" type="application/atom+xml;type=feed;inline-
depth=1" href="children"/>
Of these cases, a really strong case can be made for the first
requirement to use a media type parameter, since it has to happen
in the absence of the actual Atom document. There is only one must-
understand signaling mechanism in AtomPub and that is app:accept.
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. 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].
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.
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.
2. Does introduction of media type parameters for
application/atom+xml require standards track RFC?
Nikunj
http://o-micron.blogspot.com
[1] http://www.imc.org/atom-protocol/mail-archive/msg11398.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg21114.html
[3]
http://code.google.com/apis/finance/developers_guide_protocol.html#CreatingPortfolios
[4] http://www.oasis-open.org/committees/download.php/32668
