Re: Updated Section 4.

--8<--
4.1 Encryption
 ...
 5. EncryptedData Processing
  1. ... implementations MUST be able to return the UTF-8 encoding of the
EncryptedData element to the application ...
  2. ... then the UTF-8 encoded EncryptedData element is always returned
to the application ...
-->8--

Why must we return the UTF-8 encoding of this element? This precludes
returning, for example, a DOM structure. I would remove "the UTF-8
encoding of" and "UTF-8 encoded", so toolkits can operate as they desire.

I don't understand why crypt and replace - a mere implementation detail,
and nothing to do with interoperability - should be REQUIRED. If I
implement element encryption from, for example, a SAX source, then I
cannot formally replace, and so I cannot be compliant with this spec.
I can provide the required data for the application to replace (e.g.,
a stream of SAX events) but does that actually comply with replacement?

Merlin

r/reagle@w3.org/2001.08.22/17:28:07
>Thanks Blair, it's now clear it was under-specified before! <smile/>
>
>I've had a go as well. I made a bunch of tweaks but I think most are for the 
>best. (If I missed something, please push back.) Some of the substantive 
>tweaks/questions I have are:
>
>1. On the replace, do we need to force the encoding of EncryptedData during 
>encryption? (Probably so....)
>2. Also, I thought we agreed that the encrypt and replace was REQUIRED to 
>implement but optional to use?


-----------------------------------------------------------------------------
Baltimore Technologies plc will not be liable for direct,  special,  indirect 
or consequential  damages  arising  from  alteration of  the contents of this
message by a third party or as a result of any virus being passed on.

In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
   http://www.baltimore.com

Received on Thursday, 23 August 2001 07:40:14 UTC