[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Problems with SMTP Service Extensions document
- To: ietf-smtp <ietf-smtp@xxxxxxxxxxxxxxxxxx>
- Subject: Problems with SMTP Service Extensions document
- From: Harald Tveit Alvestrand <harald.t.alvestrand@xxxxxxxxxxxxxxx>
- Date: Tue, 8 Sep 1992 03:14:54 +0000
- X400-content-type: P2-1984 (2)
- X400-mts-identifier: [/PRMD=uninett/ADMD= /C=no/;920908101454]
- X400-originator: firstname.lastname@example.org
- X400-received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Tue, 8 Sep 1992 03:15:10 +0000
- X400-received: by /PRMD=uninett/ADMD= /C=no/; Relayed; Tue, 8 Sep 1992 03:15:01 +0000
- X400-received: by /PRMD=uninett/ADMD= /C=no/; Relayed; Tue, 8 Sep 1992 03:14:54 +0000
- X400-recipients: email@example.com
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
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
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