[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (DSSX-25) Public Comment 201809c00001s01
[ https://issues.oasis-open.org/browse/DSSX-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Hagen updated DSSX-25:
-----------------------------
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|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:
Â
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|
|
|
was:
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}
Â
> Public Comment 201809c00001s01
> ------------------------------
>
> Key: DSSX-25
> URL: https://issues.oasis-open.org/browse/DSSX-25
> Project: OASIS Digital Signature Services eXtended (DSS-X) TC
> Issue Type: Bug
> Affects Versions: PRD01
> Reporter: Andreas Kuehne
> Priority: Major
> Labels: PRD01_COMMENT, TC_ESI
>
> 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:
> Â
> 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|
> |
> |
--
This message was sent by Atlassian JIRA
(v7.7.2#77003)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]