Stef's suggestion

[[e-mail]]

>Take the new draft documents (EHLO, 8BIT, and SIZE) as concrete
>proposals, and accept or reject them.

Stef,
   An interesting suggestion, but one that I'm quite hesitant about.  The
difficulty I see, as I think we discussed privately some weeks ago, is
that things get lost in this process.  I have no problems with their being
dropped, but I think the WG needs to do that explicitly, rather than just
losing them.

   Since I haven't been able to study Keith's latest draft yet, and
suspect that the WG has reached consensus on the general extensions model
in draft-rose-extensions-03.txt, let me draw some examples from the 8-bit
area.

(1) This proposal changes the "8 bit transmission" model from one of
"client asserts that it is about to send a particular message containing 8
bit chars and gets server verification" to "server asserts that it can
handle 8bit messages from or two any source".  A great deal of discussion
during the WG's development period seemed to point to the necessity of the
former, especially for gateways into other environments, and that issue
has been raised again in the light of more recent discussions.  I don't
think it is reasonable to lose that position; the WG needs to explicitly
take a stance on it.

(2) This proposal changes the moderately detailed specification for trace
fields in RFC-ZZZZ to an overloading of the 821/822 "Received:...with"
phrase.   But it doesn't [re]define what is to be used with "with" in
saying "e.g., ... with binary-to-base64" (middle of page 5), nor does it
deal with the issue of registering these values (required in the existing
RFCs, although no registrations had occurred as of the last time I asked
Joyce).  It also changes the semantics of "with" from notions about
protocol or transport mechanism to conversion assertions.  Again, I don't
have any real problem with this, but do know, from long experience with
gateways that have to perform conversion, that being specific about what
is expected here (and expecting a lot) are quite important to any sort of
debugging.  So, if the WG wants to let that additional documentation and
specificity go, then it should explicitly make that decision.

(3) The second paragraph under 4.1 appears to explicitly legitimize the
sending of untagged (non-MIME) 8bit messages.  On the other hand, it
appears to prohibit the use of externally-available information (e.g.,
from agreements among consenting adults) to properly tag the converted
object.  We know that most untagged 8-bit stuff will be text of some sort;
we also know that there will be many cases in which the character set in
use is perfectly well known, e.g., at what RFC-ZZZZ and previous WG
discussions describe as an "enclave boundary".  RFC-ZZZZ prohibits
untagged 8bit messages, after long discussion about the interoperability
threats of letting them (encouraging them to) float around.  It also makes
explicit provisions for accurately tagging them should they occur, again
after long WG discussion.  Again, if the WG wants to abandon those
discussions and decisions and do that, it is fine, but the decision should
be explicit.

My guess, Stef, is that, for better or for worse, we are going to have to
reach some explicit agreements and then either modify the new draft
documents and write a new one or two or we are going to have to make
another pass through RFC-ZZZZ to incorporate some or all of the protocol
changes implied by the new documents.  Even if the WG goes with "prefer to
follow Stef's alternative", I know I've got enough editorial quibbles with
the new drafts to require at least one more iteration and I assume that
others do also.  Either way, while I don't see "a long time" in the future
of getting a WG product out, I don't see "this week" either.

 ---john