- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Mon, 30 Jul 2001 14:31:25 -0400
- To: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
http://www.w3.org/Signature/Minutes/010730-tele.html
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
2001-July-30
Chairs: Donald Eastlake and Joseph Reagle
Note Taker: Joseph Reagle [ascii]
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
--
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