[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]