OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cmis message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] Created: (CMIS-19) Reconsider HTTP Extensions

Reconsider HTTP Extensions

                 Key: CMIS-19
                 URL: http://tools.oasis-open.org/issues/browse/CMIS-19
             Project: OASIS Content Management Interoperability Services TC
          Issue Type: Improvement
          Components: REST/AtomPub Binding
            Reporter: David Nuescheler

Based on a number of conversation that I had around the "rest-binding" I would like to propose that we modify the specification 
to a degree where we do not extend HTTP if not necessary.
Throughout the specification this is mostly practiced through the addition of CMIS- headers.

There are a number of issues with that both from a design perspective and from a practical standpoint.

From a design standpoint it has to be mentioned that protocols that have a very similar scope to CMIS like WebDAV or AtomPub managed to
specify their entire scope without adding HTTP headers (or almost, they got one dubious header each ;), not prefixed though). 
So one could say that defining custom headers is just bad style, much like fully capitalizing class names in your Java or C# programs. 
HTTP offers other mechanisms to pass in parameters on an application level, that are much more commonly used.

On the other hand there are very practical issues with defining custom headers. There is a lot real-life HTTP infrastructure like Proxies, 
SSO systems and Firewalls that will strip the unknown CMIS- headers or deny the request completely. Also the simple interaction 
with a browser through a simple GET request or POST issued by an html-form becomes impossible since the user has no 
means to influence the headers.

I think we would not sacrifice any functionality or feature if we would move the respective headers to somewhere else, intuitively I would 
say query parameters. This would also make the entire specification much easier to use for an end user.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]