- From: <edsimon@xmlsec.com>
- Date: Thu, 20 Sep 2001 11:13:46 -0400
- To: Blair Dillaway <blaird@microsoft.com>, reagle@w3.org, Takeshi Imamura <IMAMU@jp.ibm.com>, xml-encryption@w3.org
Sounds fine to me, Ed -- Original Message -- >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". > > > ----------------------------------------------------------------------------------------------- Ed Simon XMLsec Inc. Interested in XML Security Training and Consulting services? Visit "www.xmlsec.com".
Received on Thursday, 20 September 2001 11:18:46 UTC