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

Re: serialization and xml wrapping

From: Ari Kermaier <arik@phaos.com>
Date: Mon, 4 Nov 2002 10:56:26 -0500
Message-ID: <004501c2841a$bbe3a670$3401a8c0@phaosarik>
To: <reagle@w3.org>, "merlin" <merlin@baltimore.ie>
Cc: <xml-encryption@w3.org>

Looks good to me too.

Ari

----- Original Message -----
From: "Joseph Reagle" <reagle@w3.org>
To: "merlin" <merlin@baltimore.ie>; <arik@phaos.com>
Cc: <xml-encryption@w3.org>
Sent: Friday, November 01, 2002 5:02 PM
Subject: Re: serialization and xml wrapping


>
>
> 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 Monday, 4 November 2002 10:57:50 GMT

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