Re: accept and Atom entry MIME type

[Peter Keane <pkeane@xxxxxxxxxxxxxxx>]

On Mon, May 18, 2009 at 11:12 PM,  <jasnell@xxxxxxxxx> wrote:
> Using a mediatype param is a good solution but introducing new type param values is not. If you go down this route, use another param. A while back a few of us were kicking around the idea of a profile param that would fit this use case nicely. E.g. Application/atom+xml;type=entry;profile=cmis. A separate param is much more easily ignored by clients that don't need it or don't understand it.
> Sent from my Verizon Wireless BlackBerry
>

I'd forgotten about that. For context:
http://www.imc.org/atom-syntax/mail-archive/msg17765.html

Some yea's and nay's at the time.  Perhaps the reasons in favor are
more attractive now (i.e. w/ specific needs/use cases)? I'm especially
intrigued by the possibility of a URI value for profile param (and
wondering what overlap there may be w/ work going on in activity
streams).

--peter

> -----Original Message-----
> From: Nikunj Mehta <nikunj.mehta@xxxxxxxxxx>
>
> Date: Mon, 18 May 2009 20:53:48
> To: <Davis_Cornelia@xxxxxxx>
> Cc: <atom-protocol@xxxxxxx>; <albertcbrown@xxxxxxxxxx>; <ryan.mcveigh@xxxxxxxxxx>
> Subject: 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
>> http://o-micron.blogspot.com
>>
>> [1] CMIS II: (C)MISsing good old AtomPub
>> [2] CMIS X: Is CMIS a good AtomPub citizen?
>
>
> Nikunj R Mehta | Consulting Member of Technical Staff | Phone: +1 650
> 506 0679 | Blog: http://o-micron.blogspot.com
> Oracle Advanced Development Projects
> 500 Oracle Parkway #4OP662 | Redwood Shores, CA 94065
>  Oracle is committed to developing practices and products that help
> protect the environment
>
>
>