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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

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


Subject: RE: wd-42 errors and typos


Thanks Ed,

Had just 5 minutes ago sent off the draft to OASIS.  Will correct them and
send it off again before they load the files onto their system.

Nick

> -----Original Message-----
> From: Edward Shallow [mailto:ed.shallow@rogers.com]
> Sent: 08 May 2006 19:11
> To: 'Stefan Drees'; 'Nick Pope'; 'Juan Carlos Cruellas'
> Cc: 'OASIS DSS TC'
> Subject: wd-42 errors and typos
>
>
> Editors ...
>
> Just in case these haven't been corrected already, here are some things to
> correct/review. Most are typos, some are semantic, some are suggested
> changes, and a few might be issues (i.e. 22, 25, 35, 39, 40).
>
> 1) line 146: remove s from applications
>
> 2) line 200: change itself to themselves
>
> 3) line 219: "The signing and verifying protocols can be used to
> create and
> verify XML timestamps;"
>
> Should be changed to "The signing and verifying protocols can be used to
> create and verify both XML and binary timestamps;"
>
> 4) line 220: make Requester Identity one word i.e. RequesterIdentity
>
> 5) line 289: change "our" to "the"
>
> 6) line 290: change "we will explain" to "it is explained"
>
> 7) line 331: "is not parseable XML data," should be changed to "is not
> parseable XML data, after appropriate decoding,"
>
> 8) line 339: capitalize xml
>
> 9) line 343: change "it contains" to "it may contain" due to optionality
>
> 10) line 351: capitalize xml
>
> 11) line 462: capitalize xml
>
> 12) line 596: remove "is suggest"
>
> 13) line 599: remove "some"
>
> 14) line 606: change "with in" to "within"
>
> 15) line 704: remove "for"
>
> 16) line 712: change "constituents" to "syntax"
>
> 17) line 808: add "a" in front of "pointer"
>
> 18) line 841: change "Transforms are applied as a server
> implementation MAY
> choose to increase robustness of the Signatures created." to
> "Transforms can be applied by a server implementation which MAY choose to
> increase the robustness of the Signatures created."
>
> 19) line 844-845: change "data binary" to "binary data"
>
> 20) line 1024: change "timestamp" to "timestamps"
>
> 21) line 1025: change "defines procedures for handling timestamps against
> the document being signed" to
> "defines procedures for generating timestamps over the content which is
> about to be signed"
>
> 22) line 1070: "The present document does not establish a unique solution.
> It is a matter of server policy to decide how to incorporate signature
> timestamps in the XML signatures rendered to its clients"
>
> This phrase should either be reworded or removed as it will create
> inter-operability anomalies across core implementations.
>
> 23) line 1207: change "included" to "include"
>
> 24) line 1216: change XMLDSig to XMLSig
>
> 25) line 1223-1226: "In the case of a non-XML input document, or
> when these
> child elements are omitted, then the server places the signature in the
> input document in accordance with procedures defined in a profile
> or as part
> of the server policy."
>
> I believe we should reject non-XML Documents as default core
> processing when
> Enveloped signatures are requested.
>
> 26) line 1274: remove "that"
>
> 27) line 1298: replace "Base64XML is indicated" with "Base64XML or
> EscapedXML may be required"
>
> 28) line 1316: change "since they are aspects of" to "they need to be
> specified by"
>
> 29) line 1322: change "on" to "of"
>
> 30) line 1324-1325: have no idea what this is supposed to mean ???
>
> 31) line 1341: "worth according to its policy for generating" to
> "appropriate as per its policy and then generates"
>
> 32) line 1364: same change as 31)
>
> 33) line 1488-1489: fix up "without attributes Attribute namespace
> inheritance" ???
>
> 34) line 1490: change "there can appear problems" to "problems
> might arise"
>
> 35) line 1515-1517: "Upon receiving this result code, the client
> SHOULD NOT
> assume any particular relationship between the signature and the input
> document(s).  To check such a relationship, the client would have
> to verify
> or inspect the signatures individually."
>
> Can this not be omitted as there is only one InputDocument in
> Multi-signature scenarios ?
>
> 36) line 1526: change "timestamp" to "timestamps"
>
> 37) line 1530: change "For definition" to "For a definition"
>
> 38) in line 1626 and 1628: change XMLDSIG to XMLSig
>
> 39) line 1656: "instead of the current time" implies that the DSS
> implementation always uses the current time by default. What if
> "SigningTime" is present in the signature ? This optional input element
> needs to be re-written to reflect questions fielded from the
> public review.
>
> 40) line 1747: a note should be made that qualifies the 3rd
> party's ability
> to attest to the SigningTime (i.e. only content Timestamps applied before
> signature creation should result in the ThirdPartyTimestamp boolean being
> turned on, since a signature Timestamp may be applied months after
> SigningTime.)
>
> 41) line 1834: change "timestamp" to "timestamps"
>
> 42) line 1851: "XML timestamps can be produced and verified using the
> timestamping profile of the DSS core protocols [XML-TSP]."
>
> This sentence implies that they cannot be produced by the core.
>
> 43) line 1872: refers to section 5.1.3 which does not exist ???
>
> 44) line 1885: change "appropriated" to "appropriate"
>
>     Didn't really check the rest ...
>
> Cheers,
> Ed
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>





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