Subject: Comments on Goals-03

From: James Rafferty <[email-masked]>
Date: Wed, 16 Sep 1998 18:33:12 -0400

Larry,   

I reviewed the Goals-03 document prior to releasing it for WG Last Call.  
It looks like its in pretty good shape to me.  I have a few minor comments.   

By section:   

Section 2.1 (last paragraph)

>When the fax has been sucessfully transmitted, the sender receives a
>"confirmation": an indication that the fax content was delivered,
>received, and processed.  This "confirmation" is an internal signal
>and is not normally visible to the sending user, although some error
>messages are visible, to allow a page to be retransmitted.

As pointed out in the communication from the ITU, not exactly.   

I think the words "received, and processed" whould be deleted from 
the first sentence to more accurately reflect what is happening
in the protocol.   (see related comments later).  

Section 2.4 Internet Fax Devices

>The Internet Fax roles may be embedded in a variety of combinations
>and configurations within devices and larger applications.  They may
>be combined with other elements, e.g., a traditional T.30 fax
>device. Many different configurations of applications should {2} be
>able to participate in Internet Fax; the specification should not
>unnecessarily restrict the range of devices, applications and services
>that can participate.

I'd propose adding the words "and systems" after "Many different
configurations of applications " .   

2.5  Operational Modes for Internet Fax

Revise the sentence on real time fax:  

>"Real-time" Internet Fax allows for two [T.30] standard facsimile
>terminals to engage in a document transmission in a way that all of
>the [T.30] communication protocol is preserved.

to read:

"Real-time" Internet Fax allows for two [T.30] standard facsimile
terminals to engage in a document transmission in a way that all of
the essential elements of the [T.30] communication protocol are preserved
and  there is minimal elongation of the session as compared to Group 3 fax
over the GSTN.   

4.3  Confirmation

....
>Originally, fax "confirmation" indicated that the message was recieved
>and processed, e.g., delivered to the output paper tray of the
>recipient fax device. With the addition of memory buffering and
>PC-based fax modems, traditional fax confirmation still indicated some
>assurance of processability; e.g., a fax modem would not confirm
>receipt of an incoming fax if it required compression mechanisms that
>were not supported.
>
To make it more accurate, I'd propose revising it to read:  

"Originally, fax "confirmation" implied that the message was received
and processed, e.g., delivered to the output paper tray of the
recipient fax device.   In reality, this implication was relying upon a
signal produced by the receiving terminal that the incoming page had been
inspected
and was determined to be of reasonable (or unacceptable) quality, via an
unspecified algorithm.   

In later devices which support error correction mode, the ECM method [per
T.30]
enabled error checking via a specific algorithm, providing a more exact
indication 
that the bits within the compressed image were not corrupted during
transmission.  
With the addition of memory buffering, PC-based fax modems and the more
common use of error correction mode, traditional fax confirmation still
implies some assurance of processability; (e.g., a fax modem would not be
able to receive an incoming fax if it required compression mechanisms that

were not supported) without reporting on whether the image has been
printed or viewed. "

And, for continuity in the following paragraph:   

>Still, this is not the same as a confirmation that the message was
>"read": that a human had confirmed that the message was
>received. Confirmation that the message was read (above and beyond the
>notification that the message was delivered) is desirable {3}, but not
>required.

Revise to read:  

"Consequently, the fax confirmation is not the same as a confirmation that
the message was "read": that a human had confirmed that the message was
received. Confirmation that the message was read (above and beyond the
notification that the message was delivered) is desirable {3}, but not
required."

5.4 Goals for Security

...

>
>In the case where the sender is responsible for payment for offramp
>services in a remote location, it is desirable {3} to provide for
>authentication of the sender and billing information from the offramp
>to be negotiated securely.

Revise to read: 

"In the case where the sender is responsible for payment for offramp
services in a remote location, it is desirable {3} to provide for
authentication and authorization of the sender, as well as enable billing
related information from the offramp to be transferred securely."

(note:  The AAA activity that just started in the IETF may be useful when we
get down to specifics for Offramp drafts.)  

That's all the comments I have.  

James 

*------------------------------------------------*
James Rafferty			
President, Human Communications 	
12 Kevin Drive			
Danbury, CT  06811-2901		
USA					
Voice/Fax:  +1-203-746-4367
Email:  [email-masked]
	 [email-masked]

HC Web Site:  http://www.humancomm.com  
*---------------------------------------------------