Re: accept and Atom entry MIME type

[Peter Keane <pkeane@xxxxxxxxxxxxxxx>]

On Mon, May 18, 2009 at 10: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?
>

Hi Cornelia-

I was just reading some old atom-protocol posts from around the time
that ID was floated. As far as I can tell, it was simply folded into
the atompub spec.

--peter

>
>
> 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
>
> http://o-micron.blogspot.com
>
>
>
> [1] CMIS II: (C)MISsing good old AtomPub
>
> [2] CMIS X: Is CMIS a good AtomPub citizen?