In addition, the registrant should (re?)read section 7.1 of RFC 3023, and strongly consider referencing that document. - dan -- Dan Kohn <mailto:dan@dankohn.com> <http://www.dankohn.com/> <tel:+1-650-327-2600> Essays announced on <mailto:dankohn-subscribe@yahoogroups.com> -----Original Message----- From: Keith Moore [mailto:moore@CS.UTK.EDU] Sent: Tuesday, October 30, 2001 09:44 To: owner-ietf-types@dokka.maxware.no Cc: ietf-types@iana.org Subject: Re: Registration of MIME media type application/vnd.nokia-mrv+xml there are lots of problems with this proposed registration. it doesn't say anything at all about what MRV document is, nor does it include a reference to the specification. as such the content type is ambiguous. the encoding considerations section is poorly worded. I'm not sure what a "a 7bit character set with an IETF character encoding mechanism" is. it would be sufficient to say that these documents need to be encoded in base64 for transmission over text-based email. the security considerations section is vague. I can't tell what is meant by

Authentication: Optional part of a Digital Rights Management system in which MRV is used.

but any system which incorporates DRM is likely to have considerable security risks - including that identity of the reader will be inappropriately disclosed or leaked to other parties, or that there are circumstances under which a reader will be denied his legal rights to use the document by the DRM system (for instance, when fair use rights are violated). these risks need to be analyzed and disclosed.

Threats: The MRV MIME content type definition provides for the inclusion of arbitrary content information. Administrators for MIME implementations that support this content type SHOULD take every standard precaution to assure the activation of MRV content is NOT automatic, but is only performed after confirmation by the recipient. In addition, administrators may want to perform virus scans of MRV content information.

this provides no information about how such threats may be ameliorated. furthermore, it is difficult to see how such threats could be ameliorated unless the specification for the encapsulation format were made public. 'confirmation by the recipient' is not sufficient to ameilorate such threats, because the recipient is not generally aware of the threats posed by the individual contents.

Interoperability considerations: Implementations that have support for the mandatory features of this content type will greatly increase the chances of interoperating with other implementations supporting this content type. Conformance to this content type requires an implementation to support every mandatory feature.

that's a meaningless statement in this context. this application should be denied or delayed until there is a published specification which may be reviewed, and until the security risks are adequately documented. Keith