Subject: RE: REVISED draft-ietf-fax-eifax-08.txt

From: "Cancio, Vivian" <[email-masked]>
Date: Mon, 26 Oct 1998 19:00:58 -0800

Here are some thoughts, in case it helps ...

If we don't know the capabilities of the (IFax) recipient, we always
first send Profile S. Note my implication that there is prior knowledge
the recipient is an "IFax" device or application. 

The current 'reporting' mechanism proposed via MDN or DSNs is an aid
that can help the IFax sender determine why the last message might have
failed and/or also what other options the receiver has to offer that
might help correct the problem or to improve the quality of the image
that was sent. It is not a replacement for a formal capabilities
discovery, this work will be developed in the MAILCAP group.
Lets not abuse of a good thing, lest we end up with nothing, until we
get true capability discovery.

Yes. We should be able to send an IFax message to just any regular email
address. Regular e-mail applications can eventually update to conform to
the additional IFax requirements.

Then ... what should we expect when we send a TIFF image (be it Profile
S) to a regular email address where the application is not yet upgraded
to support IFax? The worse case should be the same as any other
attachment that we might receive for which we don't have an application
(to open it with). It is true that the sender may possibly never know if
the receiver was ever able to open the TIFF package, if no indication is
sent back to the sender (no MDN, since it is optional and the old
application doesn't know any better). This possibility seems better than
sending a blank message, not matter which case. 

How can sending a dummy message (ever, blank or otherwise) be better
that just sending the first message in Profile S, if the hope is to get
the capabilities of a known IFax receiver?

Vivian

> >So you think users who are sending an IFax will go around sending
> >empty MDN requests to just any old email address, just for 
> the hell of
> >it? 
> 
> Yes -- if the ifax device is programmed or configured to always
> send a blank message first (to obtain recipient capabilities) the
> users will send blank messages to any email address they type
> into or configure into the device.
> 
> >That's the same as suggesting regular fax users send out faxes at
> >ramdom without some prior indication that a fax machine is on the
> >receiving end. 
> 
> We're striving for interoperability with email and fax.  Not for a 
> new private service which requires adding:
> 
>   efax: [email-masked]
> 
> to everyone's business cards.
> 
> So, yes, an ifax device would be sending ifaxes to people's normal
> email addresses.  Receiving a blank message will be confusing.

---

From: Brian Stafford <[email-masked]>
Date: Tue, 27 Oct 1998 08:51:33 +0000

"Cancio, Vivian" wrote:
> that was sent. ...

Yes, and it is *just an aid*.  Capabilities information returned in DSN/MDN
is always `stale', that is, it describes the capabilities of the receiving
device *at the time the last message was processed*.

> ... It is not a replacement for a formal capabilities

Absolutely agree.  The important thing with mailcap is that (hopefully) it
will provide a mechanism which will obviate the need for blank messages or
relying on out of date capabilities returned in DSNs or MDNs.

IMHO, the way forward for now is to live with the fact that until the first
*real* fax message is sent to a given recipient we will not know that
recipient's capabilities in advance.  Lets just forget about blank messages
etc. so as not to preempt the mailcap work.  If mailcap fails to deliver a
mechanism useful to fax, it will only be our own collective fault for failing
to participate in that WG.

> the capabilities of a known IFax receiver?

I agree with the remainder of Vivian's analysis.

-- 
Brian Stafford
OfficeLogic International Ltd.
Suite 1, Craven Hall
Sackville Street
Skipton
North Yorkshire
U.K

EMail: [email-masked]
Phone: +44 1756 702940
Fax: +44 1756 796406

---

From: James Rafferty <[email-masked]>
Date: Tue, 27 Oct 1998 11:38:45 -0500

>relying on out of date capabilities returned in DSNs or MDNs.
Right.    
>to participate in that WG.
I agree.   
>I agree with the remainder of Vivian's analysis.
ditto.   

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  
*---------------------------------------------------