Re: [apps-discuss] Organisation of draft-freed-media-type-regs-00

[Ned Freed <[e-mail]>]

First of all, there's a serious structural error in the present draft - 
sections 4 and 5 have gotten merged because of a misplaced </section>. If you
look at the draft's predecessor, RFC 4288, you'll see what I mean.

I believe many if not most of your comments here are a result of this error on
my part, for which I apologize. I'm going to post a revised draft that corrects
this error immediately.

In addition to the problems you note below, this also messes up the structured
syntax suffix additions, which are supposed to be in a separat top-level
section.

> Overall, it seems like there's a fair amount of restatement between section 4
> and those that precede it.

Not really seeing it - could you be ore specific?

> I think many people will skip straight to section 4, believing it to be most
> relevant to them, and without reference to specific requirements in the rest
> of the document, they'll end up confused and sometimes mislead.

Section 4 is supposed to lay out the specific requirements in various areas for
media types. It is in no way, shape, or form intended to provide a step-by-step
instruction list for registering things, and I think it would be a HUGE mistake
to change it into something like this.

Extensive past experience has shown that attempting to instantiate requirements
via a step by step fashion is enormously confusing when something new and
slightly different comes along.

> Furthermore, section 4 isn't clear about the step-by-step procedure that's
> appropriate to various cases.

That's hardly surprising since section 4 was in no way intended to provide such
a checklist. And I am strongly opposed to trying to turn it into such a
checklist.

Section 5, OTOH, could benefit from more structuring as step by step lists, and
it has been the plan all along to do that. But before that happens there has to
be agremeent about what the steps are - especially for standards tree
registrations. This is the major open issue in the draft that we really need to
be talking about - in particular, whether or not the IESG remains "in the
loop", and if they are to be moved out, how far out.

It seems pointless for me to try and construct text for this when the  most
basic aspects of the process are still up in the air.

> For example, 4.12.2 and 4.12.4 both refer to a review, but it's not clear to a
> casual reader whether they're different reviews or the same one.

4.12.2 in particular is impossible to nail down without clarification of the
IESG's role. I agree, however, that the present text is completely inadequate.

> I think that this can be addressed by moving much of the content in section 4
> into the various subsections of section 3, in the form of concrete, numbered
> lists of steps to take to register the various kinds of media types.

I strongly disagree with this approach. The correct thing to be doing IMO is to
leave (the proper) section 4 mostly alone and focus on fixing (the proper)
section 5. As for how to do that, I think having separate itemized lists for
vnd./prs. and for standards trees makes the most sense. Attempting to do them
both at once and  calling out exceptions between the two processes is just too
confusing.

I also think that we need to stop pretending it's necessary or even all that
helpful to take vnd. and prs. to the ietf-types list prior to registering.
Almost nobody does that and it doesn't seem to cause any significant
difficulties. And OTOH, just suggesting you're really supposed to get feedback
from a mailing list is a big disincentive for a process that really doesn't
amount to anything but filling out a web form. So in the vnd./prs. case list
review should at most be mentioned as a "need help? here's where to go!" sort
of thing.

The use of mailing list review in standards tree registrations also needs to be
reviewed, but I confess to a certain ambivalence as to exactly how it should be
done.

> This might result in some duplication (which in the worst cases can be solved
> by references to new shared sections), but that's preferable to confusing
> readers.

> I'm happy to take a stab at this if the authors would like an illustration of
> what I mean (and they can provide XML source).

Again, I think most of the issues here are the result of my structural
fuckup. Again, sorry about that.

				Ned