XML Signature WG

2001-July-30
Chairs: Donald Eastlake and Joseph Reagle
Note Taker: Joseph Reagle [text]

Participants

• John M. Boyer, PureEdge
• Blake Dournee, RSA
• Donald Eastlake, Motorola
• Merlin Hughes, Baltimore
• Joseph Reagle, W3C
• Angela Shi, RSA

Status of documents < 5 minutes

Will request a Proposed REC review from W3C Director shortly (assuming base64 schema data type is satisfactorily resolved.)

Base64 Datatype

We receieved a response from the Schema WG, with four questions:

1. The base64Binary type has no line length restriction on its lexical forms.

   Response: Agree.

2. The lexical form of base64Binary data can contain any of the 65 characters in the "Base64 Alphabet", plus any characters recognized by the XML spec as whitespace.

   Response: Agree

3. Are XML Schema processors expected to enforce the rules about equals-signs and character count which are implicit in RFC 2045?

   Response: someone has to do it, all things being equal (assuming not too much of a burden on schema and recognizing applications that don't use schema validation will still have to check) we prefer schema enforce this.

4. what is the canonical form for base64Binary values?

   Respose: Option A: 76 characters from the base64 alphabet, then a newline sequence; repeat as needed; last line of more than 0, less than 76 characters, also terminated by newline sequence,

XML Processing Model (XSLT and Schema)

Reagle: Are people ok with Suggested additions to 3.0 Processing Rules section.

Hughes, will look at it, but no one has any problems yet.

Exclusive Canonicalization

Reagle: I propose the requirement it be as or faster (or no more complex) than Canonical XML.

(Discussion on whether the original position of the namespace declaration is available in the XPath data model: no).

Boyer: the present processing requires you to look down as well.

Hughes: does it in two passes

ACTION Hughes: post data on performance of canonicalization versus parsing, and Canonical XML and Exclusive Canonicalization as presently specified. (Reagle: we might be barking up the wrong tree, might not be able to make it that much faster.)

Eastlake: in present proposal, should we elevate the namespace appearence to the highest place possible? Boyer: that sounds costly.

ACTION Reagle: write proposal akin to:

1. Create an empty ancestor_ns_stack of empty list of (prefix,value) pairs.

   ...

2. Canonicalize Element.
   1. If element in subset.
   2. Print it out it out
      1. Render the start/endtags and element name.
      2. In the start tag
         1. Render the attributes. (No need to find ancestor xml:foo attributes).
         2. For every namespace node in use within that element (by the element or its attributes) or within UnsuppressedNamespacePrefixList:
            1. If the namespace nodes (prefix,value) is not in list on top of the ancestor_ns_stack then: Render the namespace node declaration using the prefix and namespace URI.
         3. Append the list of rendered nodes to the list.
         4. Push list on stack.
      3. Do the children
      4. Pop the ancestor_ns_stack

(Action complete <smile/> please send comments to list).