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(_at_)ietf(_dot_)org or ietf(_at_)ietf(_dot_)org 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf