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


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

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

Subject: [OASIS Issue Tracker] (DSSX-25) Public Comment 201809c00001s01: textual clarification regarding AttachmentReference

     [ https://issues.oasis-open.org/browse/DSSX-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andreas Kuehne updated DSSX-25:
    Summary: Public Comment 201809c00001s01: textual clarification regarding AttachmentReference  (was: Public Comment 201809c00001s01)

> Public Comment 201809c00001s01: textual clarification regarding AttachmentReference
> -----------------------------------------------------------------------------------
>                 Key: DSSX-25
>                 URL: https://issues.oasis-open.org/browse/DSSX-25
>             Project: OASIS Digital Signature Services eXtended (DSS-X) TC
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: PRD01
>            Reporter: Andreas Kuehne
>            Assignee: Andreas Kuehne
>            Priority: Major
>              Labels: PRD01_COMMENT, TC_ESI
>             Fix For: csprd02
> 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|http://lists.oasis-open.org/archives/dss-x-comment/201809/msg00001.html]Âper attachment with accessibility issues (word file)
> {quote}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
> {quote}
> h2. Comment Â#1:
> |Clause 4.1.5 Component AttachmentReference. Second paragraph is misleading:
> Â
> 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 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|
> |
> |

This message was sent by Atlassian JIRA

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