Timely Completion for Internet Messaging Services
draft-ietf-fax-timely-delivery-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14
|
05 | (System) | Notify list changed from , to (None) |
2004-04-09
|
05 | (System) | Document has expired |
2004-04-08
|
05 | (System) | Ballot writeup text was added |
2004-04-08
|
05 | (System) | Last call text was added |
2004-04-08
|
05 | (System) | Ballot approval text was added |
2004-04-08
|
05 | Scott Hollenbeck | State Changes to Dead from AD Evaluation::Revised ID Needed by Scott Hollenbeck |
2004-04-08
|
05 | Scott Hollenbeck | Note field has been cleared by Scott Hollenbeck |
2004-04-08
|
05 | Scott Hollenbeck | Dropped per WG chair request. |
2004-04-08
|
05 | Scott Hollenbeck | Status date has been changed to 2004-04-08 from 2002-03-04 |
2004-03-10
|
05 | Scott Hollenbeck | Shepherding AD has been changed to Scott Hollenbeck from Ned Freed |
2002-10-07
|
05 | Ned Freed | Intended Status has been changed to Proposed Standard from Request |
2002-10-07
|
05 | Ned Freed | State Changes to AD Evaluation -- New ID Needed from AD Evaluation by freed |
2002-09-30
|
05 | Ned Freed | responsible has been changed to Authors from Responsible AD |
2002-09-30
|
05 | Ned Freed | State Changes to AD Evaluation -- 0 from AD Evaluation -- External Party by freed |
2002-09-15
|
05 | Ned Freed | AD review comments: Let me start with a warning. I view this document as highly problematic on a number of levels. Some of the problems … AD review comments: Let me start with a warning. I view this document as highly 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. |
2002-09-15
|
05 | Ned Freed | A new comment added by freed |
2002-09-15
|
05 | Ned Freed | State Changes to New Version Needed (WG/Author) from AD Evaluation by freed |
2002-08-21
|
05 | Ned Freed | responsible has been changed to Responsible AD from |
2002-08-21
|
05 | Ned Freed | State Changes to AD Evaluation from Requested by freed |
2002-05-08
|
05 | Jacqueline Hargest | Assigned to has been changed to freed from members by jhargest |
2001-11-06
|
05 | (System) | New version available: draft-ietf-fax-timely-delivery-05.txt |
2001-09-17
|
04 | (System) | New version available: draft-ietf-fax-timely-delivery-04.txt |
2001-06-20
|
03 | (System) | New version available: draft-ietf-fax-timely-delivery-03.txt |
2001-02-09
|
02 | (System) | New version available: draft-ietf-fax-timely-delivery-02.txt |
2000-10-10
|
01 | (System) | New version available: draft-ietf-fax-timely-delivery-01.txt |
1999-10-27
|
00 | (System) | New version available: draft-ietf-fax-timely-delivery-00.txt |