Subject: [secdir] Review of draft-denenberg-mods-etc-media-types-01

From: Rob Austein <[email-masked]>
Date: Wed, 28 Apr 2010 10:57:17 -0400

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This draft is a non-WG standards track submission whose sole purpose
is registration of four MIME types for use with XML schemata developed
by the (US) Library of Congress.  The document has a number of
nit-level issues which the sponsoring AD proposes to have fixed at the
RFC Editor stage, so I won't elaborate on them here, other than to
note that the document includes no Security Considerations section.

The MIME type registration templates that make up the body of the
document all reference the Security Considerations from RFC 3023,
which is a general (and, necessarily, rather vague and alarming)
discussion of potential security issues that might be found in any XML
document.  XML schemata are encoded as XML documents, so this
reference is correct, as far as it goes.  Nothing about XML schemata
in general or these schemata in particular.

Just about everything referenced by this document is external to the
IETF, it's either a W3C standard, work being done by the Library of
Congress, or in the case of the SRU specification, OASIS.  It's not
obvious to me why this document has been proposed for the IETF
standards track, given that MIME type registrations do not appear (as
far as I can tell) to require an RFC at all.  Informational status
might be more appropriate, but I'll leave that up to the IESG.

I don't see any security issues with the MIME type registrations per
se.  I don't know enough about the (non-IETF) protocols sitting behind
the proposed MIME types to have an informed opinion on them.

The one (non-security) part of this that I don't understand is why a
separate MIME types is necessary for each individual schema.  This
seems weird to me, but perhaps it's just the way things are done over
in Apps.  I don't consider this a blocking issue, just odd.

---

From: "Ray Denenberg, Library of Congress" <[email-masked]>
Date: Fri, 30 Apr 2010 11:59:48 -0400

From: "Rob Austein" <[email-masked]>
> separate MIME types is necessary for each individual schema.

I took this question up with the relevant implementers here. Each schema 
corresponds to a separate content type. And the fact is, this applies not 
just to these schemas in question but to even a larger set, the rest of 
which are in development now. For each of these content types there are 
applications already in use that employ content negotiation on the type (so 
some implementers have already implemented these mime types).

--Ray