| 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. Solutions: 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: 1. Use a new MIME type parameter on app:accept for the Atom entry content type 2. Use a new attribute on app:accept 3. Use an extension element in app:collection to identify CMIS requirements Why should you care? Of course, there are many AtomPub servers out there that wouldn't accept any arbitrary valid atom:content but CMIS is a case that is quite close to blogging and that is being standardized (publicly, if I may say so). This is an opportunity for the atom-protocol community to weigh in on the consequence of how AtomPub advertisements are used in CMIS. As a disclaimer, I am not a member of the CMIS TC, although Oracle is. Nikunj |