Re: app:accept and Atom entry MIME type

["Roy T. Fielding" <fielding@xxxxxxxx>]

On May 18, 2009, at 5:21 PM, Nikunj Mehta wrote:
> On May 18, 2009, at 5:06 PM, Roy T. Fielding wrote:
> > On May 18, 2009, at 11:26 AM, Al Brown wrote:
> >
> > > I believe it is more about extensions to atom. How should a group  
> > > that builds on top of atom using atom extensibility advertise  
> > > that it can accept generic atom and/or atom+it's extensions in  
> > > addition to other potential media types?
> >
> > Why does it need to?  Why not just let the client try it.
>
> Because the client would have no clue why the request just failed.  
> In effect, it would not "understand" the response even though its  
> intent was clear to the server [1]. This is at the heart of your  
> interoperability argument on atom-protocol from a few years ago [2].

Why would the request fail?

> > > In app, this is all done by media types. Both vanilla atom + atom  
> > > with extensions have the same media type which cause problems.
> >
> > Won't the extensions be ignored by a server that doesn't want them?
>
> The media type parameter is for use primarily in the app:accept  
> signaling. If a server doesn't require it or doesn't understand it,  
> it can safely ignore it.

Yes, I know.  Don't use the app:accept signaling.  AFAICT, there is
no need to do so.  Just send the AtomPub/HTTP message to the server.

> > > I am not sure leveraging categories as the signaling mechanism fits.
> >
> > I agree.  Atom categories are analogous to folders in CMIS.
> > It would make more sense to replace most of the CMIS extensions
> > by using the Atom category mechanism to hold its filing relations.
>
> Day Software is a participant in the CMIS TC and it would greatly  
> help if you could bring such thinking to the TC. It would be one  
> less NIH-borne concept to deal with.

David Nüscheler is more than capable of representing Day in the CMIS TC.
I have my hands full with the layers underneath.

....Roy