RE: draft-ietf-fax-esmtp-conneg-08.txt
"Vaudreuil, Greg M (Greg)" <[email protected]> Tue, 15 Jul 2003 02:48:15 -0500
| Newsgroups | gmane.ietf.fax |
|---|---|
| Message-ID | <54E40201497DF142B06B27255953F7970661A5DB@il0015exch007u.ih.lucent.com> |
Second sentence in the summary does not parse correctly. Is there a missing word after "with the same"? I am unclear about the intent of the last paragraph in section 1 and section 3.3. Do I read correctly that if the next hop does not support conperm, then the message must be failed? I believe that failing a message for non-support of an optional ESMTP extension is a drastic step, and I believe unprecedented. Can you justify why you are not using a DSN-style method where the options are to request conperm, and/ request notificaiton if no conperm is available? Is a absolute failure better than a notice that failure is a possiblity? An uninitiated reader may question the advantage for the added complexity of Conneg. If the next hop knows the capabilities of the recipient, why not let it do the conversion? The appendix A suggests that the true intent is to facilitate direct negotiation between directly connected sender and recipient SMTP systems. Without the direct connect use case, the conneg extension has little value, since the relay with recipient capability can do the conversion itself. It seems this document can be made more clear by identifying the two common cases in the introduction and later clearly stating the algorithm for an SMTP sender to use. If directly connected from the sender to the recipient, use CONNEG. That is, if the first hop gets CONNEG info, it can encode correctly upon submission. If it does not get CONNEG, then it send in least-common denominator format or use CONPERM, and leave the conversion to the destination. I would separate the processing rules for the content-conversion relay in section 3.2 and place them in a generalized section 3.3 (might even introduce the term content-conversion relay as that special case where a device supports both conperm and conneg) It is worth mentioning that the content-conversion relay may know the capabilities of the recipient directly, via LDAP, or via CONNEG. The processing rules should be stated independently of how the knowledge is gained. For what they are worth, Greg V. -----Original Message----- From: Hiroshi Tamura [mailto:[email protected]] Sent: Tuesday, July 15, 2003 7:44 AM To: [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: Re: draft-ietf-fax-esmtp-conneg-08.txt To SMTP experts, I asked your comments as below, but nothing. Please comment NOW if there are things to suggest/discuss about the document. If not, FAX WG will request the IESG consideration again, sooner or later. Thanks in advance. Best Regards, -- Hiroshi Tamura, Co-chair of IETF-FAX WG From: Hiroshi Tamura <[email protected]> Subject: draft-ietf-fax-esmtp-conneg-08.txt Date: Thu, 26 Jun 2003 08:52:26 +0900 (JST) > > To SMTP experts, > > FAX WG did the WG Last Call of the I-D below and it was complete. > > http://www.ietf.org/internet-drafts/draft-ietf-fax-esmtp-conneg-08.txt > > At San Francisco's meeting, our WG agreed to ask for comments > from SMTP experts after the WG LC. > In fact, last year, you had a good review for the previous I-D. > > If there are issues to say, please comment. > > Best Regards, > -- > Hiroshi Tamura, Co-chair of IETF-FAX WG >