Subject: RE: combining "simple mode" and "extended mode" documents

From: "Cancio, Vivian" <[email-masked]>
Date: Fri, 12 Mar 1999 11:55:27 -0800

The improvements that I would see necessary might be in clarifying
misunderstandings that seem to exist with simple mode and to encourage more
support of the extended mechanisms, when ever possible. Many people assume
that in simple mode it says "... you shall not do that ...", when in fact it
says "... you need only do this ... " . For example, even though in regular
email you can request DSNs and MDNs etc., some think that you can-not-do
that if (any end) operates in "simple" mode, which is a misunderstanding.
Also, in simple mode, "if-you-KNOW-the-recipients document processing
capability", you can send any other Profile defined in RFC2301. It doesn't
matter how you found out the capabilities of the recipient. But if you DON'T
know what the capabilities are, then you MUST send Profile S.
	Some also think that the sender must know if the recipient is able
to respond to a DSN or MDN before they can request one, which is incorrect.
You can implement the extensions to IFax and if you follow the
specifications, you will not break anything if the recipient happens to be a
"simple-minded" device. Of course, you will not request DSN and MDNs
response if you don't care to have the feedback. 
	If we do revise or join the RFCs (however we do it), maybe it can
clarify these concepts. It doesn't break anything and perhaps encourages
vendors to make ALL IFax devices more useful. 
	The text in the RFCs was carefully drafted to make sure it did not
impose unnecessary limitations (which do not exist in the email transport),
and yet be able to sustain interoperability between embedded devices and
regular email users.
	There is also the separate issue of 'marketing'. There are
advantages of given some 'label' to "a set of features", thus keeping the
sets separate for better advertising to the customers what they are getting
for the money. So while one RFC implies limitations, the other RFC implies
'fullness' of features.  

	Vivian

---

From: Dan Wing <[email-masked]>
Date: Fri, 12 Mar 1999 17:08:48 -0800 (PST)

> know what the capabilities are, then you MUST send Profile S.

RFC2305 probably should be clarified in that regard.

Specifically, the content of a message cannot be anything but TIFF Profile
S unless you know (via some mechanism) that the recipient can support
something different.

But it is legal in RFC2305 (without EIFAX) to use enhanced mail features,
such as DSN, ENHANCEDSTATUSCODES, MDN, SIZE, etc., to provide better
message delivery, delivery confirmation, or 'processing' confirmation.

Additionally, I think RFC2305bis (-service-v2-) should caution
implementors about including any content in the message beyond the
document body itself (such as a coverpage or such as instructions for how
to 'view' the attachment).  We can't reference Mike Ruhl's I-D because
Mike's I-D isn't at Draft Standard, which is the main goal, I think, with
the fine-tuning of RFC2305bis.

> response if you don't care to have the feedback. 

If you request a DSN and get back a "relayed" message, you know which
mailer in the path to the recipient doesn't support DSN.  Solutions are to
upgrade that mailer to support DSN.

This is sortof like driving a large truck down the highway:  if a bridge
is too short, solution is to go around the bridge (use another road) or
upgrade the bridge.

> for the money. So while one RFC implies limitations, the other RFC implies

-Dan Wing