AD review comments on draft-ietf-fax-timely-delivery-05.txt (resend)

[Resending; the first one of these went out with a truncated subject. Sorry
about that.]

Let me start with a warning. I view this document as problematic on a number of
levels. Some of the problems can be addressed fairly easily; others may prove
to much more difficult, and still others may be only be brought to light after
various current issues are addressed.

Because of this I'm going to handle this document a bit differently from the
norm. Rather than try to put together an absolutely complete set of AD review
comments whose resolution is sufficient to get the document last called, I'm
instead going to issue comments that are likely to be incomplete, necessitating
additional AD review and feedback down the road.

The first issue I have with this document is one of terminology. Its approach
is to redefine what's conventionally thought of as the final delivery step in
SMTP to cover getting the message to the what the document calls the
"disposition agent".

Unfortunately redefining existing terminology is often problematic, and this
document is no exception. Indeed, the document repeatedly trips over its own
terminology inconsistencies. For example, section 2.2.1 talks about extending
the SMTP contract, yet fails to mention that the term "delivery" means
something quite different with this extension in place. Or consider that the
terminology section of the document contains two definitions of timely delivery
(one obviously needs to go)

Timely delivery
       means a message is delivered to a recipient's MTA within a
       specified time interval.

Timely delivery
       means a message is delivered by a recipient's mail transfer
       agent (MTA) -_ that is, typically, handed to the user's
       mailbox -- within a specified time interval.

and neither of them align with the abstract and introduction saying  that
delivery processing is extended all the way to the recipient.

What this document needs to do is stop talking about this extension in terms of
modifying what it means to deliver a message. The document must instead define
a new term for the message reaching the actual disposition agent, and then talk
about extending responsibility of the transport infrastructure for the message
until that point is reached. Currently the document calls this "final receipt".
I'm not wild about the term but I cannot think of a better one.

This change needs to extend to changing the title of the document itself. It is
no longer dealing with "timely delivery", it is dealing with "timely receipt".

The only awkwardness I see in this is that the issuance of a success DSN no
longer takes place coincident with final delivery, but I'd much rather take the
(small) terminology inconsistency hit in the context of DSNs than in the much
more general context of final delivery.

My next point concerns the interaction of this extension with POP3 and IMAP4.
The document talks rather glibly about how "timeliness CAN be achieved using
existing protocols, with appropriate software design and operational
management". When talking about final receipt it also says that "The exact
mechanism by which this is achieved is a local matter, and is not defined here
or by the Internet mail specifications."

I'm afraid this just doesn't wash. There was a time when message retrieval from
a message store was a local matter undertaken by nonstandard protocols, but
that time has long since passed. Not only are POP3 and IMAP4 standardized
protocols in this space, mechanisms that use other means to affect this
transfer have become the exception, not the rule. Indeed, I suspect that if you
survey the FAX gateway space specifically you'll find POP3 and IMAP4 being used
for this.

And this leads to a big problem, because this document fails to define what
final receipt means in the context of POP3 and IMAP4. Of course there's a good
reason for this -- doing so is hard. The only definition I see offhand that
would work is a download-delete POP3 setup where deletion of the message
equates with final receipt. I see no way to do this in IMAP4 short of an
extension that lets the user agent state that final receipt has occurred. (This
could be done with a special flag, I suppose, so no actual protocol change
would necessarily be needed.)

In any case, absent some specification of how this extension is to work in a
POP3 and IMAP4 environment, I cannot see this specification going forward as a
general-purpose SMTP extension. It would have to be scaled back to become a
FAX-only extension with use in a normal POP3/IMAP4 environment being
prohibited. I also see little chance of this being placed on the standards
track by the IESG; it likely would end up being classified as experimental.

One final point. It has always been possible in SMTP for the transport
infrastructure to report that a message failed to be delivered when in fact it
succeeded. (Ths usual case where this happens is when an SMTP client gets
disconnected after successfully transferring the message to the SMTP server but
before the SMTP server acknowledges that fact, and then subsequently cannot
connect to the SMTP server at all until the message times out.) The chances of
this happening have always been low, however. But this extension raises the
chances of this sort of thing happening dramatically, and this should probably
be noted among the security considerations.

That's it for now.

					Ned