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

From: Michael Crawford <[email-masked]>
Date: Thu, 11 Mar 1999 10:09:00 -0800

Oh, sorry.  Pardon me, I have not been in the loop very long and may repeat
points that have been discussed but rejected.  Please inform me this is the
case...however, here is the position as we see it:

1.  The RFC 2305 section SUMMARY prior to section one, SCOPE, says
"extensions will follow".  I believe that statement is confusing and leads
the reader to go looking for those extensions in the 2305 document.  My
position is that the statement should reference the footnotes

2.  The footnotes should point to an extension document which is marked
OPTIONAL in a hundred different ways.  This document
in turn should discuss how the extensions SHOULD apply and perhaps refers
back to RFC2301.

3.  The current RFC2305 section must address the fact that transport should
not care whether the TIFF profile is of a 
particular value or  not.  In the current document this seems to be assumed
but not stated.  This allows improper interpretation.

4.  Real world devices probably need not be strict in accepting (receiving)
any TIFF images they can process, however, for
compatability reasons, sending (Transmitting) TIFF Images should be limited
to Simple Mode Profile S only.  This should be added to RFC2305, since
implementors will need to be aware that sending is probably more critical in
terms of compatiblity then receiving.    "The fax device will process TIFF
images it can deal with and reject those it cannot, and only send TIFF
Profile
S images. At a minimum the fax device will be able to process TIFF Profile S
images..." something of that sort.

5. Full Mode should be discussed as an extension. Reference to full mode
(RFC 2301) is not only appropriate but required.
However, the RFC2305 should state clearly that Simple Mode is a subset of
the Full Mode operation.

6.  The RFC2305 does not address how a simple mode compliant machine can
also be FULL mode compliant...thus it is not
clear how an implementor would have BOTH simple mode and full mode
implementations in the same device.  I realize 
negotiation is not part of 2305, but this needs to be addressed...perhaps by
indicating that a request for negotiation to a 
simple mode only machine will fail and this means "fall back" to simple mode
by the device requesting negotiation (the requestor assumes a failure to
negotiate MEANS implicitly that only simple mode is available and acts
accordingly).  This also will 
help us in terms of JetSend, IPP, Salutations, or other tranport/negotiation
methods that come about in the future...we always
ensure the simple mode device can operate cuz all others fallback to simple
mode.

- Mike

> -----Original Message-----
> From:	Dan Wing [SMTP:[email-masked]]
> Sent:	Wednesday, March 10, 1999 3:15 PM
> To:	Michael Crawford
> Subject:	RE: combining "simple mode" and "extended mode" documents
> 
> On Wed, 10 Mar 1999 14:06 -0800, Michael Crawford wrote:
> 
> > Here, Here !  I'd much rather split out RFC2305 and extended features.
> 
> (Sorry, I didn't quite understand your email)
> 
> So - you like things as they are, correct?
> 
> -d
> 
> 
> > 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: Dan Wing <[email-masked]>
Date: Thu, 11 Mar 1999 13:00:27 -0800 (PST)

On Thu, 11 Mar 1999 10:09 -0800, Michael Crawford wrote:

One meta-comment:  the terms "Full Mode" and "Simple Mode" are absolutely
LOADED with meanings for people.  However, some of the features attributed
to "Full Mode" are impossible to implement with a potentially disconnected
recipient, and thus are not implementable using SMTP -- especially if the
implementor does not want to place requirements on the SMTP infrastructure
to support SMTP service extensions which would permit similar end-user
behavior to be experienced.

Thus, I would really prefer to not use "Full Mode" or "Simple Mode".  In
EIFAX we eliminated this as much as possible, and in RFC2305 it exists
so that the ITU would clearly understand that RFC2305 is the IETF's
"simple mode fax-over-email" document.

Larry's "Goals" document does clearly define the goals of Internet
fax, but that, too, does not use terms such as "Full Mode" which are
loaded with meaning depending on the context and the speaker.

> position is that the statement should reference the footnotes

So, for new wording, would something like this be better:

OLD:
   This specification provides for "simple mode" carriage of facsimile
   data over the Internet.  Extensions to this document will follow.
NEW:
   This specification provides for "simple mode" carriage of facsimile
   data over the Internet.  Other documents which extend this "simple
   mode" will follow [EIFAX].

> OPTIONAL in a hundred different ways. 

A product can be compliant with RFC2305 without being compliant with
EIFAX -- that was the intent and that is the case today.  I'm unclear why
a forward reference to a non-specific doucument needs to be quite so
explicit in saying it is non-normative.  The simplier solution is to
not mention the extension document at all in RFC2305 (or
draft-ietf-fax-service-v2).

> This document

RFC2305, you mean?

> but not stated.  This allows improper interpretation.

see my response to (4), below.

> images..." something of that sort.

Section 2.2.3 of RFC2305 states:

  2.2.3     Content
 
   The data format of the facsimile image is based on the minimum set of
   TIFF for Facsimile[6], also known as the S profile.   Such facsimile
   data are included in a MIME object by use of the image/TIFF sub-type
   [19].  Additional rules for the use of TIFF for Facsimile, for the
   message-based Internet facsimile application, are defined later.

what specific change would you like to see?  It seems to clearly require
the "S" profile of TIFF, as described in RFC2305's reference [6].

> (RFC 2301) is not only appropriate but required.

"Full mode" is not RFC2301.  RFC2301 merely describes the various file
formats of TIFF that are acceptable for "Internet Fax".  There is no
protocol mechanism to determine if a recipient can understand anything
beyond "TIFF profile S" other than the new stuff described in
draft-ietf-fax-eifax and its companion documents (which use CONNEG syntax
and MDNs or DSNs to indicate supported capabilities).  We're waiting on
the RESCAP/MAILCAP WG for a solution that doesn't require a low-quality
TIFF profile S message to be sent first.

> However, the RFC2305 should state clearly that Simple Mode is a subset of

EIFAX states clearly that EIFAX is a superset of RFC2305.

I am sure there is an example, but I can't think of something that
declares itself as a subset of something larger -- certainly with the
current desire of some folks to keep Simple Mode (RFC2305) and EIFAX
separate documents with separate editing timeframes and the like, we
can't have two companion documents issued at the same time which 
reference each other easily -- one will always be "out in front"
of the other.

> 6.  The RFC2305 does not address how a simple mode compliant machine
> can also be FULL mode compliant...

I don't understand: A simple mode machine could implement IMAP, HTTP, IPX,
PPP, or half a dozen other features and functionalities.

Why does RFC2305 need to explain what else an implementor could do?  That
is the job of another document which describes a different feature --
namely, that is the job of draft-ietf-fax-eifax.

> thus it is not clear how an
> implementor would have BOTH simple mode and full mode implementations
> in the same device.

draft-ietf-fax-eifax explains how to do this -- draft-ietf-fax-eifax is a
superset of RFC2305 and explains the additional features that should be
provided to be compliant with draft-ietf-fax-eifax.

Note that draft-ietf-fax-eifax might not be the same as "Full Mode" -- I
have never seen a description of "Full Mode" that is implementable over
unextended SMTP in the absense of SLAs between the sender and receiver.

> I realize negotiation is not part of 2305, but
> this needs to be addressed...perhaps by indicating that a request for
> negotiation to a simple mode only machine will fail and this means
> "fall back" to simple mode by the device requesting negotiation (the
> requestor assumes a failure to negotiate MEANS implicitly that only
> simple mode is available and acts accordingly).  This also will help
> us in terms of JetSend, IPP, Salutations, or other
> tranport/negotiation methods that come about in the future...we always
> ensure the simple mode device can operate cuz all others fallback to
> simple mode.

I believe you'll find that in draft-ietf-fax-eifax.

-Dan Wing

---

From: MAEDA toru <[email-masked]>
Date: Fri, 12 Mar 1999 19:56:36 +0900

Wing-san

Sorry interrupt the discussion on
RE: combining "simple mode" and "extended mode" documents.

I have questions about SLA.

Could you explain why FullMode needs SLA between the sender and receiver?
Does SLA mean service level agreement (SLA) ?

Does FullMode require an extended SMTP?

Regards

Toru MAEDA
CANON Inc.

> unextended SMTP in the absense of SLAs between the sender and receiver.
----------------------------
CANON INC.
TORU MAEDA
Technology Advancement Div. 3
3-30-2,Shimomaruko Ohtaku,Tokyo,Japan
E-mail    [email-masked] 
TEL  +81-3-3757-9738  FAX  +81-3-3757-8205
----------------------------

---

From: Dan Wing <[email-masked]>
Date: Fri, 12 Mar 1999 07:39:21 -0800 (PST)

> Does FullMode require an extended SMTP?

The only proposal I have seen to implement "Full Mode", from Mike Lake,
was to send T.30 in a mail message.  He never wrote a full proposal
describing how this would work or the failure conditions, so I have no
idea what kind of SMTP it would have required.  However, it would
certainly require an agreement between sender and receiver that the
recipient's mailbox be able to understand this protocol tunneling (that
is, tunneling T.30 inside a non-real-time protocol and making assumptions
about the recipient's capabilities).

However, that proposal still did not implement all of the ITU's
requirements for "Full Mode" which were, if I recall them correctly, to
completely emulate all aspects of the real-time T.30 fax transmission
features over a non-real-time transport (SMTP), and to do this without
requiring any changes to intermediate mailers and without loosing any
of the less-used fax features such as T.30 authentication, polling,
etc.

And yes, by "SLA" I meant Service Level Agreement.

-Dan Wing