XML Signature WG
XML Signature WGBartel, Boyer, Eastlake, Reagle like it. ACTION: Move forward with the
new organization.
2.1.1 Uses transforms, using a base64 transform. Change example to
Canonical XML.
Eastlake: question about serialization of line feeds. John clarifies ... .
Reagle: seems like a complex section, might frighten people, but I expect if people want to do this, this level of specificity is necessary. ACTION: go with this and see if there are further comments on the list and at last call.
Eastlake: Aside, add a sentence in editorial convention say we don't rely upon default in DTD/schema.
Eastlake: Reagle's text MUST understand URI syntax, but not all scheme and methods, "XML Signature applications MUST be able to dereference (obtain the octets associated with) the resource identified by a URI (e.g, DOM, an API, network method). " Must understand URI syntax, scheme is application dependent.
Bartel: and we recommend HTTP.
Reagle, Eastlake, Boyer, Bartel want to go forward. Simon and Srinivas had not had a chance to read it yet.
ACTION Reagle: touch bases with all those at last FTF to make sure they are comfortable with moving forward.
Boyer: similar to understanding some of XPath, makes a distinction between unverifiable versus invalid.
Eastlake: if we were doing a more API type specification, we would probably have focussed on the processor model a bit more.
Eastlake: put something in Section 3 that makes it clear there is a potential state of unverifiable even if it might be valid.
Simon: speaking of returning something other than invalid if the algorithm isn't available.
Boyer: in XPath, "throw an exception to show the particular function/algorithm is not available."
Eastlake: write two sentences as proposal for unverifiable.
Stay with what we have.
Go with text as it is minimal and clarifying: "While the signing application should be very careful about what it signs (it should understand what is in the SignatureProperty) a receiving application has no obligation to understand that semantic (though its parent trust engine may wish to)." More extensive text can be proposed, but go with we have and we'll probably get comments and arguments.
Boyer: present XPath specified (in DSig) doesn't preserve the DTD or declaration. John could change it if necessary, are there any requests? Also, preserving order of comments in and around that declaration could be done, but seems too complex.
Boyer: little difficulty with idea that we'd have an XPath specified in UTF-8 that operates over a UTF-16 document. The XPath application will be comparing a 3 byte sequence for a 16 byte sequence. Eastlake: present text seems ok. Reagle: an Xpath application could use whatever internal representation it wants but should be able to handle this regardless.
Generate a candidate last call by 21st, move forward with last call on the 28th.