Re: NFC

r/reagle@w3.org/2002.03.19/17:38:52
>On Monday 18 March 2002 16:56, merlin wrote:
>> >However, I'm not sure what is meant by this... What do you mean by "XML
>> >processor." We've defined an application and encryptor. Either the
>> >*application* or the *encryptor* serialize the data, if they do so, they
>> >would have to use NFC right, particularly if it's signed?
>>
>> I was trying to mirror text from c14n. I'm trying to say that we should
>> require that the XML input to encryption already be in NFC, as dsig and
>> c14n do, so it is not the responsibility of the encryptor to normalize
>> it. I'm not sure how else to express this..
>
>The text in question is, "([NFC] MUST be applied when this involves 
>conversion from a legacy (i.e. non-Unicode) encoding.)"
>
>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.

Merlin


-----------------------------------------------------------------------------
Baltimore Technologies plc will not be liable for direct,  special,  indirect 
or consequential  damages  arising  from  alteration of  the contents of this
message by a third party or as a result of any virus being passed on.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
   http://www.baltimore.com

Received on Tuesday, 19 March 2002 18:06:31 UTC