Subject: Silly analogy on alternate features/ configurations

From: John C Klensin <[email-masked]>
Date: Wed, 17 Feb 1999 09:34:47 -0500

Suppose there is a company which decides, in the name of 
security, not only to run NAT boxes at it boundary firewalls, 
but to actually run a different basic transport protocol 
internally than is used on the public Internet.  Let's call 
them  Security National Associates.   At the boundary between 
the public internet and their environment, they run, not merely 
a firewall and/or address translation gateway, but a full-scale 
protocol translation gateway.  Within their native environment, 
they run email clients that use unique protocols at the mail 
transport, header, and message body format/identification 
levels: it is the responsibility of the protocol conversion 
gateways to straighten all of that out before injecting the 
messages into the Internet.

Questions:

(i) Regardless of biases about different types of network 
technology and the advantages of end-to-end systems, does anyone
wish to argue that the SNA company should be prohibited by a 
standard from setting its network up that way?  Or whether there 
is any reason to believe that, were the IETF to issue such a 
prohibition, the company would pay any attention at all?

(ii) Does anyone wish to argue that the IETF should prohibit 
mail systems of the variety described on such a private, 
isolated, network or that, if it did, anyone would pay any 
attention to it?

And now come the harder questions:

(iii) Does anyone want to argue that the hosts _within_ that 
environment are "conforming Internet hosts"?  Note that a "yes" 
answer puts you at serious variance with RFC 1122 and 1123, 
which basically define what a host needs have on it, and how it 
needs to behave, to be considered a conforming internet 
host.  Those requirements start with running TCP and IP and ICMP
and then move up the protocol stack to insisting that such hosts
use DNS for name to address resolution, use SMTP, including MX 
resolution, for sending mail if they do that, etc.   If they 
don't, they may be perfectly good hosts on the SNA network, they
just aren't "internet hosts".

(iv) Does anyone want to argue that 821bis must have enough 
flexibility (and/or weak enough rules) that the mail systems on 
such hosts should be considered conforming to 821bis... in spite
of the fact that they are not running anything resembling SMTP, 
are not using anything resembling 822 headers, and are not 
transporting the data over TCP?

Is there some reason why we are wasting time on this?  Does 
anyone have an interest in delaying DRUMS completing its work?

     john

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Feb 1999 21:26:33 -0500 (Eastern Standard Time)

On Wed, 17 Feb 1999 20:04:08 +0000 (BST) Philip Hazel 
<[email-masked]> wrote:

> You have said it, not I! *That's* the phrase that will keep lots of us 
> happy. I don't mind a "conforming Internet host" having to support SMTP 
> and MX resolution etc. In fact, I would argue in favour of that 
> position. What I and others are arguing is that a "conforming *SMTP* host"
> shouldn't necessarily have also to conform to the DNS/MX rules in order
> to claim to be conformant to SMTP (only).

Sorry.  821, if you recall, provided for SMTP over several 
different things, some of them distinctly "not internet".  
For 821bis, I got very clear instructions to remove all of 
the alternate transport stuff and other non-Internet 
things and to move things in a direction I'd describe as  
   "SMTP" == "Internet SMTP" == 821bis
Whatever you want to do "somewhere else" is, in that 
context, your problem.

I can go back and change it if there is clear consensus, but
what you are suggesting is a reversal of a trend established
in 1123.   

> Er, no, of course not.

Seems to me that your position above is halfway down the 
slippery slope to exactly this position.  1123 says that, 
if one is an "Internet host", then one uses the DNS and MX 
resolution.  So, in your world, something that is off on a 
LAN and therefore is somehow using SMTP but isn't an 
Internet host gets to claim 821bis conformance.  Where do 
you draw the line?

> The only reason I am "wasting time" is because I see at the very least a 
> a terminological problem being generated here - a problem that will be
> with us until 821bis gets revised, which, on past form, won't be for at
> least 10 years. The problem stems from combining the definition of an 
> "on the wire" protocol with a (partial) definition of the way an 
> "Internet host" should behave, all in the same document. 

But combining the email handling and transport portions of 
821, 974, 1123, and 1869 and associates was precisely the 
charter of this part of the DRUMS work.  It is a bit late 
to change that.

> I don't. If there isn't clear consensus (as there appears not to be) 
> then DRUMS has to move on. I can live with it. I just reserve the right
> to say "I told you so". Equally, you may say the same to me if my
> prognisis proves to be unfounded.

That is, IMO, quite reasonable.

    john

---

From: Philip Hazel <[email-masked]>
Date: Thu, 18 Feb 1999 09:21:06 +0000 (BST)

> Whatever you want to do "somewhere else" is, in that 

So, basically, "SMTP" is being defined as "SMTP over TCP/IP with MX 
resolution". There is a long history of acronyms being retained and what 
they stand for changing, so I guess we could change the M to MX and the 
T to TCP/IP. :-)

The problem is getting the naming right. I would like to see separate
names for (a) the protocol on the wire (any wire), (b) the protocol on a
TCP/IP wire, (c) the protocol on a TCP/IP wire with MX resolution. The
last is probably "fully compliant Internet mail host", but lack of
generally understood names for the others causes confusion. If a private
network uses X.25 to connect hosts, and they use all the commands/responses 
of 821bis to transfer mail, then I would almost be prepared to bet (and 
I'm not a betting man - never even bought a lottery ticket) that that 
*will* be described as "SMTP over X.25" and no amount of anybody 
pointing out that this isn't the case will prevent it. Human language is
like that, as Humpty Dumpty pointed out.

> That is, IMO, quite reasonable.

Life is far to short to continue this. I've tried to make my point 
several times. I won't say any more.

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

---

From: Philip Hazel <[email-masked]>
Date: Wed, 17 Feb 1999 20:04:08 +0000 (BST)

On Wed, 17 Feb 1999, John C Klensin wrote:

> environment are "conforming Internet hosts"? 

I agree it is all distinctions of terminology, and that people are going 
to do their thing whatever the RFC says.

Er, no, of course not.

> Is there some reason why we are wasting time on this?

>  Does

---

From: Brad Knowles <[email-masked]>
Date: Sun, 21 Feb 1999 08:25:16 +0100

>to claim to be conformant to SMTP (only).

    Problem is, the IETF only defines Internet standards, and SMTP is an
Internet standard for the transmission of electronic mail.  Therefore, in
some sense, to speak SMTP implies that you are an Internet host, and
therefore that you must follow the DNS/MX rules, etc....

    IMO, Bart Schaefer has the right idea.  We need to separate the bare
prototocol itself (which can be used in many different contexts, not just
the "Internet"), from the operational requirements of how that protocol
must be implemented on the Internet.

    Unfortunately, this also creates a rather artificial distinction
between this Macintosh PowerBook G3 that has all the appearance of being
"on the Internet" regardless of whether I am dialed-in with a modem or
connected with Ethernet to a network that is one hop away from the
backbone of the ISP I work for.

    Perhaps the best solution is to create a "Restricted SMTP" or "rSMTP"
[0] that does not require the use of DNS, MX records, etc... and is
intended to be implemented by less intelligent clients, and to
distinguish between that and the "full SMTP".

    We would have to define rSMTP in some section of the document, and
then add another section that describes what additional things
MUST/SHOULD/MAY/SHOULD NOT/MUST NOT be done in order to be fully
compliant with the more complete unrestricted standard.

    MUAs would be expected to be only rSMTP compliant, and many dumb
gateways (e.g., to LAN e-mail programs such as cc:Mail and Microsoft
Mail) would likewise only be rSMTP compliant.

    I think this is what we're all dancing around, we just now have to
find some language and some intelligent way to structure the document
along these lines.

[0] Someone (I don't recall who, I apologize for forgetting) suggested a
"cSMTP" that would be implemented by "clients".  Since this term has been
used in a rather confusing manner in the past, I would suggest getting
away from that word in the description of the protocol itself, but the
idea is otherwise essentially the same.

-- 
  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

---

From: Dave Sill <[email-masked]>
Date: Mon, 22 Feb 1999 09:45:35 -0500 (EST)

Philip Hazel <[email-masked]> wrote:
>
>What I and others are arguing is that a "conforming *SMTP* host"

I agree.

-Dave