Re: FYI, resolution of "Digest" issue

Paul, there is more here (and has been going on behind the scenes) than
you know.  I'll try to summarize the situation as I see it from the mail
that has been flowing between the area directors, Larry and myself.

The basic problem is a procedural one (that Keith Moore, Harald
Alvestrand, Larry and I might be held responsible for): last calls
were issued on the documents independently, and they are not written
to interdepend in appropriate ways.  With 20-20 hind sight, we should
have issued a single last call with covering explanation, and done the
wordsmithing slightly differently.

The IETF and IESG get very upset if any normative requirements (i.e. MUSTs,
SHOULDS, etc.) change between the final draft and the RFC; after all,
that is what is Last Call is all about.  Any changes should be entirely of
an editorial nature.

So, we have to ways to fix this.

1) Issue new drafts for both documents, and have to issue a new IETF
last call.  Once that is done, the IESG does its thing.  This would
take a month or two. (or three)....

2) Have the IESG immediately issue the RFC's for both HTTP/1.1 and
Digest.  Go ahead immediately with issue a separate (about 1 page) draft
that states the normative requirements we all intend(ed), forward to the
area directors instantly, and do IETF last call on it.
This would take a month or two. (or three)....

Both 1) and 2) take the same length of elapsed time to the same
desired end state.  1) causes us to wait months more for any IESG
action (i.e. we don't get RFC's immediately), and 2) gets us the announcement
of the IESG action of last Thursday approving both our existing
documents issued, and then the tiny RFC gets us the normative requirements
we want at the same elapsed time that 1 would have taken.

So the right outcome in our minds (Larry, myself, Keith, and Harald)
is 2), so that more time does not elapse for proposed standard on HTTP/1.1. 

By going ahead with the existing documents we get Proposed standard immediately,
without taking significantly longer elapsed time for the requirements we've
been discussing.

Larry didn't make clear in his mail what our options are procedurally, in
the current process state.

And we'll pull all this together into the Draft version of the document(s),
so that this strange short RFC we'll end with won't matter thereafter.

Hopefully, this will clarify the situation to everyone.

Aren't standards processes fun? :-)
				- Jim

Received on Thursday, 29 August 1996 19:04:35 UTC