[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

Yes indeed.

				Ned

> -----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