RE: draft-reagle-xenc-mediatype-01.txt

At 15:07 02/08/08 -0700, Larry Masinter wrote:
>What it actually says is:
>
># Optional parameters: charset
>
>#  Same as charset parameter of application/xml as
>#  specified in RFC 3023 [XML-MT] or the most recent
>#  specification that supersedes it.
>
>I admit I was a little confused on this one, and misread
>what it said. However, I don't understand
>"or the most recent specification that supersedes it",
>though, since a specification may supercede RFC 3023
>but not be appropriate for a reference to a particular
>section. None of the other references (to XML, DES,
>HTTP, MIME, etc.) have this qualification (that they
>refer to either the current version or anything that
>supersedes it.)

I agree with Larry that a moving target is a bad idea.
At W3C, we use (mostly) dated references, don't we :-).


>I would prefer if the reference were more specific about
>what was the "same": the same syntax, the same set of
>allowable values, the same recommendation for use of
>particular values, the same interpretation of defaults,
>or all of the above. Assuming you mean 'all of the above',
>you could be more explicit:
>
> >  Optional parameters: charset
> >
> >   The allowable and recommended values for, and interpretation
> >   of the charset parameter are identical to those given
> >   for 'application/xml' in section 3.2 of RFC 3023.

I'm not sure this is a good idea. It may lead to
questions such as 'and what about the default value,
is that different',... In other words, trying to list
up all the aspects in which the charset parameter for
application/xenc+xml is the same as that for application/xml
is a futile exercise; not listing any aspects and therefore
making clear that it's everything makes things clearer
and easier, I guess.


>I'm a little concerned about allowing arbitrary charset
>values for the entire application/xml+enc body, though,
>when any encrypted data are always UTF-8 encoded.
>Is it expected that the decryption algorithm do transcoding?
>Shouldn't the behavior of the processor with non-UTF-8
>encoded xml+enc bodies be discussed?

As far as I remember it, encryption does something like
the following:
1) Convert the necessary pieces to UTF-8 (from the encoding
    the document is in)
2) Encrypt the UTF-8 bytes
3) 'Textify' the result of the encryption by using base64

The decryption algorithm has to reverse these steps,
including step 1).

Allowing arbitrary charset values for application/xml+enc
is no problem. First, these values will apply to the
non-encrypted pieces of the document. (I can obviously
have something like <ds:KeyName>鈴木太郎</ds:KeyName>)
Second, once the encrypted part is textified as base64,
that text can still be encoded in us-ascii (which would
be covered by UTF-8) or in ebcdic or utf-16,...

So what I think may make sense is to add something like:

Note: The character encoding denoted by the "charset"
parameter is the character encoding of the resulting XML
document after encoding.


> > > > the 'encoding considerations'
> >
>http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/#sec-MediaType-Regi
>stration
>
>Again, I would prefer if the reference were more explicit
>about exactly was 'the same'.

Again, in general I would disagree here.

>You might even note that because
>encrypted data is encoded in base64 that encrypted data
>may have different encoding requirements than the data
>it replaces.

Good point.

># Published specification: this document.

I think that 'published specification: this document' is quite
dangerous. Assume somebody (that may be IANA) copies the registration
only for their own purposes. Then the reference is lost.

Regards,    Martin.

Received on Saturday, 10 August 2002 00:12:18 UTC