Subject: editing status of 821bis, draft -10.

From: John C Klensin <[email-masked]>
Date: Sat, 30 Jan 1999 12:58:04 -0500 (Eastern Standard Time)

Status report on 821bis, draft 10.

The following changes have already been incorporated into draft
10.  I recommend not spending further list time on them unless
someone wants to make a case for backing them out.

	 (i) A large series of typos, most of them caught by
	 Philip Hazel, corrected. 

	 (ii) Residual problems with references to mailboxes,
	 forward, and reverse paths in 4.1.1.2 and 4.1.1.3
	 corrected and some text, I hope, clarified.

	 (iii) Text added to 4.2.5 to talk about 5yz errors
	 after DATA.  This text should be checked carefully --
	 it is a proposal and may or may not reflect WG
	 consensus.

	 (iv) Upper bound on "seconds" has been changed to 60
	 (not 61), per list discussion.  Years are still
	 four-digits and will stay that way unless the list
	 discussion converges on something else.  The increase
	 to 60 seconds includes an explicit note about leap
	 seconds.

This list merely indicates what I've gotten to first and that
seemed quite clear.  It is not prejudicial to other discussions
now going on, one way or the other.

Two specific questions/comments:

(1) Dan, if there are additional places where the EHLO
preferences should be toned down as indicated by the minutes,
please tell me where they are.  If I can get a precise list,
especially if it comes with a minimum of gratituous noise, they
will be fixed; any omissions are errors, not intentional.

This situation is the reason I have asked several times that
people provide me with proposed text for changes, not just
principles.  I will try to fix things according to principles if
that is all I get, but I do make mistakes.

(2) In the process of working through one of Philip's
suggestions, I found something that I want to verify with the
WG.  In 4.1.1.3, there is some text, and an example, about
reverse-path stripping.  The text has been tentatively changed
to exactly reflect what 4.1.1.3 apparently intended to say in
-09 and earlier, s.t.,
   if a relay receives
       RCPT TO:<@hosta.int,@jkl.org:[email-masked]>
we prefer that it interpret it as (and send to)
       [email-masked] 
i.e., drop the source route.  But the text permits it to use the
route selectively, i.e., to send to hosta.int with
       <@hosta.int,@jkl.org:[email-masked]>
or to jkl.org with
       <@jkl.org:[email-masked]>
is that what is intended?   Of course, the counter-theory would
say that one should either use the source routes or not, but
shouldn't mess with them if they are used.

Finally, a general observation, which has been made before.
821bis, like every other internet standard (or documents heading
in that direction) is designed to specify standard behavior
under normal, on-the-internet conditions.  We could clearly
insert "unless the network crashes mid-operation" or "unless the
disk crashes" or "assuming the sun doesn't go nova" in every
specification-statement, but it wouldn't add much and would make
already-too-complex documents much harder to read.  Similarly,
there are situations in which the network architecture or
security requirements of particular enterprises require behavior
that is different from that of the specification.  Such behavior
isn't "prohibited", nor will the protocol police seek out and
jail the enterprise involved... it is just not standard.  

Now, if there are particular cases in which it seems useful to
repeat these points, I'm quite willing to do so... assuming
someone provides text and there is consensus around that text.
This is an area in which proposed text is particularly important
because, unlike several other areas where it has been suggested
that my biases are deliberately impacting my editing, I really
do not like a lot of this sort of thing to the point of probably
being incapable of spotting and properly altering the text in
the right places.

    --john

---

From: Brad Knowles <[email-masked]>
Date: Sat, 30 Jan 1999 19:34:03 +0100

>we prefer that it interpret it as (and send to)

    Ye, gods.  Talk about bringing up painful memories.

>shouldn't mess with them if they are used.

    IMO, strip it completely and make that a MUST.  These abominations
have been around *way* too long, and should have died years and years
ago.  It's time that we make a clean break with the past and just chuck
them out the window.

    I think I cleared up the worst of the rest of them at AOL when I
started doing reverse-path stripping and then refusal if the result isn't
resolvable.  There were plenty of people who were bitching (mostly old
BitNET sites using ancient programs), but I think we withstood the heat.

-- 
  These are my opinions -- not to be taken as official Skynet policy
 ____________________________________________________________________
|o| Brad Knowles, <[email-masked]>            Belgacom Skynet NV/SA |o|
|o| Systems Architect, News/mail/FTP Admin   Rue Col. Bourg, 124   |o|
|o| Phone/Fax: +32-2-706.11.11/12.49         B-1140 Brussels       |o|
|o| http://www.skynet.be                     Belgium               |o|
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
                The Sky is no longer the limit