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

From: [email-masked]
Date: Wed, 23 May 2001 07:15:41 -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 Functions
	Author(s)	: K. Mimura, K. Yokoyama, T. Satoh, C. Kanaide
	Filename	: draft-ietf-fax-gateway-protocol-04.txt
	Pages		: 12
	Date		: 22-May-01
	
An Internet FAX Gateway provides functions which translate facsimile
between the general switched telephone network (GSTN) the Internet.
This document provides information on recommended behaviors for 
Internet FAX Gateways Functions. In this context, an Offramp means
facsimile data transmission to the GSTN from the Internet, and onramp
means facsimile data transmission to Internet from the GSTN. 
This document covers the delivery-process of the data among equipment
which may include Internet Fax terminals, PCs on the Internet and FAX
terminal on GSTN.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-fax-gateway-protocol-04.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-04.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-04.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: Wed, 23 May 2001 13:17:09 +0100

Section 3.2.1 indicates the offramp gateway must create a local dial number.
This isn't required -- rather, it must be able to process the E.164 correctly,
which MIGHT require rewriting it to a local number.  For example, it is
possible that the full E.164 is handed to the telephony service, and no
internal rewriting is required in the fax gateway.  Specifically, a PBX might
accept a full E.164 number and might do the rewriting necessary, which means
the gateway shouldn't be doing what is described in section 3.2.1.  Thus,
section 3.2.1 sets a requirement which isn't necessary.  I suggest rewording
this section to remove the requirement that the gateway be able to translate
the E.164 to a local number -- rather, say that the gateway must be able to
utilize the E.164 number, and that the TYPICAL way to utilize the E.164 number
is to rewrite it to a local phone number.

Section 3.3, "User authorization", contains:

  1) Encipherment of user authorization and facsimile data is performed
     by the existing SMTP, such as S/MIME and X-Header, using the possible
     security technique.

which discusses encryption of the data -- not just user authorization.  The
title of the section should be changed, or the above text describing
encryption should be moved to a new section.

I don't understand

  2) The distribution demand from the user who permitted use of the
     Internet Fax Gateway is received using the user authorization function
     and E-mail transmitting function of WWW.

The requirement

   An offramp gateway MUST 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.

is already in RFC2305.  Is the requirement in RFC2305 not sufficient?

   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.

The above text requires that the onramp communicate directly with the
destination PC or IFAX device.  This is not how SMTP works -- you seldom,
if ever, communicate directly with the destination device, but rather
with intermediate SMTP servers.  Please remove this requirement, as it
is unattainable from a technical viewpoint:  the onramp has no way to
communicate 'directly' to the end device.

I believe the requirement in rfc2305 is sufficient for describing
this specific onramp fax function.

Please remove section 4.1.

  4.2 Address designation

   An onramp gateway MUST have the function that onramp gateway analyze
   destination address from address data sent by facsimile device over
   GSTN.

There isn't any "destination address [...] sent by facsimile device under
GSTN".   I'm not sure what section 4.2 is requiring, but as there isn't
any "destination address" in T.30 / T.4, and not all facsimile devices
can get the DNIS, I'm not sure what this section is requiring.

I know there was a proposal to add some sort of information to T.30 --
is this what you're referring to?  I'm really unclear where the
information described in 4.2.1 comes from over the GSTN...?

Most of section 4.2 describes a "redialer".  If there is a desire to
standardize this, that's fine, but let's standardize this as a separate
document, as the behavior with redialers is complex and it is important
to describe redailer behavior clearly, including timeouts, E.164 versus
non-E.164 numbers, and so on.  This would allow manufacturers to indicate
clearly which type of redialers they support (redialers for authentication
only, redialers for destination routing only, redialers for both
authentication and destination routing, etc.).

Section 4.3 describes a "relay function", but doesn't explain what a
relay function is.  Please update the Internet Draft to clarify this.

Section 4.4 says:

   4.4 File format conversion

   An onramp gateway MUST counvert file format from an facsimile over
   GSTN to file format TIFF Profile-S for Internet Fax defined in
   [RFC2301].

This is already a requirement of rfc2305, and does not need to be
restated in this Internet Draft.

  4.5 User authorization

   Onramp gateway MAY have a user authorization function to confirm
   that they are the data that suitable user transmitted.

   For example, User authorization is done by using user ID, password
   extracted from DTMF (Dual Tone Multi Frequency).

it can be done by CLID, too, which is more secure and doesn't require a
redialer nor any change in user behavior when using a fax call-around service
or onramp+offramp.

Overall, it seems this document is really trying to specify the requirements
for redialers -- the rest of the document seems to repeat what is already in
rfc2305.  Repeating RFC2305 requirements is redundant and adds confusion.

IETF documents are layered on each other -- there isn't a need, nor is it
possible, to have all requirements in one document for one 'application', such
as fax-over-SMTP.  There is one document which specifies the baseline
requirements for fax over SMTP, which is rfc2305 (T.37), and there are
documents which can extend this baseline without repeating requirements unless
they do, in fact, change.  See RFC2532 for an example, which adds MDN and DSN
support to a device that already supports RFC2305.  Likewise, a device that
supports RFC2305 has to support SMTP (RFC821, 822), the MIME RFCs, TCP, IP,
ARP, and many other lower-layer protocols.  However, use of those protocols
isn't restated in RFC2305 because it would be redundant.

-d

---

From: "Herman R. Silbiger" <[email-masked]>
Date: Wed, 23 May 2001 11:25:01 -0400

I think it should be made clear in this document, perhaps up front somewhere, that
it only discusses fax gateway functions that apply to internet mail based fax
(T.37) an that gateway functions and protocols for real time internet fax are
described in Rec. T.38.  This might reduce possible confusion in some readers
minds.

Herman Silbiger

[email-masked] wrote:

>   ------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID:     <[email-masked]>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 23 May 2001 16:59:47 +0100

I agree, but I would cite RFC2305 or RFC2305bis (whatever RFC it becomes),
not the ITU T.37 specification.  Folks in IETF-land don't know of T.37;
T.37 refers to the IETF RFC.

-d

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Herman R. Silbiger
> Sent: Wednesday, May 23, 2001 4:25 PM
> To: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-fax-gateway-protocol-04.txt
>
>

---

From: Katsuhiko Mimura <[email-masked]>
Date: Mon, 28 May 2001 14:28:50 +0900

We had defined below in Section 1 .
Do you think that you should describe
these in Abstract?

 > Scope of Internet FAX Gateway defined in
 > this document is shown below.
 >
 >   1) A format of image data is a data format
 >      defined by "Simple Mode" in [RFC2305].
 >   2) Operational mode is "store and forward"
 >       defined in section 2.5 of [RFC2542]

/mimura

---

From: "Herman R. Silbiger" <[email-masked]>
Date: Tue, 29 May 2001 13:31:41 -0400

I would suggest the following additions of text to
draft-ietf-fax-gateway-protocol-04.txt.

Change the first sentence of the abstract to:

   An Internet FAX Gateway provides functions which translate facsimile
   between the general switched telephone network (GSTN) the Internet.
   This document provides information on recommended behaviors for
   Internet FAX Gateways Functions for email-based Internet fax.

Change the third sentence in the first paragraph of section 1 to:

   A more detailed definition of onramps and offramps for email-based Internet
fax is provided in [RFC2542].  Internet FAX Gateways functions for real-time
Internet fax are defined in [T.38].

 Add to References:

[T.38]  "Procedures for real-time Group 3 facsimile communication over IP
networks", ITU-T Recommendation T.38,  June, 1998.

By the way, date of the reference to T.30 should now  be April 1999.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 29 May 2001 11:28:06 -0700

Okay by me.

-d

> Behalf Of Katsuhiko Mimura
> Sent: Sunday, May 27, 2001 10:29 PM
> To: Dan Wing
> Cc: [email-masked]; [email-masked]

---

From: Katsuhiko Mimura <[email-masked]>
Date: Wed, 30 May 2001 09:28:27 +0900

Thank you for your good suggestion.

We would like to change the draft like your
suggestion.

/mimura