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

From: "Chan, Roger" <[email-masked]>
Date: Wed, 10 Mar 1999 14:34:29 -0500

Larry,

While I appreciate your intention, I am afraid that your proposal will raise
the blood pressure of quite a few product development people.  Can you
achieve the same goal by adding an optional addendum to the current document
without changing the original spec?  

Along the line, I would appreciate if you could summarize your proposal of
requirements to make Simple Mode devices interoperable with Extended Mode
devices, preferably in bullets to reduce the chance of mis-interpretation.
The reason I'm asking is we are still in the developmental stage of a 2Q
product.  We know we can't do an extended mode implementation but we might
be able to justify a little additional effort if the end result will allow
us to advertise interoperability with extended mode devices.  The base line
is we have to be compliance with today's Simple Mode.  

Thanks in advance!
Roger

> ----------------------------------------------------------------------
> Roger Chan
> GMO/WPBU/CST/Internet Services
> 800 Phillips Road  MS 0111-02J
> Webster, NY 14580
> Email: [email-masked]
> Phone: 716-422-5771  (8*222-5771)
> Fax: 716-422-2350 (8*222-2350)
> ----------------------------------------------------------------------

-----Original Message-----
From: Larry Masinter [mailto:[email-masked]]
Sent: Wednesday, March 10, 1999 1:53 PM
To: [email-masked]
Subject: combining "simple mode" and "extended mode" documents

I think that as we move to Draft Standard, we should
combine the two documents of "simple mode" and
"extended mode", in order to clarify a misunderstanding.

Apparently some groups believe that "simple mode"
devices cannot request DSNs or MDNs, even though those
mechanisms are, in fact, still optional.

So I'd like to have a single document which points out
a "minimal compliance" which corresponds to "simple mode"
but which contains all of the recommended mechanisms
that constitute "extended mode".

This won't break any current implementations, as far
as making them non-compliant, but it will encourage
additional fuller implementations.

Along the way, I do think it is useful to consider the
results of interoperability testing, as we move from
"proposed" to "draft".

There was an enormous pressure to complete "simple mode"
by only including those facilities that we could agree
on quickly. 

As we move forward, though, let's consider the full
goals of Internet Fax, and recommend those components
that actually accomplish the goals. I don't want to
make current "simple mode" implementations non-compliant,
but I think that a combined draft that recommends
confirmation and capability exchange when feasible
would improve the functionality of "Internet Fax".

Larry

---

From: Dan Wing <[email-masked]>
Date: Wed, 10 Mar 1999 13:00:43 -0800 (PST)

> is we have to be compliance with today's Simple Mode.  

I believe Larry is proposing a document which would have a table
of contents similar to this:

  1. Introduction
  2. Simple Mode
     (essentially the text of RFC2305)
  3. Enhanced Mode
     (essentially the text of draft-ietf-fax-eifax-XX.txt)

Regarding your statement "will raise the blood pressure of quite a few
product development people", I don't see how combining RFC2305 and -eifax-
makes development more difficult.  It could make marketing more difficult
because instead of saying "Compliant with RFC2305" a product would have
to say "Compliant with Simple Mode of RFCnnnn" which implies a less-than-
full-featured implementation -- something marketing people never really
want to call out and make obvious to customers.

-Dan Wing

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 10 Mar 1999 18:01:59 PST

>      (essentially the text of draft-ietf-fax-eifax-XX.txt)

Actually, I'm imagining a document which has a table of contents:

1. Introduction (from -service-v2- and -eifax- section 1)
   with a note about "Simple Mode" denoting the minimum
   capabilities required to be compliant
2. Communication protocols
2.1 Transport (from -service-v2-)
2.2 Formats (from -service-v2-)
2.3 Delivery and Processing Confirmation (from -eifax- section 2,
   noting that these methods are optional for simple mode)
3 Addressing (from -service-v2-)
4. Image File Format (from -service-v2-)
5. Additional Document Capabilities (from -eifax- section 3
   noting that these methods are optional for simple mode)

Larry
-- 
http://www.parc.xerox.com/masinter