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

[Mark Nottingham <[e-mail]>]

Thanks, Ned. I'll wait for the revised draft.

On 06/09/2011, at 6:10 AM, Ned Freed wrote:

> 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

--
Mark Nottingham   http://www.mnot.net/