Subject: Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP

From: Bruce Lilly <[email-masked]>
Date: Mon, 28 Mar 2005 16:58:47 -0500

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
> [email-masked] or [email-masked] 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: [email-masked]
Date: Tue, 29 Mar 2005 11:03:25 -0800 (PST)

> contains a spelling error: "Acknowledgements" should be

According to two dictionaries I checked (Random House and Ultralingua) both
spelling are acceptable. But shorter is better so I'll switch to the shorter.

> "environments" and " This").

Fixed.

> Formatting seems a bit peculiar (e.g. huge empty space on page 5).

An unavoidable consequence of the "put each major section on a new
page" rule imposed by xml2rfc.

> names, sect. 4 w.r.t. additional name components). [see also RFC

I'll add a note to this effect.

> consumption (perhaps something like the description in BCP 18).

Perhaps, but this text was very carefully crafted after a long
debate and I don't feel comfortable changing it.

> Section 4.2.6 contains a spelling error: "labelled" should be

Again, your dictionary needs some new entries. Both spellings are perfectly
acceptable. I'll change it since shorter is better.

> as defined in the draft, which explicitly includes '%'. [draft

Yep, % is now reserved in parameter names at least. Forgot about that. I'll
remove it from the ABNF. This also will prevent it from being used  in a media
type name, but that's hardly a bad thing...

More generally, the intent here is to have an explicit list of what characters
can be used, as opposed to defining what's allowed by exclusion. The result is
deliberately intended to be more restrictive than what's actually allowed by
the RFC 2045 ABNF.

> Section 4.8 introduces "framed" content type, but that change is

Added.

> providing information on those codes would be appropriate in

Suggestions welcome as to what an appropriate reference would be.

> has been obsoleted by RFC 3986.

Updated.

> (regarding which section(s) of RFC 2026 is meant to apply) seems

It is not necessary for RFC 2026 to have text specifically dealing with the
case of appealing a reviewer decision. RFC 2026 specifies what's necessary to
appeal something, and that's sufficient. The fact that RFC 2026 also deals with
several specific sorts of appeals and why they might arise is not relevant.

I see no real reason to add anything here, but I'll make the reference specific
to section 6.5.4 (which describes the actual appeals procedure).

> section seems somewhat sparse).

Well, if the goal is to make the procedure more effective, the last thing we
need to do is nail it down more precisely. This has been shown over and over
and over again to be an inhibiting factor in this general space, not a
facilitator.

What really needs to happen here is for someone to issue a comment on a
registration and let the process run. If this turns up a problem we can examine
it and amend the process accordingly. And if it doesn't, if it ain't broke...

In any case, I am extrelemy reluctant to twiddle with this further in the
absence of any "running code".

> media type or subtype in the standards tree.

The vagueness here is intentional since it isn't clear who gets to make the
call as to whether or not some other organization is a standards body or not.
If the IESG and/or IAB wants this changed they can request a change with
specific text. Absent that I'm not touching it, as I believe I have told you
when you brought the matter up previously.

> consolidated in one place as mentioned above.

I disagree with making this change. The entire documement, more or less, is
about IANA considerations and the IANA considerations section says as much.

> errata should probably be included.

I disagree. I don't think a reference to RFC 2231 is necessary. I also think 
including references to errata is neither necessary or appropriate. Moreover,
including them opens a huge can of worms  as to whether or not an errata can be
normative. This is a sleeping dog I'm going to let lie.

> and change control principles in the draft should probably be included

It might be nice but I don't think such a list is necessary, so unless someone
else produces it I'm not going to add it.

				Ned

---

From: Joe Abley <[email-masked]>
Date: Wed, 30 Mar 2005 12:47:27 -0500

On 29 March 2005, at 14:03, [email-masked] wrote:

>> Section ١٣ heading in table of contents and in the actual section

"Acknowledgements" is the most common spelling outside the US. 
"Acknowledgments" is most common within the US.

>> Section ٤.٢.٦ contains a spelling error: "labelled" should be
>> "labeled".
>

"Labelled" is the most common spelling outside the US. "Labeled" is 
most common within the US.

Declarations of correctness depend very much on your frame of 
reference, I think.

Personally, I don't think it matters which spelling conventions are 
used in a document, but I think consistency (i.e. using US English 
spelling or rest-of-world English spelling throughout) is better than 
mixing.

The approach of choosing the spelling with the least number of letters, 
word-by-word, might well approximate the convention of using US English 
throughout. However, that goal (if chosen) might be better achieved by 
installing a US English dictionary and spell-checking the text.

The "spelling error" comments above are attributed to "The IESG". As 
someone who learnt to read and write outside the US, I would hope that 
there's no conscious ambition to enforce the us US English spelling in 
new documents.

Joe

---

From: Bill Fenner <[email-masked]>
Date: Wed, 30 Mar 2005 11:59:10 -0800

>The "spelling error" comments above are attributed to "The IESG".

"The IESG" authored the Last Call message to which the "spelling error"
comments were a reply.  Ned quoted Bruce's attribution with no
attribution (but it was indented with a ">" prefix.)

  Bill

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 31 Mar 2005 07:25:23 +0200

Joe Abley wrote:
 
> The approach of choosing the spelling with the least number
> of letters, word-by-word, might well approximate the
> convention of using US English throughout.

Not for "centre".  "Shorter is always better" was only a joke,
Ned is the author, he can pick any correct spelling he likes.

           Bye, Frank (back to LTRU and its en-GB-oed)

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 31 Mar 2005 11:16:45 -0500

On Tue March 29 2005 14:03, [email-masked] wrote:

[I wrote]
> debate and I don't feel comfortable changing it.

I recall the debate :-).  BTW, I like the wording under the application
media types discussion, which may be sufficient to cover the case of
scripting (computer programming) languages.
 
> Suggestions welcome as to what an appropriate reference would be.

Hmmm.  As we've discussed, that may be difficult.  Unfortunately,
the vendor (Apple) doesn't seem to provide much useful information
(at least not online); the best I was able to find after hours of
searching was http://docs.info.apple.com/article.html?artnum=55381.
IIRC you suggested http://cocoa.mamasam.com/COCOADEV/2001/09/1/11740.php.
It is -- as you noted -- unclear whether either of those URIs would be
acceptable to the RFC Editor
(http://www.rfc-editor.org/policy.html#policy.urls).

By the way, a note to the effect that in order to avoid confusion,
four-letter words indicating lack of a code (e.g. "none") should
be avoided, might be advisable (since the codes themselves
consist of four characters).

> to section 6.5.4 (which describes the actual appeals procedure).

6.5.4 discusses content and timing, but doesn't address to whom (IESG
as a body, IESG/IETF chair, IAB, ISOC).  I don't anticipate problems,
but I mentioned the issue for completeness.  I've had my say; I'll
leave it to you, the IESG, and/or other commenters to discuss and
decide whether to further tweak the wording.
  
> absence of any "running code".

We've discussed this off-list based on a security-related comment on
a registered type; let's see what happens.
 
> call as to whether or not some other organization is a standards body or not.

Hmmm. That wasn't my concern.  Rather it's about individual submissions
(as distinct from WG items) as standards tree registrations (a real
case that is in process, albeit under the current RFC 2048 procedure)
and the case of a revision to an RFC-based registration for the purpose
of adding comments (e.g. revising security considerations; see below).

> normative. This is a sleeping dog I'm going to let lie.

Well 2231 section 7 amends applicable parts of RFC 2045.
Unfortunately, some developers seem to be unaware of that amendment
or of the erratum to 2231 section 7.  And of course there's the
pending erratum for the 2045 ABNF affecting tspecials (thanks, BTW).

My opinion regarding the "can of worms" is that an approved erratum
amends the affected RFC, but does not change whether the RFC reference
is normative or informative.  It does, however, pose a problem
regarding how a reference to the errat[um,a] are/is presented in a
draft or RFC (again, I suspect I'm about to find out, as I have a
draft in process which references 2045, 2231, and errata).  The RFC
Editor has a search engine that will display errata for a specified
RFC, but unfortunately it doesn't provide a URI that can be used to
reference the RFC-specific errata.  If such a URI were available, the
cleanest solution would be to provide RFC-specific URIs of the same
category (normative vs. informative) as the referenced RFC.

> else produces it I'm not going to add it.

I'm not planning to produce it.  My concern is that if an existing
registration in the standards tree requires an RFC update to add a
comment, and the process for doing so gets bogged down in administrivia
such as new boilerplate required, changes required to the bulk of the
registration template (because it would be a new RFC and therefore no
longer "grandfathered"), etc. that such comments simply won't happen.
In the case of security-related issues, that would be a shame.  I think
a reasonably light-weight mechanism for commentary in such a case (as
distinct from a registration template which is not part of a published
RFC, and which therefore (theoretically at least) could be amended by
IANA without much fuss) would be desirable, but I am at a loss to
suggest a specific mechanism. [our off-list discussion of
message/partial is an example of this specific scenario; it's not
merely hypothetical]

---

From: [email-masked]
Date: Thu, 31 Mar 2005 09:14:11 -0800 (PST)

> scripting (computer programming) languages.
 
Good. It's always hard to know if the balance between specificity and generality
is right in these things.

> searching was http://docs.info.apple.com/article.html?artnum=55381.

OK, let's run with that. We'll see what the RFC Editor thinks. Besides, it
gives me the chance to try out some xml2rfc features I just learned about on
the xml2rfc list ;-) FWIW, the cite I came up with looks like this:

<reference anchor="MacOSFileTypes"
           target="http://docs.info.apple.com/article.html?artnum=55381">
   <front>
     <title>Mac OS: File Type and Creator Codes, and File Formats</title>
     <author>
       <organization>Apple Computer, Inc.</organization>
     </author>
     <date month="June" year="1993"/>
   </front>
   <seriesInfo name="Apple Knowledge Base" value="Article 55381"/>
</reference>

> (http://www.rfc-editor.org/policy.html#policy.urls).

On inspection I think this one is too much about file extensions and too little
about file type codes to be useful.

> consist of four characters).

Good idea. Added. I also pointed out that there are similar concerns
for file extensions.

> a registered type; let's see what happens.
 
Agreed.

> of adding comments (e.g. revising security considerations; see below).

OK, now I understand. I don't think there is, or should be, a real distinction
between WG documents and individual submissions. I expect the IESG, in its role
"central scrutinizer", will look at individual submissions more closely (I know
I did when I was on the IESG), but that's a matter of IESG policy, not
something we should write down in a registration document.

It is worth noting that in practice a fair number of media types in the
standards tree have been come about through individual submissions.

> or of the erratum to 2231 section 7.

Hmm. I'd agree with this if there was a reference to this aspect of RFC 2045 in
the current document but there wasn't one. OTOH, perhaps there should be such a
reference in regards to how the ABNF in this document and the MIME relate to
each other. I'll add one, which of course will require an informative reference
to the RFC 2231 amendment.

> And of course there's the

No problem. Sorry it took so long.

> category (normative vs. informative) as the referenced RFC.

I'm going to take a wait-and-see appproach on this one...

> message/partial is an example of this specific scenario; it's not

FWIW, I have every intention of incorporating your comments on message/partial
into the next revision of the base MIME specification. I like to think we a
reasonable job overall on the initial set of security considerations, but this
is one we clearly missed.

In any case, I'll be sending in an updated draft in a bit that incorporates all
these changes. Thanks for reading this specification so carefully.

				Ned