Subject: E2E communication over SMTP

From: MAEDA toru <[email-masked]>
Date: Wed, 07 Feb 2001 19:09:52 +0900

Hi, forks,

I have mailed the goals for Terminal Mode into the mailing list last week.
I proposed that the end to end communication over SMTP in the goal.
We have been discussed about the store and forward IFAX for long time
and developed Simple Mode and EIFAX.
My question is why do we need the store and forward system for Internet fax.
In case of communication to Email client such as PCs,
the existing S&F mailing environment must be used.
Since the Terminal Mode IFAX devices will run and will be connected to 
iternet all time,
end to end communication is more practical and more beneficial.

I think it will be easy to connect to the receiver by SMTP as end-to-end,
when the destination address is the global address instead of the Email 
address.

Any comments?

Regards,

Toru MAEDA

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

---

From: "Toyoda, Kiyoshi" <[email-masked]>
Date: Wed, 07 Feb 2001 19:58:00 +0900

Maeda-san,

>end to end communication is more practical and more beneficial.

In the most enterprise, fire wall rejects SMTP to the terminal other than
mail server. If we want end to end communication in the Internet, we need
security policy of fire wall to allow to open the port of SMTP to the IFAX. 
On the other hand, end to end communication is practical in the Intranet 
and we can get benefits deifferenet from S&F communicaton.

I think that IPP has the same problem and the IFAX which communicate directry 
between terminals on T.38. If we can solve the problem of fire wall, I 
prefer terminal mode than T.38 because SMTP protocol is simple and easy 
to implement. 

Kiyoshi Toyoda

---

From: MAEDA toru <[email-masked]>
Date: Thu, 08 Feb 2001 12:28:00 +0900

Toyoda-san

IPPFAX and T.38 have same problem over firewall.
Terminal Mode will also have the same firewall problem too.

I am not sure that the firewall problem should be discussed within
standardization or deployment.
ITU-T did not discuss about it during T.38 standardization.

The problem should be asked to the group who has responsible of
firewall operation after the standardization.

Regards,

Toru Maeda

>prefer terminal mode than T.38 because SMTP protocol is simple and easy

-----------------------------------
キヤノン株式会社
映像事務機MIE推進センター
映像事務機MIE第２開発部
前田　徹
146-8501　東京都大田区下丸子３−３０−２
電話　03-3757-9738、FAX　03-3757-8205
-----------------------------------

---

From: "Toyoda, Kiyoshi" <[email-masked]>
Date: Thu, 08 Feb 2001 16:45:05 +0900

Maeda-san,

I comment below.

>firewall operation after the standardization.

I agree.

I would like to add terminal mode to new charter if terminal mode
has a feature and goals below you said in your e-mail.

Maeda-san wrote:
>
>Also new features are designed such as (1) legal support by fax header or
>cover page with sender's ID and Time&date, (2) end to end SMTP session
>and (3) One SMTP session for capability exchange/image 
>transmission/confirmation.
>
>2. Goals for Terminal Mode
>Those are goals for Terminal Mode
>
>Easy to Implement
>Interworking with G3 fax, IFAX Simple Mode and EIFAX
>Features shared with G3 fax
>
>Proof of delivery/receipt
>Capability Exchange
>Timely Delivery
>

What idea do you have to interwork with IFAX Simple mode or EIFAX?
How about falling back method below?

At first, IFAX try to resolve the IP address of the target by DNS.

 If IFAX can get the IP address, then IFAX communicates with the target 
 directry by terminal mode.

 If IFAX can not get the IP address, IFAX communicate with the target
 by Simple mode or EIFAX mode.

Regards,

Kiyoshi Toyoda

---

From: MAEDA toru <[email-masked]>
Date: Fri, 09 Feb 2001 13:51:22 +0900

Toyoda-san

>How about falling back method below?

Terminal Mode will use TIFF-FX file format,
so it will be no problem to  send image file to IFAX Simple mode
without confirmation nor capabilities exchange.

>  by Simple mode or EIFAX mode.

Yes, this will be the first step of the protocol in Terminal Mode
We should ask SMTP and DNS people that it is possible.

Regards,

Toru Maeda

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

---

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

On Fri, 9 Feb 2001 13:51 +0900, MAEDA toru wrote:

Hi.

> We should ask SMTP and DNS people that it is possible.

DNS has supported this functionality for a long time with MX records.  
Using SRV records, it is possible to provide further refinement beyond
MX to help find the correct host.

But all this assumes fixed locations for a recipient.  This is outdated.
Using something like SIP would allow a user to move around and register
where they would most like to receive their communications -- video, fax,
voicemail, live voice, and email.

-Dan Wing

---

From: "Robert A. Rosenberg" <[email-masked]>
Date: Tue, 13 Feb 2001 12:36:33 -0500

At 19:58 +0900 on 02/07/2001, Toyoda, Kiyoshi wrote about Re: E2E 

>security policy of fire wall to allow to open the port of SMTP to the IFAX.

One solution to this problem might be to define a Well Known Port 
Number for incoming E2E IFAX devices (Just like there already is a 
SMTP port [547?] for Mail Submission Agents [MUA-to-SMTP] that can be 
used in lieu of Port 25 to inject new mail as opposed to forward mail 
from MTA to MTA). This port number can be opened in the Firewall by 
listing the device as a IFAX Server just like the SMTP Servers are 
currently listed as Port 25 authorized.

---

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

> currently listed as Port 25 authorized.

Let's examine the requirements that I believe we're trying to meet.

If we could get agreement on these we can look at technologies to 
solve all the requirements.

I believe the requirements which aren't currently solved with RFC2305
and RFC2532 are:

  *  absolutely guaranteed delivery receipts with functionality identical
     to PSTN-based fax delivery receipts
  *  immediate delivery

Comments?

We can define "immediate" in a few days.  As we all know, nothing is
immediate and physics says that there isn't such a thing as an
"explosion", either -- just a fast burn.

-d

---

From: "Toyoda, Kiyoshi" <[email-masked]>
Date: Wed, 14 Feb 2001 11:37:38 +0900

>currently listed as Port 25 authorized.

If the port number can be opened in the Firewall at both sending side
and receiving side, IFAX can communicate. Registering IFAX to MX record
on DNS server also realize direct communication of IFAX.

But I'm afraid how many Manager of Information System devision allow it. 
If we certify that IFAX has no security hole, they may allow it. 
Maybe we can certify it because IFAX only has limited function for IFAX
communication.

Kiyoshi Toyoda

---

From: "Toyoda, Kiyoshi" <[email-masked]>
Date: Wed, 14 Feb 2001 16:35:00 +0900

>     to PSTN-based fax delivery receipts

I want to add the below which Maeda-san said in previous e-mail as
"Goals for Ternmnal Mode".

- interworking with IFAX Simple Mode and EIFAX
- capability exchange (maybe the requirements above include it)

Kiyoshi Toyoda

---

From: Hiroshi Tamura <[email-masked]>
Date: Mon, 19 Feb 2001 17:06:25 +0900 (JST)

Chair's comments.

There are some comments about Maeda-san's ideas.
Some of his ideas are not accepted.

But, one agreement is E2E communication, I think.
Our group may agree to somthing about it.

Folks,
Please continue to discuss E2E communication, together with
the items necessary for E2E communication.

Maeda-san,
Please summarize your ideas and the pros/cons
after your draft is circulated.

Regards,
--
Hiroshi Tamura, Co-Chair of IETF-FAX WG
E-mail: [email-masked]