Subject: I-D ACTION:draft-ietf-fax-gateway-options-02.txt

From: [email-masked]
Date: Wed, 23 May 2001 07:15:36 -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		: Guideline of optional services for Internet FAX 
                          Gateway
	Author(s)	: K. Mimura, K. Yokoyama, T. Satoh, K. Watanabe,
                          C. Kanaide
	Filename	: draft-ietf-fax-gateway-options-02.txt
	Pages		: 11
	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 guideline of optional services
and some examples for an Internet FAX Gateway classified as an onramp
gateway and an offramp gateway.
So this document does not intend to specify the actions that ifax offramp and onramp Gateways conform to.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-fax-gateway-options-02.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-options-02.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-options-02.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 12:56:19 +0100

Section 3 of this document provides an example, including ABNF.  This isn't an
example but rather it is an attempt to create a standard for sending
authentication information (and that authentication information is supposed to
subsequently be used for authorization).  This doesn't belong in an
Informational document.

Please remove this example in section 3.1 from this document.

If the desire is to create a standard for sending authenication information,
it should be done as a full standards document, not an Informational RFC.

-d

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of [email-masked]
> Sent: Wednesday, May 23, 2001 12:16 PM
> To: IETF-Announce:
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-fax-gateway-options-02.txt
>
>

---

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

Hi Dan,

Thank you for your comments.
Since I was absent till last weekend,
the reply was overdue.

In Section 3,
I would like to provide an example of how to
send authentication information.
(the desire is not to create a standard.)

In the case of Onramp action,
I think that there are a lot of methods to send
authentication information and it depends on
a provider's services.

And, I think ,
Although the item to tell can be specified,
it is difficult to specify the format,
because it is concerned also with a user's
user friendliness and security.
The format means kind of a separator , length
of user ID , length of password , permutation of
an item and so on.

So, Section 3 shows an example.

How is it?

Is it better to indicate an example more?

/mimura

---

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

> (the desire is not to create a standard.)

An example doesn't require ABNF.  Please remove the ABNF.

> authentication information and it depends on

Yes, that is true.  And that is why I would prefer you add a paragraph (or so)
of text indicating that the mechanism you're describing in the Onramp section
is merely one, of many, methods.  It is an example of one method, but is not
the only method.

> user friendliness and security.

Yes, agreed.

> Is it better to indicate an example more?

It is important to clearly indicate the example is non-normative.

As you are undoubtably aware, many implementers look at examples when writing
parsers, designing systems, and so forth, and it is vital that implementations
are not unnaturally restricted to specific methods of authentication, specific
use of redialers, specific ABNF for example authentication strings, etc.

-d

---

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

> An example doesn't require ABNF.  Please remove the ABNF.

I agree.

We think two ways of changes.
Which is good?

1) We would like to remove example and change
    a Section 3.1 as follows.

    3.1 Example of User authorization

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

    In the case of Onramp action,
    there are a lot of methods to send
    authentication information and it depends on
    a provider's services.
    So, an example is not described.

2) We would like to cut ABNF as follows.

   3.1 Example of User authorization

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

    Example of user authorization by DTMF, GSTN
    user might send user-ID, password data after
    destination gstn-phone(Dual Tone Multi Frequency).

    example

    8155551234*81467745523*98765# is detect by DTMF
    Each data are extracted as follows, and
    user authorization is done.
    Destination facsimile number : 8155551234
    User ID : 81467745523
    Password : 98765
    "*" is separater, "#" is terminater.

/mimura

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 29 May 2001 18:04:15 -0700

I would prefer (1).  If you really want to do (2), examples for each of the
types of authentication should be shown, or else it implies that the one
method is the most-preferred method.  While our own gateways support it quite
well, it often isn't the most preferred method based on what our customers
have implemented to-date.

-d

> Behalf Of Katsuhiko Mimura
> Sent: Tuesday, May 29, 2001 5:24 PM
> To: Dan Wing
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-fax-gateway-options-02.txt
>
>
>

---

From: Katsuhiko Mimura <[email-masked]>
Date: Wed, 30 May 2001 11:20:11 +0900

Thank you for your good opinion.
We would like to change the draft to (1).