[Top] [All Lists]

Re: More references in 2821bis

2007-04-01 11:33:19

John C Klensin wrote:

 [PCMAIL and IMAPv2]
part of the point here is that it was those older protocols
that marked the change being discussed, not the newer,
consolidated, IMAP and the newer POP which is somewhat
bloated relative to historical assumptions about its role.

More generally, you are making an assumption with which I
disagree.  I believe that, when a document is being produced
that updates or summarizes a well-established protocol,
information about the sources of differences and evolution is
important.   Putting things in context that was may not be
optimal for a completely new, "white room", implementation of
SMTP but it is often useful in reviewing an older implementation
or collection of modules to understand what must be updated and

You may, of course, disagree.

Not sure, depends on what 2821bis tries to be.  Is it "only" a
specification of ESMTP as is today, where interested readers can
(try to) reconstruct the history by following "obsoletes NNN" in
referenced RFCs ?

Or does it also try to explain how SMTP used to work in the past
starting with 821 and 822 ?  You certainly know that I proposed
to extract the history resulting in two smaller documents, so I'm
not against documenting history, quite the contrary.  And if you
prefer to do it in one document it's also fine, as a consequence
2821bis will be rather long.  I can manage (from a reader's POV).

BUT - if 2821bis is supposed to contain a history, then it should
also explain why the original concept of the <reverse-path>s was
removed, how that affected forwarding to third parties, how it
affected the use and later forgery of envelope sender addresses,
and ultimately killed the accept-and-bounce strategy as used in
the first decades of SMTP.  IOW the disaster we face today, it
would be at least somewhat different with RFC 821 reverse-paths.

Our definitions of "easy" also differ.

Maybe.  In the case of references I've adopted Scott's strategy
to use something like [I-D.2234bis] instead of [RFC 2234] when
it's likely that the referenced I-D gets its RFC number _before_
the referencing I-D.  Of course 2440bis is not yet approved, and
you can as well delay such cleanups until AUTH48.  I'd probably
forget such nits, and with an I-D as reference it's more obvious
that there was something needing a last minute check.  If you've
a different strategy to watch such details the [2440] is okay.

If 2440bis is approved, assigned an RFC number, and published
before 2821bis is published, it would, of course, be appropriate
to update the reference, but it is not, IMO, appropriate to do
so on the basis of an I-D.

I only happened to see that the IESG review for 2440bis started
on March 29, if you knew that already simply ignore my hint...

point to an I-D instead of to RFC 2440 would be a cosmetic
change and one that would move things in the wrong direction.'s not my idea to have references to _any_ I-D in the final
(published) 2821bis.  It's the SMTP specification.  It's one of
the most important IETF documents anybody could ever write.  It
is of utmost importance to get it right for readers today.

If you still want to try to convince people that an upgrade to
2821 is not worth doing unless it can be completely restructured,
I would personally recommend and request that you focus on that,
rather than trying to gain that effect by exhaustion.

So far I focus on fixing bugs, ambiguities, unclear terminology,
and anything I might stumble over while reading the I-D looking
for something else.  There are lots of places were 2821 silently
assumed that it's always possible to report problems later, and
we know that this is generally not more true today.  It's not
impossible to identify such issues, and make them more obvious
in the specification.  Of course that's exhausting, but you did
not like my proposals to cut this work into smaller pieces.

These have been fixed (although some of the resulting
constructions seem clumsy)

Thanks.  If the wording is clumsy I think you can always replace
the verb "bounce" by either "reject" or "return", and the noun
by either "reply code" or "non-delivery report" - it shouldn't
be too ugly, 821, 974, 1123, and 1869 don't use "bounce" at all.


<Prev in Thread] Current Thread [Next in Thread>