Hi all,

Looking through this document again...

I don't really know whether comments from http://www.ietf.org/mail-archive/web/happiana/current/msg00184.html have been considered (at least, no response from authors have been received so far), but here is what I see in the current version with respect to the issues these comments concerned:

--citing begins (my comments in-line starting with "MY>")--

Ned, all,

Some additional (to Julian's) comments.

In Abstract, it must be mentioned that the document obsoletes RFC 4288.

MY> Still relevant.

I find the current text in Introduction very confusing (or irrelevant), as it is very generic and not related to media types. It should be rewritten to make clear the goal of the doc. I also concur with Julian that Historical Note should be moved in the Introduction section.

MY> Now Introduction seems fine.

In Section 3.1: when specifying the procedures for registration media types in Standards Tree, you mentioned (in terms of RFC 5226): IESG approval, Specification Required, IETF Consensus, RFC Required with IESG Approval, i.e. 4 different registration policies. Whereas they serve a variety of possible cases, I think we would benefit from a single policy which would cover all of them. I suppose it is "Specification Required with IESG Approval" that would cover the following cases: (1) IESG-approved document, (2) specification of other standards body; registration undergoing IESG approval, (3) non-IESG-approved RFCs, registration of which also undergo IESG approval. The possible cases may also be discussed, though.

MY> Also relevant in this version.

Section 3.3: the "vanity" naming. I may be wrong cause it may be some sort of stylistic choice, but I actually think that "personal" is enough to characterize this tree. Whereas English native speakers would understand such naming, this would be frankly difficult for those who speak English as a foreign lang. I can't manage to find Russian or Ukrainian translation of RFC 4288 to prove, but I'm sure that the said formulation is applicable in English language only, and isn't appropriate for the international-scoped document.

MY> Relevant as well.

Section 3.4: this is what Julian has already mentioned for Section 4.2. APPSAWG is obliged to bring the draft deprecating x- to BCP, so if we revising the procedures docs, we need to take it into account. I propose you remove Section 3.4 and naming convention from Section 4.2 but put a note in Appendix B referring to the RFC-to-be. <later when="after reading reply to Julian's message">I think that if we produce new version of the doc we should take into account the current practice documented as BCP (and I hope it will get BCP). At least you should note that their registration is not absolutely prohibited; I also agree that in exceptional cases they can be registered, but only if wide use is demonstrated.</later>

MY> Current WG draft on deprecating x- says nothing on this, so I think we still should mention something in this document.  Let'as consider my above proposal.

Section 4.2: Shouldn't it explain the differences between RFC 2045 and the given ABNF?

Section 4.10: "Proposals for media types registered in the standards tree by the IETF itself MUST be published as RFCs.". Do you really mean "proposal"? Also, do we need to encourage publishing RFCs for vnd and prs registrations?

MY> This is ok in the current version.

Section 5.1: "Registrations in other trees MAY be sent to the list for review as well." Maybe SHOULD?

MY> Fixed; thanks.

Section 5.9: Do we need to leave mail-style lines in the template (I mean To: and Subject:)?

MY> (Now s5.7), and fixed in the doc.

Ibid:  Please move the para about MacOS file types into Section 4.11.

MY> Now moved, I see.

Section 6: s/RFC 3978/RFC 5378/ (and in References)

MY> This is fixed.

Sections 6 and 8: As your document sets up the registry for +suffixes, it should contain the description as required by RFC 5226, which it currently doesn't have.

MY> This comment still applies.

--citing ends--

These are my November comments, and so I suppose there could be more while discussing the document.

Mykyta Yevstifeyev