RE: Minor comments on Section 4

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".

Received on Wednesday, 19 September 2001 18:29:49 UTC