Uploaded image for project: 'OASIS Cloud Application Management for Platforms (CAMP) TC'
  1. OASIS Cloud Application Management for Platforms (CAMP) TC
  2. CAMP-174

requirement for URL-encoding of parameter values is misplaced and/or confusing

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: SPEC PR2
    • Labels:
      None
    • Proposal:
      Hide

      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

      Show
      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:
      Hide

      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

      Show
      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

      Description

      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.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              jdurand2 Jacques Durand (Inactive)
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: