Next in thread → Next in month →

[OASIS Issue Tracker] (CAMP-174) requirement for URL-encoding of parameter values is misplaced and/or confusing

From
OASIS Issues Tracker <>
Date
2014-07-24T14:41:38+00:00
ID
Thread
[OASIS Issue Tracker] (CAMP-174) requirement for URL-encoding of parameter values is misplaced and/or confusing
[ https://issues.oasis-open.org/browse/CAMP-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Chapman  updated CAMP-174:
---------------------------------

      Proposal: Martin: proposes to delete PR-11 and fix the example in Table 6-1 by      s/name,description,tags/name%2Cdescription%2Ctags/ in table 6-1
    Resolution: 
From 23rd July 2014:

      Martin: proposes to delete PR-11 and fix the example in Table 6-1 by      s/name,description,tags/name%2Cdescription%2Ctags/ in table 6-1
      MOTION: Tom moves to resolve CAMP-174 with the above proposal , AlexH seconds
      RESOLUTION: CAMP-174 resolved with the above proposal

> requirement for URL-encoding of parameter values is misplaced and/or confusing
> ------------------------------------------------------------------------------
>
>                 Key: CAMP-174
>                 URL: https://issues.oasis-open.org/browse/CAMP-174
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: SPEC PR2
>            Reporter: Jacques Durand 
>            Priority: Minor
>
> The normative req PR-11:
> "] The Consumer SHALL URL encode the request parameter values. [PR-11]"
> seems to apply only to select_attr parameter, as currently placed in the narrative. Yet this parameter does not need extra care for its values because attribute names are restricted enough so that PR-11 appears to be pointless here.
> First a more explicit wording would remove possible misinterpretations: when PR-11 says "URL encode", it is referring to the values of the request parameters (meaning use of URL conventions for representing special characters in parameter values, like space, quotes); it doesn't mean that they values will *be* URLs. 
> Then, should there be other query parameters covered by section 6.5 (in a future version?) PR-11 would make sense, but then should be placed at the beginning of 6.5, not just when describing select_attr . And there should be a Section 6.5.1 "Retrieving a Subset of a Resource's Attributes" (or some such) that introduces select_attr.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
Next in thread → Next in month →