W3C home > Mailing lists > Public > xml-encryption@w3.org > August 2001

Re: Updated Section 4.

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>
Message-Id: <20010823184014.1861F8751D@policy.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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:04 UTC