Subject: ffpim revised draft

From: Dave Crocker <[email-masked]>
Date: Mon, 18 Mar 2002 16:13:44 -0600

Folks,

A very tardy Christmas present...

I've posted a revised draft of FFPIM at:

<http://www.brandenburg.com/specifications/draft-ietf-fax-ffpim-03-03dc.txt>.

If there are no problems with it, it will be posted as the draft for Last
Call.

d/

----------

Dave Crocker
<mailto:[email-masked]>

TribalWise, Inc.
<http://www.tribalwise.com>

tel +1.408.246.8253; fax +1.408.850.1850

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 18 Mar 2002 20:08:28 -0800

The introduction (section 1.0) mentions enhancements to
reliability, timliness, and capability negotiation.
What is the enhancement introduced by FFPIM for
reliability?

Section 1.1 mispells "RCPT-TO".

There is a missing section 3 (section numbers go from 1.1 directly
to 3).

Is there really an expectation that TIMELY will be implemented when
DSN hasn't been implemented in all these years?  I mean to say, why
does 3.0 require support of TIMELY, but doesn't require support
of NOTARY (DSN)?

Section 5 says that FFPIM is an extension of both RFC2305 and
RFC2532.  Does this mean that an FFPIM implementation must
conform to RFC2305 and RFC2532?  If so, FFPIM doesn't state
that anywhere but in section 5, which is the security section.

The draft appears to contain some non-ASCII characters (specifically
smart quotes).

-d

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Dave Crocker
Sent: Monday, March 18, 2002 2:14 PM
To: IETF-FAX
Subject: ffpim revised draft
Importance: High

Folks,

d/

----------
Dave Crocker <mailto:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

---

From: Graham Klyne <[email-masked]>
Date: Tue, 19 Mar 2002 15:02:08 +0000

>does 3.0 require support of TIMELY, but doesn't require support

The TIMELY spec actually requires support for DSN (and more).

(But it may help to be more explicit.)

#g

-------------------
Graham Klyne
<[email-masked]>

---

From: Graham Klyne <[email-masked]>
Date: Tue, 19 Mar 2002 14:58:00 +0000

>If there are no problems with it, it will be posted as the draft for Last 

Dave, I think section 1.1 should say something like this:

[[[
      When the sender is able to connect directly with the
      receiving MTA,
      use of this facility permits senders to transfer a richer
      document form than is permitted when using the safer default
      form
]]]

(Also, cross-ref appendix A here?)

And it should be section 2.1, not 1.1,

#g

-------------------
Graham Klyne
<[email-masked]>

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 19 Mar 2002 08:11:53 -0800

> The TIMELY spec actually requires support for DSN (and more).

Thanks.

> (But it may help to be more explicit.)

Yes, it would -- perhaps by pointing out that FFPIM achieves is
higher reliability of delivery confirmation by TIMELY's requirement
to implement DSN.  If there are other aspects of TIMELY that FFPIM
finds beneficial, especially if they're SHOULDs in TIMELY, it's vital
that FFPIM calls them out explicitly.  Currently, FFPIM only mentions
the timely delivery of TIMELY as the important part of TIMELY.

-d

---

From: Graham Klyne <[email-masked]>
Date: Tue, 19 Mar 2002 17:04:09 +0000

>the timely delivery of TIMELY as the important part of TIMELY.

This was an illustration of how I read what I expected to find.  I read the 
text that Dave drafted, and thought it picked out quite nicely that the 
thrust of TIMELY wasn't to make email faster, but to make it more 
deterministic (my words).  But that's what I expected to read ;-)

[[[
      Internet mail is often reliable and speedy.  However it
      displays a very wide range of variability, depending upon
      details such as software implementation, systems operation,
      network connectivity and network activity.  By contrast, ...
  ]]]

Maybe, also add here:

[[[
      But when the network is congested or software implementations are
      poor, messages can be lost without any warning to the sender.
]]]

Other part of the text:

[[[
      This specification uses a set of capabilities that permits
      an originator to request that the email transport system
      seek a particular timeliness in delivery and then assures
      that the system will report the success or failure of that
      request.

      The specification for this technique is in [TIMELY].
      Implementations that are conformant to FFPIM MUST support
      timely completion.
]]]

Seems to capture the intent when you know what to look for.  Maybe this?:

[[[
      The specification for this technique is in [TIMELY], which
      requires and extends support for [DSN] and [DELIVERBY].
]]]

(+ appropriate references)

It's been a while now, but I don't think there are any optional (or SHOULD) 
elements in [TIEMLY] that need to be mandated by FFPIM.

#g

-------------------
Graham Klyne
<[email-masked]>

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 19 Mar 2002 09:16:10 -0800

>       network connectivity and network activity.  By contrast, ...

Wordy, but okay.

>       poor, messages can be lost without any warning to the sender.

Congested networks don't, to my knowledge, cause failure of SMTP.  The
sender will continue trying to send the message for days and days
until the sender gets a positive acknowledgement.  During those 
multiple delivery attempts you could well have multiple deliveries,
of course (as documented a decade ago in RFCmumblemumble).

As for buggy software implementations causing problems -- buggy software
is everywhere, not just in Internet software!

>       requires and extends support for [DSN] and [DELIVERBY].

That's perfect.  Thanks.

> elements in [TIEMLY] that need to be mandated by FFPIM.

Okay.

Thanks, Graham.

-d