W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 2001

Minutes of 2001-07-30 Teleconf

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Mon, 30 Jul 2001 14:31:25 -0400
Message-Id: <>
To: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>

It includes the response to the Schema WG on the base64 type and my proposal 
for exclusive canonicalization. (The proposal might have a bug, and might be 
too "implementation specific" but that's because if something like that 
worked, that's how I would implement it with a few lines of code! <smile/>. 
If it's decent, it can probably be generalized...)


IETF W3C   XML Signature WG

Chairs: Donald Eastlake and Joseph Reagle
Note Taker: Joseph Reagle [ascii]


   * 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 

     Response: Agree.

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

     Response: Agree

  3. Are XML Schema processors expected to enforce the rules about 
     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 

  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 

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, 
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

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
              2. For every namespace node in use within that element (by the
                 element or its attributes) or within
                  1. If the namespace nodes (prefix,value) is not in list on 
                     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

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
Received on Monday, 30 July 2001 14:31:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:36 UTC