RE: Minor comments on Section 4

I like the direction of your proposed 3.1 wording but I want to tweak it
so that we don't sound like we are requiring applications to always provide
a serialization algorithm even if they would only use the Encryptor's supplied
one (which I don't think is the intention, correct me if I'm wrong).  So
here goes...

3.1 If the data is an [XML] Element or [XML] Element Content, obtain the
octets by serializing the data in UTF-8 as specified in [XML].  Note that
Encryptors are NOT required to implement a serialization algorithm.  If
an Application using an Encryptor that does not provide a serialization
algorithm, that Application must provide this functionality.  Of course,
if an Application is using an Encryptor that implements a serialization
algorithm, that Application need not supply its own.


Regarding the use of the "Type" attribute, I'm not sure there will always
be a 1-to-1 correspondence between the Type attribute and the serialization
algorithm.  For now, let's assume the Type attribute is sufficient and only
address the issue if it becomes obvious this is not the case.

Ed

-- Original Message --

>Ed,
>
>My read of the current draft is that there is no REQUIRED serialization
>algorithm for compliant implementations.  Hence, a compliant
>implementation need not provide any serialization functionality.  So I
>don't understand how one can assume the encryptor is going to do this.
>(FWIW, I happen to agree most implementations will supply serialization
>functionality and most apps with simply use it.  But, unless its
>mandatory Section 4 shouldn't assume it.)
>
>We've also discussed in Section 4.3 the reasons why App must be allowed
>to handle serialization.  The Encryptor doesn't understand the app
>context and might not use the best, or even a useful, serialization
>method.
>
>I really feel we should expand the language in Step 3.1 along the lines
>I suggested to clarify how this serialization is expected to happen.  
>
>On your second point, can't the app do this by defining an appropriate
>type value to be carried in the Type attribute?
>
>Blair
>
>
>
>-----Original Message-----
>From: edsimon@xmlsec.com [mailto:edsimon@xmlsec.com] 
>Sent: Wednesday, September 19, 2001 3:00 PM
>To: Blair Dillaway; reagle@w3.org; Takeshi Imamura;
>xml-encryption@w3.org
>Subject: RE: Minor comments on Section 4
>
>
>
>Blair wrote
>
>>we're ambiguous in Step 3.1 about who is responsible for serializing 
>>the data.
>>
>
>I don't think the text is ambiguous because all the steps starts out
>with "the encryptor must:".  Hence all the steps are the Encryptor's
>responsibility unless otherwise specified.  Unless there is a good
>reason otherwise, I wouldn't want the application to have the handle the
>serialization of XML Elements and Content.
>
>On a related topic, for non-XML data where we require the application to
>do the serialization (because the Encryptor can't do arbitrary
>serialization), does it make sense to allow the application to provide
a
>hint in <EncryptedData> how the the serialization was done?  I'm
>thinking of the receiving end, where the Decryptor want's to
>de-serialize the data and wants to know how the serialization was done.
>
>Ed
>
>------------------------------------------------------------------------
>-----------------------
>Ed Simon
>XMLsec Inc.
>
>Interested in XML Security Training and Consulting services?  Visit
>"www.xmlsec.com".
>
>
>

-----------------------------------------------------------------------------------------------
Ed Simon
XMLsec Inc.

Interested in XML Security Training and Consulting services?  Visit "www.xmlsec.com".

Received on Wednesday, 19 September 2001 19:49:00 UTC