- From: Joseph Reagle <reagle@w3.org>
- Date: Thu, 23 Aug 2001 14:40:12 -0400
- To: "Blair Dillaway" <blaird@microsoft.com>
- Cc: XML Encryption WG <xml-encryption@w3.org>
[Resulting document: http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/ $Revision: 1.38 $ on $Date: 2001/08/23 18:31:43 $ ] On Thursday 23 August 2001 13:13, you wrote: > On the issue of 'replacement' ops being required vs recommended. I > picked up the recommended tag from an earlier draft. I'm OK with this > being a MUST. Ok, and I've now used Ed's tweaks. > Section 4.1 > > Step 2 - You've dropped the information on how an EncryptedKey is > constructed and encoded. It either needs to be added back in here or > possibly combined with the processing rules in Step 4 since it parallels > the EncryptedData Ok, (See email to Takeshi) > Step 3. The Encryptor always treats the data as an octet sequence. In > sub-step 2 it should say something like "If the data is of any other > type, the application is responsible for defining the encoding into an > octet sequence." Ok. > Also, add back in a statement that the Encryptor is > not responsible for validating the input. (See email to Takeshi) > Step 5 - When returning the UTF-8 encoded EncryptedData, do we need to > state whether this is returned as a serialized string or some other > implementation-defined manner? Given all the requirements to support > UTF-8 serialized representations seems like this should be the default > everyone must support. If they also want to return DOM nodes or SAX > events seems fine to me, but its value added. This is one of the things I continue to be a little muddled on (see Merlin's email.) I'm not sure if we even need to say return the UTF-8 encoding. It could return an Infoset (abstract representation), a DOM node set (implementatin of Infoset), the characters as UCS code points (without worrying about their encoding), or the octets as a UTF-8 Encoding,...? > In doing replacement please add back in a statement that changing the > character encoding to that of the target document may be required. (See Takeshi email) > Section 4.2 > > Step 3. Should the ability to pass a decrypted key value to the app be > required or recommended. I suggest required. Ok, "The Decryptor MUST ..."
Received on Thursday, 23 August 2001 14:40:16 UTC