RE: Minor comments on Section 4

You've got my intent.  Apps certainly can't be required to use an
Encryptor's serializer when present, but many probably will.  Those that
do shouldn't need to also create their own serializer.

I did a little word smithing, I wanted to work in the notion that an
Encryptor's serialier may not be suitable for the Application's needs
consistent with the discussion in 4.3.  How's this sound?

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 is using an Encryptor that does not provide a
serializer, the Application must provide this functionality.  Of course,
when using an Encryptor that implements a serializer suitable for the
Application's needs, it need not supply its own.

Blair

-----Original Message-----
From: edsimon@xmlsec.com [mailto:edsimon@xmlsec.com] 
Sent: Wednesday, September 19, 2001 4:47 PM
To: Blair Dillaway; reagle@w3.org; Takeshi Imamura;
xml-encryption@w3.org
Subject: 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 20:11:52 UTC