- From: Joseph Reagle <reagle@w3.org>
- Date: Thu, 8 Aug 2002 15:00:28 -0400
- To: ned.freed@mrochek.com, Larry Masinter <LMM@acm.org>, Martin Duerst <duerst@w3.org>
- Cc: w3c-policy@apps.ietf.org, ietf-types@iana.org, ietf-xml-mime@imc.org, XML Encryption <xml-encryption@w3.org>
[I'm going to separate this thread into three replies: (1) the requirements on me for advancing the W3C document, (2) questions associated with the policy, and (3) comments on the actual registration -- which I'll also cc to the appropriate lists.] (3) The actual registration On Thursday 08 August 2002 01:58 am, ned.freed@mrochek.com wrote: > > As for the registration itself at > > http://www.w3.org/TR/2002/CR-xmlenc-core-20020802/#sec-MediaType-Registration > > > > I think there are several problems; most of which are of the > > form that the template makes references that aren't specific > > enough. For example, the 'charset' parameter is defined > > by reference to RFC 3023, but RFC 3023 allows for a wide > > range of usage of the 'charset' parameter, and it's not > > clear which this specification means; t > > The charset reference isn't to RFC 3023, it is to the charset parameter > defined in RFC 3023 for the application/xml media type. I believe that's > specific enough; if it isn't surely that would mean that the definition > for application/xml isn't specific enough either... As Ned and Martin point out, the intent is to express the fact that "application/xenc+xml" is XML, and consequently shares the same charset and encoding semantics/processing as that defined in RFC 3023. > > the 'encoding considerations' > > are clearly incorrect ("Same as charset parameter"?!?), > The encoding text looks like a cut and paste error to me; I suspect the > intent was to refer to the encoding considerations for application/xml > defined in RFC 3023. Correct, this was a cut and paste error and now remedied in the Editors' draft. Thanks! http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/#sec-MediaType-Registration $Revision: 1.234 $ on $Date: 2002/08/08 18:34:24 $ GMT > > the "Security Considerations" section contains a vague > > reference ('many of those described in') to a section > > of the document that doesn't actually do a threat analysis > > of the MIME type. Ned and Larry, can you indicate what you mean by this? I looked at other encrypted data formats included S/MIME and PGP; on this point I relied upon the example of application/pgp-encrypted [1] which references [2] in the same way I have done. I haven't been able to find any example of a "MIME type threat analysis". [1] http://www.rfc-editor.org/rfc/rfc3156.txt [2] http://www.ietf.org/rfc/rfc2440.txt > > The 'public specification' reference isn't Do you mean, "published specification" -- I'm not sure what you are referring to. > > clear which byte streams can legitimately be called > > 'application/xenc+xml' (do you mean 'an XML body that > > conforms to the Encryption Syntax specified in section 3 > > of this document', perhaps)... The specification says, "This media-type is only used for documents in which the EncryptedData and EncryptedKey element types appear as the root element of the XML document." I'm not sure how to be much more clear than that? -- * I will be on holiday the week of August 12th; I will try to return any calls or emails received the following week. Joseph Reagle Jr. http://www.w3.org/People/Reagle/ W3C Policy Analyst mailto:reagle@w3.org IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature/ W3C XML Encryption Chair http://www.w3.org/Encryption/2001/
Received on Thursday, 8 August 2002 15:01:03 UTC