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". 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"). Formatting seems a bit peculiar (e.g. huge empty space on page 5). 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] 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). Section 4.2.6 contains a spelling error: "labelled" should be "labeled". 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] Section 4.8 introduces "framed" content type, but that change is not noted in Appendix B. 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. Section 4.11 refers to RFC 2396, which (according to the rfc-index) has been obsoleted by RFC 3986. 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. 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). 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. 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. 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. 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. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf