> On Tue March 15 2005 16:25, The IESG wrote: > > The IESG has received a request from an individual submitter to consider the > > following document: > > > > - 'Media Type Specifications and Registration Procedures ' > > <draft-freed-media-type-reg-02.txt> as a BCP > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send any comments to the > > iesg@xxxxxxxx or ietf@xxxxxxxx mailing lists by 2005-04-12. > >[...] > Comments, in same order as the draft (though some as noted apply in > general or to multiple sections of the draft): > Section 13 heading in table of contents and in the actual section > contains a spelling error: "Acknowledgements" should be > "Acknowledgments". According to two dictionaries I checked (Random House and Ultralingua) both spelling are acceptable. But shorter is better so I'll switch to the shorter. > Historical Note, 2nd paragraph, 2nd line needs a period and additional > space character at the end of the first sentence (i.e. between > "environments" and " This"). Fixed. > Formatting seems a bit peculiar (e.g. huge empty space on page 5). An unavoidable consequence of the "put each major section on a new page" rule imposed by xml2rfc. > There does not appear to be any mention of case-insensitivity of > media type and subtype names (e.g. sect. 3 w.r.t. tree and facet > names, sect. 4 w.r.t. additional name components). [see also RFC > 1958 section 4.3] I'll add a note to this effect. > 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. > Section 4.2.6 contains a spelling error: "labelled" should be > "labeled". Again, your dictionary needs some new entries. Both spellings are perfectly acceptable. I'll change it since shorter is better. > Syntax of parameter attribute names is significantly changed from > that of RFC 2045 as amended by RFC 2231 and errata. Those RFCs > prohibited '%' and tspecials, while the draft specifies "reg-name" > as defined in the draft, which explicitly includes '%'. [draft > sections 4.2, 4.3] Yep, % is now reserved in parameter names at least. Forgot about that. I'll remove it from the ABNF. This also will prevent it from being used in a media type name, but that's hardly a bad thing... More generally, the intent here is to have an explicit list of what characters can be used, as opposed to defining what's allowed by exclusion. The result is deliberately intended to be more restrictive than what's actually allowed by the RFC 2045 ABNF. > Section 4.8 introduces "framed" content type, but that change is > not noted in Appendix B. Added. > 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. > Section 4.11 refers to RFC 2396, which (according to the rfc-index) > has been obsoleted by RFC 3986. Updated. > Section 5.4 references RFC 2026 regarding decisions made by the > media types reviewer, but RFC 2026 does not contain any text > specifically regarding media types review. RFC 2026 section 6.5 > discusses conflict resolution and has three parts, none of which > seem apropos to media type review (6.5.1 Working Group disputes, > 6.5.2 [IESG] Process Failures, and 6.5.3 Questions of Applicable > Procedure) [publication of the draft as-is as a BCP might raise > a question of applicable procedure]. At minimum, some clarification > (regarding which section(s) of RFC 2026 is meant to apply) seems > necessary. It is not necessary for RFC 2026 to have text specifically dealing with the case of appealing a reviewer decision. RFC 2026 specifies what's necessary to appeal something, and that's sufficient. The fact that RFC 2026 also deals with several specific sorts of appeals and why they might arise is not relevant. I see no real reason to add anything here, but I'll make the reference specific to section 6.5.4 (which describes the actual appeals procedure). > 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". > 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. If the IESG and/or IAB wants this changed they can request a change with specific text. Absent that I'm not touching it, as I believe I have told you when you brought the matter up previously. > Section 9 raises some issues which should probably be incorporated > into the IANA Considerations section so that IANA's roles are > consolidated in one place as mentioned above. I disagree with making this change. The entire documement, more or less, is about IANA considerations and the IANA considerations section says as much. > 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. > 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. Ned _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf