Uploaded image for project: 'OASIS Digital Signature Services eXtended (DSS-X) TC'
  1. OASIS Digital Signature Services eXtended (DSS-X) TC
  2. DSSX-25

Public Comment 201809c00001s01: textual clarification regarding AttachmentReference

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: PRD01
    • Fix Version/s: csprd02
    • Component/s: Core

      Description

      Comments from TC ESI to OASIS DSS-X TC on DSS-X V2 -  1 of 19 submitted by Liaison Andreas Kuehne on behalf of Sonia Companies via message  201809c00001 per attachment with accessibility issues (word file)

      following steering committee call on 17/09 and addition of 2 other editorial comments, the resulting pre-agreed comments are now for ESI approval for submission to OASIS DSS-X TC by 28 September

      Comment  #1:

      Clause 4.1.5 Component AttachmentReference. Second paragraph is misleading:
       
      COMMENT:
      Original text: “Below follows a list of the sub-components that MAY be present within this component”, and then follows a list of two subcomponents, one of which is AttRefURI
      Then the XML schema piece in clause 4.1.5.2 shows that the AttRefURI attribute is MANDATORY.
       
      In summary the introductory text uses “the sub-components that MAY be present” while one of them is actually mandatory.
       
      In addition to that the first sentence after the former paragraph is: “The optional DigestInfo element MAY occur zero or more times containing a sub-component.” So the leading sentence says “sub-components that MAY be present:”, and the sentences start speaking of elements that contain sub-components…..this seems an unadequate wording that does not clarify what is the relationship between element and component, and clearly indicates that are not the same.
       
      REQUEST: modify the introductory text so that the MAY disappears. Below follows a proposal:
       
      “This component:
      MAY contain zero or more DigestInfo sub-components……

      MUST contain one AttRefURI sub-component. The value of this sub-component MUST be an URI…

      By doing so, there is no possible ambiguity in the reading. The text says whether the sub-component is mandatory (MUST contain) or optional (MAY contain).
       
      In the case that a component has a choice and also mandatory and optional components outside the choice, the text should read something like:
      “This component:
      MUST contain EITHER:
      One XXX sub-compoonent (….)OR
      One YYYY sub-component (….) OR
      One (or one or more) ZZZZ sub-component
      MAY contain one (or the suitable cardinality) of AAA sub-component (….)
      MUST contain one (or the suitable cardinality) of BBB sub-component (….)
      This type of misleading constructs appear in a number of other clauses. Below follows a list of the ones detected.
      1. Clause 4.1.11 Component ResponseBase. Result is mandatory.
      2. Clause 4.2.3 Document. Base64Data is mandatory.
      3. Clause 4.2.4 TransformedData. Base64Data is mandatory
      4. Clause 4.2.5 DocumentHash. Base64Data is mandatory
      5. Clause 4.2.8 SignatureObject. In this case the content is a choice between two sub-components and additionally there may be another sub-component. Try to specify exactly this semantics. Otherwise the syntax goes beyond the semantics (the semantics does not say anything about Base64Signature and SignaturePtr being a choice).
      6. Clause 4.3.9, ClaimedIdentity. Name is mandatory
      7.
      8.
      9.
      CONCLUSION: Accepted to pass this comment to DSS-X TC

        Attachments

          Activity

            People

            • Assignee:
              kuehne Andreas Kuehne
              Reporter:
              kuehne Andreas Kuehne
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: