Re: Review of Media Type Specifications and Registration Procedures - draft-freed-media-type-regs-00

> This is a review of the Media Type Specifications and Registration
> Procedures - draft-freed-media-type-regs-00 [1] document.

> 3.1: The abbreviation "IESG" (for Internet Engineering Steering Group)
> was not introduced. While it's well-known, it might still make sense
> to introduce it.

The RFC Editor has rules for abbreviation handling I don't profess to
understand. After flailing about on this issue a couple of times I'd much
rather leave it to them to apply their secret sauce.

> 3.1: One occurrence of "can't" should be replaced by "cannot" for
> consistency reasons.

Changed.

> 3.2: It is unclear who "they" are in "Changes to the specification
> will be made at their request, as discussed in subsequent sections.":
> are "they" the product vendors, or whoever needs to interchange files
> associated with the particular product?

I'm not making this change. The term "their" clearly refers to the antecedent
"vendor or organization" in the previous sentence. It's the only possible
reference and the specifation would be less, not more, clear if this was
expanded.

> 3.3: For consistency reasons "ietf-types list" should be replaced by
> "ietf-types@iana.org mailing list", just as in 3.2.

Changed.

> 4.2: Albeit type and subtype names are case-insensitive, "Type and
> subtype names beginning with "X-" " should probably use a lowercase
> "x-", in consistence with 3.4.

Changed.

> It should also mention "x.", the other
> variant (it is mentioned afterwards, but without quotes).

No, that would be incorrect. x. is a facet, not a prefix like x-.

> 4.2.1: This section talks about parameters, however, parameters are
> only introduced in 4.3. Add a reference to 4.3.

No, parameters are introduced in RFC 2046 which is where media types are
formally defined. Repeating lots of introductory material from RFC 2046 in a
registration procedures document is both unncessary and undesirable.

> 4.2.1: "that allow the arbitrary mixing of text segments with opposite
> writing directions" might sound better if "opposite" was replaced by a
> sentence with "bi-directional text", or "right-to-left text".

Opposite is awkward but so are your suggested replacements. I changed opposite
to different.

> 4.2.1: "from such unreadable data as images, audio, or text
> represented in an unreadable form" could mention the term "binary
> data".

Except that would be incorrect. Data can be textual in nature and still be
unreadable. That's the entire point of text being a distingished top-level
type. It's also possible for material that requires the binary label to be
readable.

> 4.2.5: "This does not mean, however, that any application program name
> may be used freely as a subtype of "application"." OK, but what are
> the constraints then?

The ones specified in this document? I'm sorry, but this seems pretty obvious
to me; if you want a change made please suggest specific text.

> 4.2.5: One occurrence of "application/PostScript" should probably be
> replaced by "application/postscript" as in other sections.

Changed.

> 4.2.8: There is no link to RFC3023, whereas all other RFCs are linked to.

Sounds like an artefact of whatever text->HTML converter you are using. There
are two references to RFC 3023. Both are done in the XML source with xrefs and
both produce [RFC 3023] in the text output and a link in the HTML (which I
produced for the first time to check this).

> 4.2.8: Probably +xml, +der, +fastinfoset, and +json should each be
> enclosed in quotes.

OK.

> 4.2.8: +suffix should be enclosed in quotes consistently.

OK.

> 4.2.8: "The primary guideline for whether a structured type name
> suffix should be registerable is that it be) described by a
> readily-available description". There is a ')' too much.

Fixed.

> 4.3: "Similar behavior is encouraged for media types registered in the
> vendor or personal trees but is not required.". There is a missing
> comma before "but".

Fixed.

> 4.4: "isn't" should be replaced by "is not" in consistence with all
> other occurrences.

OK.

> 4.4: "The deposited specifications will meet the same criteria as
> those required to register a well-known TCP port". There should be a
> link to the document that specifies this process.

This actually brings up an important issue that needs to be addressed. The
requirement for depositing specifications for prs. types has led to essentially
none of them being registered. Vnd. is always used instead, even when
prs. would be more appropriate. This is not good.

And having just reviewed RFC 6335, it appears that the procedures have changed
out from under us and that the IANA doesn't do specification deposits any more
(assuming it ever did - I know of no case where one was requested). So this
whole paragraph really needs to go. I'm therefore folding the handling of
personal types into the preceeding paragraph and eliminating this one.

> 4.8: "The content consists of unrestricted sequence of octets." should
> probably be "The content consists of unrestricted sequences of
> octets.".

No, it's one sequence, not multiple sequences. And this is an important
distinction, as the existence of the framed encoding indicates.

I added an "an".

> 4.12: "Notice of a potential media type registration in the standards
> tree MUST be sent to the "ietf-types@iana.org" mailing list for
> review.". The email address should probably not be enclosed in quotes,
> in consistence with other email addresses.

OK.

> 4.12.3: "A web form for registration requests is also available"
> should probably be "A Web form for registration requests is also
> available".

I don't see why. "web form" isn't a proper name or title.

> 4.12.7: The last bullet point is repeated in flow text directly after
> the bullet point. Copy and paste error?

Yep. Fixed.

> 4.12.7: The flow text contains the additional phrase "The IESG
> determines whether or not a given organization qualifies as a
> standards body.". Therein, "standards body" should probably replaced
> by "Standards Body", as in the other sections.

No, it should go the other way. No need to capitalize this.

> 4.12.8: "The owner of a media type may pass responsibility to another
> person or agency by informing the IANA and the ietf-types list", the
> email address should be spelled out, in consistence with other
> sections.

OK.

> 4.13: 1): "Check IANA's registry of media type name suffixes", there
> should be a link to this registry.

Can't link to something that doesn't exist yet and we don't get to choose the
name. THis sort of stuff will be addressed as part of IANA actions.

> 4.13: 5) "(or pointer to document containing it)" should be "(or
> pointer to the document containing it)".

Fixed.

> 4.13: 1) [the one at the end]: "IANA checks the current registry for a
> entry with the same name" should be "IANA checks the current registry
> for an entry with the same name".

Fixed.

> 4.13: 5) [the one at the end]: "If Expert Review recommends
> registration registration" should be ""If Expert Review recommends
> registration" (double "registration").

Fixed.

> Best,
> Thomas Steiner for the Media Fragments Working Group [2]

Thanks for the very careful review, and especially for uncovering the issue
with prs. specifications. That one could easily have gotten by.

				Ned

Received on Wednesday, 7 September 2011 18:32:05 UTC