RE: Last call comments on draft-freed-mime-p4-03.txt

["Michelle S. Cotton" <cotton@icann.org>]

Ned,

The Vendor and personal types will still be expert review, correct?

Michelle
IANA

-----Original Message-----
From: iesg-admin@ietf.org [mailto:iesg-admin@ietf.org]On Behalf Of
ned.freed@mrochek.com
Sent: Monday, October 20, 2003 2:39 PM
To: Martin Duerst
Cc: iesg@ietf.org; ned.freed@mrochek.com; klensin@jck.com
Subject: Re: Last call comments on draft-freed-mime-p4-03.txt


> Dear IESG,

> This are my last call comments on draft-freed-mime-p4-03.txt.

> I have read the document and I am glad to see this in last call
> (ending soon) and hope it will move on to BCP soon. It will
> simplify the registration procedure for document types produced
> e.g. by the W3C, and will allow to keep the MIME type registration
> template together with the rest of the definition of the format,
> for the benefit of all the readers of the specification.

> I have found a few minor issues that (can and) should be fixed
> before publication:

> - IESG approval and IANA registration:

>    Section 3.3.2, IESG Approval, says: "Media types registered in the
>       standards tree MUST be approved by the IESG prior to registration."

>    Section 3.3.3, IANA Registration, says:
>      "When the registration is part of an RFC publication request, close
>       coordination between the IANA and the IESG means IESG approval in
>       effect submits the registration to the IANA.  There is no need for an
>       additional registration request in such cases."

>    It may be better to change "When the registration is part of an RFC
>    pulication request" to "When the registration is submitted to the IESG
>    for approval", which would include all registrations approved by the
>    IESG. My guess is that this is just an oversight, but it should be
>    checked with the authors.

I'll add some text to this section to make it clear it is also talking about
submissions from other standards bodies to the IESG. I don't like collapsing
the two cases, however, so I'll instead make it an A or B sort of thing.

I do note it would also be possible for standards tree submissions from
other standards bodies to go through IANA first. I detected some preference
for it to be an IESG first sort of thing so that's how I wrote it up, but
if folks want to change it that would certainly be possible.

> - 3.2.9: "stanards" -> "standards"

Fixed.

> - ibid: "require require" -> "require"

Fixed.

> - 3.6: "Nevertheless, the IANA has the authority to
>          identify obviously incompetent material and exclude it."
>       Change 'exclude it' to 'return it to the submitter for revision'.
>       'exclude is confusing; it would seem strange that in the case
>       of obviously incomplete security discussions, this material
>       would simply be excluded. The intent was probably that the
>       whole proposal would be excluded from registration, but if
>       that's the case, it should be said so.

Changed.

> - 3.6: Overall, this is worded a bit confusingly, and should be
>         cleaned up. There are the following problems:
>         - The intro says "Vendor and personal types will be
>              registered by the IANA automatically and without any formal
>              review as long as the following minimal conditions are met:",
>           but then the remainder falls back to overall requirements and
>           requirements for standards track.

Uh, no it doesn't. The requirements for vendor and personal types are quite
minimal, and amount to cusory documentation of any known issues. This falls FAR
short of formal review. Standards tree registrations go through the IESG and
will receive some amount of formal review. (Exactly how much will be for the
IESG to determine. I suppose it is conceivable the IESG won't ask for more than
what's required for vendor or personal tree registrations, but I think this is
fairly unlikely.)

>         - The last bullet point says "Registrations in the standards
>              tree MUST satisfy the additional
>              requirement that they originate from another standards body
>              recognized as such by the IETF."
>           This is obviously incomplete; add "or the IETF itself".

Added.

Since time is fairly short I'll submit a revised version with these
clarifications right away.

				Ned