Re: Minutes of the Atlanta smtpext meeting

John, folks,

It is now obvious to me that the minutes of the meetings at the
plenary sessions were not nearly detailed enough.  I will work to
increase the detail of the discussions for the final versions in the
minutes.

A few observations.  I personally felt the meetings were well
attended, and reasonably well balanced, both between the Multi-part,
multi-media folks, the 8 bit character set users, gateway
implementors, and User Agent writers.  In the room were four people
who had at least partial implementations of the message format
document.  There were no attendees who have worked on implementations
of the SMTP extensions.

I will write this with a view towards the SMTPext mailing list, but it
is of interest to both mailing lists.  Please pardon my cross
posting, but this particular subject matter does not split easily
between the two mailing lists.

Let me use Klensin's note as a beginning.

The mailing list #consensus#:

John Klensin discussed at length the work of these meetings in
reviewing and re-assessing some of the work from the mailing lists.  I
have learned that mailing lists are not reasonable mechanisms to come
to consensus.  They are not a good means of gauging community
sentiment.  They are good for raising technical points and debating
the pro's and con's.  One of the purposes of the Atlanta meeting was
to affirm the progress on the mailing list in a room where true give
and take could be had.  Any person who has had to lead a group is
aware of the silent, contemplative, or frustrated attendee who has a
lot of real substance to contribute.  In a face to face meeting, it is
possible to draw these deeply interested attendees into a discussion
who either do not have the time to respond to the megabytes of mail,
or have the english language skills to generate long convincing
arguments in the face of megabytes a day of proposals.  I'm both
interested (Heck I chair the effort) and I speak English well, and
even I had to drop out of some discussions at some points!

> Some specific comments/questions:

 
> >There was a general feeling among many participants that a simple
> >extension to support only 8 bit textual data was not worth the
> >transition costs involved in upgrading the system. 

>  This was, of course, how the "let's find a simple and easy extension
> that supports transport of 8bit characters" effort got hijacked the
> first time.  I suggest that it may demonstrate that the decision-making
> and/or the WG chartering/defining models may be defective.

To explain further; I have never been convinced that the working group
has reached consensus on this work.  The only solid assertion I have
heard made is that folks want negotiation in any new protocol. I could
not feel comfortable with even this assertion.  Reality check!  No one
has implemented the new SMTP protocol. I do not know of anyone
implementing and experimenting with it. Many vendors ship products
which do not negotiate.

At the Atlanta meeting I wanted to know "The real story".  Here is the
story I heard.  1) The Europeans REALLY REALLY want to send their
stuff without encoding it.  They REALLY REALLY want to do this via a
negotiated option so they could have an assurance that the mail was
delivered as intended.  2) Existing software vendors, Prime, Sun, Dec,
and others not so visible do not feel that 8 bit textual data
transmission is worth the costs of modification.  This was strongly
asserted at the St. Louis IETF, and while the mailing list (led in
part by myself) went off and did a spec anyway.  Not a real convincing
situation.  3) Even the multi-part multi-media mail people could agree
with the assertion that the world would be a better place if Binary
data could be sent.

Given these points, it did not take a whole heck of a lot of
discussion to see that the 8 bit proposal was very and binary was very
attractive.  It was asserted that a binary mode would not be so hard
to do in either the protocol or in most MTA software.  

> >2) Interworking of 7 bit, 8 bit and Binary transport
> >...
>   From my perspective, a fine plan, since I see the critical tradeoff 
> not (as Mark Crispin does) as between burdens on gateways vs burdens on 
> UAs, but as a tradeoff needed to keep gateways "dumb".  I think keeping 
> gateways as dumb as possible--out of the business of redesigning and 
> restructuring the internals of messages--is essential to accurate 
> interoperability.
>   But this is an example of where, while I prefer the conclusion, the 
> decision at the IETF meeting directly contradicts the conclusion/ 
> discussion on the list.  So I'm not happy about the process.

Well, not really.  I assert that there was never really consensus,
just silence, where the last person(s) speaking agreed.  They were the
most assertive and prolific contributors.  This list has 100+ people
and I remember about 6 active people talking.  I know the positions
and the technical arguments.  The major positions were represented at
the meeting, and the positions were stated and defended.  No one
disagreed that nested encodings are more painful to implement than
single-level encodings.  No one disagreed that nested encodings are
possible on almost all know platforms.  People realized that some of
this complexity could be pushed off onto gateways, but after
exchanging sendmail horror stories for 30 minutes, it became clear
that having gateways mung messages was really sickening to many in
attendance. I will honestly say that after 2 hours of talking, a
strawman poll was taken which was just about evenly split between the
two camps.  At that point, I as the chairman took the power of the
chair to move on.  To avoid further delay in publishing the proposed
standard version of the message format document, I asked for a
compromise position.  This position will be clearly stated in the
revised minutes.

POSITION: The proposed standard version of the message format document
will allow nested encodings.  If in implementing this specification,
it is determined by the group that it is either technologically
unfeasible or excessively cumbersome, it will be dropped at the Draft
Standard stage.

Restated, lets call a truce, and let the internet tradition of
implementation and experimentation have a chance. I asked, and I
poked, and queried each person individually and while no person in the
room felt particularly happy, no one said they could not live with it.
We all knew that if Mark Crispin were there he would in fact have
objected in the strongest terms.  Mark, you were there in spirit.  You
still have your voice.  This is a move I made reluctantly to make
progress.  The Message Format document is a really good document, and
to hold it up for further endless debate was uncalled for.

> >3) Defining the ''new`` SMTP

There are lots of bugs and lots of new features.  Unless I'm mistaken
the group did not agree to implement but a tiny subset of the possible
features.  What the group did was instead to work on a framework to
gracefully evolve the protocol to do new things.   This does not need
to be any more complex than defining the action in response to unknown
verbs, though it could be significantly more efficient and elegant.

> Greg,
>   Could you clarify whether I/we should start fitting some of this 
> stuff, in particular the encapsulation stuff, into RFC-ZZZZ at this 
> point, or is that now a dead document to be replaced by some future 
> consolidation of "specific negotiation strategies"?  Did you get 
> sufficient signup from from the volunteers that you can predict when 
> these proposals will arrive and how we are going to figure out when we 
> have enough of them that it is time to start consolidating?

Several people volunteered to write up strawmen negotiation systems.
In many of the proposals discussed, they can be slipped painlessly
into the existing document.  I hope these proposals come soon.

Good night.

Greg Vaudreuil