[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (CMIS-134) getContentStream andcontent-range support
[ http://tools.oasis-open.org/issues/browse/CMIS-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=10636#action_10636 ]
Al Brown commented on CMIS-134:
-------------------------------
Ryan, how so? difference between p1 saying SHALL and p2 saying MAY?
my interp - p1 says bindings must provide a way to do this appropriate to its context. p2 says this is how it is done in this binding (meets the must provide a way) and the functionality may be provided by the impl.
I could be misinterpretating p1.
> getContentStream and content-range support
> ------------------------------------------
>
> Key: CMIS-134
> URL: http://tools.oasis-open.org/issues/browse/CMIS-134
> Project: OASIS Content Management Interoperability Services (CMIS) TC
> Issue Type: Bug
> Components: REST/AtomPub Binding
> Affects Versions: Draft 0.50, Draft 0.60
> Reporter: Ryan McVeigh
> Assignee: Al Brown
>
> The getContentStream (REST) service description includes query params for offset and length (to indicate a sub-range of the return stream). And will "return the current content stream using HTTP mechanisms, including respecting the HTTP Content-Range parameters". I assume that this means that Content-Range should be part of the return header (with a status of 206) when offset/length params are supplied. However, the choice of the verb "respecting" leads to to assume that possibly the spec intends to also support the Range request header field? If so, it should be called out. Also, if this is the case, why have the query parameters when there is already a standard HTTP mechanism for supporting this feature?
> 1. If we supported the Range request header, would we also have to therefore support multiple ranges (in a multi-part reply)?
> 2. Would it be feasible to allow Range/Content-Range support be optional?
> The v0.6 Part 1 now says each protocol binding SHALL support ranging in a protocol-appropriate manner. This implies that it is recommended/encouraged/expected but not strictly manditory. It also (hopefully) means that the query parameters are gone and the v0.6 REST will rely on Range headers (but this is not clear).
> I think this should be truely optional (MAY), as it is unlikely to really be necessary. Else provide a compelling use-case for its need.
> In v0.6 part I it says SHALL, but we propose it say MAY. Also, part II doesn't even specify any request params for GET, so not sure if they were left out accidentally, of it was deferring to part I (which is what we'd prefer). Part II REST section should also state that if you do implement range, you should use the standard HTTP headers (Range/ContentRange).
--
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]