W3C home > Mailing lists > Public > xml-encryption@w3.org > November 2002

Re: serialization and xml wrapping

From: Joseph Reagle <reagle@w3.org>
Date: Fri, 1 Nov 2002 17:02:52 -0500
To: merlin <merlin@baltimore.ie>, arik@phaos.com
Cc: xml-encryption@w3.org
Message-Id: <200211011702.52247.reagle@w3.org>


BTW: We're getting close! The W3C AC vote period closed yesterday and things 
look pretty straightforward there, now we just need to close this thread...

On Thursday 31 October 2002 12:27 pm, merlin wrote:
> Perhaps change the language to something like this:
>
>   A namespace declaration xmlns="" MUST be emitted with every apex
>   element that has no namespace node declaring a value for the
>   default namespace.

That does it for me, and I think addresses what I undestood Ari to be 
saying. Reflected in:
  http://www.w3.org/Encryption/2001/Drafts/xmlenc-decrypt
  $Revision: 1.68 $ on $Date: 2002/11/01 20:42:41 $ GMT

> >> 1. We should make the text less confusing... 4.3.3 Starts off by
> >> saying, "When serializing an XML fragment for subsequent wrapping and
> >> parsing, serialization of the namespace axis should be changed as
> >> follows". This makes it sound like it's part of the decryption
> >> process. If so, exactly which step of 4.3.{1,2} is this relevant?
> >> (Text Wrapping is explicitly called in 4.3.1 and 4.3.2)  There's
> >> probably no hook in 4.3.2 because it's a nodeset sorta-based
> >> replacement mechanism. Whereas the one in the Decryption transform is
> >> a much more specific octet based canonicalization and replace based
> >> mechanism. Is that right? If so, how do we make that more clear? Be
> >> more explicit that 4.3.2 is a node-set based mechanism, but 4.3.3 only
> >> applies to mechanisms like those in the Decryption Transform?
>
> Actually, this is an *encryption* process. This is a non-normative
> suggestion for how to serialize XML into an octet stream for
> subsequent encryption.
>
> The encryption step, 4.1#3.1 states 'obtain the octets'. 4.3.3
> is a recommendation for how to do this by augmenting a c14n
> algorithm. We leave the process wide open; however, if people
> na´vely use c14n then they leave themselves open to the
> problem described and solved by 4.3.3.
>
> Perhaps replace 4.3.3 with this:

Ok, reflected (with tweaks) in:
  http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/#sec-Serializing-XML
  $Revision: 1.255 $ on $Date: 2002/11/01 22:00:48 $ GMT
Received on Friday, 1 November 2002 17:04:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:21 GMT