- From: Joseph Reagle <reagle@w3.org>
- Date: Wed, 27 Mar 2002 17:32:41 -0500
- To: merlin <merlin@baltimore.ie>
- Cc: xml-encryption@w3.org, duerst@w3.org
I've changed the text in step 3.1 of section 4.1 to: " (The application
MUST provide XML data in [NFC].) "
http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/#sec-Processing-Encryption
$Revision: 1.167 $ on $Date: 2002/03/27 22:30:46 $ GMT b
On Tuesday 19 March 2002 18:06, merlin wrote:
> >The problem is that we might be encrypting element with an XML character
> >datum for a composed charcter ("a"+"^"). It's NFC should be "â". We
> > don't want to encrypt and hand another application "dirty" (non-NFC)
> > characters upon decryption.
>
> I agree with this principle.
>
> >We could, state that the Element and Content must be in NFC form.
> > Otherwise whomever is serializing (the encryptor or application) MUST
> > throw an error. Is this acceptable?
>
> However, I don't really like the MUST throw an error part. C14n doesn't
> have this requirement, and there is no real difference between checking
> for NFC and actually performing NFC. I'd prefer merely:
>
> Element and Content MUST be in NFC form.
>
> This serves the same end, using exactly the same mechanism as dsig and
> c14n: Whoever is handing us the data MUST be working in NFC.
Received on Wednesday, 27 March 2002 17:32:46 UTC