Re: Data replacement

>> I don't have any concrete serialization, but one may want to serialize
an
>> element in UTF8 and then compress it...
>
>I think this could be done by providing the compression algorithm as the
>type. I believe that we said instead of providing a sophisticated
transform
>mechanism such as xmldsig, such content could be wrapped. So for instance,
>
>        <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
>         Type='http://www.example.org/xmlenc#zipCompressed'>
>          <CipherData>
>            <CipherValue>A23B45C56</CipherValue>
>          </CipherData>
>        </EncryptedData>
>
>When the CipherValue is decrypted, one might have:
>  <zipCompressed xmlns='http://www.example.org/xmlenc#zipCompressed'
>    Type="http://www.w3.org/2001/04/xmlenc#Content">
>       76fdsawerwae74747
>  </zipCompressed>

In this example, it is an element content that is processed.  So an
application may want an implementation to replace the element content with
the resulting EncryptedData element.  That is why I asked this question.
But if others don't think such an application is likely, I don't say any
more.

>> Yes.  But anyway, I think I understand what the spec says, and to my
>> understanding, the sentence in step 3.2 for encryption:
>>
>> For example, the data might be a serialization of an XML Information
Set,
>> set of characters, binary image data, or a compressed XML element.
>>
>> may be confusing because "an XML Information Set" and "a compressed XML
>> element" seem to hint an element or element content being encrypted.
>
>How about if I move the comressed bit and add the following e.g.,'s:
>
>For example, the data might be a serialization of an XML Information Set
>(MimeType="text/xml"), set of characters (MimeType="text/plain"), or
binary
>image data (MimeType="image/png").

How about "a document [XML, section 2.1]" instead of "an XML Information
Set"?  I think it is still confusing.

>We can not address compressed XML, or elsewhere in the document mention if
>one has a compressed element content one might use the approach I
specified
>above. I think we'd also want to point out that the following is not
>approriate as the MimeType is supposed to complement the Type attribute if
>both are available, it's not a transform mechanism:
>
>        <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
>         Type='http://www.w3.org/2001/04/xmlenc#Content'
>         MimeType='application/zip'>
>             ....
>        </EncryptedData>
>
>(The MimeType should not be read as "first do me then look at the
>corresponding Type." Type, MimeType, and Encoding should all be concurrent
>and accuration descriptions of the decrypted form of the CipherData.

I agree with you on this.  If we address such a case, we might have to
introduce another attribute.

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
imamu@jp.ibm.com

Received on Wednesday, 6 February 2002 00:03:38 UTC