- From: Martin Duerst <duerst@w3.org>
- Date: Fri, 09 Aug 2002 12:45:14 +0900
- To: "Larry Masinter" <LMM@acm.org>, <reagle@w3.org>
- Cc: <w3c-policy@apps.ietf.org>, <ietf-types@iana.org>, <ietf-xml-mime@imc.org>, "'XML Encryption'" <xml-encryption@w3.org>
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