Subject: I-D ACTION:draft-ietf-fax-gateway-protocol-00.txt

From: [email-masked]
Date: Mon, 10 Jul 2000 06:33:00 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Fax Working Group of the IETF.

	Title		: Internet FAX Gateway Protocol
	Author(s)	: k. mimura, K. Yokoyama, T. Satoh, C. Kanaide
	Filename	: draft-ietf-fax-gateway-protocol-00.txt
	Pages		: 13
	Date		: 07-Jul-00
	
An Internet FAX Gateway incorporates the facsimile on general switched
telephone network (GSTN) into Internet by translating data and protocol
between them.
This document specifies an Internet FAX Gateway Protocol, especially
describes behavior of offramp/onramp gateway making reference to neither
authentication nor security, where offramp means facsimile data
transmission to GSTN from Internet, and onramp means facsimile data
transmission to Internet from GSTN. 
Behavior of offramp/onramp covers the delivery-process of the data among
equipments including IFAX terminal, PC on Internet and FAX terminal on
GSTN.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-fax-gateway-protocol-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-fax-gateway-protocol-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-fax-gateway-protocol-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Dan Wing <[email-masked]>
Date: Mon, 10 Jul 2000 10:14:21 -0700 (PDT)

> 	Filename	: draft-ietf-fax-gateway-protocol-00.txt

Hi.

I have the following comments about this document:

   3.2 drop the duplicate mail

   An offramp gateway MUST drop the duplicate mail by confirming whether 
   Message-ID is the same as old one.
   This is to avoid the duplication of the transmission to same facsimile 
   device over GSTN.

The above mechanism does not work and is insufficient to determine
if a message is a duplicate message.  The simplest example of when this
doesn't work is in the case of resent messages with a Resent- header,
as those messages don't have their Message-IDs changed.  Reference
draft-ietf-drums-msg-fmt-08.txt, section 3.6.6.  

There are other cases where the Message-ID is not sufficient to detect a
duplicated message, or where it causes false positives.

Additionally, there is no significant operational advantage gained by
attempting to prevent duplicate message delivery.

   3.3 return notice

   An offramp gateway SHOULD have the function which the offramp gateway send
   return notice to the source IFAX device, when a transmitting error 
   occurred then finished with the facsimile data not transmitted.
   In order to put into practice this function, it is necessary to SMTP sender 
   MTA on offramp gateway. 

RFC2305 section 2.3.1 states that this is a MUST requirement.

Generating a bounce is a MUST requirement for all Internet mail, and
cannot be specified as a SHOULD requirement.

Section 3.3.1 uses the term "multicast".  I am sure you're aware that
multicast has a specific meaning in IP networking.  This may be confusing
to some readers.

   3.3.1 When send return notice

   Transmitting time to facsimile terminal over GSTN from offramp gateway  
   changes by the case. Transmitting time changes by the performance of FAX 
   and the circuit condition. It is important when to transmit return notice 
   in the multi-cast transmission.
   When a onramp gateway received Internet FAX which specify multiple 
   destination facsimile devices (multicast request), there are two methods
   to send return notice from  the onramp gateway to the source IFAX device.
   The onramp gateway send return notice, when every time an error occurs.
   Or send return notice at the end together This SHOULD be able to select
   by user.

I can't parse the last three sentences, above.  The rest of section 3.3.1
is equally confusing; is it specifying recommended behavior, or simply
eludicating the reader?

Section 3.3.2 is great, except for its last sentence, which I don't
understand.

Section 3.3.3 is great, but it needs to be more specific.  It reads:

   3.3.3 Information of return notice
 
   The following information must be contained at least in return notice.
 
   - Transmission start time
   - Destination dial
   - Number of total pages
   - Number of real transmitted page
   - Cause of error
 
   An offramp gateway adds the following information, when it have the
   function of automatically transmission retry.
 
   - number of retry times
   - Transmission retry start time

The information returned cannot be in a specific language (English,
German, Japanese) unless it is known which language is common for the
user.  Unfortunately, there isn't a way to know.  We should have a
standard format for such information in a computer-parsable and
human-parsable format.  Such formats have been proposed previously in this
working group but never achieved consensus.

   3.4 Authentication
 
   An offramp gateway SHOULD provide the authentication function to judge
   whether the received E-mail is sent by appropriate source IFAX device.

The words "by appropriate source IFAX device" imply that only an "IFAX
device" might be a valid source of an RFC2305-compliant message for an
offramp gateway.  But a PC with appropriate software is one such IFAX
device.  I suggest to replace "is sent by appropriate source IFAX device"
with "was sent by an authorized sender".

RFC2305 describes the authorization and authentication requirements of
an offramp and onramp gateway in quite a lot of detail.  You may want
to use some of that text.

   4.1 Onramp Functions

   An onramp gateway MUST have the function that the onramp gateway receive
   facsimile data from facsimile device over GSTN, then generated Internet
   fax is sent to appropriate IFAX devices or PC by the onramp gateway.
   How to transmit data from an onramp gateway to IFAX devices MUST based
   on RFC 2305.

   Sending to the device on Internet for E-mail data , the onramp gateway
   should set From field or Replay-To field for the following sentences.

     < the numbers of sender > @ < Domain name of onramp gateway >

   We can use for the Return notice from destination function by this setting.

I have several issues with the above section.

1.  "Replay-To" should be "Reply-To"

2.  The domain name of the onramp gateway is not correct.  Instead, the
domain name of a valid *offramp* gateway should be used!  It cannot be
assumed that an onramp gateway will also function as an offramp
gateway.  An onramp gateway might not be able to provide offramp
functions.

This seems to be described in section 4.2, but I am wary of the
text mentioning use of the onramp gateway's domain name in these
fields at all.

3.  The last sentence, "We can use for the Return notice from destination
function by this setting" is incorrect.  None of the return notices used
by offramp gateways use the "From:" or "Reply-To:" fields; using such
fields for automatic replies to errors is incorrect and will lead to
problems in integrated mail environments.  Proper handling of mail
message returns, notifications, etc., is described in other RFCs, and 
none of them suggest or allow using the RFC822 "From:" or RFC822
"Reply-To:" fields in such a manner.

4.  The "the numbers of sender" field should be clearly specified to
be the E.164 address as specified in RFC2304.

Section 4.2(2) says:

      When user authentication is necessary, the next information is
      included, regardless of the direct address designation or the indirect
      address designation.
 
      - User ID
      - Password

Please explain what this means.

The example in section 4.2(2) includes several non-7-bit-ASCII
characters and my editor cannot view the file correctly.  Please remove
these characters; they are not legal in Internet Drafts.

   4.3 Choice of Offramp gateway
 
   Onramp gateway SHOULD have the function which chooses destination offramp
   gateway by analyzing a specified destination facsimile number.
   Onramp gateway SHOULD hold course information of offramp gateway to
   realize this function.

Please explain "hold course information".  I am not familiar with this
term.

   4.4 User authentication
 
   Onramp gateway should have a user authentication function to confirm that
   they are the data that suitable user transmitted.

Two comments on the above:

1. I disagree that this is a "should" requirement.  It should be a "MAY".
This is because, today, nearly all fax machines around the world permit
any fax machine to transmit a fax to that fax machine with no
authorization.

2. Please be careful with use of "authorization" and "authentication".  
The section is titled "authentication", but the first sentence discusses
"authorization".

"Authorization" essentially means "allowed".  "Authentication" essentially
means "known".  It is usually impossible to know if a user is "allowed"
(authorized) to perform an action without first "knowing" (authenticating)
which user is attempting the action.

Section 4.5 needs substantial clarification.  Is section 4.5 describing a
requirement where an onramp gateway authenticates a GSTN-based fax
transmitter and then re-creates that authentication using PGP (or
S/MIME) towards an offramp gateway, and then the offramp gateway recreates
that authentication information again when the message is sent over GSTN
again?

This is a very difficult problem to solve, even in a closed, proprietary
single-vendor ifax network.  I honestly feel such behavior is best solved
with T.38 at this time; trying to do this with RFC2305/T.37 is nearly
impossible without weaking either the T.30 fax authentication, the
over-the-internet authentication/encryption, or both.

   4.7 Option function
 
   Onramp gateway can provide various option functions for facsimile device
   user on GSTN by adding an option number at the end of the DTMF data.
   A data format at this time is following either.

What is the purpose of this "option number"?

   4.8 return notice
 
   When it has a function that receives and analyzes return notice from
   destination,
   Onramp gateway MAY send delivery status to suitable facsimile device user
   on GSTN.
   This function is used in accordance with the 5.4 user authentication.
   In order to put into practice this function, it is necessary to SMTP
   receiver MTA on onramp gateway.

An onramp gateway cannot transmit a fax over GSTN.  Transmitting a fax
over GSTN is the function of an offramp gateway.

   4.9 Multicasts transmit request
 
   Onramp gateway can specify destination of maximum 99 by specifying it in
   To: or c: field by 1 mail.
   But, destination beyond 100 SHULD NOT be specified in 1 mail.
   And, address SHOULD NOT be specified whit BCC:.

I have a few issues with the above sentence:

1.  To:, CC:, and BCC: are not used for routing mail messages.  RFC821 is
used to route messages.  The "To:" and "CC:" fields are used only to help
describe a message and are described in RFC822.

2.  There is absolutely no need for an arbitrary 99 recipient limitation.

Section 4.9 also says:
 
   How to specify address in this case it SHOULD be indirect address
   designation (5.2 2).

I don't understand "5.2 2".  Is this a section of this Internet Draft?

Section 5 says:

   5. Security Considerations
 
   The Security Considerations sections of [RFC2305] applies to this
   document.

There are additional security considerations introduced by requirements
in this document, beyond those described in RFC2305.  Those should be
discussed in this section.

-Dan Wing

---

From: Yokoyama <[email-masked]>
Date: Tue, 11 Jul 2000 18:31:05 +0900

Dear Mr. Wing.

Thank you for your comments.
We have many comment from you.
So we cannnot anser at once.

> attempting to prevent duplicate message delivery.

When an offramp gateway uses POP, this mechanism is necessary.
There is a cause in the mechanism of mail server.

RFC2305 2.1.3 mailbox protocols define that
an offramp gateway MAY use a mailbox access protocol such as POP or IMAP.

example.
A mail server is set up to forward all mail for "FAX=+"* to "IFAX".
IFAX is mailbox of the offramp gateway.
If MTA receive an mail it is TO:FAX=+1111,FAX=+2222,
Mail server will copy two same mail on the IFAX mail box.
(most mail server does such a movement)
Then offramp gateway receive the mail from IFAX mail box by using POP,
the offramp gateway receive same 2 mails.

> multicast has a specific meaning in IP networking.  This may be confusing

Thank you for your comment.
We will change to MUST from SHOULD
and will chage term to "broadcast" from "multicast"

> is equally confusing; is it specifying recommended behavior, or simply

Verry sorry . after 4 sentence, onramp and offramp is became reverse.

> Section 3.3.2 is great, except for its last sentence, which I don't

Sorry
for example
An offramp gateway is sending total 30 pages facsimile data.
But an error occurs and transmittion is stopped after 15 pages is send mormally.
The offramp gateway should re-transmit the facsimile data from page 16.

> working group but never achieved consensus.

Above information is needed by most of our users
so our system carries this information in the individual method.
(Our system carrys the information in mail body)
But RFC 2305 defined failure message should be in format of a DSN.
We think return noticeis also message should be in format of a DSN.
So we do not specify more detail yet.

> to use some of that text.

Thank you we will change to below.
An offramp gateway SHOULD provide the authentication function to judge
whether the received E-mail was sent by an authorized sender.
And we will reconsider this section.

> 1.  "Replay-To" should be "Reply-To"

Sorry

> "Reply-To:" fields in such a manner.

This section is considered again.

> Please explain what this means.

Thank you we will change.

> Please explain "hold course information".  I am not familiar with this

course information -> routing information

> over-the-internet authentication/encryption, or both.

This section is considered again.

> What is the purpose of this "option number"?

By specifying option number, an onramp gateway is made to do a special monovement.
not only specify destination facsimile No.

> over GSTN is the function of an offramp gateway.

Sorry
Our gateway system is act as both onramp and offramp gateway.
We will reconsider by dividing our system into offramp with onramp.

> describe a message and are described in RFC822.

Sorry we will change.

> 2.  There is absolutely no need for an arbitrary 99 recipient limitation.

           recipients buffer

               The maximum total number of recipients that must be
               buffered is 100 recipients.

is defined by RFC821.
In our test, some of MTA return error when 100 destinations are specified.

> I don't understand "5.2 2".  Is this a section of this Internet Draft?

(5.2 2) -> 4.2(2)

> discussed in this section.

We will reconsider with security again.

--
K. Yokoyama   E-mail:[email-masked]

---

From: Dan Wing <[email-masked]>
Date: Wed, 12 Jul 2000 11:03:28 -0700 (PDT)

> Dear Mr. Wing.

I prefer "Dan", if that's okay.

> When an offramp gateway uses POP, this mechanism is necessary.

Oh, I wasn't aware that this I-D was standardizing POP gateways.  My
mistake.

> the offramp gateway receive same 2 mails.

I have been using various mail packages for years but have never seen
this behavior except in very low-end mailers which do not correctly
collapse aliased addresses.

When a mailer has aliased "FAX=+"* to "IFAX", it can eliminate duplicate
localparts.  In my experience, mailers such as sendmail and PMDF do
eliminate duplicate localparts when such an alias is used.  I expect
qmail would collapse duplicate addresses as well.

However, that aside, I still stand by my original comment on using
Message-ID.  Using the Message-Id is insufficient to detect duplicate
messages and does not work with Resent-* headers and does not work in
other situations.  These problems have been discussed on this mailing list
in the past (check the archives; I recall discussions that included Keith
Moore and Ned Freed on this specific topic).  Perhaps you could propose
using a hash of Message-Id and the To, From, Resent-To, and Resent-From
fields to resolve the detect-duplicate-message problem sufficiently for
the needs of a POP-based mail gateway.

Would you have a recommendation for how many, and how long, a POP-based
offramp gateway should store this duplicate message identifying
information?  If so, that should be included in the I-D.

In the archives, you can also find strong arguments for why a POP-based
ifax gateway has other problems with message routing.  I expect that
if we delve into the details of using a POP-based ifax offramp gateway
again (as we did a year or so ago), you will discover strong resistance
to standardizing its use among the SMTP community.

I don't know if we (the IETF-FAX working group) would like to have a
single "gateway requirements" document that covers both POP- and
SMTP-based ifax onramp and offramp gateways, or if we want separate
documents.  

But I know there isn't complete concurrency between this document and
draft-ietf-fax-implementers-guide.  The two documents need to agree on how
various aspects are handled (such as success and error notification).

> and will chage term to "broadcast" from "multicast"

Thanks.

> Verry sorry . after 4 sentence, onramp and offramp is became reverse.

No problem.  If you could rewrite section 3.3.1 so it is clearer that
would be helpful.

> The offramp gateway should re-transmit the facsimile data from page 16.

Thanks.  If you could add that text to the I-D, that would be helpful.

> We think return noticeis also message should be in format of a DSN.

DSN is only appropriate, and can only be generated, by SMTP mailers;
a POP-based mailer cannot generate DSNs for successful message 
deliveries, as the message as actually already been delivered.

MDN is appropriate for the purpose you've described.  MDNs are described
in RFC2298.

> So we do not specify more detail yet.

Language-specific information in the body of a message is not good.  For
example, my company is global but you can imagine that it is most
desirable when a Cisco employee in Spain sends an ifax which goes to an
offramp in California that the employee in Spain receives a transmission
confirmation in Spanish.  That is only possible by either (a) the offramp
gateway knowing the user's preferred language or (b) the offramp gateway
generating a computer-parsable transmission confirmation which could
be interpreted by the MUA of the user in Spain.

Both mechanisms, (a) and (b), could be described for ifax offramps.  I
suggest putting such a description into a separate I-D, however, as the
format of this message is quite independent of other aspects of offramp
faxing.

> whether the received E-mail was sent by an authorized sender.

That would be great.  Thanks.

> This section is considered again.

At the time I wrote (3), above, I wasn't aware that your I-D was
describing the functions of a POP-based ifax gateway.  As I mentioned
earlier in this message, there are difficulties with using POP (or
IMAP) with an ifax offramp gateway, and (3), above, describes one of
the problems.

Perhaps we could require the POP gateway only use POP servers that
generate a Return-Path: header.  This would allow the POP gateway to
correctly deal with error conditions by responding to the correct
address with an error.  However, the error can't be in the format of
a DSN [as the message has already been delivered], and MDNs can only
be generated if the appropriate header exists (reference RFC2298, section
2.1, paragraph 4).

> course information -> routing information

Thanks.  The term is still confusing and I couldn't find a similar use on
the Internet (after searching using www.google.com).  I would encourage
you to please rephrase this sentence when you update the I-D.

> This section is considered again.

Thanks.

> not only specify destination facsimile No.

Where are the option numbers defined?  Are they standardized?

> Our gateway system is act as both onramp and offramp gateway.

So can ours, but ours can be configured to perform only onramp or only
offramp functions (and many customers configure the devices this way on
purpose).

> We will reconsider by dividing our system into offramp with onramp.

Thanks.

> > describe a message and are described in RFC822.

Thanks.  This, too, is due to the nature of trying to use POP for message
routing when SMTP is for message routing.

> In our test, some of MTA return error when 100 destinations are specified.

See section 4.5.3.1 of draft-ietf-drums-smtpupd-11.txt which more clearly
explains this limit than RFC821.

My point, however, is that the limit should not be on the sender at all;
there is no reason for the sender to unnecessarily restrict the number of
RCPT TOs in a single SMTP session unless the SMTP server returns an error
(452 or 552, as described in draft-ietf-drums-smtpupd-11.txt).

> > I don't understand "5.2 2".  Is this a section of this Internet Draft?

At this time, it would be sufficient to simply add "Further security
considerations are introduced by this document, but they will be described
in this section prior to publication as an RFC."

Without such text, it appears you believe that the security section is
complete with only its current sentence ("The Security Considerations
sections of [RFC2305] applies to this document").

Thank you for considering and replying to my comments.

-Dan Wing

---

From: Hiroshi Tamura <[email-masked]>
Date: Thu, 13 Jul 2000 08:40:53 +0900 (JST)

Hi.

As a co-chair,
I welcome I-D about gateway issue was introduced, followed by the discussion.

Thank you, Mimura-san, Yokoyama-san, Dan.

<snip>

> various aspects are handled (such as success and error notification).

Comments, as one of editors of draft-ietf-fax-implementers-guide.
I think notification issue on offramp/onramp gateway is diffcult
to handle in draft-ietf-fax-implementers-guide.

One of the reasons is that it has something to do with
G3/G4 Fax protocol.

We(editors) do not have a plan to include it.
And, there is a section about Addressing, but no contents.
I think we delete this section.

Notification issues on gateway are better to be done in other documents,
I think now.

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

---

From: Yokoyama <[email-masked]>
Date: Fri, 14 Jul 2000 19:23:21 +0900

Dan

Thank you for your detailed comment.
Our new policy is shown in the following.

-Authentication and Authorization.
     About 4.4 User Authentication
     This section define about authorization.
     So, we will rewrite 4.4 to authorization from authentication.

     3.4 Authentication
     4.5 Authenticaiotion toward Offramp gateway
     These section is defined by RFC2305 5.2.1 Spoofed sender and
     RFC2305 5.2.2 Resources consumed by dialout
     So, We will include these section in 5. Security Considerations.

-Return notice
     DSN and MDN is used by return notice.
     DSN is generated by MTA.
     MDN is generated by UA.
     Only DSN or MDN are used for return notice.
     Tamura-san said
           Notification issues on gateway are better to be done in other documents,
           I think now.
     So we will define only when generete return notice.

-Drop the duplicate mail
      I understand duplicate message id is rare case.
      We will drop "3.2 drop the duplicate mail".

-Option function
     We will also remove "4.7 Option function".

-Multicasts transmit request
     About  4.5.3.1 of draft-ietf-drums-smtpupd-11.txt .
     We know maximum total number of recipients is defined by MTA.
     So, limit of recipients is not defined by sender.
     We will change draft  to fit the above.

-Security Considerations
     We will change below.
     The Security Considerations sections of [RFC2305] applies to this document.
     Further security considerations are introduced by this document,
     but they will be described in this section prior to publication as an RFC.

Good weekend.

---

From: Dan Wing <[email-masked]>
Date: Fri, 14 Jul 2000 18:28:50 -0700 (PDT)

Thanks.

>      So we will define only when generete return notice.

Okay.

>       We will drop "3.2 drop the duplicate mail".

Mmm, I do think it is valuable to have in your document, though.  I
believe it can be worded so it explains the case.  

In a separate I-D we could describe a mechanism that reliably detects a
duplicate message, make sure it's valid (by having a group well-versed in
SMTP, POP, and IMAP issues review it), and then, next time the gateway
document is updated, the gateway document could refer directly to the
duplicate-message-detection mechanism.

Thanks.

Thanks.

>      but they will be described in this section prior to publication

Thanks, looks great.

> Good weekend.

And to you, as well.

-Dan Wing

---

From: Yokoyama <[email-masked]>
Date: Mon, 17 Jul 2000 11:48:55 +0900

> >      So we will define only when generete return notice.

Thank you.

> believe it can be worded so it explains the case.

We will add the case when an offramp gateway drop the duplicate mail.

> duplicate-message-detection mechanism.

I understand, it is valid.

--
横山 景一   Keiichi Yokoyama   E-mail:[email-masked]
東洋通信機株式会社  システム事業本部
通信システム事業部  マルチメディア技術部