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

From: Dan Wing <[email-masked]>
Date: Mon, 26 Oct 1998 16:02:57 -0800

James Rafferty wrote:
> At 02:44 PM 10/24/98 +0900, MAEDA toru wrote:
> >McIntyre-san and Wing-san
> >
> >Can I send a dummy message or a dummy TIFF file with MDN request?
> >
> >Regards.
> >
> >Toru MAEDA
> >CANON Inc.
> >
> The principle we talked about in August was the following.
> 
> In the event a recipient is unable to process an incoming image/tiff
> attachment,
> the recipient should report this using an MDN or an MTA can send back a DSN
> on behalf of the recipient as has been specified in -eifax.
> 
> So, if the primary intent is to elicit a capabilities report using the new
> DSN or MDN reporting extension defined in "reporting-extensions", the best
> way to elicit this is to send a TIFF file that one does not believe the
> receiver will be able to process.  

RFC2305 prohibits this, and -eifax- doesn't allow this, so it remains
prohibited by -eifax-.

>This could be a very small  image file
> and still be valid.   So, it is much better to send a TIFF file to elicit
> this response rather than a blank or text message that could easily be
> mis-interpreted.

But there needs to be a computer-parsable mechanism for the recipient to
understand the image isn't to be "processed":  or else it will try to
process the image by displaying it to the user or transmitting it (in
the case of an offramp).

However, there is no computer-parsable mechanism that is understood
by the millions of existing MUAs which says "do not show this message to
the user, simply respond with an indication of your capabilities".
While I think we may be able to extend MDNs to indicate capabilities,
I doubt we'll be able to create a "do not show this message to the
user" mechanism.  Unfortunately, the existing
Disposition-Notification-Options looks like a possibility at first
glance, but it is applicable only to disposition notifications -- we
need something that is applicable to "non-processing".

The written proposal on the floor, draft-ietf-fax-mime-fullmode-01.txt,
indroduces a new concept:  ignoring (not processing) blank messages.

My experience with users is different from everyone else's experience.
However, my experience tells me a blank message will cause a user
to delete it immediately or press the Reply button and send 
"John, did you intend to send me something?".  Given to opportunity
to answer "did you read the message", I suspect most would answer
"no" because the message is, in fact, blank!

The stronger wording in -eifax- for generating an MDN or DSN if the
attachment isn't processable (section 5.2) is only to increase
reliability.  It is only an implementation note.  There is still no
assurance that the sender will receive a message indicating the
recipient failed to process the message, or will receive the recipient's
capabilities in that failed-to-process message.

> By sending an image/tiff file with one of the the fax orientedapplication 
> parameter, this is a clear indication that fax imagecontent is being sent;  
> otherwise the recipient may have no idea thatthere is an interest in 
> Internet fax.

Um, so we send something like the attached?

What if the recipient reads only German?  Or Japanese?  Or -- one of the
worst cases -- can't read my handwriting, can't decode the message at
all and struggles for hours and hours trying to find an appropriate
image viewer ??

If we want to send an image/tiff, how is an offramp, or an MUA, or an
ifax black box, supposed to know it isn't supposed to process the
message?

-Dan Wing

---

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

At 04:02 PM 10/26/98 -0800, Dan Wing wrote:
>--ABC
>Content-Type: text/plain
Right.   (sigh)
>> this response rather than a blank or text message that could easily be
My key point was that a TIFF file should be sent; for now, a profile S file
is 
probably best, since it is always legal (as  Vivian has noted).  
>the user, simply respond with an indication of your capabilities".
Indeed.   

>indroduces a new concept:  ignoring (not processing) blank messages.
I
>"no" because the message is, in fact, blank!
I agree that blank messages are confusing and are not desirable, for the
reasons you note.     
>capabilities in that failed-to-process message.
What I was getting at in my previous message was that if the attachment
isn't processible, there should be a notification back (as per -eifax).
And, this would also seem to imply that the sender DOES NOT know the
capabilities of the recipient and that the recipient may want to notify the
sender of their capabilties.  

What I'm thinking of is some text like: 

"In the event that a fax image attachment is received that is not
processible and the sender is known to the recipient, the recipient or
associated MTA may wish to use the mechanism defined in 3.3 to inform the
sender of its capabilities. "   

Your thoughts?  

>all and struggles for hours and hours trying to find an appropriate
My point is that unless an image/tiff file is sent, the recipient will have
no idea that we are even interested in Internet fax and a list of
associated capabilities.   So, if they can't process the message and the
sender is known to them, it would be useful to send back the "not
processible" message via DSN or MDN (as has been specified) AND the list of
capabilities.   For security reasons, I don't think we can go any further
than that using this (DSN/MDN) approach.   
>ifax black box, supposed to know it isn't supposed to process the
Unless a method is invented, they don't (yet)!  I see that GK has a thought
about this.   

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