Re: app:accept and Atom entry MIME type

[Al Brown <albertcbrown@xxxxxxxxxx>]

I believe it is more about extensions to atom. How should a group that builds on top of atom using atom extensibility advertise that it can accept generic atom and/or atom+it's extensions in addition to other potential media types?

In app, this is all done by media types. Both vanilla atom + atom with extensions have the same media type which cause problems.

I am not sure leveraging categories as the signaling mechanism fits.

-Al

Al Brown
Emerging Standards and Industry Frameworks

Office 714 327 3453
Mobile 714 263 6441
Email albertcbrown@xxxxxxxxxx
CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation.

Peter Keane ---05/18/2009 10:54:33 AM---Hi Nikunj-

From:	Peter Keane <pkeane@xxxxxxxxxxxxxxx>
To:	Nikunj Mehta <nikunj.mehta@xxxxxxxxxx>
Cc:	atom-protocol Protocol <atom-protocol@xxxxxxx>, Al Brown/Costa Mesa/IBM@IBMUS, Ryan McVeigh <ryan.mcveigh@xxxxxxxxxx>
Date:	05/18/2009 10:54 AM
Subject:	Re: app:accept and Atom entry MIME type

---

Hi Nikunj-

On Mon, May 18, 2009 at 12:29 PM, Nikunj Mehta <nikunj.mehta@xxxxxxxxxx> wrote:
> 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.

Here is an excerpt from RFC 5023

This is the basis of my suggestion of using atom:category to specify
that an atom:entry is of a particular "kind" or exhibits particular
properties.  And filtering on such is already built into the AtomPub
spec:

---------------

8.3.6 The "app:categories" Element

The "app:categories" element provides a list of the categories that
can be applied to the members of a Collection. See Section 7.2.1 for
the detailed definition of app:categories.

The server MAY reject attempts to create or store members whose
categories are not present in its categories list. A Collection that
indicates the category set is open SHOULD NOT reject otherwise
acceptable members whose categories are not in its categories list.
The absence of an app:categories element means that the category
handling of the Collection is unspecified. A "fixed" category list
that contains zero categories indicates the Collection does not accept
category data.

-----------------------------------------

--peter

> 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?