At 2:25 PM -0400 4/5/05, Scott Hollenbeck wrote:
As described in 2434, "IESG Approval", "though the IESG has discretion to request documents or other supporting materials on a case-by-case basis".
Right.
I'd really like to see some guidance in the document to describe what the IESG should look for. We're not atom experts, so it's going to be hard to determine what we should and shouldn't approve. Another paragraph will help future IESGs understand what they need to consider when reviewing requests.
Sounds reasonable. (I was erring on the side of not micro-managing the IESG.) Rob/Mark: please take a shot at some guidance for them.
At 1:04 PM -0400 4/5/05, Scott Hollenbeck wrote: >There needs to be both text explaining why IETF practice isn't being used
Good.
>and there needs to be an identified URI.
Bad.
> We don't need the URI *right now*, >but I want it in the document BEFORE I bring the document to the IESG for >review. Explanatory text will suffice for last call purposes.
Just to be clear: you are asking us to get the final URI for the namespace *before* the IESG has approved of the document. That means that it is really, really likely that some implementers will write and deploy code based on the draft that is going to the IESG, not waiting to see if the IESG demands changes for the wire protocol or the MUSTs and SHOULDs.
Do you really want that (he asks pejoratively)?
Hmm. Part of the problem is that there is no "normal" editing opportunity once the document is in the hands of the IESG. The editors can make changes as a result of IESG review, or in auth48, but those changes are supposed to be directed. Auth48 changes are supposed to be editorial only. This is clearly a normative situation.
Correct. I was assuming that, once everything else got approved, you would put a DISCUSS vote on the document because of the lack of final namespace. We then ask the W3C for it, get it, tell you, and make the change to the n+1 version of the document (along with the editorial comments that often come out of an IESG review). Does that sound doable?
The other part of the problem is that you're asking the IESG to review a specification that is incomplete without that little detail, and what's in there now looks very obviously non-standard. If you want to pursue a course of action that is similar to what was done with the IDN prefix [1] you're going to have to be a bit more clear about why the spec is incomplete.
I'm fine with that. And, yes, I was modelling this process after than one.
I'm OK with that, but please add text to the document to explain what needs to be done, who will do it, and when it needs to be done. Include a note that says "this paragraph to be removed by the RFC Editor" if appropriate. If this all means that the URI will be provided to the RFC Editor when they ask for it to finish the document, fine -- just say so.
My preference is that the namespace be minted and included between the time that all other issues are cleared and when it is sent to the RFC Editor. In retrospect, we could have done that for the IDN spec as well. Does that work for you?
--Paul Hoffman, Director --Internet Mail Consortium
