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

From: "McIntyre, Lloyd" <[email-masked]>
Date: Fri, 23 Oct 1998 10:17:26 -0700

Is there a reason why the draft does not very clear state whether a
sender may issue an MDN request independent of sending a message?

"2.1.2.  Processing Confirmation

   If the sender desires processing confirmation, the sender MUST
   request Message Disposition Notification using the method described
   in section 2 of [RFC2298]."

I appreciate that the criteria may be spelled out in RFC2298, but would
it not make life easier to spell things out up front?

Lloyd

> -----Original Message-----
> From:	Larry Masinter [SMTP:[email-masked]]
> Sent:	Wednesday, October 21, 1998 4:28 PM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	REVISED draft-ietf-fax-eifax-08.txt
> 
> Dear Cynthia,
> 
> I've just spoken to my co-author on the telephone, and I would like
> to *revise* draft-ietf-fax-eifax-08.txt.
> 
> I want to add the following paragraph to the Abstract:
> 
> ========================
>    NOTE: The authors of this document have recently been made aware of
>    several intellectual property claims that relate to the technology
>    described in this document, including US patent 5812278. This
>    disclosure is being made according to the rules laid out in RFC
>    2026 and 2028, where contributors are required to disclose the
>    existence of any proprietary or intellectual property rights in the
>    contribution that are reasonably and personally known to the
>    contributor. These intellectual property claims may interfere
>    with this specification moving forward along standards track.
> =========================
> 
> Attached is a revised version of the document with this notice
> added.
> 
> 
>  << File: draft-ietf-fax-eifax-08.txt >>

---

From: Dan Wing <[email-masked]>
Date: Fri, 23 Oct 1998 11:48:39 -0700

>it not make life easier to spell things out up front?

Sorry, I don't quite understand what addition or modification to eifax
you would like to see.  

I don't see any mechanism to request an MDN without sending a message
with the MDN request ('MDN request' = 'a message with a
Disposition-Notification-To: field').

-Dan Wing

---

From: "McIntyre, Lloyd" <[email-masked]>
Date: Fri, 23 Oct 1998 11:58:38 -0700

I recall significant earlier discussion with regard to sending blank
messages with MDN request. I believe that this was deemed to be
inappropriate. My question is whether this should be clearly stated,
given that receiver rules for issuing MDN are clearly stated.

Lloyd

> From:	Dan Wing [SMTP:[email-masked]]
> Sent:	Friday, October 23, 1998 11:49 AM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked]; [email-masked]
> Subject:	RE: REVISED draft-ietf-fax-eifax-08.txt
>

---

From: Dan Wing <[email-masked]>
Date: Fri, 23 Oct 1998 12:10:47 -0700

Oh, yes, okay.  I understand now.

The proposal to send a blank message was to obtain capabilities of the
recipient - a blank message wasn't used for processing confirmation.
However, I agree we should clarify this to avoid interoperability problems 
with normal email.

What does everyone think of this revision to two the following two
sections:

  2.1.2.  Processing Confirmation

     If the sender desires processing confirmation, the sender MUST
     request Message Disposition Notification [RFC2298 section 2]
     when sending the message itself.

and:

  3.3.  Capabilities Returned in MDN or DSN

  ...

  The sender MUST NOT send a message to the recipient soley to elicit an 
  MDN or DSN message from the recipient containing capability information.  
  Doing so with a blank message or a message containing fax-specific
  request-for-capabilities will confuse any recipient not already
  designed to understand the semantics of such a message.

-Dan Wing

---

From: "McIntyre, Lloyd" <[email-masked]>
Date: Fri, 23 Oct 1998 12:20:36 -0700

Section 3 contains references to the SYNTAX, REPORTING-EXTENSION and
SCHEMA drafts but omits the REGISTRATION draft. Should REGISTRATION not
be included in the set?

Lloyd

---

From: "McIntyre, Lloyd" <[email-masked]>
Date: Fri, 23 Oct 1998 12:15:55 -0700

The question has be asked, what should be done when a receiver wishes to
indicate support for only Profile S features in responding to a DSN or
MDN request that contains the reporting extension for capabilities?
Should there be no "media-feature-tags " response or should there be a
response with content of null or the Profile S feature list?
 
Is this a question better addressed in the Reporting document?

Lloyd

---

From: Dan Wing <[email-masked]>
Date: Fri, 23 Oct 1998 12:24:59 -0700

>Is this a question better addressed in the Reporting document?

RFC2305 allows sending Tiff Profile S to anyone and anything.

I agree it is the job of -eifax- to require indication of support
for Tiff Profile S to be present or allowing the lack of indication
to imply support.

My opinion is to follow what MIME has done here already with
text/plain.  MIME recommends using "Content-Type: text/plain" for
plain-text messages which is redundant (because omitting the
Content-Type causes the deafult -- text/plain -- to be assumed). 
However, it is somewhat valuable because the recipient knows the
sender is MIME-aware and has properly formatted the document and
formatted it per the rules of text/plain.  

I think recommending a similar thing in -eifax- (with "SHOULD") is
proper.

We can also strengthen the wording recommending DSN/MDN be used
for capabilities until something better comes along (from the
MAILCAP working group).

-Dan Wing

---

From: "McIntyre, Lloyd" <[email-masked]>
Date: Fri, 23 Oct 1998 12:32:18 -0700

Please see below.

Lloyd

> Sent:	Friday, October 23, 1998 12:11 PM
> Cc:	[email-masked]; [email-masked]; [email-masked]
	[McIntyre, Lloyd]  I am not sure about this sentence. I believe
I agree with the intent. If I have never communicated with client A
before. Must I not send a message to A in order to elicit a response and
capture  the capability information?

>   [McIntyre, Lloyd]  The sender MUST NOT send a blank message to the
> recipient to elicit an MDN or DSN message from the recipient
> containing capability information. 
	[McIntyre, Lloyd]  This I understand.

---

From: Dan Wing <[email-masked]>
Date: Fri, 23 Oct 1998 12:41:40 -0700

>capture  the capability information?

Read the sentence carefully:  "... soley to elicit...".

If the message ALSO contains content the recipient is supposed
to use, the message is NOT being sent *soley* to elicit an MDN/DSN
response.

If you agree with this but would like better wording, please suggest 
wording.  Perhaps just capitalizing "soley to elicit" would be 
sufficient.

-Dan Wing

---

From: "McIntyre, Lloyd" <[email-masked]>
Date: Fri, 23 Oct 1998 12:40:58 -0700

Dan,
I would support your proposals.

Lloyd

> Sent:	Friday, October 23, 1998 12:25 PM
> Cc:	[email-masked]; [email-masked];
> [email-masked]; [email-masked]

---

From: Dan Wing <[email-masked]>
Date: Sat, 24 Oct 1998 9:22:47 -0700

>Read the sentence carefully:  "... soley to elicit...".

But, as was pointed out to me, ignore my incorrect spelling.  It
should have been:

  "... solely to elicit ..."

The wording in -09 removed this phrase but retains the meaning:

   A sender MUST NOT send a message with no processable content to
   attempt to elicit an MDN/DSN capability response.  Doing so with a
   message with no processable content (such as a message containing
   only a request for capabilities or a blank message) will confuse a
   recipient not already designed to understand the semantics of such a
   message.

-Dan Wing

---

From: Graham Klyne <[email-masked]>
Date: Sat, 24 Oct 1998 20:54:57 +0100

>wording.  Perhaps just capitalizing "soley to elicit" would be 

Dan,  a thought for you...

"... message with no content or intent other than to elicit ..."

I'm thinking this might be a (rare) case when using more words to make a
point serves to emphasize that point.

#g

------------
Graham Klyne
([email-masked])

---

From: Graham Klyne <[email-masked]>
Date: Sat, 24 Oct 1998 20:54:54 +0100

>response with content of null or the Profile S feature list?

To follow up on Dan's response, I think:

(a) that, per RFC2305, in the absence of any explicit capability
information, the sender should assume a capability "feature set" equivalent
to TIFF Mode S.

(b) a receiver that supports RFC2305 should be encouraged (but not
required) to send a report indicating as much, to promote interworking with
non-Ifax systems that may use the same capability identification framework.

Thus, to answer Lloyd's question, I think a non-null capability response is
more helpful.

I think this has similar effect to Dan's response in this matter.

#g

------------
Graham Klyne
([email-masked])

---

From: Geoff <[email-masked]>
Date: Sun, 25 Oct 1998 07:48:23 -0800

I'm curious to know the motives behind this paragraph.

It's got to be a very poorly coded off-ramp that gets 'confused' by *any* empty, incomplete, or badly composed message, with or without an MDN request. 
So what is the real reason for inserting it?

Geoff

----------
From: 	Dan Wing
Sent: 	Saturday, October 24, 1998 8:22 AM
To: 	[email-masked]
Cc: 	[email-masked]
Subject: 	RE: REVISED draft-ietf-fax-eifax-08.txt

-Dan Wing

---

From: Dan Wing <[email-masked]>
Date: Sun, 25 Oct 1998 8:56:10 -0800

>So what is the real reason for inserting it?

The reason is: Not every recipient is an offramp.  

-Dan Wing

---

From: Dan Wing <[email-masked]>
Date: Sun, 25 Oct 1998 20:27:00 -0800

>I do not know the behavior of common MUAs when they receive a IFAX message
>or a IFAX TIFF file -- MS Outlook, Netscape, Eudora, pine, elm,
>existing mail->fax gateways, Lotus cc:Mail, exmh, mutt, pagasus mail,
>etc.
>
>What is the user's behavior?

Confusion.

-Dan Wing

---

From: Geoff <[email-masked]>
Date: Mon, 26 Oct 1998 09:20:42 -0800

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?

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.

Geoff

----------
From: 	Dan Wing
Sent: 	Sunday, October 25, 1998 8:56 AM
To: 	[email-masked]
Cc: 	[email-masked]
Subject: 	RE: REVISED draft-ietf-fax-eifax-08.txt

-Dan Wing

---

From: Dan Wing <[email-masked]>
Date: Mon, 26 Oct 1998 8:04:19 -0800

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

Today, a blank message is only received when the sender hit SEND 
prematurely or the sending mailer lost the content (due to a disk 
error or index file error).

And there is no human language-neutral way of asking for an MDN.  And
even if there were, few users will understand what an "MDN" is, so 
asking:  "Please allow your software to generate an MDN including
your capabilities" is not possible.

-Dan Wing

---

From: Geoff <[email-masked]>
Date: Mon, 26 Oct 1998 19:17:50 -0800

See below

----------
From: 	Dan Wing
Sent: 	Monday, October 26, 1998 8:04 AM
To: 	[email-masked]
Cc: 	[email-masked]
Subject: 	RE: REVISED draft-ietf-fax-eifax-08.txt

Disagree, they'll send it to an address whose 'owner' has declared it to be his Internet Fax Address, and  MDN's will work just fine for capabilities requests.

>ramdom without some prior indication that a fax machine is on the

We're striving for interoperability with email and fax.  

And failing abysmaly because you do not consider the needs of the fax user, only the those of the email user.

Not for a 

This will happen anyway. Many IFax users won't need or want a regular email address, or it could be the address of a single device that is used by many people, just like most fax machines. Plenty of email users would like a second address whose messages are always printed, and a second email address is the only way of doing it. 

By striving for interoperability solutions that only work for email users, and not 'fax' users, the latter will either bend your rules or come up with something totaly different that doesn't talk to email at all....like IPP maybe.

email addresses.  

Rarely ! There won't be many IFax devices out there without ways of getting reliable receipt confirmation and capabilities information and eifax seems specially designed to avoid providing them.

Receiving a blank message will be confusing.

Doesn't need to be blank.
Try something like.

You've published this address as your Internet Fax Device. This message is a standard request for it's capabilities. To provide them please switch on receipt confirmation. 

The smart devices could put it in the correct language by getting the country from the recipient's address.

Or you and Larry try to make a point on this list :)

And there is no human language-neutral way of asking for an MDN.  And
even if there were, few users 

You are just thinking about email users, but the very title of your document pretends it has something to do fax. Why not try thinking about fax users for a change?

will understand what an "MDN" is, so 

Perhaps not but call it receipt confirmation as per the latest versions of Netscape, Eudora et al and most will know what is being requested. 

-Dan Wing

Disagree. See message above. A user who has just installed his wonderfull new IFax device will be delighted to accept assistance on how to get it to work properly. 

Geoff

---

From: Graham Klyne <[email-masked]>
Date: Tue, 27 Oct 1998 11:20:58 +0000

At 08:54 26/10/98 -0500, James  Rafferty wrote:
[...]
>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.

Or, better still, send the image you would prefer to send if the receiver
could process it, and fall back later if it turns out to be unusable?

#g

------------
Graham Klyne
([email-masked])

---

From: Dan Wing <[email-masked]>
Date: Tue, 27 Oct 1998 10:28:01 -0800

>> Sure, we could, but -eifax- doesn't permit this today.  If we all
>> think this is a good change, we'll have to change -eifax-.  However,
>> note that this will not work with existing mailers which cannot
>> generate a "I couldn't process the attachment" MDN.
>
>
>You *can* send "the image you would prefer to send if the receiver
>could process it" along with a minimum S profile, using
>multipart/alternative.
>I don't see why this isn't permitted...

Sure, that's fine and would be allowed.  I'll add text so that's 
clearer.

-Dan Wing

---

From: "McIntyre, Lloyd" <[email-masked]>
Date: Tue, 27 Oct 1998 11:58:49 -0800

> From:	Graham Klyne [SMTP:[email-masked]]
> Sent:	Tuesday, October 27, 1998 3:21 AM
> To:	James Rafferty
> Cc:	[email-masked]
	[McIntyre, Lloyd]  This is my vote.

	Lloyd

---

From: Graham Klyne <[email-masked]>
Date: Wed, 28 Oct 1998 11:56:36 +0000

At 07:19 27/10/98 -0800, Ned Freed wrote:
>> The Content-disposition:metadata proposal springs to mind as *part* of any
>> possible approach.
>
>I completely agree that content-disposition tagging should be part of
this, but
>I'm not convinced the metadata tag is appropriate here.
>

[...]
>Finally, getting back to the possible use of a "metadata" disposition,
>I don't see this as a sufficiently strong indicator. Metadata translates
>to "don't display", it does not translate to "receipt and discard if
possible".
>And the latter is what we want if we can get it.

Accepting various other points you make, I point out that I was thinking of
"metadata" simply as a possible way of reducing display of what you call
"administrative non-mesage".  I didn't expect it to carry the other
implications you mention.

On reflection, I see the administrative non-message is going to be a
difficult nut to crack.  I think that any header used for this purpose
would need to be defined as a message header rather than a content header.
So "content-disposition" is maybe not the best way to carry this (since it
can be applied to inner MIME parts)?

#g

------------
Graham Klyne
([email-masked])

---

From: Graham Klyne <[email-masked]>
Date: Wed, 28 Oct 1998 11:56:40 +0000

At 11:35 27/10/98 -0500, James  Rafferty wrote:

[...]
>Unless a method is invented, they don't (yet)!  I see that GK has a thought
>about this.   

In the light of Ned's response, I don't think my thought is going anywhere.

The problem seems to be:  how to supress "administrative non-messages".

I had an idea that "content-disposition:metadata" might help, but on
reflection, that only supresses display of the content, not the message
(i.e. not its inbox listing).  So one effectively has a blank message,
which is not a Good Thing.

#g

------------
Graham Klyne
([email-masked])

---

From: Graham Klyne <[email-masked]>
Date: Wed, 28 Oct 1998 11:56:38 +0000

>generate a "I couldn't process the attachment" MDN.  

That was a flawed suggestion.

As Vivian pointed out, in this scenario I think it would be better to send
TIFF-S first time around.

#g

------------
Graham Klyne
([email-masked])