----- Original Message -----
From: "John C Klensin" <john+smtp(_at_)jck(_dot_)com>
Matti,
I've got two reactions to your suggestion. The first is that it
should be a separate BCP: 2821 is already too long. Adding
this type of text to it would just further discourage reading,
and "not reading" is the problem in the first place.
The second is, while your list is excellent, virtually every
point could be summarized by saying "before doing an SMTP
implementation, it is really important to RTFM (RTFStandard?),
because some things aren't as obvious as you think they are and
are mostly there for good reasons". That is, for me at least,
profoundly depressing.
John, would it make sense to have a consolidated guide, similar (but not
the same) to RFC 1113 for "host requirements?"
I often find the following IMC web page extremely useful as a quick summary
site as a quick reference to the various mail related guides:
http://www.imc.org/rfcs.html
General Comment regarding the RFC style and RTFM:
Although I can appreciate and understand why Postel molded the RFC as he did
(by reading the history), one of the difficulties I see common with the RFC
style is many times it gets the target audience mixed up. So it can often
be difficult (or not obvious) to extract information for one or it may be
too much for the other to grasp.
The RFC are often written as Functional or Technical specifications or
blends of each. Functional Specs basically outline a model, idea or
protocol. Technical Specs spell out the protocol and implementation
details.
Not a real big deal, but this could explain why you have ambitiguity at
times.
Here is a recent example of functional vs. technical spec conflicts which
ironically touches base with the syntax issue discussion we had here
regarding "Mail From:SP". This was just submitted today:
Title : OPES SMTP Use Cases
http://www.ietf.org/internet-drafts/draft-ietf-opes-smtp-use-cases-02.txt
See the C/S SMTP session example in this draft and you will see what I am
talking about.
Great for the general modeling example and description, but you can see the
how a simple technical mistake can be generated when someone sees this in
the documents.
Also, a potential timeout discussion for OPES call out sinks is left out.
Probably not required at this level but it probably should pointed out in a
comment since it may be important in OPES SMTP Use Cases.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com