[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: accept and Atom entry MIME type

§12.1 of RFC 5023 actually defines the media type parameter "type" for application/atom+xml. See See §9.6 and §16.6 of RFC 5023 for additional semantics. ignore the typeparam I-D as it was superseded by previous drafts of RFC 5023.

Details of my suggestion appeared in a previous message on this thread [1] where I was using the parameter cmis-object-type-id.

Nikunj

[1] http://www.imc.org/atom-protocol/mail-archive/msg11380.html
On May 18, 2009, at 8:22 PM, Davis_Cornelia@xxxxxxx wrote:

A question to the group – while I find an I-D on the definition of a “type” parameter, with values of “entry” or “feed”, for the “application/atom+xml” media type here: http://tools.ietf.org/html/draft-ietf-atompub-typeparam-00, it looks to have never advanced.  Yet RFC 5023 uses it in an example?  What does using something like “application/atom+xml;type=entry” mean if the atompub type param draft was not standardized?
 
So, Nikunj, so I make sure I understand option #1 below, you were suggesting something like: “application/atom+xml;type=cmisentry” as this alternative?
 
Cornelia
 
Cornelia Davis
Senior Technologist
EMC Corporation, Office of the CTO
davis_cornelia@xxxxxxx
p: 805.560.9039
m: 805.452.8941
f: 805.880.0390
From: owner-atom-protocol@xxxxxxxxxxxx [mailto:owner-atom-protocol@xxxxxxxxxxxx] On Behalf Of Nikunj Mehta
Sent: Monday, May 18, 2009 10:29 AM
To: atom-protocol Protocol
Cc: Al Brown; Ryan McVeigh
Subject: app:accept and Atom entry MIME type
 
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