Comments to WD34pre4-set I

[Juan Carlos Cruellas <cruellas@ac.upc.edu>]

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.