[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: accept and Atom entry MIME type
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
-----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