> On Tue March 29 2005 14:03, ned.freed@xxxxxxxxxxx wrote: > [I wrote] > > > Section 4.2.1 might benefit from a clarification of "text" as > > > communication in a natural language intended primarily for human > > > consumption (perhaps something like the description in BCP 18). > > > > Perhaps, but this text was very carefully crafted after a long > > debate and I don't feel comfortable changing it. > I recall the debate :-). BTW, I like the wording under the application > media types discussion, which may be sufficient to cover the case of > scripting (computer programming) languages. Good. It's always hard to know if the balance between specificity and generality is right in these things. > > > As "Mac OS" is a somewhat obscure platform, and as the registration > > > template provides for "Mac OS" "Type codes", a normative reference > > > providing information on those codes would be appropriate in > > > section 4.11. > > > > Suggestions welcome as to what an appropriate reference would be. > Hmmm. As we've discussed, that may be difficult. Unfortunately, > the vendor (Apple) doesn't seem to provide much useful information > (at least not online); the best I was able to find after hours of > searching was http://docs.info.apple.com/article.html?artnum=55381. OK, let's run with that. We'll see what the RFC Editor thinks. Besides, it gives me the chance to try out some xml2rfc features I just learned about on the xml2rfc list ;-) FWIW, the cite I came up with looks like this: <reference anchor="MacOSFileTypes" target="http://docs.info.apple.com/article.html?artnum=55381";> <front> <title>Mac OS: File Type and Creator Codes, and File Formats</title> <author> <organization>Apple Computer, Inc.</organization> </author> <date month="June" year="1993"/> </front> <seriesInfo name="Apple Knowledge Base" value="Article 55381"/> </reference> > IIRC you suggested http://cocoa.mamasam.com/COCOADEV/2001/09/1/11740.php. > It is -- as you noted -- unclear whether either of those URIs would be > acceptable to the RFC Editor > (http://www.rfc-editor.org/policy.html#policy.urls). On inspection I think this one is too much about file extensions and too little about file type codes to be useful. > By the way, a note to the effect that in order to avoid confusion, > four-letter words indicating lack of a code (e.g. "none") should > be avoided, might be advisable (since the codes themselves > consist of four characters). Good idea. Added. I also pointed out that there are similar concerns for file extensions. > > > The section 6 procedure (modified from RFC 2048 section 2.4) doesn't > > > seem to be effective in practice. While the additional step of review > > > by the media types reviewer might be an improvement, specific > > > statements regarding necessary IANA actions should probably be included > > > in the IANA Considerations section (the present IANA Considerations > > > section seems somewhat sparse). > > > > Well, if the goal is to make the procedure more effective, the last thing we > > need to do is nail it down more precisely. This has been shown over and over > > and over again to be an inhibiting factor in this general space, not a > > facilitator. > > > > What really needs to happen here is for someone to issue a comment on a > > registration and let the process run. If this turns up a problem we can examine > > it and amend the process accordingly. And if it doesn't, if it ain't broke... > > > > In any case, I am extrelemy reluctant to twiddle with this further in the > > absence of any "running code". > We've discussed this off-list based on a security-related comment on > a registered type; let's see what happens. Agreed. > > > Section 8 is somewhat unclear regarding standards tree registration > > > requirements. It states "Registrations in the standards tree MUST > > > satisfy the additional requirement that they originate from the > > > IETF itself or from another standards body recognized as such by the > > > IETF". Ignoring the part about "another standards body", there is > > > some ambiguity regarding standards tree registrations using IETF > > > procedures (i.e. published RFCs). The ambiguity arises from the > > > phrase "originate from the IETF itself", coupled with the fact that > > > "the IETF" is not a well-defined set. It is unclear whether or not > > > an individual submission RFC (as distinct from an RFC which is the > > > product of an IETF working group) qualifies for registration of a > > > media type or subtype in the standards tree. > > > > The vagueness here is intentional since it isn't clear who gets to make the > > call as to whether or not some other organization is a standards body or not. > Hmmm. That wasn't my concern. Rather it's about individual submissions > (as distinct from WG items) as standards tree registrations (a real > case that is in process, albeit under the current RFC 2048 procedure) > and the case of a revision to an RFC-based registration for the purpose > of adding comments (e.g. revising security considerations; see below). OK, now I understand. I don't think there is, or should be, a real distinction between WG documents and individual submissions. I expect the IESG, in its role "central scrutinizer", will look at individual submissions more closely (I know I did when I was on the IESG), but that's a matter of IESG policy, not something we should write down in a registration document. It is worth noting that in practice a fair number of media types in the standards tree have been come about through individual submissions. > > > Several of the references are amended by other RFCS (e.g. RFC 2231 > > > amends normative reference RFC 2045) or by errata maintained by the > > > RFC Editor. Additional references to those amending RFCs and > > > errata should probably be included. > > > > I disagree. I don't think a reference to RFC 2231 is necessary. I also think > > including references to errata is neither necessary or appropriate. Moreover, > > including them opens a huge can of worms as to whether or not an errata can be > > normative. This is a sleeping dog I'm going to let lie. > Well 2231 section 7 amends applicable parts of RFC 2045. > Unfortunately, some developers seem to be unaware of that amendment > or of the erratum to 2231 section 7. Hmm. I'd agree with this if there was a reference to this aspect of RFC 2045 in the current document but there wasn't one. OTOH, perhaps there should be such a reference in regards to how the ABNF in this document and the MIME relate to each other. I'll add one, which of course will require an informative reference to the RFC 2231 amendment. > And of course there's the > pending erratum for the 2045 ABNF affecting tspecials (thanks, BTW). No problem. Sorry it took so long. > My opinion regarding the "can of worms" is that an approved erratum > amends the affected RFC, but does not change whether the RFC reference > is normative or informative. It does, however, pose a problem > regarding how a reference to the errat[um,a] are/is presented in a > draft or RFC (again, I suspect I'm about to find out, as I have a > draft in process which references 2045, 2231, and errata). The RFC > Editor has a search engine that will display errata for a specified > RFC, but unfortunately it doesn't provide a URI that can be used to > reference the RFC-specific errata. If such a URI were available, the > cleanest solution would be to provide RFC-specific URIs of the same > category (normative vs. informative) as the referenced RFC. I'm going to take a wait-and-see appproach on this one... > > > A list of the specific media types which are affected by ownership > > > and change control principles in the draft should probably be included > > > in Appendix A. > > > > It might be nice but I don't think such a list is necessary, so unless someone > > else produces it I'm not going to add it. > I'm not planning to produce it. My concern is that if an existing > registration in the standards tree requires an RFC update to add a > comment, and the process for doing so gets bogged down in administrivia > such as new boilerplate required, changes required to the bulk of the > registration template (because it would be a new RFC and therefore no > longer "grandfathered"), etc. that such comments simply won't happen. > In the case of security-related issues, that would be a shame. I think > a reasonably light-weight mechanism for commentary in such a case (as > distinct from a registration template which is not part of a published > RFC, and which therefore (theoretically at least) could be amended by > IANA without much fuss) would be desirable, but I am at a loss to > suggest a specific mechanism. [our off-list discussion of > message/partial is an example of this specific scenario; it's not > merely hypothetical] 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. In any case, I'll be sending in an updated draft in a bit that incorporates all these changes. Thanks for reading this specification so carefully. Ned _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf