Registration of MIME media type application/vnd.nokia-mrv+xml

[Keith Moore]

> 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.
> LH> This is vendor specific MIME type. The spec are not ready for public
> consumption.

the spec doesn't have to be generally available, but you do need a spec.

> 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.
>
> LH> Security models surrounding DRM are complex and endless. Security is a
> spectrum of threats and (less than 100% bullet proof) counter measures.
> Additionally each security infrastructure is highly. All the above types
> refer to documents which have an orthoginal security implementation. Each
> implementor is free to implement security levels appropriate for there
> application.

this is not sufficient. it gives the user or implementor *no* idea of what 
kind of security risks he will encounter if he chooses to recognize this type.

> > 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.  
> LH> This is innacurrate. MRV and the other three types are non executable 
> content. The only risk posed is the standard risk of being a host for a 
> virus which is the same with all other document/MIME types?

your second statement doesn't follow from your first one.  there are
many other potential threats to recipients besides executable content - 
particularly for DRM systems, where privacy violations are quite common.  
and it is difficult to imagine how an implementor could write a virus 
detector/filter if he/she doesn't know how enough details of your format 
the virus is encapsulated  

> > 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.
> LH> It is meaningful when the specs are published.

perhaps you should wait until the specs are published before attempting
to register the content-type.  then it will be much easier to evaluate
the security risks, also.

> 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.
> LH> Do any of the answers I provide above help you? It is unlikely that the
> specifications will be published prior to MIME type registration. 

if you're not willing to provide any details of the nature of your content
type, nor of the risks that users will incur by evaluating this content-type,
I don't see what purpose is served by your registration.  

perhaps the registration should simply say that it is not possible to 
evaluate the risks with this content-type since no information about
the time has been disclosed; and users should therefore avoid using 
this content-type unless *they* have reliable information about the nature
and format of this content-type which enables them to evaluate the risks
associated with using it.

Keith