I recently had the please of reading and trying to use the I-D and it is in very good shape. My "implementation experience" input is:

* However robust the x. and x- discussion text becomes, it is essential that x. continues to be allowed so that well behaved applications can reject non registered types, without some other private agreement to use and x. instance.

OK.

* I understand that the standards track RFC for Standards Tree registration can be a dedicated RFC (start life as a dedicated I-D) OR included in the IANA considerations section of a "not dedicated" RFC. Whether or not the latter case is allowed, please state this explicitly (it's not so clear). I definitely support allowing the MIME registration to be bundled with a wider purpose RFC as surely that's what the IANA considerations sections are meant for anyway?

I would have thought it obvious that registrations can either be standalone or they can be part of a more general specification. However, I have no problem making this explicit and will do in the next revision.

* It would be helpful to state whether or not the "bundled RFC" (and a dedicated RFC) must use the syntax of the registration template or whether it is sufficient to cover all those items (in the whole RFC or specifically in the IANA considerations). As someone who has so far not registered any MIME types, I couldn't say from draft-freed-media-types-reg-01 whether the template is for a specific communication to IANA only (e.g. in an email).

Actually, this is explicit in the document: The section on publications requirements says "Such specifications MUST contain an appropriate media type registration template." I'll add a pointer to the actual template.

* Which bring me to my final request, for a registration-newbie (like me) the registration process is something of a black art and a newbie does not know what action they must take. Does RFC Editor queue entry OR standards track RFC publication OR email from RFC author actually initiate the IANA registration process for Standards Tree? (i.e. does the individual or the IETF have to translate the I-D/RFC into a request to IANA?)

This is also fairly explicit in the current document. The section on registration procedures says "The normal IETF processes should be followed for all IETF registrations in the standards tree, with the posting of an internet-draft being a necessary first step." It is considerably beyond the scope of this document to cover the process of moving a document from Internet Draft to RFC. Ned