Subject: Extension of SMTP in Terminal Mode

From: MAEDA toru <[email-masked]>
Date: Fri, 09 Feb 2001 14:18:16 +0900

Hi,

I described the extension of SMTP in the goals for Terminal Mode.

(3) One SMTP session for capability exchange/image transmission/confirmation.

If the extension is possible, capabilities exchange, image transmission and 
confirmation
will be done in one SMTP session as the classic fax session.
Followings  are my idea of the extension of SMTP.

(1) turn over
One of idea is to add turn over mechanism in SMTP.
In a SMTP session, the client sends the command and the server responds to 
the command.
Extend SMTP to support the turn over during the SMTP session
so that the server sends the command and client responds to the command.

(2) polling command
The other idea is add optional polling command.
The client sends the polling command to get receiver's capabilities and 
confirmation.
The server responds with it's capabilities or confirmation.

Are there any idea?

Regards,

Toru Maeda

--------------------
MAEDA TORU
MIE Development Div. 2
CANON Inc.
--------------------

---

From: Dan Wing <[email-masked]>
Date: Thu, 8 Feb 2001 21:52:46 -0800 (PST)

> so that the server sends the command and client responds to the command.

Supported today with ETRN, RFC1985.  Sendmail, PMDF, and a bunch of
other mailers support ETRN:

  % telnet proxy1.cisco.com 25
  220 proxy1.cisco.com ESMTP Sendmail 8.11.2/8.11.2; Thu, 8 Feb 2001 21:46:41 -0800 (PST)
  ehlo j
  250-proxy1.cisco.com Hello omega.cisco.com [171.69.26.42], pleased to meet you
  250-ENHANCEDSTATUSCODES
  250-EXPN
  250-VERB
  250-8BITMIME
  250-SIZE
  250-DSN
  250-ONEX
  250-ETRN                      <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  250-XUSR
  250 HELP

> The server responds with it's capabilities or confirmation.

What sort of capabilities are you looking to see?  Remember that SMTP
is not an end-to-end protocol -- it works hop-by-hop.  Examine the
"Received:" headers of this email that you're reading.  Every
"Received:" header is one more SMTP server that has processed the
message.

Outside of my company, there is no way to determine which IP address
actually receives the mail addressed to "[email-masked]".  And there is
no way to connect directly to my mailer from outside the company.  This is
by design and is typical of any company's firewalled connectivity to the
Internet.

SMTP can't be used for _immediate_ delivery of information.  For
_immediate_ delivery something else must be used.

In my experience the delay of email is much less than the delay of fax.  
It takes about 15-20 seconds to receive one page of fax, including dialed
digits, fax modem training speed, transmission time, etc.  Email is faster
-- this message will be distributed to several hundred recipients
mailboxes in far less than 20 seconds.  And that includes the time to
be processed by several SMTP servers on the way to each recipient's
mailbox.

-Dan Wing

---

From: Hiroshi Tamura <[email-masked]>
Date: Fri, 09 Feb 2001 16:03:11 +0900 (JST)

Dan,

At first, I would like to say,
I neither support his ideas nor oppose it.

> "Received:" header is one more SMTP server that has processed the

I think Maeda-san wants to use SMTP as end-to-end communication,
not as hop by hop. A sender(he) DIRECTLY connects to a receiver(her). I.e,
he specfies her IP address and her port number 25 and connects
to her(connect() in socket). She accepts it(bind(), listen(), accept()).

> _immediate_ delivery something else must be used.

Personally, I think so, now. Like T.38. But T.38 syntax is a little
diffcult, so, some people do not like it. This is one of the background
in his idea, I think. Am I right? Maeda-san.

Anyway, as a co-chair,
I keep watching this thread.

> be processed by several SMTP servers on the way to each recipient's

Oh, Timely delivery may be useful!
If so, Delivered by how many minutes is effective?

Regards,
--
Hiroshi Tamura, Ricoh Company, LTD.
E-mail: [email-masked]

---

From: Dan Wing <[email-masked]>
Date: Fri, 9 Feb 2001 08:28:48 -0800 (PST)

> to her(connect() in socket). She accepts it(bind(), listen(), accept()).

Yes, I agree that is Maeda-san's proposal.

> If so, Delivered by how many minutes is effective?

The sender should decide how many minutes of delay is acceptable.  The
existing DELIVER BY extension is quite useful for this - RFC2852.

-d

---

From: Graham Klyne <[email-masked]>
Date: Sat, 10 Feb 2001 14:28:55 +0000

>existing DELIVER BY extension is quite useful for this - RFC2852.

The timely delivery for fax proposal draft has just been updated.  In this 
latest version, it extends the DELIVERBY mechanism of RFC2852, and DSN, to 
provide a deterministic framework for timely message delivery, including 
confirmation.

The new I-D has been submitted, and should be announced very soon.

#g

------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<[email-masked]>    <http://www.mimesweeper.com>
                                 <http://www.baltimore.com>
------------------------------------------------------------

---

From: MAEDA toru <[email-masked]>
Date: Tue, 13 Feb 2001 20:29:25 +0900

Tamura-san

Thank you very much for clarification about my idea.
The extension of SMTP in Terminal Moden is based on the end-to-end SMTP 
communication
which I proposed in the previous mail.

>to her(connect() in socket). She accepts it(bind(), listen(), accept()).

Thank you, I wanted mean this.

>in his idea, I think. Am I right? Maeda-san.

T.38 has another difficulty on the delay of Internet.
Response timers in SMTP is longer than T.30 timer (T4 3.0+-15%).

>If so, Delivered by how many minutes is effective?

Objectives of E2E SMTP communication and the extension of SMTP are
to support one fax session over SMTP without S&F.
When end-to-end SMTP communication is supported, Timely delivery may not be 
required.

Toru Maeda

--------------------
MAEDA TORU
MIE Development Div. 2
CANON Inc.
--------------------

---

From: Dan Wing <[email-masked]>
Date: Tue, 13 Feb 2001 08:15:19 -0800 (PST)

> When end-to-end SMTP communication is supported, Timely delivery may not be 

SMTP won't solve the delay and jitter sensitivity of T.30 timers, though.  
In fact, it would be more sensitive to delay and jitter than T.38 because
TCP is slower to recover from network-induced jitter.

-Dan Wing

---

From: Dan Wing <[email-masked]>
Date: Tue, 13 Feb 2001 18:06:28 -0800 (PST)

I had an offline discussion with George Pajari and he helped me understand
your proposal better.

I believe there are several scenarios that are possible with this
end-to-end proposal [view with fixed-width font]:

1)

  scanner -> ifax ------------> ifax -> printer
                      ^
                      ^
                     SMTP

2)
 
  scanner -> fax -> PSTN -> ifax -----------> ifax -> printer
                                     ^
                                     ^
                                    SMTP

3)

  scanner -> ifax ------------> ifax -> PSTN -> fax -> printer
                      ^
                      ^
                     SMTP

4)

  scanner -> fax -> PSTN -> ifax --------> ifax -> PSTN -> fax -> printer
                                    ^
                                    ^
                                   SMTP

I believe that only (1) is useful.  Any of (2), (3), or (4) would have the
same jitter and delay sensitivity as T.38 itself.  SMTP may well be easier
to implement than T.38, but using SMTP doesn't avoid the jitter and delay
sensitivity problems in scenario (2), (3), or (4), above.

So, if we constrain the problem to (1), I think this WG can address it.  
In fact, I believe it can be done using existing SMTP technologies and
without inventing anything new, AND provide all the necessary guarantees
for a real delivery receipt.

-d

---

From: MAEDA toru <[email-masked]>
Date: Wed, 14 Feb 2001 12:32:43 +0900

Wing-san

Thank you very much for clarification of my idea.
2), 3) and 4) are the gate way function of T.38.
1) is the target of Terminal Mode which communicates end-to-end as fax 
terminals.

--------------------
MAEDA TORU
MIE Development Div. 2
CANON Inc.
--------------------