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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf