--On Sunday, 01 April, 2007 00:20 +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
Robert A. Rosenberg wrote:
I agree that it is mainly a Submit issue BUT since 2821bis
says that HELO is a valid way of initiating a SMTP Session
Obviously not for ESMTP, ESMTPA, ESMTPS, ESMTPSA, or the future
(experimental) UTF8SMTP set.
...
Is what you're looking for a pointer to chapter 2.2 in 3.2 ?
Or in 4.1.1.1 ? (I'm not sure what you consider as "HELO
section")
I think there's an xml2rfc trick forcing header level 4
sections like 4.1.1.1 into the table of contents.
maybe just noting that HELO is not compatible with Submit
That's not the case...
pointing at the Submit RFC for details
...but an informative reference to 2554bis somewhere in
chapter 7 is an idea if you think that the 4409 reference
isn't good enough.
The references might need more work: Maybe s/[13]/[14]/ and
get rid of [13].
Check these in context. [13] (RFC 1176, the original IMAPv2
spec) is used as part of a comment about historical development,
for which [14] (RFC 3501, IMAPv4r1) would just be inappropriate.
I'm mentioning this just to suggest that tampering with the
references is not completely straightforward... see below.
Chapter 7.1 is a mess. I think adding
2554bis is a job for chapter 7 (security considerations), not
for one of the EHLO sections. DKIM, EAI, SPF, and Alexey's
I18N I-D could also get informative references somewhere. Now
while I didn't see a slippery slope in John's IPv6 reply, this
"more references" idea should trigger all "rathole" alerts.
IMO 2821bis really needs a reference to RFC 3848 somewhere. As
"downref" if necessary (why on earth is 3848 a PS and no BCP ?)
FWIW, it is clear to me that 2821 went too far in the direction
of trying to provide a general "roadmap" for email protocols.
If we were trying to do a more significant revision, I think I'd
try to reduce the number of such references, rather than
increasing them.
Partially because of your rathole alert (with which I agree),
I'm personally disinclined to start down the path of trying to
significantly upgrade, or even fine-tune, the external
references (although, if people really want it and supply
specifics, I'll try to find time).
I believe that it is clearly desirable to get a document that
provides a good map of email protocols and a discussion of their
relationships. A decade or so ago, there were
commercially-published books that did a fairly good job of that.
However, things have changed significantly since and at least
the books that come readily to my mind are out of print. I
started on such a document as part of the newtrk/ ISD effort,
but never got very far with it because that effort was busy
collapsing. If someone would like to use that very preliminary
I-D as a starting point, I'd be happy to supply the source and
lots of encouragement.
john