Last Call Review of draft-denenberg-mods-etc-media-types-
review-denenberg-mods-etc-media-types-secdir-lc-austein-2010-05-03-00

Request Review of draft-denenberg-mods-etc-media-types
Requested rev. no specific revision (document currently at 03)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-05-04
Requested 2010-03-15
Authors Ray Denenberg
Draft last updated 2010-05-03
Completed reviews Secdir Last Call review of -?? by Rob Austein
Assignment Reviewer Rob Austein
State Completed
Review review-denenberg-mods-etc-media-types-secdir-lc-austein-2010-05-03
Review completed: 2010-05-03

Review
review-denenberg-mods-etc-media-types-secdir-lc-austein-2010-05-03

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.