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

 


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

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


Subject: [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)


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