Re: app:accept and Atom entry MIME type

[Peter Keane <pkeane@xxxxxxxxxxxxxxx>]

On Mon, May 18, 2009 at 7:11 PM, Nikunj Mehta <nikunj.mehta@xxxxxxxxxx> wrote:
>
> 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:

I am not sure how it follows that a client will NOT attempt a post due
to the presence of that parameter? (I note that RFC 2046 states "MIME
implementations must also ignore any parameters whose names they do
not recognize." (1. Introduction 3rd paragraph).  I would assume that
whatever mime-parsing facility that a discovery mechanism would use
would simply drop that param on the floor, no?

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

oh , ok.  I was thinking hierarchy was one of the use cases.

--peter

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