Problems with SMTP Service Extensions document

[Harald Tveit Alvestrand <harald.t.alvestrand@xxxxxxxxxxxxxxx>]

Hello,
I am now reading through the document set produced by Marshall et al.
If we are to replace the documents that were so painfully chopped over
in meetings over so many IETFs, they should at least get a fair amount
of picking of nits.

So, here are my headaches about Service Extensions:

1) What is the structure of a message in Extended-SMTP?
   Page 2, bullet 2, states that it is a header according to RFC 822
   and a body according to MIME, both written in US-ASCII.

   My problems with this:
   - It does not state whether it is the present, unextended version
     or the model under which all extensions have to behave.
     If the first, requiring MIME for the body is wrong.
     If the second, requiring US-ASCII for the message is wrong.
   - It is not conformant to RFC-822. The set of all (7-bit encoded)
     MIME messages is a *subset* of all possible RFC-822 messages.

2) Why do you say that a client SMTP MUST NOT cache information returned
   by EHLO? (page 3, last paragraph before section 4.1)
   In the old draft (chapter 7; the draft seems unpaginated) the
   text was "clients should, in general, not cache the information".
   Section 7 in general contains a lot of text about *why* one
   should do or not do things with EHLO replies. Sample section:

 <> Discussion:  EHLO Response Caching.
      A client is permitted to send whatever commands it likes if it does
      not send EHLO.  The worst that can happen is that it will get a
      rejection reply, and that can happen regardless.  With the
      exception of the size limits, the other capabilities can be
      thought of as optimizations--if you can use them in a particular
      situation, then things will work a little better, or smoother, or
      faster, or...  And it will be a rare case indeed that a host will
      start supporting a given enhanced feature and then stop supporting
      it.

      So caching and consequently making a "wrong" inference is not,
      unlike picking up a bad address from a DNS cache, a threat to much
      of anything.  It would be sensible (although not necessarily
      ideal) to operate on a basis that, if you don't like the answer
      you get, you don't cache it for very long at all; if you do like
      the answer, you keep it cached until such time as you get a
      rejection message.

3) Why do you require service extensions to be registered with a
   *standards-track* RFC only? (Page 4) I would have thought that registration
   was a means of achieving uniqueness. Look for instance at the
   registration of MIME body parts for ATOMICMAIL. No RFCs at all.
   In the MIME group, I think the reasoning went that "requiring RFCs
   for all of these would cause 1000 one-line RFCs to be written".
   It may make sense to require RFCs, but I see no big advantage in
   outlawing experimental RFCs for this purpose.

Yes, the draft is short. And probably understandable. At lest for
people who know what it was supposed to say.  BUT: We need to
carefully consider the details.

And - do we want the documentation of the reasoning behind those
details *in* the RFCs (making them longer) or *outside* the RFCs
(making them unfindable)?

Yours for a better mail service


                    Harald Tveit Alvestrand