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

[Leon.Hurst at nokia.com]

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 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.
LH> Agreed, will change.

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.

> 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?

> 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.

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. Thus, we
decided to use a vendor mime type which is appropriate in this situation and
does not require any approval. However, I would like to make the
registration
as meaningful as possible now with your help, given the constraint of an
unreleased
spec.

Thank you for your comments and I look forward to hearing what you think.

Cheers,
Leon.