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

Re: NFC

From: Joseph Reagle <reagle@w3.org>
Date: Wed, 27 Mar 2002 17:32:41 -0500
Message-Id: <200203272232.RAA28433@tux.w3.org>
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 GMT

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