On Fri April 1 2005 12:02, Ned Freed wrote:
FWIW, I have every intention of incorporating your comments on message/partial
into the next revision of the base MIME specification. I like to think we a
reasonable job overall on the initial set of security considerations, but this
is one we clearly missed.
As I mentioned to you and Nat, I think RFC 1344 covers the relevant
message/partial issues; unfortunately it hasn't been kept up-to-date
with the rest of the MIME RFCs, and has merely Informational status.
It very obviously has been ignored by developers, at the peril of those
developers' customers and the Internet at large. My comments to you
and Nat the following day regarding general MIME security issues I
believe addresses issues that have not yet been covered in any MIME-
related RFCs. And I'm confident that the issues will be addressed in
due course.
However my concern about the registration/commentary mechanism remains
that there does not appear to be a lightweight mechanism for
registering commentary on media type registrations issued as RFCs (2046
isn't a single type registration per se, and represents an unusual case
that probably isn't worth fussing over w.r.t. the draft under
discussion). For example, consider the potential problems that might
arise if the application/msword registration had been in an RFC [it is
not, but my reading of section 3.1 of the draft under discussion is
that if it weren't grandfathered it would have to be an RFC]; as I see
it there would be two possible approaches to adding security issues
comments:
1. issue a separate RFC addressing only the security issues, requesting
that the RFC Editor note that it updates the original RFC. Even
with such a note, that later RFC would likely be ignored by many
developers (as many have ignored 2231, which updates 2045; as many
have ignored updates to 821/822, leading to consolidation in 2821
and 2822 via DRUMS). [medium-weight, low-visibility mechanism]
2. issue a new RFC obsoleting the old one, and incorporating the
entire media type registration. In the case of application/msword,
I doubt that the "specification by example" would pass muster in a
new registration, and there are a number of new registration
template items that would have to be added. Somebody who wishes to
note security considerations (or e.g. to note a new value for the
"version" parameter) shouldn't have to jump through a lot of hoops
to do so. [heavy-weight, high-visibility mechanism]
Either type of RFC would take a minimum of 6 weeks for a mere peon
such as me (2-week types review plus 4 week Last Call period)
[according to RFC 2026, the IESG can request a variance (sect. 9.1),
but such a variance itself would require a Last Call of at least 4
weeks, so that would result in a longer overall process!], and in the
case of security considerations in particular, such a delay might be
inadvisable. An IETF WG could rush through an RFC with a 2 week Last
Call; maybe the media types review panel
(http://www.iana.org/numbers.html#M under Multipurpose Internet Mail
Extensions (MIME) Media Types) should be an IETF WG so as to be able to
take advantage of that. [maybe IANA is wrong about a panel, as I don't
see that in the draft under discussion]
As I wrote earlier, I don't have a specific lightweight mechanism to
offer, and if your plan remains to work out such issues on-the-fly as
problems arise, so be it. My immediate objective is to make my
concerns clearly known.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf