Subject: RE: draft-ietf-fax-t30-capabilities-00.txt

From: Dan Wing <[email-masked]>
Date: Mon, 14 Sep 1998 19:10:12 -0700

>Again, my apologies for the delayed positing of my comments.  Some of these
>might be superseded by ongoing work to analyze the T.30 DIS/DTC bits and
>build a decision table for mapping them.  I think this memo may be an
>appropriate document to contain such a decision table.
>
>In addition to the comments below, I note that Maeda-san's draft also
>contains mention of SUB, SEP, PWD, SID and other T.30 values that we may
>need to consider.

My 1996 version of T.30 doesn't mention SUB or SID, but does show SEP
is used for selective polling and PWD is the password used for
polling. 

T.30-style polling cannot be implemented over email, but only makes
sense using a closed T.30-to-SMTP-to-T.30 protocol or when a
GSTN-based T.30 terminal dials a system that has already stored the
message and wishes to 'pull' messages -- exactly as T.30 polling is
implemented today and requires _no_ sending/receiving of T.30 polling
bits or passwords over email.

It is my understanding that this IETF working group is trying to not
create a closed T.30-to-SMTP-to-T.30 protocol. 

I am actively trying to recruit someone else to take over editing
tasks for the -t30-capabilities- document.  If no one can be found I 
will continue and will integrate your other comments.

[...]
>>3.2.  Polling 
>>
>>   With SMTP polling is acheived with the TURN, ETRN, and
>>   ATRN commands [ref].
>>   
>>   With HTTP polling is acheived with GET [ref].
>>   
>>   With FTP polling is acheived with RETR.
>>
>>   Thus, information about a remote machine's ability to have messages
>>   polled is not useful to use over the Internet.
>
>I understand that the T.30 bits are also used to indicate that there is
>data ready to be sent by the polling mechanism (i.e. more than just
>indicating a polling capability).

Yes, but can you describe how this would work over email?  The only
scenario I can conceive of is this, using Maeda's I-D and old
messages from Mike Lake as a basis:

1.  GSTN-based T.30 device makes a call to Device A, sends its password 
    and asks Device A to give it messages (polling).  

2.  Device A authenticates the GSTN-based T.30 device.

3.  Device A tells the GSTN-based T.30 device "I have no messages for you" 
    and hangs up

4.  Device A sends a message to Device B message to device B with the 
    password provided by the T.30 device.  

5.  Device B authenticates the password and sends stored images to the 
    device A.  

6.  Device A stores the stored images.

7.  The GSTN-based T.30 device eventually calls device A again, requests 
    messages.  This puts us back up at step (1), except at step (3)
    device A now sends the GSTN-based T.30 device the messages and
    deletes them from its local message store.

As device A must be configured with the mapping between the 
GSTN-based fax machine and the remote email address of "device B",
it could just as easily be configured with the authentication password 
for T.30 polling, and device B could be configured with device A's
email address, and the unnecessary steps (4) through (5) would
be eliminated.  Mail would flow normally without non-compliant
extensions.

Further, if one desires to integrate with SMTP really well, perhaps
the most proper and accurate mapping between T.30 polling and SMTP
would be using AUTH+ATRN, where AUTH could even send the
base64-encoded T.30 password to the remote SMTP server, then TURN
could be used to fetch messages realtime (just like T.30).  Whee!  All
without sending T.30 bits inside of any mail messages, and all without
requiring any knowledge of T.30 at the sending system or receiving
system. 

>>3.10.  Password
>>
>>   The password, used to authenticate the recipient, is
>>   equivalent to the password necessary to retreive POP (or
>>   IMAP) messages from a POP (or IMAP) server.  Similar 
>>   authentication is available with SMTP with [AUTH], and
>>   with the password with FTP.  
>>   
>>   With SMTP, stronger authentication is available with [SMIME] or
>>   [PGP-MIME] and [SMTP-TLS], and with HTTP with [HTTP-SSL].
>>
>>   The fax offramp may wish to use the legacy machine's supplied
>>   password to authenticate the recipient.  This could be done
>>   by comparing a special field in the recipient's email address
>>   (if using SMTP), such as "/T30PASSWORD=8924".
>
>My my mind, this relates to T.30-based fax security only, and is simply not
>applicable to e-mail based security.  I base this view on the principle
>that "security cannot be gatewayed".

The security inherient with polling can be gatewayed quite
successfully using AUTH+ATRN, I think. 

-Dan Wing