Re: Draft registration for application/xenc+xml

On Friday 24 May 2002 13:22, Mark Baker wrote:
> On Fri, May 24, 2002 at 11:18:37AM -0400, Joseph Reagle wrote:
> > On Wednesday 22 May 2002 18:26, Joseph Reagle wrote:
> > >    @@ Should we include a redundant type parameter of the encrypted
> > >    object? @@
>
> I believe that this is more than a good idea, it's a necessity.
> Moreover, it should also be a required parameter.

Hi Mark, the XML Encryption syntax has the capacity to represent this 
information. (And it is OPTIONAL, so if we have it in both places, it would 
be odd to have it be required in the mediatype.) If you encrypt a PNG, the 
resulting instance might look like:

  <?xml version='1.0'?> 
  <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
   MimeType='image/png'>
    <CipherData>
      <CipherValue>A23B45C56</CipherValue>
    </CipherData>
  </EncryptedData>


> The reason I say this is because an xml-enc intermediary may want to
> encrypt some HTML that arrived as text/plain.  If it just gets
> encrypted, relabelled as application/xenc+xml, and then forwarded on,
> the fact that it was "text/plain" is now lost (it's not redundant),
> and the next intermediary to process it must guess the encapsulated
> content type.

My bias when presented with a situation where some characteristic of some 
resource can be described in multiple/orthogonal ways is not to be 
redundant, but have it represented as close to its "home." Consequently, I 
figure if you know enough about xenc to care about what's in there, read 
the xenc instance. However, I ask the question because I'm not sure how 
people architect their dispatching such that if an agent receives a xenc 
instance:

1. it calls the xenc processor and hands the instance to it,
2. but instead of waiting for the xenc processor to return the decrypted 
object and type, it can prep for the expected type while it's waiting.

I don't think this likely, and I'd rather not be redundant, but I honestly 
don't know.

Received on Friday, 24 May 2002 14:14:36 UTC