Post-facto reporting of media type security considerations

[Bruce Lilly]

On Thu October 21 2004 11:47, ned.freed at mrochek.com wrote:

> The IANA is no more capable or incapable than anyone else to write an RFC
> commenting on something. Whether or not such an RFC would get published is
> another matter, of course - such documents have been published in the past, but
> the practice of writing "commentary" RFCs has become less common in recent
> years, perhaps because the initial vetting and approval process has been
> improved to the point where it isn't nearly as useful to create such things.

Agreed about IANA's capability for additional commentary RFCs, which
is a somewhat different matter from superseding or obsoleting an RFC
which is in need of an update.  Some problems with commentary RFCs are
that it becomes difficult to keep track of exactly what has been modified
and in what way, and that they tend to scatter related information through
multiple non-consecutive documents, with little clue to the reader of the
original document that something has been changed.  That, coupled with
the relative ease with with documents can now be revised probably also
account for the decline in the number of pure commentary RFCs.

> Again, since the comments mechanism has never been used, whereas the ability to
> revise registrations has been used on quite a few occasions, I think this is a
> case of worrying about a purely hypothetical problem that seems unlikely to
> become real. We have a backlog of pernicious problems causing us considerable
> grief that need to be solved; I simply cannot see the point in spending time on
> this.

My initial queries were intended to gauge whether or not the mechanisms
were considered current and useful before making use of those
mechanisms.  I gather that the brief answer is that they are believed to
be largely current and useful, but have not been tested.  Initially I had
one media type in mind, defined in the core MIME RFCs.  While
subsequently looking for an indication that the commentary mechanism
might have been used, I found a rather obvious case of another media
type in the standard tree, registered via a text form rather than an RFC,
which is in need of an update.

I plan to make use of the commentary mechanism for those two types. In
the case of the text registration, I plan to request IANA to attach comments
to the registration.  I do not plan to do so for the core MIME RFC type
under consideration, and I do plan to copy the RFC authors (that would be
you Ned, and Nat Borenstein; I have already had some initial correspondence
with Nat regarding the media type in question, for which the relevant
issues are touched upon in RFC 1344, which has not kept pace with other
MIME RFC updates).  For the record, my queries and comments regarding
commentary vs. RFCs and RFC updates are not intended to indicate any
expectation of problems or to reflect on you or Nat, but instead arise out
of past experience regarding RFC updates (non-security-related and not
media type related) where authors have declined to consider revisions
due to discontinued interest in the subject matter; to reiterate, I do not
expect that to be the case with the issue at hand.