Re: app:accept and Atom entry MIME type

[Nikunj Mehta <nikunj.mehta@xxxxxxxxxx>]

On May 18, 2009, at 4:56 PM, Peter Keane wrote:

> On Mon, May 18, 2009 at 3:36 PM, Nikunj Mehta  
> <nikunj.mehta@xxxxxxxxxx> wrote:
> > On May 18, 2009, at 11:26 AM, Hadrien Gardeur wrote:
> >
> > 2009/5/18 Peter Keane <pkeane@xxxxxxxxxxxxxxx>
> > > <snip>
> > > ---------------
> > >
> > > 8.3.6 The "app:categories" Element
> > >
> > > <snip>
> >
> > <snip>

> > For the server to signal that it will not accept a certain kind of  
> > Atom
> > entry, the best approach would be a custom Atom Format parameter  
> > (see §12 of
> > RFC 5023). The good thing about this approach is that:
> > 1. There is no need for a new AtomPub or Atom standard
> > 2. The intent is communicated as a must-understand requirement
>
> Those are definitely compelling points.  I have a few questions:  what
> parameter would you use (since 'type' is taken)?  Also, what is
> expected of the atom:entry posted?  Anything?  Seems like what you are
> communicating is: "if you post and atom:entry w/ this parameter in the
> mime type (e.g., role=master), the server will insert an
> app:collection element in the entry or a link@rel=service in the
> entry." Is that more or less correct?


The choice of the media type parameter (not to be confused with "type"  
which has a special meaning in the context of the Atom Entry media  
type) is entirely up to the application. For example, CMIS could use  
the term cmis-object-type-id. It would be great if they registered  
this parameter to IANA for the Atom media type so that no one else  
would use it for something different.

The client would see something like this:

<app:collection href="...">
  <app:accept>application/atom+xml;type=entry,cmis-object-type- 
id=...</app:accept>
</app:collection>

Therefore a client that does not understand the new media type  
parameter will not attempt to post to the server. A CMIS client can of  
course use other techniques to figure out what the value means and  
submitting a request with the appropriate Content-Type. In fact, it  
would be perfectly legitimate to do this:

POST ...
Content-Type: application/atom+xml;type=entry
Content-Length: nnn

[body]

It does not need to nor does any response from the server need to use  
the new parameter in a Content-Type header. It is there only to signal  
to the rudimentary Atom client to not attempt a naive POST.

This whole business of media type parameter has nothing to do with  
hierarchy or h:role at all.

Nikunj Mehta
http://o-micron.blogspot.com