Re: app:accept and Atom entry MIME type

[Al Brown <albertcbrown@xxxxxxxxxx>]

>Why would the request fail?
If the server has no intent to support non-cmis documents, then it would not advertise it supports those media types.  Adding profile="" or cmisprofile=1.0 to the atom media type solves the signaling issue. If the repository does advertise it supports those media types, then it is a configuration issue of the underlying repository due to a) no default type available b) default type requires information not specified or c) some other resource not available (network between tiers, database, storage, etc)


>AFAICT, there is
>no need to do so.  Just send the AtomPub/HTTP message to the server.

The server could return the following to handle the scenarios:

412 Precondition failed (httpbis[1]) (a or b)
415 Unsupported media type (httpbis) (if the request is in a format other than what is allowed; e.g., missing cmis extensions)
500 Server error (most likely c)

Per Roy's point, including app:collection and thus app:accept inside is nice (extra information so the client can be aware before the request), however, I think the signaling provided by http[bis] is sufficient and the client can just send the message to the server.

-Al

[1] http://www.ietf.org/internet-drafts/draft-ietf-httpbis-p2-semantics-06.txt

Al Brown
Emerging Standards and Industry Frameworks
CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home
Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home

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.

"Roy T. Fielding" ---05/18/2009 07:34:31 PM---On May 18, 2009, at 5:21 PM, Nikunj Mehta wrote:

From:	"Roy T. Fielding" <fielding@xxxxxxxx>
To:	Nikunj Mehta <nikunj.mehta@xxxxxxxxxx>
Cc:	Al Brown/Costa Mesa/IBM@IBMUS, Peter Keane <pkeane@xxxxxxxxxxxxxxx>, atom-protocol Protocol <atom-protocol@xxxxxxx>, pjkeane@xxxxxxxxx, Ryan McVeigh <ryan.mcveigh@xxxxxxxxxx>
Date:	05/18/2009 07:34 PM
Subject:	Re: app:accept and Atom entry MIME type

---

On May 18, 2009, at 5:21 PM, Nikunj Mehta wrote:
> On May 18, 2009, at 5:06 PM, Roy T. Fielding wrote:
>> On May 18, 2009, at 11:26 AM, Al Brown wrote:
>>
>>> 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?
>>>
>>
>> Why does it need to?  Why not just let the client try it.
>
> Because the client would have no clue why the request just failed.  
> In effect, it would not "understand" the response even though its  
> intent was clear to the server [1]. This is at the heart of your  
> interoperability argument on atom-protocol from a few years ago [2].

Why would the request fail?

>>> In app, this is all done by media types. Both vanilla atom + atom  
>>> with extensions have the same media type which cause problems.
>>>
>>
>> Won't the extensions be ignored by a server that doesn't want them?
>
> The media type parameter is for use primarily in the app:accept  
> signaling. If a server doesn't require it or doesn't understand it,  
> it can safely ignore it.

Yes, I know.  Don't use the app:accept signaling.  AFAICT, there is
no need to do so.  Just send the AtomPub/HTTP message to the server.

>>> I am not sure leveraging categories as the signaling mechanism fits.
>>
>> I agree.  Atom categories are analogous to folders in CMIS.
>> It would make more sense to replace most of the CMIS extensions
>> by using the Atom category mechanism to hold its filing relations.
>>
>
> Day Software is a participant in the CMIS TC and it would greatly  
> help if you could bring such thinking to the TC. It would be one  
> less NIH-borne concept to deal with.

David Nüscheler is more than capable of representing Day in the CMIS TC.
I have my hands full with the layers underneath.

....Roy