W3C home > Mailing lists > Public > public-xmlsec@w3.org > April 2009

Re: ACTION-259 Propoal for the C14N spec change wrt. namespace nodes

From: Konrad Lanz <Konrad.Lanz@iaik.tugraz.at>
Date: Tue, 21 Apr 2009 18:23:46 +0200
Message-ID: <49EDF312.4030007@iaik.tugraz.at>
To: XMLSec WG Public List <public-xmlsec@w3.org>
In short ... below is what should remain of C14n's namespace processing:

A namespace node is rendered *irrespective of whether* it is in the 
node-set, if it has not been ancestrally declared.

Similar thought could be applied to xml:lang, xml:space and for xml:base
[...] more sophisticated versions applying the combination rules of the 
join-URI-References function.


BR
Konrad

Konrad Lanz wrote:
> Konrad Lanz wrote:
>   
>> #######################################################################
>>
>> *B1* A simpler version of B
>>
>> Some discussion about *B*:
>> At a first look *B* seems to be a complex version of the current spec
>> language, but if the section is not formulated in that way, but as it
>> currently is in C14n and C14n 1.1, it can happen that [Na], despite not
>> being in the node-set would be rendered just as well as [N], because
>> [Na]'s parent may not have an ancestor in the node-set or it's parent's
>> ancestor may also not have a "selected" namespace node.
>>
>> So a simpler version might be:
>>   
>>     
> /A namespace node is rendered *irrespective of whether* it is in the 
> node-set, if it has not been ancestrally declared.
>
>
>   
>> Note: The latter fact can be derived from a map of stacks. It maps the
>> prefix to a stack onto which the namespace is pushed when the namespace
>> declaration is rendered and poped when the corresponding closing tag is
>> rendered. So if a namespace node is to be processed, the stack is either
>> empty (the declaration will be rendered and pushed) or it has a peek
>> value that is not equal(the re-declaration will be rendered and pushed)
>> or it has a peek value that is equal (the re-declaration is superfluous)/
>>
>> Similar thought could be applied to xml:lang, xml:space and for xml:base
>> push and pop have to be more sophisticated versions applying the
>> combination rules of the join-URI-References function.
>>
>>
>> The current functionality of C14n however would only make sense if C14n
>> would render to XML 1.1 where the lack of namespace nodes between [Na]'s
>> and [N]'s parents (i.e. [A] and [E]) would have caused a namespace
>> un-declaration in [A]'s direct successor which is also ancestor to [E].
>> In such a situation (using XML 1.1, and reflecting the lack of a
>> namespace node by an un-declaration) the current definition of C14n
>> would be sound.
>>
>>
>> BR
>> Konrad
>>
>> P.S.: The Sentence I hate the most in C14n is:
>>
>> "Consider a list [L] containing only namespace nodes in the axis and in
>> the node-set in lexicographic order (ascending)".
>>
>> The examples (cf the bullet: Persistence of omitted namespace
>> declarations in descendants)
>> http://www.w3.org/TR/xml-c14n.html#Example-DocSubsets suggest that it's
>> correct reading is:
>>
>> * Consider a list [L] containing all namespace nodes in the namespace
>> axis or from the node-set in lexicographic order ...
>>
>> * Consider a list [L] consisting only of namespace nodes containing the
>> namespace axis in lexicographic order (ascending).
>>
>> ...
>>
>> The more I think about it the more I feel there is the need for an
>> erratum here, as it seems that the example
>> (http://www.w3.org/TR/xml-c14n.html#Example-DocSubsets) and the spec
>> language might be somewhat contradicting. Reality seems to have given
>> preference to the example.
>>     


-- 
Konrad Lanz, IAIK/SIC - Graz University of Technology
Inffeldgasse 16a, 8010 Graz, Austria
Tel: +43 316 873 5547
Fax: +43 316 873 5520
http://www.iaik.tugraz.at/content/about_iaik/people/lanz_konrad/
http://jce.iaik.tugraz.at/sic/products/xml_security/

Downlaod certificate chain (including the EuroPKI root certificate):
http://ca.iaik.tugraz.at/capso/certs.jsp



Received on Tuesday, 21 April 2009 16:24:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:43:58 GMT