On May 18, 2009, at 8:27 PM, Peter Keane wrote:
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:<snip>The choice of the media type parameter (not to be confused with "type" whichhas a special meaning in the context of the Atom Entry media type) is entirely up to the application. For example, CMIS could use the termcmis-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 somethingdifferent. 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 legitimateto 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?
app:accept behavior is similar to RFC 2616's Accept Header behavior with media ranges (modulo preference). In order for app:accept to work, a client would therefore have to understand the media range matching algorithm required by RFC 2616. For a moment, forget the Atom type. Media ranges such as text/html;level=1, would also require the client to understand the media type parameter "level". If a client willfully ignores this parameter, it is not a server problem because the server can just summarily refuse the request.
Remember that app:accept processing is not just a string match operation. This is why it is the only must-understand mechanism in AtomPub.
<snip>