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

From: Michael Crawford <[email-masked]>
Date: Wed, 10 Mar 1999 14:06:36 -0800

Here, Here !  I'd much rather split out RFC2305 and extended features.

If is important to have the extension or blissfully ignore extensions we
need to
say that directly, and if necessary refer to a separate RFC which lists the 
extensions to simple mode.  In this way we can say we are RFC2305 compliant,
Simple Mode compliant, and still not have to address the options
specifically.

I would recommend we make sure optional or extended functionality be
specifically
called out as optional or extensions AND ensure that if we believe it
necessary to
"play through" an optional or extension request, then state that as well.  

In other words, "receive options/extensions gracefully, send rigorous simple
mode".

Michael Crawford
iReady Corporation

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

> -----Original Message-----
> From:	Dan Wing [SMTP:[email-masked]]
> Sent:	Wednesday, March 10, 1999 1:01 PM
> To:	Chan, Roger
> Cc:	Masinter, Larry <[email-masked]>; [email-masked]
> Subject:	RE: combining "simple mode" and "extended mode" documents
> 
> On Wed, 10 Mar 1999 14:34 -0500, Chan, Roger wrote:
> 
> > 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.  
> 
> 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: Graham Klyne <[email-masked]>
Date: Fri, 12 Mar 1999 16:46:15 +0000

I think it's sad that the utility of RFC2305/RFC2532 is sometimes perceived
to be in their names rather than their content.

As an *engineering* group, should not our goal be to present the required
engineering detail in the form most conducive to effective quality
implementations?

#g

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

---

From: Graham Klyne <[email-masked]>
Date: Sat, 13 Mar 1999 16:38:35 +0000

At 11:55 12/03/99 -0800, Cancio, Vivian wrote:
>	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. [...]

It's good to see a post on this topic that addresses the content.

You raise a number of good points, which I hope the authors have noted.
Reading them, I think that combining the documents would probably help to
overcome some of the confusions that you describe, by emphasizing that the
optional features are part of the same basic service.

>	There is also the separate issue of 'marketing'. [...]

A separate issue indeed.  I hope we can leave this to marketing departments.

#g

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