[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments to WD34pre4-set I
Dear all, I would like to make some comments to the latest WD distributed before our last conf call. I include editorial (ED) comments, as well as technical and just questions for clarification of certain parts of the text. They cover from the beginning to section 3.3.3 (enveloped signatures), which is what I hhave been able to read so far. I will read the rest and send another set of comments. First of all I would like to appologize if the size of this message seems too long but I have not been able to do anything shorter. Below follows the list of comments. C1. ED lines 222-225. I would insert a new line separating the text dealing with ignorePISComments. C2. ED line 222 I would change the font of "ignorePISComments" to be the one used for names of the elements and attributes at the rest of the document. C3. ED. line 234. Change font to "xml:lang". C4 264. Would not be better to add something like "as specified in section 2.4.2 of the present document" to clearly state that <Document> can not contain any kind of "other data" in any form but as stated in section 2.4.2? For any other way, we have the Other element. C5. ED line 267 Wouldn't it be good to add some text for "Other"? If so, maybe my former comment could be ignored. C6. line 303. Suppress.. already said in conf call and collected in the minutes. C7. ED line 300 should not be read "<ds:Transforms> and require it.", i.e., with the and inserted? C8. ED lines 314-316. Should the not read as follows: "If the content inside one of the following mutually exclusive elements <InlineXML>, <EscapedXML> *or* <Base64XML> *and* is not parseable XML data, then the server MUST report a RequesterError" I have marked the proposed changes with *. C9. lines 322-323. Why the content of InLineXML MUST NOT depend on parts that are normative for a prolog? What "normative" does mean in this sentence? C10 ED line 324. Font of ignorePIsComments. Is there not a certain redundance with what has been stated in section 2.2?. C11. ED line 338. The text ". The non-xml content of the <Base64Data> element is processed binary after it is base64 decoded." does not seem to me very aligned with the preceding text. It does not talk of hashing but "processed binary". What about something like: "he non-xml content of the <Base64Data> element is base64 decoded and the binary result of this decoding is hashed." or somethin similar... C12 ED line 377. What about changing "has already applied to the input document and then hashed" with something like "has already applied to the input document before hashing it"? C13 line 417 Does the explicit reference to <Base64XML> element and the absence of <EscapedXML> and <InLineXML> mean that the XPath attribute may only be applied to xml data coming in <Base64XML>, which would mean that for enveloped signatures, only <Base64XML> would be permitted? Unless there is anything that I do not see now, I would say not, and suggest the explicit inclusion of the two aforementioned elements. C14 line 503-507. I am not sure of understanding its meaning. Do they mean that these inputs do not have any default value or that if they are not present, the server just merely does nothing? C15 ED line 611. Font for attribute WhichDocument. Now come a set of comments on the Basic processing. C16. lines 633-635. Why there is only an explicit mention to <Base64XML>? What about the other xml inputs? Should not be present somewhere in the basic processing. In my opinion, this section should say what to do with every different type of document, and say it explicitely here, even if things as the extraction is clarified in another subsection... Under this perspective I would be more in favour of text as the one present in wd33pre9 C17. ED line 639. "produced" to "produce" C18 lines 639. The current text does not contain any conditional sentence, so it seems that this step will always consist in "processing and transforms"!! I would say that some If should appear here for making it clear that in certain circumpstances, there will not be transformations at all. C19. line 643. The end of this line contains a step (hashing an octet stream) that does nothing to do with the rest of the step. I would say that it deserves to be separated. C20 lines 660-661. What is the purpose of making this reference to the order of the documents? Is there anything useful behind? If so, maybe the text should point out it. C21. There is not mention of DocumentHash at all in the whole Basic processing. In summary: my feeling is htat the current text leaves a number of issues implicit and do not describe a precise algorithm to be followed by the developers of servers. C22. ED line 676 <ds:Objects> to <ds:Object>. ED line 677 <ds:References> to <ds:Reference>. C23. line 682. The text says "provided only same-document RefURIs (RefURI starts with #)"...well, RefURI="" is also a same-document URI..., and unless we say anything against it, it would be perfectly possible that a client would send a RefURI="", forcing the server to insert a XPath filtering for retrieving the corresponding <ds:Object>...so, do we allow this behaviour? C24 ED line 686. Font of WihchDocument. C25 line 690. I think that text describing the purpose of hasObjectTagsAndAttributeSet and createReference must be added so that they are presented and explained as the other attributes of the element. C26. line 702 contains "The client". Line 703 contains "A client can use...". I think that line 702 should be suppressed or changed. Below follow a set of comments on XMLDSIG enveloping signatures. C27. line 707. The text speaks about an "Object". Is it a <ds:Object> or a Document?. If it is a <ds:Object> the two sentences of the paragraph seem to me somehow contradictory. If it is a Document, then both sentences seem to me OK. C28. What does the server if createReference is false? C29. line 720-722 Bad reference 2.4.2 must be changed by 2.5.2. Text should be more precise, not just "see section..." see, for doing what? what steps, if any of that section?, and what if <EscapedXML> or <Base64Data>? C30. Line 731. What does this means? to me is like impossing that this optional input MUST be processed before the other "normal" input documents!! and this to me seems just a matter of implementation that each server must solve as it wants. In addition this seems to be in contradiction with step c. (which for me should be re-formulated without speaking about the generation of the <ds:Signature> at all at this stage, as we do not know if by then the rest of <ds:Reference> elements to be created will have been actually created.... In summary, I also think that this detailed processing should be polished and detailed. Comments on enveloped signatures. C31. Line 735. "enveloped" instead "enveloping". C32. Line 749. What about saying something like: "The rules for XPath evaluation are those stated in section 2.5...."? C33. Line 779 starts "the client". Line 780 starts "1. The client"... two "the client". Suppress or change contents of 779. C34. Line 789. The text anticipates that the server splices the <ds:Signature> in the document before starting to say how it must process the optional input!. I would not put that text here. This steps must reflect the order that the server must follow for processing this optional input. C35. Lines 793-795. Same comment as C29. C36 Line 796. How the server can splice the <ds:Signature> if we are not sure whether the rest of input documents have been treated? In my opinion, the processing of this optional input must end when the corresponding <ds:Reference> is built. It is up to the server (and a matter of implementation) to decide the moment when it will insert the signature within the document. C37. Line 799. There is no step v in basic processing.In addition steps a to c include extraction of the xml data and this has been already described in the step a!. C38 lines 803-804. This is the first time that the list of documents to be processed appears. In my opinion this is an implementation matter and should not appear here. C39. line 805. Same comment as C30. I think it should be suppressed. Well, this is everything. Again, sorry for the length. Regards Juan Carlos.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]