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
