RE: accept and Atom entry MIME type

["Brian Smith" <brian@xxxxxxxxxxxxxx>]

Nikunj Mehta wrote:
> Here's an issue we came across in reviewing the CMIS spec
> and I wanted to draw the atom-protocol community's
> attention to it and solicit feedback.
>
> Synopsis:
>
> CMIS is a fairly sophisticated AtomPub extension. A CMIS
> server will advertise collections that are writable using
> the same mechanisms we all know and use, i.e., app:accept.
> Some CMIS servers, though, further restrict the atom:entry
> documents that they will successfully process for POST
> requests. Others may accept any valid Atom entry. I have
> blogged about the consequences of such diverse behavior
> [1, 2] and the basic problem is that a client would not
> know the nice kind from the restrictive kind of CMIS server.

Almost every AtomPub server has the same behavior. Notice that RFC 5023
doesn't define any useful semantics for app:accept, except for the case of a
single empty app:accept element (which means new entries will probably not
be accepted). A server can advertise <app:accept>text/plain</app:accept>
while simultaneously rejecting all text/plain documents based on their
Content-Type. 

> The basic question is whether, for standard AtomPub clients 
> that don't understand any CMIS extensions, there is benefit
> to receiving better app:accept advertisements. In other
> words, is there some additional information about
> app:accept that will help clients better determine whether
> a request is likely to be accepted by the server. I know
> there is no must-understand extension mechanism for
> app:collection, so I don't know what would be the best>
> alternative:

This was discussed extensively in the past. James Snell wrote a I-D (12
drafts, actually) for a "features" extension to document the ways the server
specializes AtomPub. Check the archives for the discussions. 

In any case, I don't think there are any "standard AtomPub clients." Because
an AtomPub server is allowed to do anything it wants in response to a
request, there's no way to write a useful AtomPub client without making many
assumptions about the server's behavior. That is why there's no real
interoperability in AtomPub. The nice thing about CMIS is that it is close
to specifying enough behavior to make useful interoperable implementations
without such assumptions.

Considering CMIS also has a SOAP binding, it is probably best off
documenting its policies using WS-Policy. WS-Policy also fits in AtomPub
very well. Besides what kinds of content can be POSTed, there are many other
server policies that an AtomPub client needs to be aware of.

- Brian