From owner-ietf-fax@mail.imc.org Thu Aug 1 06:31:30 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20066 for ; Thu, 1 Aug 2002 06:31:29 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g71AA8V03368 for ietf-fax-bks; Thu, 1 Aug 2002 03:10:08 -0700 (PDT) Received: from mail.notes.ricoh.co.jp (mail.notes.ricoh.co.jp [202.211.49.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g71AA5w03361 for ; Thu, 1 Aug 2002 03:10:06 -0700 (PDT) Received: from delsol.isd.ricoh.co.jp (IDENT:mirapoint@[133.139.250.75]) by mail.notes.ricoh.co.jp (8.11.6/3.7W) id g71A9tF29009; Thu, 1 Aug 2002 19:09:55 +0900 Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by delsol.isd.ricoh.co.jp (Mirapoint) with ESMTP id ADT66624; Thu, 1 Aug 2002 19:09:53 +0900 (JST) Received: from localhost (tulip.toda.ricoh.co.jp [133.139.60.74]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id TAA07793; Thu, 1 Aug 2002 19:05:18 +0900 (JST) To: ietf-fax@imc.org, claudio.allocchio@garr.it Subject: draft minutes at Yokohama meeting From: Hiroshi Tamura X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020801190959R.tamura@toda.ricoh.co.jp> Date: Thu, 01 Aug 2002 19:09:59 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 325 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, Sorry for my slow action. Attached is the draft minutes. I modified and added a little for Claudio's "short notes". Please let me know soon if there are comments. Claudio, Thanks again for the detailed notes. By the way, are the following numbers correct, regarding ESMTP CONNEG issue? " A query to the ones present in the room showed 2 hands in favour of a simple command (current specification), 3 hands in favour of using 2 separate commands and the vast majority of the WG, which did not ...." "2 hands" and "3 hands". As the other mails, it seems that they are "1 hand" and "2 hands". Anyway, there were few hands for both at the meeting. We can modify like that. Regards, -- Hiroshi Tamura, Co-chair of IETF-FAX WG tamura@toda.ricoh.co.jp --------------------------------------------------------------------- TUESDAY, July 16 at 0900-1130 ============================== CHAIRS: Claudio Allocchio Hiroshi Tamura --------------------------------------------------------------------- Opening --------------------------------------------------------------------- FAX WG meeting was held jointly with VPIM WG, on July 16 2002. Hiroshi Tamura, co-chair of FAX WG, welcomed the participants at his home town Yokohama and started the meeting. --------------------------------------------------------------------- Agenda Bashing and etc. --------------------------------------------------------------------- Hiroshi Tamura proposed to change slightly the order of the agenda discussion, moving the ESMTP-CONNEG and FFPIM topics at the end of the Fax part of the meeting, in order to allow more time to these topics without compressing the other ones. The change was approved unanimously. We also received apology from Ned Freed, an Area Director of Application Area, who could not be with us, but Patrik Faltstrom, another Area Director, was here replacing him. --------------------------------------------------------------------- The I-Ds which IESG approved and are in RFC editor's queue --------------------------------------------------------------------- Hiroshi Tamura reported that the following documents are already in the RFC editor's queue: - draft-ietf-fax-implementers-guide-08.txt - draft-ietf-fax-content-negotiation-05.txt - draft-ietf-fax-tiff-regbis-05.txt - draft-ietf-fax-tiff-fx-reg-01.txt He assured the WG that the chairs should take action with RFC editors and IANA administrators, in order to have the RFC number assigned ASAP (i.e. prior to publication) to the tiff-regbis and tiff-fx-reg I-Ds. It is needed for Draft Standard process of TIFF-FX (RFC 2301) itself as well as the reference in implementers-guide I-D and ITU-T T.37. After the meeting, Hiroshi Tamura asked RFC editors and IANA administrators for their action. Also, content-negotiation I-D was assigned RFC number and was published. It is RFC 3297. --------------------------------------------------------------------- The I-Ds for which IETF Last Call was finished --------------------------------------------------------------------- Hiroshi Tamura presented the list of documents whose IETF last call was completed without significative comments: - draft-ietf-fax-gateway-protocol-08.txt - draft-ietf-fax-gateway-options-05.txt - draft-ietf-fax-service-v2-05.txt Regarding service-v2-05 I-D, it refer DSN (RFC 1894 update) and TIFF-FX (draft-ietf-fax-tiff-fx-11.txt). Greg Vaudreuil reported the status of DSN (see slides). After IANA questions were answered in April, and an extended implementation report was submitted in early June, the document is currently on IESG table, without any apparent outstanding issues. The ADs will check its status, too. The draft-ietf-fax-tiff-fx-11.txt I-D is waiting for the supplementary implementation report to be published (see later on). We confirmed, even if the targeted I-D refers other I-Ds, it may finish IETF Last Call and move to RFC-editors' queue. In that case, it will be published as RFC after all the reference I-Ds become RFC. In fact, service-v2-05 I-D will finish IETF Last Call sooner or later, while it refers DSN and TIFF-FX. --------------------------------------------------------------------- The I-D which IESG is reviewing (Before IETF Last Call) --------------------------------------------------------------------- Hiroshi Tamura presented one I-D on the IESG queue (Area Directors review stage): - draft-ietf-fax-timely-delivery-05.txt There were no comments and modifications since the last meetings. The WG Last Call was already finished. Thus, we just wait for the ADs review and for the reference to draft-vaudreuil-1983ext-01.txt to be solved. The 1983ext I-D status was also updated by Greg Vaudreuil. The situation is very similar to DNS. There are no outstanding issues. After the meeting, Greg Vaudreuil and Hiroshi Tamura agreed that FAX WG will do the WG Last Call after it is reposted, as it is already expired. --------------------------------------------------------------------- TIFF-FX implementation report --------------------------------------------------------------------- Hiroshi Tamura introduced it. There is already the original report in IETF site. This was for the additional (new) report to be submitted. He explained (see slides) that the CIAJ (Communications and Information network Association of Japan), whose members practically contain all the fax manufactures in Japan, agreed to perform an extended further TIFF-FX implementation test, to supplement the original report. CIAJ already succeeded IFax and TIFF-FX testing in 1999 and 2001 for Profile S, F and J. The participats are Oki Data, Canon, Kyocera Mita, Sharp, Toshiba-Tec, NEC, Fuji-Xerox, Brother, Matsushita, Minolta, Murata and Ricoh. The testing for Profile C, L and M is planned. Some testings for Profile C was done successfully last month, and the remains will be done by the end of August. CIAJ requires the new report should be supplementary to the orignal report. It will include specified product name, supported tag information, license validation for some profiles It will be submitted by the end of September. Patrik Faltstrom, Area Director, explicitly reminded that the license statement should specify that the company has exercised the proof of "independent licensing" in implementing their products. The chairs should be careful for it. --------------------------------------------------------------------- Addressing --------------------------------------------------------------------- -draft-allocchio-gstn-03.txt Claudio Allocchio made a short report about the addressing documents. After the last meeting and the suggestions from the WG, version 03 was published in March. The only difference from version 02 was that the "implementer's note", regarding 'pause' and 'tonewait' was turned into a recommended (SHOULD, MAY) implementation specification. As there were not further comments, and a numver of IDs are starting to use the docuement as a reference, the ADs decided to issue the IETF last call: the request was submitted on July 15th. --------------------------------------------------------------------- FAX in ENUM --------------------------------------------------------------------- Kiyoshi Toyoda reported on the I-D in preparation to register IFax service in ENUM with IANA. The IFax functional specification is different from the normal email service, PSTN-fax service and T.38 fax service. The returned DNS NAPTR record will specify an email address that is to be used for reaching the target system fax mailbox. The email address is used in accordance with "Simple Mode" RFC 2305, "Extended Mode" RFC 2532 or FFPIM. Service name: "ifax" Protocol: smtp URI scheme: "mailto" Intended Usage: COMMON Patrik Faltstrom, as editor of the current ENUM NAPTR record specification, reported the discussion of the preceding day at the ENUM WG, where the final syntax was again discussed. Now the final decision will be taken on the mailing list. Thus, the Ifax ENUM I-D, which Kiyoshi Toyoda prepare, will have to follow the discussion, and conform with it. However, this is not a problem for the IFax case, as we do not require specific hierarchical syntax for the resource record data fields. Patrik and the WG asked Kiyoshi Toyoda now to submit the text of the I-D, and discuss it within the FAX WG, with CC to the ENUM mailing list, although Patrik commented it should be mainly discussed and solved in FAX WG. He promised he will submit it within a short time. --------------------------------------------------------------------- ITU issues --------------------------------------------------------------------- Hiroshi Tamura introduced. The next ITU-T SG16 meeting is held in October 2002. He will report our activities there. Also, As a WG the documents which are referenced by ITU-T documents and need some processing are: "image/tiff" MIME Sub-type Registration "image/tiff-fx" MIME Sub-type Registration Implementers Guide FAX WG are now asking the RFC editors at least for the assignement of the RFC number. He will also report on the status of the TIFF-FX issue, which should progress after the supplementary implementation report is submitted in September. The inputed information will be decided on the mailing list. --------------------------------------------------------------------- SMTP Service Extension for Content Negotiation (ESMTP CONNEG) --------------------------------------------------------------------- Claudio Allocchio summarized the status of the discussion which started on the mailig lists after the IETF last call was issued for the Service Extension for Content Negotiation. The new version is at http://www.brandenburg.com/specifications/draft-ietf-fax-esmtp-conneg-03.txt. It is not yet available at ID repository. On the mailing lists (including the IETF general one), we saw discussion which mainly can be grouped under these three major topics: - is the proposal doing layering violations of the model MTA-MUA? - how the proposal handles the multi-relays case? - which is the most efficient/more elegant specification approach, i.e. use RCPT TO or another sepcific command and then RCPT TO? On the mailing list the dabate did not show yet a clear direction, and the WG discussion should help in clarifying ideas. After Claudio's introduction, Dave Crocker, one of the authors of the I-D, started the debate, thanking Claudio for his very neutral introduction of the topics, and explained the reasons why he is convinced that the current approach taken into the document should be the one to go for. On the layering violations (i.e. the MTA knowing the MUA capabilities and keeping information about it to report back to the sender MUA), Dave suggested that we should be pragmatic, and consider that for most of the cases where Internet Fax is involved, the final MTA and MUA are on the same host, and very often are the same piece of software. This might not be the case in all possible circumstances, but it will quite well fit the model. Furthermore, most of the Ifax traffic would be point to point, without relaying. There were comments reminding that in most of the corporate cases, this might be false, as firewalls and single entrance SMTP relay are in common use, and this might introduce complications into the paradigm. After a discussion about the general model, which showed that there is not a common behaviours expected from the current SMTP messaging system, the WG pointed out that this is not a situation specific to Ifax, but it applies in general to all messaging purposes, incliding VPIM, MIME etc. Solving the basic philosophical problem thus requires the involvement of the whole SMTP area expertise people, and not only the FAX WG people. There was a comment that the debate on this should continue either on the general IETF list, or considered to be moved to the area covered by the proposed WG on "unified messaging" having a BOF later during the week (LEMONAGEe). The discussion then focused on the implementation methods, i.e. should we use an option into the RCPT TO command, and thus use a single command, or should issue first another command, and then when capabilities of the recipient(s) are discovered, only then issue the set of RCPT TO commands? The aim should be the efficiency of the interaction in the transport system between MTAs, and also some MUAs. Dave defended the current specification, where a single command (RCPT TO) is used to ask and discover capabilities of the recipient MUA, while Greg Vaudreuil prefered the idea of another command to be issued before the RCPT TO sequence is started, in order to sort first recipients depending on capabilities. Claudio, removing momentarily his chair hat, also supported the single command, in favour of a more practical, even if probably less elegant, approach. Patrik Faltstrom reminded that Ned Freed commented a lot on this topic, and at the end asked the WG to come to a conclusion on this two alternates. Harald Alvestrand, as a member of the IESG, also reminded that this is the fundamental topic where the IESG should be convinced of the best solution, and also removing his IESG hat for a moment, he instead suggested that two separate commands would do an easier job for implementors. Claudio reminded that there is no apparent prevalent opinion on how the current SMTP system behaves, and reminded that some implementers think the SMTP world is mostly "one recipient per MTA" when there is not a firewall or similar security measures in effect, and "many users per relay MTA" where these measueres are in effect. A query to the ones present in the room showed 2 hands in favour of a simple command (current specification), 3 hands in favour of using 2 separate commands and the vast majority of the WG, which did not make its mind on it yet (the FAX WG is not so good in humming, we use hands). Keeping in mind that also many other people not present in the room have opinions on this topic, the further discussion and decision was moved to the mailing lists involved, including the general IETF list. --------------------------------------------------------------------- FFPIM --------------------------------------------------------------------- Dave Crocker reported the the newest version of the document contained some minor edits (upon suggestions from Dan Wing), and asked to those presents some questions: - Use of ESMTP options as MAY or SHOULD? - FFPIM conformance require RFC2305 and RFC2532 conformance? We decided to vote by a show of hands. The result was "SHOULD" and "require". After the meeting, Hiroshi Tamura again asked them in the mailing list. But, there were no comments. Thus, those are the results. Moreover, the document refers ESMTP CONNEG specification. It was agreed that the CONNEG text should be more detailed in ESMTP CONNEG I-D, and that we should of course adapt it to the output of the dicussion about it. --------------------------------------------------------------------- Closing --------------------------------------------------------------------- FAX WG handed over to VPIM agenda points, and Glenn Parsons, chair of VPIM WG, chaired the rest of the meeting. Note that the FAX and VPIM WGs confirmed they will continue joint meetings until all their work is finished. Thus, we will meet again together in Atlanta, in November 2002. From owner-ietf-fax@mail.imc.org Thu Aug 1 07:09:13 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23319 for ; Thu, 1 Aug 2002 07:09:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g71AuNx06158 for ietf-fax-bks; Thu, 1 Aug 2002 03:56:23 -0700 (PDT) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by above.proper.com (8.11.6/8.11.3) with SMTP id g71AuLw06154 for ; Thu, 1 Aug 2002 03:56:21 -0700 (PDT) Date: Thu, 1 Aug 2002 12:55:59 +0100 To: Hiroshi Tamura cc: ietf-fax@imc.org In-Reply-To: <20020801190959R.tamura@toda.ricoh.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: Re: draft minutes at Yokohama meeting Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > "2 hands" and "3 hands". > > As the other mails, it seems that they are "1 hand" and "2 hands". Yes the other mails ARE correct: "1 hand and 2 hands" is exact. My notes were wrong. :-) > We can modify like that. yes, please do it. Regards, Claudio PS: Ok for the rest for me! From owner-ietf-fax@mail.imc.org Thu Aug 1 13:41:23 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08991 for ; Thu, 1 Aug 2002 13:41:23 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g71HRLt28537 for ietf-fax-bks; Thu, 1 Aug 2002 10:27:21 -0700 (PDT) Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g71HRKw28532 for ; Thu, 1 Aug 2002 10:27:20 -0700 (PDT) Received: from GK-VAIO.NineByNine.org (jay.songbird.com [208.184.79.253]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g71HML425857 for ; Thu, 1 Aug 2002 10:22:21 -0700 Message-Id: <5.1.0.14.2.20020801183718.0399dcc0@127.0.0.1> X-Sender: gk@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 01 Aug 2002 18:39:21 +0100 To: IETF fax WG From: Graham Klyne Subject: RFC 3297 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I am reminded by Tamura-san's meeting minutes that another of our work items has now been published. Thanks to everyone who helped us get there. #g -- [[ A new Request for Comments is now available in online RFC libraries. RFC 3297 Title: Content Negotiation for Messaging Services based on Email Author(s): G. Klyne, R. Iwazaki, D. Crocker Status: Standards Track Date: July 2002 Mailbox: GK@ACM.ORG, iwa@rdl.toshibatec.co.jp, dcrocker@brandenburg.com Pages: 47 Characters: 97094 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-fax-content-negotiation-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3297.txt ]] ------------------- Graham Klyne From owner-ietf-fax@mail.imc.org Mon Aug 5 08:04:57 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09155 for ; Mon, 5 Aug 2002 08:04:57 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g75BjGD13456 for ietf-fax-bks; Mon, 5 Aug 2002 04:45:16 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g75BjFw13452 for ; Mon, 5 Aug 2002 04:45:15 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08409; Mon, 5 Aug 2002 07:44:03 -0400 (EDT) Message-Id: <200208051144.HAA08409@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-fax@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-fax-esmtp-conneg-03.txt Date: Mon, 05 Aug 2002 07:44:03 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Fax Working Group of the IETF. Title : SMTP Service Extension for Content Negotiation Author(s) : K. Toyoda, D. Crocker Filename : draft-ietf-fax-esmtp-conneg-03.txt Pages : Date : 02-Aug-02 This document defines a content negotiation service extension for SMTP [ESMTP1, ESMTP2] whereby an SMTP client may request information about content capabilities of the target device or system that is serviced by an SMTP server. The SMTP server may report the target's content capabilities back to the client. This process emulates a classic facsimile start-of- session capabilities negotiation, although it can be used for a broad range of email-based scenarios. This service extension is primarily intended for 'direct', one-hop, originator/recipient SMTP transfers, although relayed scenarios through multiple SMTP servers are permitted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fax-esmtp-conneg-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-fax-esmtp-conneg-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-fax-esmtp-conneg-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020802150956.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-esmtp-conneg-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-esmtp-conneg-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020802150956.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Mon Aug 5 12:04:52 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19375 for ; Mon, 5 Aug 2002 12:04:51 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g75FnJU25326 for ietf-fax-bks; Mon, 5 Aug 2002 08:49:19 -0700 (PDT) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g75Fm0w25300; Mon, 5 Aug 2002 08:48:00 -0700 (PDT) Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id IAA05219; Mon, 5 Aug 2002 08:57:02 -0700 Message-Id: <5.1.1.2.2.20020805084437.035119e0@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Mon, 05 Aug 2002 08:47:53 -0700 To: ietf-fax@imc.org, ietf-smtp@imc.org From: Dave Crocker Subject: Fwd: I-D ACTION:draft-ietf-fax-esmtp-conneg-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, The SMTP Conneg draft has been revised, with the primary change being addition of two Appendices. One discusses use of the option when there are multiple recipients. The other discusses use of the option when there is relaying. d/ >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Internet Fax Working Group of the IETF. > > Title : SMTP Service Extension for Content Negotiation > Author(s) : K. Toyoda, D. Crocker > Filename : draft-ietf-fax-esmtp-conneg-03.txt > Pages : > Date : 02-Aug-02 > >This document defines a content negotiation service >extension for SMTP [ESMTP1, ESMTP2] whereby an SMTP >client may request information about content >capabilities of the target device or system that is >serviced by an SMTP server. The SMTP server may report >the target's content capabilities back to the client. >This process emulates a classic facsimile start-of- >session capabilities negotiation, although it can be used >for a broad range of email-based scenarios. This service >extension is primarily intended for 'direct', one-hop, >originator/recipient SMTP transfers, although relayed >scenarios through multiple SMTP servers are permitted. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-fax-esmtp-conneg-03.txt ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Mon Aug 5 15:40:36 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28974 for ; Mon, 5 Aug 2002 15:40:35 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g75JKMs07007 for ietf-fax-bks; Mon, 5 Aug 2002 12:20:22 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g75JJww06980; Mon, 5 Aug 2002 12:19:58 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g75JJkY29591; Mon, 5 Aug 2002 15:19:46 -0400 (EDT) Message-Id: <200208051919.g75JJkY29591@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Fwd: I-D ACTION:draft-ietf-fax-esmtp-conneg-03.txt In-reply-to: (Your message of "Mon, 05 Aug 2002 08:47:53 PDT.") <5.1.1.2.2.20020805084437.035119e0@jay.songbird.com> Date: Mon, 05 Aug 2002 15:19:46 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [bcc'ed to iesg - on the assumption that they might not want to see the resulting replies] > The SMTP Conneg draft has been revised, with the primary change being > addition of two Appendices. One discusses use of the option when there are > multiple recipients. The other discusses use of the option when there is > relaying. I think the two appendices help slightly. However they also introduce new problems not present in the previous draft. Also, the new version of the document fails to correct a number of problems (some of them serious) in the previous version. In particular, - it is still overbroad, claiming applicability for general email when it really works only for a limited subset of content which has an obvious ordering relation for "quality". perhaps illustrating this, all of the examples are for fax. - it still permits unauthorized parties to make arbitrary and unspecified alterations to mail. - worse, the new version permits unauthorized parties to make arbitrary assertions of recipient capabilities in the absence of explicit information. - the new version also permits multiple conversions to take place, potentially degrading the message considerably more than a single conversion. - it still mandates use of particular reply and status codes in cases where they are not always appropriate - it still has the server reporting status codes for conditions that are best detected on the client - it still allows SMTP servers to make assertions of recipient capabilities without actual knowledge of those capabilities. - I still think overloading of RCPT is a pessimal way to do this since the command will often need to be issued twice anyway - either because of a mixture of recipient capabilities, or because the conversion could not be performed on-the-fly. recommendations for near-term publication: - this feature should be renamed and the document reworded to make it clear that it is fax-specific rather than general purpose. - misleading text should be fixed, unworkable recommendations should be removed. - the document should be published as experimental rather than on the standards track, since it doesn't meet the requirements for proposed standard. things that need to be fixed before the document should be considered as standards-track: - needs to be examined for a wide range of content - needs to have a well-defined protocol by which senders can request conneg "convert-or-fail" semantics on a per-message, and probably per-bodypart, basis. if they are not requested, such semantics must not be applied. - needs to explicitly specify which conversion algorithms are permissible and how new conversion standards may be added, since there can be multiple ways to perform a conversion and some are worse than others. - needs to state that conneg features are only advertised with the recipient's consent and control - needs to state exactly which parties are authorized to perform conversion. - needs to prevent multiple conversions. some details are below. not everything above can be seen from a close-up view, so the list of details below should be considered separately from the overall problems listed above. > 1. INTRODUCTION > > When a data source and a receiver have interactive access to > each other, the receiver often informs the source of its > capabilities, to permit optimized performance or functionality for > the interaction. Classic telephone-based facsimile is an example, > as are voice over IP and ESMTP, among Internet applications. The > store-and-forward nature of Internet mail is usually assumed to > preclude such capabilities exchanges, although the sender in a > store-and-forward scenario could benefit from knowing precise > details about the receiver. In some configurations, direct > email-based interactions -- with the originating ESMTP client > and the destination ESMTP server able to have direct TCP > connect -- are possible, such as over an intranet. In addition > an end-to-end exchange can ESMTP for hop-by-hop enforcement. nit: s/can/can use/ ??? problem: this proposal doesn't provide any way to "enforce" content negotiation past a single hop. there is no requirement that the CONNEG option be relayed from one hop to another. even if there were, it would be problematic - it would require earlier SMTPs to advertise capabilities of recipients for which they did not have information, and it would require (and trust) later SMTPs to perform arbitrary and undefined conversions on content to satisfy recipient-specific constraints. > This document defines an SMTP-based service extension [ESMTP1, > ESMTP2] for content negotiation, whereby an SMTP client may > request information about content capabilities of the target > device or system that is serviced by an SMTP server. nit: the capability request is on a per-recipient-mailbox basis rather than a 'target device or system' basis. of course being able to request per-recipient-mailbox capabilities is sufficient to request target device capabilities when all recipients accessed via a single SMTP server have the same capabilities. but the fact that it's a per-recipient capability makes the proposal more complex to handle for the sender, and it would be better to make this clearer from the start. > The SMTP > server may report the target's content capabilities back to the > client. This process can be used to emulate a classic facsimile > start-of-session capabilities negotiation, as well as being used > for other email-based services. The extension is primarily > intended for "direct" SMTP transfers, although relayed scenarios > are permitted through a series of SMTP servers and are discussed > in Appendix B. > > > 2. CONVENTIONS > > In examples, "C:" and "S:" indicate lines sent by the > client and server respectively. > > The key words "MUST", "MUST NOT", "SHOULD", "SHOULD > NOT", and "MAY" in this document are to be interpreted > as defined in "Key words for use in RFCs to Indicate > Requirement Levels" [KEYWORDS]. > > > > 3. CONTENT NEGOTIATION SERVICE EXTENSION > > (1) The name of the SMTP service extension is > "Content_Negotiation" > > (2) The EHLO keyword value associated with this extension > is "CONNEG" > > (3) A parameter using the keyword "CONNEG" is added to the > RCPT command > > (4) The server responds with a report of the content > capabilities of the device or system that embodies the > target RCPT address. > > > > 4. CONNEG PARAMETER TO RCPT > > 4.1 Parameter > > Keyword: > > CONNEG > > Argument: > > REQUIRED > The client requires support for the capability. If the > target does not support the CONNEG parameter, the target > MUST reject the RCPT command with a 504 reply. > > If the target can not support the capability due to a > temporary problem, it MUST reject the RCPT command with > a 404 reply. nit: It is not clear whether it is desirable for the server to give CONNEG errors priority over all other sources of error. For instance, if a recipient address is invalid, reporting *that* probably results in a more useful error message than reporting that the CONNEG feature is not supported for that particular recipient. suggestion: reporting of errors with the CONNEG=REQUIRED option SHOULD only occur if the RCPT command would otherwise have a successful result. If the RCPT command would fail for other reasons, the error and status codes should reflect the nature of that failure. In most cases this will result in a more useful error message. An reasonable exception might exist if the server checks several potential error conditions concurrently, and it determines that the command would fail the CONNEG=REQUIRED criteria before it determines that the command would fail due to other reasons. > OPTIONAL > The client requests the target to use the capability. If > the target can not support the capability at this time, the > target MUST process the address and message as if the > requested CONNEG capabilities had not been specified. > > If the argument does not exist, the default is "REQUIRED". > > When a capability is REQUIRED by the client but can not > currently be supported by the target, an error response will > have significant performance impact to overall SMTP > processing. Use of the OPTIONAL parameter will ensure high > SMTP performance. nit: s/ensure high SMTP performance/facilitate better SMTP performance/ even better would be to say that REQUIRED SHOULD only be used when the sender has specified that the message delivery should fail unless it is known that the recipient has the necessary capability. even better would be to omit REQUIRED entirely, since it increases the complexity of the server implementation and the protocol, for essential zero benefit to the client. REQUIRED doesn't remove the need for the client to detect errors due to content negotiation, since it is always possible that the server/recipient does not support any way of handling the content at all, or even if such conversion might be possible, the client does not have the capability to perform that specific conversion. > 4.2 Client Action > > If the server issued a 250-CONNEG, as part of its > EHLO response for the current session, the client MAY > issue the CONNEG parameter with RCPT. > > If the client issues the CONNEG parameter with > RCPT, then it MUST honor the capabilities specified > in the CONNEG RCPT reply, and transform data that is > sent, so that the server can accept the data. The > client SHOULD transform the data to the "highest" level > of capability of the server. problem: the client cannot be compelled to perform transformations that are impossible or for which the client lacks the capability. no client can reasonably convert video to audio. few clients could convert audio or fax to text, and then only if the audio or fax contained words. if taken literally this provision would prevent any client from asserting CONNEG. suggestion: rather than saying "MUST honor" say that the client MUST NOT send forward which is inconsistent with the recipient's stated capabilities. the client SHOULD, if capable, perform transformations which are likely to preserve the recipient's ability to use most of the information in the content. if the client is unable to perform such transformations, it MUST bounce the message. (there probably needs to be some interaction with critical content here - it might be acceptable for a SMTP to discard conntent marked as non-critical rather than bouncing the message. but under no circumstances should the message be delivered to the recipient when the recipient has stated via CONNEG that he/she cannot receive it) > If the server rejects the RCPT command with a 404 reply, the > client may later reissue the RCPT with the CONNEG parameter > in a different SMTP session. nit: presumably "may" should be capitalized here. > If the server returns an EHLO 250 code without CONNEG > capabilities, the client MUST NOT issue a CONNEG parameter > with RCPT. > > Methods of using of this option with multiple addressees, for > the same content, are discussed in Appendix A. > > > 4.3 Server Action > > If the client specifies "CONNEG=REQUIRED" in the RCPT, > but the server does not support the CONNEG parameter, the server > MUST reject the RCPT command with a 504 reply. > > If the server supports the CONNEG parameter, but can not return > the recepient's capability temporarily, the server MUST reject the > RCPT command with a 404 reply. For example, if the server gets > the capability information from a directory, but its connection is > offline, the server MUST reject the RCPT command with a 404 > reply. > > If the client specifies "CONNEG=OPTIONAL" in the RCPT, > but the server does not support the CONNEG parameter or can not > return the recipient's capability temporarily, the server MUST > process the address and message as if the requested CONNEG > capabilities had not been specified. > > Regardless of the value of the parameter, if the server does > support the CONNEG parameter and the address is acceptable, > then it MUST issue a 250 reply, followed by the capabilities > of the server that is specified by the RCPT address. > Successful responses to CONNEG RCPT requests will always be > multiple SMTP lines. The first line is the normal RCPT response, > and subsequent lines beginning with the exact string > "250-CONNEG " and "250 CONNEG " are the CONNEG responses. > The last line begins with "250 CONNEG ". > > If the SMTP server supports ENHANCEDSTATUSCODES [RFC1893], the > response strings for a success are "250-2.1.5 CONNEG" and > "250 2.1.5 CONNEG". nit: I think you want these to be "250-2.1.5 CONNEG " and "250 2.1.5 CONNEG ". nit: it is out of scope for this document to specify the status codes for a successful RCPT command. > The response strings for indicating a > permanent failure are "504-5.3.3 CONNEG" and "504 5.3.3 CONNEG". > The response strings for a temporary failure are "404-4.3.3 > CONNEG" and "404 5.3.3 CONNEG". problem: this overloads existing status codes for new error conditions. there needs to be new status codes for "sender insisted on not delivering the message unless it knew for sure that the recipient could deal with it and the recipient's capabilities could not be obtained". > All CONNEG-capable clients and CONNEG-capable servers MUST > be able to successfully process CONNEG lines that are up to 512 > characters long, as required by RFC2821. If the length of CONNEG > lines is greater than 512 characters, the server MUST insert > line breaks and make next CONNEG line. problem: you need to explain more about how this is done. e.g. can "250-2.1.5 CONNEG " be inserted in the middle of a token? are spaces at the end of a reply line significant? > The contents of the capability listing MUST conform to > the specifications in "Content Feature Schema for Internet Fax". > [RFC2879] problem: this restriction seems inappropriate if the content is not a fax. > > > 5. SYNTAX > > Command with "CONNEG": > "RCPT TO:" ("" / "" > / Forward-Path) (SP "CONNEG =" ("REQUIRED" / > "OPTIOANL") CRLF nit: OPTIONAL is misspelled nit: "CONNEG =" should be "CONNEG=" nit: "" is redundant with Forward-Path problem: grammar excludes other RCPT options suggestion: the RCPT command syntax should not be formally described in this document; it is adequately described elsewhere and CONNEG doesn't change the syntax. > Reply: > ( ("250-" CRLF) *("250-CONNEG" capability CRLF) > ("250 CONNEG" capability CRLF) )/ > ( ("250-2.1.5" CRLF) > *("250-2.1.5 CONNEG" capability CRLF) > ("250 2.1.5 CONNEG" capability CRLF) )/ > ("504" CRLF) / > ("504 5.3.3" CRLF) / > ("404" CRLF) / > ("404 4.3.3" CRLF) / > > capability = <> problem: this grammar excludes the possibility of other kinds of responses besides CONNEG. problem: need to specify how line wrapping works. radical suggestion: 1. server encodes the recipient's conneg string in quoted-printable, with the line length limits and wrapping rules per the MIME spec. 2. server then prefixes each of the resulting quoted-printable lines with "250-2.1.5 CONNEG " (perhaps adding 2.1.5 even if ENHANCEDSTATUSCODES are not supported) 3. client collects all lines from the response that begin with "250-2.1.5 CONNEG ", removes that prefix from each line, and processes the resulting set of lines as a quoted-printable encoded file in order to obtain the conneg string for the recipient. > > 6. EXAMPLES > > 6.1 Success Response > > An example of ESMTP sequence with successful RCPT response > > S: 220 ifax1.jp IFAX > > C: EHLO ifax1.jp > > S: 250-ifax1.jp > S: 250-DSN > S: 250 CONNEG > > C: MAIL FROM: > > S: 250 sender ok > > C: RCPT TO: CONNEG = REQUIRED nit: should be "CONNEG=REQUIRED" > S: 250- recipient ok > S: 250 CONNEG (&(image-file-structure=TIFF-minimal) > S: (MRC-mode=0)(color=Binary)(|(&(dpi=204) > S: (dpi-xyratio=[204/98,204/196]) )(&(dpi=200) > S: (dpi-xyratio=[200/100,1]) )(&(dpi=400) > S: (dpi-xyratio=1) ) )(|(image-coding=[MH,MR,MMR]) > S: (&(image-coding=JBIG)(image-coding-constraint=JBIG-T85) > S: (JBIG-stripe-size=128) ) )(paper-size=[letter,A4,B4]) > S: (ua-media=stationery) ) nit: example shows inappropriate line wrapping, without explanation. > C: DATA > > S: 354 okay, send data > > C: < Per: > ( image-file-structure=TIFF-minimal > dpi=400 > image-coding=JBIG > size-x=2150 > ) > >> nit: example shows invalid content-type nit: example assumes fax. > S: 250 message accepted > > C: QUIT > > S: 221 goodbye > > > 6.2 Long Response > > An example of successful RCPT response when the length of > capability is greater than 512 characters. > > S: 250-2.1.5 recipient ok > S: 250-2.1.5 CONNEG (&(image-file-structure=TIFF-minimal) ... > S: 250-2.1.5 CONNEG ..... > S: 250 2.1.5 CONNEG (color=Binary) okay, that helps, but it still doesn't show whether line wrapping can occur in the middle of a conneg token. > > An example of succssful RCPT response when CONNEG-capable > server supports ENHANCEDSTATUSCODES. > > S: 250-2.1.5 recipient ok > S: 250 2.1.5 CONNEG (&(image-file-structure=TIFF-minimal) > S: (MRC-mode=0)(color=Binary)(|(&(dpi=204) > S: (dpi-xyratio=[204/98,204/196]) )(&(dpi=200) > S: (dpi-xyratio=[200/100,1]) )(&(dpi=400) > S: (dpi-xyratio=1) ) )(|(image-coding=[MH,MR,MMR]) > S: (&(image-coding=JBIG)(image-coding-constraint=JBIG-T85) > S: (JBIG-stripe-size=128) ) )(paper-size=[letter,A4,B4]) > S: (ua-media=stationery) ) nit: example assumes fax. > > 6.3 Failure Response > > An example of ESMTP sequence with parmanent failure RCPT > response. > > S: 220 ifax1.jp IFAX > > C: EHLO ifax1.jp > > S: 250-ifax1.jp > S: 250-DSN > > C: MAIL FROM: > > S: 250 sender ok > > C: RCPT TO: CONNEG = REQUIRED nit: should be "CONNEG=REQUIRED" > > S: 504 recipient ok > > C: QUIT > > S: 221 goodbye > > > 6.4 Temporary Failure Response > > An example of an ESMTP sequence with temporary failure RCPT > response when the value of parameter is "REQUIRED": > > S: 220 ifax1.jp IFAX > > C: EHLO ifax1.jp > > S: 250-ifax1.jp > S: 250-DSN > S: 250 CONNEG > > C: MAIL FROM: > > S: 250 sender ok > > C: RCPT TO: CONNEG = REQUIRED nit: should be "CONNEG=REQUIRED" > > S: 404 recipient ok > > C: QUIT > > S: 221 goodbye > . > . > . > retry according to implementation > > > 6.5 Temporary Failure with Optional handling > > An example of an ESMTP sequence with temporary failure RCPT > response when the value of parameter is "OPTIONAL": > > S: 220 ifax1.jp IFAX > > C: EHLO ifax1.jp > > S: 250-ifax1.jp > S: 250-DSN > S: 250 CONNEG > > C: MAIL FROM: > > S: 250 sender ok > > C: RCPT TO: CONNEG = OPTIONAL nit: should be "CONNEG=OPTIONAL" > > S: 250 recipient ok > > C: DATA > > S: 354 okay, send data > > C: < Per "A Simple Mode of Facsimile Using Internet Mail" > RFC2305 > >> nit: example assumes fax > > S: 250 message accepted > > C: QUIT > > S: 221 goodbye > > > > 7. IANA CONSIDERATIONS > > On publicatiom of this document by the RFC Editor, the IANA > shall register the Content_Negotiation ESMTP extension defined > in section 3. > > > > 8. SECURITY CONSIDERATIONS > > This ESMTP option calls for a respondent to disclose > its capabilities. Mechanisms for determining the > requestor's authenticated identity are outside the > scope of this specification. It is intended that this > mechanism permit disclosure of public information; > hence there is no particular need for security > measures. > > However there is nothing to prevent disclosure of > sensitive information that should receive restricted > distribution. It is, therefore, the responsibility of > the disclosing ESMTP server to determine whether > additional security measures should be applied to the > use of this ESMTP option. > > A man-in-the-middle attack might change the capabilities reported > for a given recipient. For example: Suppose the sender knows the > recipient has the ability to view color documents so they mark > some things in red in what is otherwise a black and white > document. But someone interferes with the returned capabilities, > indicating that the recipient only supports black and white. The > document is duly downgraded, with the result that the recipient > doesn't see what the sender marked. > > An indirect exposure can occur when the report of a capability > implies use of specific software. If that software is known to > have security weaknesses, the capabilities report effectively > advertises the associated opportunity to exploit the security > weakness. > > For target SMTP servers that require security mechanisms to be in > force at the start of the session, the target SHOULD refrain from > including the CONNEG parameter in an EHLO response until the > requisite security mechanisms are in force. > > For digitally signed content, the use of this option poses a > special challenge. Digitally signing content relies on that > content to be in a particular form. Use of this option changes > that form. Hence an SMTP client that uses this option on > digitally signed content MUST be able to recompute the digital > signature of the content. > > > > 9. ACKNOWLEDGEMENTS > > Graham Klyne provided useful suggestions to an earlier > draft. > > > > 10. NORMATIVE REFERENCES > > [ESMTP1] Klensin, J., Freed, N., Rose, M., Stefferud, > E. and D. Crocker, "SMTP Service Extensions", > RFC 1869, November 1995 > > [ESMTP2] Klensin, J., "Simple Mail Transfer Protocol", > RFC 2821, April 2001. > > [RFC2879] McIntyre, L. and G. Klyne, "Content Feature > Schema for Internet Fax", RFC 2531, August > 2000 > > [RFC2305] Toyoda, K., Ohno, H., Murai, J. and D. Wing, > "A Simple Mode of Facsimile Using Internet Mail", > RFC 2305, March 1998. > > > > 11. AUTHORS' ADDRESSES > > Kiyoshi Toyoda > Matsushita Graphic Communication Systems,Inc > 2-3-8 Shimomeguro, Meguro-Ku > Tokyo 153 JAPAN > > +81.3.5434.7161 > ktoyoda@rdmg.mgcs.mei.co.jp > > > Dave Crocker > Brandenburg InternetWorking > 675 Spruce Drive > Sunnyvale, CA 94086 USA > > +1.408.246.8253 > dcrocker@brandenburg.com > > > > 12. FULL COPYRIGHT STATEMENT > > Copyright (C) The Internet Society (2001). All Rights > Reserved. > > This document and translations of it may be copied and > furnished to others, and derivative works that comment > on or otherwise explain it or assist in its > implementation may be prepared, copied, published and > distributed, in whole or in part, without restriction > of any kind, provided that the above copyright notice > and this paragraph are included on all such copies and > derivative works. However, this document itself may > not be modified in any way, such as by removing the > copyright notice or references to the Internet Society > or other Internet organizations, except as needed for > the purpose of developing Internet standards in which > case the procedures for copyrights defined in the > Internet Standards process must be followed, or as > required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and > will not be revoked by the Internet Society or its > successors or assigns. > > This document and the information contained herein is > provided on an "AS IS" basis and THE INTERNET SOCIETY > AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL > WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT > LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A > PARTICULAR PURPOSE. > > > > APPENDIX > > A. USAGE FOR MULTIPLE RECIPIENTS > > ESMTP permits specification of multiple recipients for the same > content. This option specified here can produce information that > different recipients have different content capabilities. How > this differential information is used will depend upon the > requirements of the sender. This specification does not mandate > particular choices. Three scenarios are possible: > > (1) Single Recipient > > For each recipient, conduct a separate ESMTP session. This > ensures that each content transfer can be tailored to the > capabilities of each recipient. This also consumes the largest > amount of bandwidth and the largest number of cross-network SMTP > protocol exchanges > > (2) Common Content > > For a single ESMTP session, issue RCPT commands that obtain > content capabilities information for each recipient. With the > DATA command, send the best content form that can be processed by > ALL of the recipients. Some recipients will receive content that > is below their best capabilities. However this approach also > consumes the least bandwidth and has the fewest cross-network > protocol exchanges problem: this scenario does not work because the sender has no way to know a priori whether it is possible to produce a common form that is acceptable to all recipients. so any sender that sends multiple RCPT commands in a single session MUST be prepared to terminate the session (either via RSET or QUIT) and retry sending only to those recipients that DO have a common format. suggestion: delete scenario 2, as it is not workable. > (3) Partial Batching > > This scenario begins the same as the "Common Content" scenario. > Content capabilities information is obtained during a single ESMTP > session, with all of the RCPT commands issued together. The > difference for this scenario is that the client SMTP then > terminates the session with an RSET and begins one or more new, > separate sessions. Addressees are processed in batches, according > to the similarity of their capabilities. This option balances > consumption of bandwidth with optimization of content, at the cost > of a terminated session. > > > B. SCENARIOS FOR RELAYING > > ESMTP is a direct transfer mechanism, using a single TCP > connection. It supports Internet mail store-and-forward through > such characteristics as global addressing and ESMTP enforcement of > global features. nit: I'm not at all sure what this last sentence means. > Use of the ESMTP Conneg option is > straightforward when the originating ESMTP client is able to > directly connect to the destination ESMTP server. The nature of > this option is to return address-specific information that will > affect content transmission. Hence the use of this option in the > presence of the in-direct effects of store-and-forward is not > obvious. > > This Appendix discusses some styles of use for the ESMTP Conneg > option when messages are being relayed. The Appendix is intended > only to provide discussion. It is neither intended to be > exhaustive nor restrictive. Other scenarios are likely and > encouraged. > > > B.1 Relay Server Modes > > The key challenge for use of the ESMTP Conneg option is the > requirement the receiving ESMTP server be able to return > capabilities on behalf of a target addressee. This requirement > translates into two, basic styles of operation for the receiving > ESMTP server: > > (1) Server Knows Addressee Capabilities > > Here the receiving server has the necessary details about an > addressee, at the time the sending server issues the RCPT > response. Typically, this information will be obtained through a > direct, real-time query mechanism, either to a directory > containing addressee information or to a service run directly on > behalf of the individual addressee and possibly on the addressee's > system. > > One form of query to the addressee's system is to stack a > cascading sequence of ESMTP sessions and RCPT commands > together, all the way to the destination ESMTP server. Although > theoretically possible, this attempt to turn a multi-hop scenario > into a real-time, pseudo-direct query is not practical. It > will most likely result in response delays for the RCPT command > that are not acceptable, particularly over the public Internet. > > (2) Server Ensures Conversion > > Fundamental to the use of a capabilities exchange is the > requirement that the receiver of capabilities information be able > to convert content into a form that is more capable than the > default form, when the receiver indicates that it can support the > superior form. That is, use of this option presumes that the > sender is holding a "more capable" form of the content and will > map it to a "less capable form" if the receiver does not support > the superior form. problem: there is inherently no way for the sender to know in advance whether it can convert the message in a form that is suitable for the recipient. problem: for most kinds of content there is not an obvious ordering which determines "more capable" or "less capable". fax images containing text are not inherently more or less capable than text - each has different benefits and drawbacks. HTML is not inherently more or less capable than PDF. it depends on how the recipient will use the message. so the assumption by which relaying is justified is not valid. > Hence another style of relaying configuration is to have a relay > SMTP respond to an RCPT capability query by indicating that it > supports the most capable form. The sender will pass the best > version it can. The receiver has then taken responsibility for > performing later conversions, as necessary, to the next hop in the > sequence. That is, the receiving ESMTP server inherits the same > level of responsibility already being held by the sending ESMTP > client. problem: this is unworkable unless the SMTP server already knows the recipient's capabilities, since without knowing those capabilities the SMTP server cannot be sure that it can convert the message to something the recipient can accept. and if the SMTP server already knows the recipient's capabilities, there is no need for it to lie about them. problem: this introduces the possibility of multiple conversions. multiple conversions can cause considerable lossage due to interference between the conversions - e.g. aliasing when audio or image sampling rates are changed, interference caused when artifacts in the the output of one audio codec appear in the input of another. problem: this provision almost certainly allows SMTPs to make assertions about recipient capabilities without the permission of the recipient. > B.2 Some End-to-End Scenarios > > This section suggests methods of using ESMTP Conneg for achieving > an end-to-end service that uses knowledge of recipient > capabilities for modifying the content or the handling of the > content. This section is intended only to explore possible > scenarios. Others are feasible and likely. The choice of scenario > to support will depend upon particular service policies chosen for > a relay. This specification provides no constraint or guidance > about which policies to choose. > > (1) Basic Tranfer betweeen Organizations > > Again noting that alternative configurations and support > environments are permitted, a simple example of combining the two > modes of receiving server style can be helpful. The scenario to > consider is sending from one organization's email system to > another organization's email system, across the Internet. > > This scenario presumes two, independent email services, one for > each organization. In this simple example, the user has a local > ESMTP server and it talks with the organization's Internet email > gateway. Hence there are four ESMTP servers. The originating > server takes the message from the originating user. It then > relays the message to the originating organization's ESMTP > gateway. This gateway, in turn, relays the message to the > destination organization's gateway, which finally delivers it to > the recipient's server. > > In this simple example, the originating ESMTP server includes a > CONNEG option on the RCPT command problem: for the originating server to include CONNEG on outgoing mail without any per-message authorization from the sender presumes that it is never desirable to deliver mail unless the recipient capabilities are known. this is a radical departure from current practice and is probably not feasible. if the example assumes that the organizations have a mutual agreement to support CONNEG for all recipients and the outgoing server only asserts CONNEG when sending to recipients at that organization, this needs to be stated explicitly. > to the originating > organization's Internet gateway and the gateway always responds > that it supports the highest capabilities. It is then given the > most capable form of the content. > > The originating gateway then performs a RCPT CONNEG exchange with > the destination organization's gateway. This gateway can operate > in the same "Ensure Conversion" mode as the originating gateway, problem: no it cannot, at least not without more assumptions than are stated. > or it can perform a real-time query about the addressee's > capabilities. The former mode defers resolving recipient > capabilities until the final step. The real-time query requires > both that the query mechanism be timely, in order to avoid RCPT > response delays, and that it be accurate, with correct information > about the addressee. > > The final exchange is, of course, "direct". The recipient's ESMTP > server is presumed to have easy access to the necessary > capabilities information. > > (2) Integration with Multipart/Alternative > > Basic support for Conneg will typically involve a Conneg client > that has a single, high-quality version of content and then maps > is "down" to the best quality that can be supported by the > responding Conneg server. That is, the sending system will do a > conversion. In another mode of operation the Conneg client > already holds a number of different mappings of content at > different levels of quality. The client will use the Conneg > response to choose the content quality that is "closest" to the > capabilities of the receiver. > > MIME's Multipart/Alternative provides a means for a content > originator to send a fixed set of content quality choices. An > ESMTP relay in the sequence can then choose to use Conneg as a > means of selecting one of the alternatives to transmit, rather > than transmitting the full set. Such a scenario is particularly > useful when the communication path changes from high-bandwidth to > low. > > (3) Content Staging on Retrieval Server > > Rather than converting content to a lower quality, an ESMTP Conneg > client might choose to use a Conneg response for choosing not to > send the content directly. It might, instead, remove the content > from the message and store the content on a retrieval server (for > access through HTTP, FTP or the like.) It can then put a citation > into the message, which points to the stored content. > > For the retrieval server, access security, as well as life-time > management of the content on the retrieval server, should be > considered. A full discussion of these considerations is out of > the scope of this memo." > > (4) Alternate Addressing > > If an ESMTP Conneg client has access to multiple addresses for the > same recipient, it might use Conneg to determine which is most > capabable for particular content and send the content to that one. > > This scenario requires a number of infrastucture features for > which there currently are no standards. From owner-ietf-fax@mail.imc.org Tue Aug 6 04:41:14 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29419 for ; Tue, 6 Aug 2002 04:41:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g768M8L00232 for ietf-fax-bks; Tue, 6 Aug 2002 01:22:08 -0700 (PDT) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g768Law00164; Tue, 6 Aug 2002 01:21:37 -0700 (PDT) Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id BAA04142; Tue, 6 Aug 2002 01:30:39 -0700 Message-Id: <5.1.0.14.2.20020805143051.02b2d5d0@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Tue, 06 Aug 2002 01:21:23 -0700 To: Keith Moore From: Dave Crocker Subject: Re: Fwd: I-D ACTION:draft-ietf-fax-esmtp-conneg-03.txt Cc: ietf-fax@imc.org, ietf-smtp@imc.org In-Reply-To: <200208051919.g75JJkY29591@astro.cs.utk.edu> References: <(Your message of "Mon, 05 Aug 2002 08:47:53 PDT.") <5.1.1.2.2.20020805084437.035119e0@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Keith, Responding to those items that I can: At 03:19 PM 8/5/2002 -0400, Keith Moore wrote: >- it is still overbroad, claiming applicability for general email > when it really works only for a limited subset of content > which has an obvious ordering relation for "quality". Please feel free to provide real-world examples of usage that is likely to be attempted and that will not work properly. > perhaps illustrating this, all of the examples are for fax. You believe that making examples be for something other than fax will materially affect the adequacy of the normative specification? >- it still permits unauthorized parties to make arbitrary and > unspecified alterations to mail. Sorry, no. It makes no alterations to the power of intermediaries. It gives them better information, not different capabilities. In any event, the "permissions" assigned to intermediaries are a matter of administration policy, not technical specification. If an administrative authority does not want to permit use of this option, it will not use it. >- worse, the new version permits unauthorized parties to make > arbitrary assertions of recipient capabilities in the absence > of explicit information. That is not what the discussion says. It describes a way of having the receiving SMTP server take on the responsibilities for matching capabilities that already reside with the sending SMTP server. Remember that these servers about which you are so suspicious already have "control" over the semantics of the recipient's address. You can't get more powerful than that. And, by the way, please remember that the appendix is not normative. It does not change the specification. It "permits" and "prohibits" nothing. >- it still allows SMTP servers to make assertions of recipient capabilities > without actual knowledge of those capabilities. What is the problem this causes? How does it make this service fail? >- I still think overloading of RCPT is a pessimal way to do this A number of separate analyses of the design choices suggest pretty strongly that a separate command is actually worse than an RCPT parameter. A separate command changes the SMTP state machine. That is not a minor thing. An example of the impact of this is probable failure in getting through some firewalls. > since the command will often need to be issued twice anyway - Your use of the word "often" is contrary to the likelihoods expected by others. >recommendations for near-term publication: > >- this feature should be renamed and the document reworded to make it > clear that it is fax-specific rather than general purpose. There is nothing in the normative text that is fax specific. >- misleading text should be fixed, unworkable recommendations should be > removed. Please offer whatever text changes you think helpful. >- the document should be published as experimental rather than on the > standards track, since it doesn't meet the requirements for proposed > standard. You have so far offered no details of failure scenarios that warrant the fears you are expressing. >things that need to be fixed before the document should be considered >as standards-track: > >- needs to be examined for a wide range of content Again, you are offering such a generic suggestion, there is no way to know what problems you fear or how to satisfy them. >- needs to have a well-defined protocol by which senders can request > conneg "convert-or-fail" semantics on a per-message, and probably > per-bodypart, basis. if they are not requested, such semantics > must not be applied. So, SMTP is not appropriate to standardize without having submit and pop also specified at the same time? That is a barrier that is equivalent to the one you wish to impose before standardizing the current option. It means that you believe that an entire suite of specifications must be offered at the same time, before any one of the components may be standardized. This is contrary to typical IETF practise. >- needs to explicitly specify which conversion algorithms are permissible > and how new conversion standards may be added, since there can be > multiple ways to perform a conversion and some are worse than others. Conneg is not new to this option. The requirement that you wish to impose has not been imposed on other uses of Conneg. It appears that you are confusing a carriage scenario with a conversion mechanism. >- needs to state that conneg features are only advertised with the > recipient's consent and control If you have text to suggest for the draft, please offer it, for working group review. (It would have been nice to have had that text offered earlier. The danger is that there will be a running stream of non-normative modifications of this nature.) >- needs to state exactly which parties are authorized to perform > conversion. Huh? >- needs to prevent multiple conversions. What does that mean? What problems are you concerned about? >problem: this proposal doesn't provide any way to "enforce" content >negotiation past a single hop. You believe that there does not already exist a requirement for relays to enforce content quality? You believe that the concern about enforcing content quality is new to this option? >nit: It is not clear whether it is desirable for the server to give >CONNEG errors priority over all other sources of error. The nature of any complex system is that there can be multiple errors at approximately the same time. Hence your concern for prioritization of error reporting is not specific to this option. >problem: the client cannot be compelled to perform transformations that >are impossible or for which the client lacks the capability. no client >can reasonably convert video to audio. Please provide a detailed example of Conneg use that could lead to the problem of needing to convert video to audio. > > (2) Common Content > > > > For a single ESMTP session, issue RCPT commands that obtain > > content capabilities information for each recipient. With the > > DATA command, send the best content form that can be processed by > > ALL of the recipients. Some recipients will receive content that > > is below their best capabilities. However this approach also > > consumes the least bandwidth and has the fewest cross-network > > protocol exchanges > >problem: this scenario does not work because the sender has no way to know a >priori whether it is possible to produce a common form that is acceptable >to all recipients. Feel free to provide a real-world example of being unable to produce a common form within the context of conneg capabilities information. You have raised this concern before and we have, so far, seen nothing concrete to substantiate the concern. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Tue Aug 6 14:37:45 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22982 for ; Tue, 6 Aug 2002 14:37:44 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g76IDiE24234 for ietf-fax-bks; Tue, 6 Aug 2002 11:13:44 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g76ID7w24211; Tue, 6 Aug 2002 11:13:07 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g76ID0f00742; Tue, 6 Aug 2002 14:13:00 -0400 (EDT) Message-Id: <200208061813.g76ID0f00742@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: Keith Moore , ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Fwd: I-D ACTION:draft-ietf-fax-esmtp-conneg-03.txt In-reply-to: (Your message of "Tue, 06 Aug 2002 01:21:23 PDT.") <5.1.0.14.2.20020805143051.02b2d5d0@jay.songbird.com> Date: Tue, 06 Aug 2002 14:13:00 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Keith, > > Responding to those items that I can: > > At 03:19 PM 8/5/2002 -0400, Keith Moore wrote: > >- it is still overbroad, claiming applicability for general email > > when it really works only for a limited subset of content > > which has an obvious ordering relation for "quality". > > Please feel free to provide real-world examples of usage that is likely to > be attempted and that will not work properly. I have already done so, on multiple occasions. Perhaps we have different ideas of what is 'likely' or what is 'real-world'. To me it seems likely and consistent with the real world that senders will send around a wide variety of content, that recipients will want to specify what kinds of content they are willing to accept to keep from having their mailboxes cluttered with useless content, and that senders will at least occasionally want to specify that the message should not be delivered unless the recipient is willing to accept the content. All of which is fine. But the assumption that some intermediate MTA can then be expected to "transform" the sender's content into something that the recipient is willing to accept - that does not seem either fine, likely, or consistent with the real world. At any rate, I don't think it's acceptable for an extension to cause delivery failure or unrequested munging of messages even in 'unlikely' cases - when whether the extension is employed isn't under control of the sender. > > perhaps illustrating this, all of the examples are for fax. > > You believe that making examples be for something other than fax will > materially affect the adequacy of the normative specification? I think that the examples being all fax illustrates that other cases have not been adequately considered. Because as soon as you start to consider other cases of how SMTP is used to send content, you find that the existing proposal doesn't suffice. > >- it still permits unauthorized parties to make arbitrary and > > unspecified alterations to mail. > > Sorry, no. It makes no alterations to the power of intermediaries. It > gives them better information, not different capabilities. No, it's not just giving better information - because the SMTP client is *required* to do something with that information. And there are words and examples in the current proposal that have MTAs doing transformations without any authorization from the sender or recipient to do so. > In any event, the "permissions" assigned to intermediaries are a matter of > administration policy, not technical specification. If an administrative > authority does not want to permit use of this option, it will not use it. I disagree that it is appropriate to assign such authority to administrators. Certainly the transformations will not be performed (i.e. the software will not be installed) without the administrators' consent, but the authority to transform a particular message needs to be given by the user, not the administrator. The administrator is rarely in a position to know whether the transformation is appropriate. > > >- worse, the new version permits unauthorized parties to make > > arbitrary assertions of recipient capabilities in the absence > > of explicit information. > > That is not what the discussion says. It describes a way of having the > receiving SMTP server take on the responsibilities for matching > capabilities that already reside with the sending SMTP server. I think you have that backwards, or something. It doesn't make any sense to me. > Remember that these servers about which you are so suspicious already have > "control" over the semantics of the recipient's address. You can't get > more powerful than that. Yes, but the function of SMTP intermediaries has generally been limited to relaying of the message intact - not performing arbitrary transformations on the message. We've accepted that minor transformations might be necessary in a gateway situation, but we've never blessed the idea that arbitrary MTAs should change the content of messages within the SMTP world. > And, by the way, please remember that the appendix is not normative. It > does not change the specification. It "permits" and "prohibits" nothing. Perhaps it is only misleading or confusing, but it still affects the quality of the document. > >- it still allows SMTP servers to make assertions of recipient capabilities > > without actual knowledge of those capabilities. > > What is the problem this causes? How does it make this service fail? If the message is not delivered intact when sender did not request transformations and the receiver did not request transformations, that's a failure. SMTP isn't supposed to mung messages. > >- I still think overloading of RCPT is a pessimal way to do this > > A number of separate analyses of the design choices suggest pretty strongly > that a separate command is actually worse than an RCPT parameter. A lot of that analysis depends on how you assume that this is used - and in particular whether it is used only by special-purpose devices or if it's used between UAs in general. I don't share those assumptions. > A separate command changes the SMTP state machine. That is not a minor > thing. An example of the impact of this is probable failure in getting > through some firewalls. A separate command doesn't have to change the state machine in the sense that it adds either new states or new state transitions - and I'd argue that the command should not do so. I'll grant that firewalls might have trouble with a new command. But I've also seen firewalls have trouble with new parameters, so I don't know how much the existence of firewalls favors a new parameter over a new command. And RCPT with CONNEG most definitely changes the state machine of the sender, even in cases where the sender sends at most one RCPT per session, because there is at least new one state transition necessary for "cannot adapt content to recipient's capabilities". And in general MTAs will need to deal with the multiple RCPT cases, which adds a fair amount of complexity to the sender's state machine. > > since the command will often need to be issued twice anyway - > > Your use of the word "often" is contrary to the likelihoods expected by > others. Yes, I understand that, though I think "some others" would be more accurate. People will disagree about what they think are probable usage scenarios. > >recommendations for near-term publication: > > > >- this feature should be renamed and the document reworded to make it > > clear that it is fax-specific rather than general purpose. > > There is nothing in the normative text that is fax specific. The expectation that it's possible to downgrade to a common format is specific to fax. It might work with voice mail assuming no proprietary codecs were used, but that seems like a stretch. Also, the assumptions about how this will be used, that governed design decisions like overloading RCPT vs a new command, seem to be heavily based on fax. > >- misleading text should be fixed, unworkable recommendations should be > > removed. > > Please offer whatever text changes you think helpful. To some degree I have tried to do so already, though perhaps not bracketed as such. But I don't think we're quite to the point we can solve the problems by mere wordsmithing. > >- the document should be published as experimental rather than on the > > standards track, since it doesn't meet the requirements for proposed > > standard. > > You have so far offered no details of failure scenarios that warrant the > fears you are expressing. That's false. I've done so on multiple occasions. > >things that need to be fixed before the document should be considered > >as standards-track: > > > >- needs to be examined for a wide range of content > > Again, you are offering such a generic suggestion, there is no way to know > what problems you fear or how to satisfy them. Well, I've already stated them on multiple occasions. And when the problem is one of a failure to consider some important factor early in the design phase (as this seems to be), the fix is to reconsider that factor. Until that is done, all protocol fixes will be suspect. > >- needs to have a well-defined protocol by which senders can request > > conneg "convert-or-fail" semantics on a per-message, and probably > > per-bodypart, basis. if they are not requested, such semantics > > must not be applied. > > So, SMTP is not appropriate to standardize without having submit and pop > also specified at the same time? I didn't say anything about the mechanism, and in fact I expect that senders would specify transformation permissions in message and body part headers. I don't know if it's necessary to standardize the mechanisms by which recipients specify conneg parameters, but I do think it's necessary that recipients consent to such rather than having some unrelated other party make assertions on their behalf. > That is a barrier that is equivalent to the one you wish to impose before > standardizing the current option. It means that you believe that an entire > suite of specifications must be offered at the same time, before any one of > the components may be standardized. This is contrary to typical IETF > practise. I think you have this backwards. It's contrary to IETF practice to standardize a protocol that has known technical omissions - which this proposal certainly does. Your claim that it's appropriate to advance an incompete specification because 'an entire suite of specifications must be offered at the same time' is baseless and not supported by either the process standards or by 'typical IETF practise'. > >- needs to explicitly specify which conversion algorithms are permissible > > and how new conversion standards may be added, since there can be > > multiple ways to perform a conversion and some are worse than others. > > Conneg is not new to this option. The requirement that you wish to impose > has not been imposed on other uses of Conneg. It appears that you are > confusing a carriage scenario with a conversion mechanism. The difference here, I believe, is that with CONNEG over SMTP arbitrary SMTP servers are both allowed and expected *as a matter of protocol conformance* to perform conversions without consent of either sender or receiver. > >- needs to state that conneg features are only advertised with the > > recipient's consent and control > > If you have text to suggest for the draft, please offer it, for working > group review. (It would have been nice to have had that text offered > earlier. The danger is that there will be a running stream of > non-normative modifications of this nature.) I could offer text on this one specific point, but there are other points for which offering text seems counterproductive. In general, it seems premature to offer text when we don't even have a vague agreement on what specific mechanisms (e.g. for indicating consent) should look like. > >- needs to state exactly which parties are authorized to perform > > conversion. > > Huh? > > > >- needs to prevent multiple conversions. > > What does that mean? What problems are you concerned about? this is mentioned below in the detailed comments. > >problem: this proposal doesn't provide any way to "enforce" content > >negotiation past a single hop. > > You believe that there does not already exist a requirement for relays to > enforce content quality? You believe that the concern about enforcing > content quality is new to this option? I don't know what it means to "enforce content quality", partially since I think it's the job of MTAs to "maintain content integrity" and partially since the MTA has no notion of what "quality" means to the recipient. I believe there is now a requirement for relays to relay mail intact - in the current world, any relay that doesn't do so is nonstandard. The proposed extension tries to change that. > >nit: It is not clear whether it is desirable for the server to give > >CONNEG errors priority over all other sources of error. > > The nature of any complex system is that there can be multiple errors at > approximately the same time. > > Hence your concern for prioritization of error reporting is not specific to > this option. No, but the proposal says that it MUST take precedence, and that seems overbroad. I did attempt to suggest better wording. > >problem: the client cannot be compelled to perform transformations that > >are impossible or for which the client lacks the capability. no client > >can reasonably convert video to audio. > > Please provide a detailed example of Conneg use that could lead to the > problem of needing to convert video to audio. Someone sends mail with a video attachment to a recipient that advertises that it can only accept audio. Somebody (whether the sender or an intermediate MTA) adds the CONNEG option for that recipient. The conversion is not possible, yet it is required by the current spec. > > > (2) Common Content > > > > > > For a single ESMTP session, issue RCPT commands that obtain > > > content capabilities information for each recipient. With the > > > DATA command, send the best content form that can be processed by > > > ALL of the recipients. Some recipients will receive content that > > > is below their best capabilities. However this approach also > > > consumes the least bandwidth and has the fewest cross-network > > > protocol exchanges > > > >problem: this scenario does not work because the sender has no way to know a > >priori whether it is possible to produce a common form that is acceptable > >to all recipients. > > Feel free to provide a real-world example of being unable to produce a > common form within the context of conneg capabilities information. You > have raised this concern before and we have, so far, seen nothing concrete > to substantiate the concern. As far as I can tell, this is only because you believe that nobody will try to use CONNEG except in those cases that you've anticipated or where it has been observed to work well. It's not as if I haven't supplied concrete examples as to how things can fail, but you dismiss them as not 'real-world'. In my "real world" users' interests and habits are quite diverse and are not so predictable. At any rate, making things work in your idea of the real world is not sufficient. Email must function properly as a matter of design, so that if the specifications are followed then predictable and useful behavior is assured. Speculation about what users are likely to do and what administrators are likely to impose is not sufficient. Keith From owner-ietf-fax@mail.imc.org Tue Aug 6 15:38:20 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25816 for ; Tue, 6 Aug 2002 15:38:20 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g76JFt626487 for ietf-fax-bks; Tue, 6 Aug 2002 12:15:55 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g76JFgw26472; Tue, 6 Aug 2002 12:15:42 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g76JFif00799; Tue, 6 Aug 2002 15:15:44 -0400 (EDT) Message-Id: <200208061915.g76JFif00799@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: ietf-fax@imc.org, ietf-smtp@imc.org Subject: an attempt to make CONNEG-over-SMTP work reasonably over mail relays cc: moore@cs.utk.edu From: Keith Moore Date: Tue, 06 Aug 2002 15:15:44 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: this is an attempt to outline what it will take to make CONNEG-over-SMTP work reasonably over mail relays goals: - make it possible for a client to request recipient capabilities, for whatever use, provided it can communicate directly with recipient's SMTP servers. - make it possible for senders to request "assuredly deliver in a form the recipient can use, else fail" semantics. - work with relaying - no change to current SMTP functioning unless explicitly requested by sender 1. providing recipient capability information for general-purpose mail reception, recipient capability information MUST be under the control of the recipient. for fixed-function devices which have exclusive use of one or more mailboxes, the recipient capabilities associated with those mailboxes MAY be set by such devices to reflect their capabilities. the mechanism by which this is done, in the case where the SMTP server and the receiving device are separate, is currently unspecified. posting of recipient capability information DOES NOT imply that the recipient is unwilling to accept contents that are outside of those capabilities. (if this functionality is desirable this needs to be a separate capability - because it's clearly useful to state preferences while still being willing to accept the occasional attachment in an unpreferred format) 2. obtaining recipient capability information recipient capability information (if available) may be obtained by any party in the following way: - do a SRV lookup in DNS for {prefix-tbd}._tcp.{recipient-domain}. if any servers are returned, contact them using the SMTP protocol. if server supports CONNEG in the EHLO response. issue RCPT CONNEG=OPTIONAL, record results, issue QUIT, and close connection. this allows senders to potentially determine recipient capability prior to sending the message. there is no requirement that the SMTP servers advertised in this manner actually be willing to accept mail, unless they are also advertised as MXes for that domain. e.g. they can respond to all DATA and similar commands with 5xx errors. any CONNEG information returned by such servers MUST be consistent with CONNEG information that would be obtained by MTAs relaying mail to the recipient, though the information is allowed to change over time. 3. originating mail with "deliver recipient-usable content or fail" semantics this extension attempts to provide a new transport option, known as "deliver recipient-usable content or fail" (DRUCOF for short) semantics - DRUCOF semantics MUST be explicitly requested by the sender - in SMTP, the sender's request is communicated with a DRUCOF option to RCPT (which is advertised in EHLO in the usual way, details to be determined) - server advertisement of DRUCOF in EHLO asserts that the server is willing to convey any sender's request for DRUCOF semantics and to implement them as provide in section 4. DRUCOF applies only to critical portions of a message. By default all portions of a message are assumed to be critical. This can be specified by the sender on a per-body part basis by including an appropriate body part header. details to be determined. it should be possible to mark a body-part in any of several ways: conversion-prohibited, conversion-permitted, omission-permitted; it should also be possible to mark a body-part as to whether ability to provide the specified integrity level is critical to successful message delivery. the DRUCOF extension is defined as a mechanism to allow the sender's request for "deliver recipient-usable content or fail" semantics to be communicated through relays. if initial submission of the message (from the UA) is directly to the recipient's primary MX, DRUCOF is not needed, and the behavior of the sender is as specified in the next section. 4. relaying mail with the DRUCOF option when an SMTP client attempts to relay mail to a recipient for which the DRUCOF option was specified, or for which the SMTP client knows for certain that the sender requests DRUCOF semantics, the following applies: - if the SMTP server advertises CONNEG: - if an attempt to request a CONNEG string for the recipient succeeds { - if the client can perform conversions to make the message acceptable to the recipient, or if no conversions are necessary to make the message acceptable, perform conversions as necessary and relay the message without asserting DRUCOF or CONNEG. - else, if the server supports DRUCOF, relay the message with the DRUCOF option (if the client can't perform the conversion, perhaps a later MTA can) - else, the delivery fails (conversion required but not supported) } - else (request for CONNEG string for a recipient fails due to a permanent or temporary error) { - if the server supports DRUCOF, relay the message with the DRUCOF option to RCPT - else, the delivery fails (DRUCOF specified but capabilities unavailable) } - else, if the SMTP server advertises DRUCOF - relay the message with DRUCOF set - else - the delivery fails (no way to relay sender's preference for DRUCOF) note: the above assumes that it's better to convert as early as possible, and (more to the point) to provide as many opportunities for conversion as possible. one could argue that it's better to convert as late as possible so that the conversion is closer to the recipient and more likely to be done according to the recipient's preferences. I'm not sure about which is better. note 2: it should be feasible to extend this to allow the sender to optionally request conversion when available and appropriate, but to deliver intact if conversion cannot be performed. 5. conversions conversions MUST NOT be performed unless requested by the sender conversions MUST NOT be performed in the absence of specific information about the recipient conversions MUST NOT be performed on content marked conversion-prohibited. conversions performed by MTAs other than the sender or recipient's SHOULD be standardized by some appropriate body conversions SHOULD be chosen in such a way as to minimize loss of information when multiple conversions are possible, the least lossy conversion SHOULD be employed. From owner-ietf-fax@mail.imc.org Wed Aug 7 02:19:23 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27385 for ; Wed, 7 Aug 2002 02:19:22 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g775wYZ22284 for ietf-fax-bks; Tue, 6 Aug 2002 22:58:34 -0700 (PDT) Received: from mail.notes.ricoh.co.jp (mail.notes.ricoh.co.jp [202.211.49.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g775wWw22278 for ; Tue, 6 Aug 2002 22:58:32 -0700 (PDT) Received: from delsol.isd.ricoh.co.jp (IDENT:mirapoint@[133.139.250.75]) by mail.notes.ricoh.co.jp (8.11.6/3.7W) id g775wCF09734; Wed, 7 Aug 2002 14:58:12 +0900 Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by delsol.isd.ricoh.co.jp (Mirapoint) with ESMTP id ADU69659; Wed, 7 Aug 2002 14:58:10 +0900 (JST) Received: from localhost (tulip.toda.ricoh.co.jp [133.139.60.74]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id OAA08998; Wed, 7 Aug 2002 14:53:31 +0900 (JST) To: minutes@ietf.org Cc: ned.freed@mrochek.com, paf@cisco.com, ietf-fax@imc.org Subject: IETF-FAX WG minutes at Yokohama meeting From: Hiroshi Tamura X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020807145756G.tamura@toda.ricoh.co.jp> Date: Wed, 07 Aug 2002 14:57:56 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 306 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Attached is the FAX WG minutes at Yokohama meeting. Regards, -- Hiroshi Tamura, Co-chair of IETF-FAX WG E-mail: tamura@toda.ricoh.co.jp --------------------------------------------------------------------- TUESDAY, July 16 at 0900-1130 ============================== CHAIRS: Claudio Allocchio Hiroshi Tamura --------------------------------------------------------------------- Opening --------------------------------------------------------------------- FAX WG meeting was held jointly with VPIM WG, on July 16 2002. Hiroshi Tamura, co-chair of FAX WG, welcomed the participants at his home town Yokohama and started the meeting. --------------------------------------------------------------------- Agenda Bashing and etc. --------------------------------------------------------------------- Hiroshi Tamura proposed to change slightly the order of the agenda discussion, moving the ESMTP-CONNEG and FFPIM topics at the end of the Fax part of the meeting, in order to allow more time to these topics without compressing the other ones. The change was approved unanimously. We also received apology from Ned Freed, an Area Director of Application Area, who could not be with us, but Patrik Faltstrom, another Area Director, was here replacing him. --------------------------------------------------------------------- The I-Ds which IESG approved and are in RFC editor's queue --------------------------------------------------------------------- Hiroshi Tamura reported that the following documents are already in the RFC editor's queue: - draft-ietf-fax-implementers-guide-08.txt - draft-ietf-fax-content-negotiation-05.txt - draft-ietf-fax-tiff-regbis-05.txt - draft-ietf-fax-tiff-fx-reg-01.txt He assured the WG that the chairs should take action with RFC editors and IANA administrators, in order to have the RFC number assigned ASAP (i.e. prior to publication) to the tiff-regbis and tiff-fx-reg I-Ds. It is needed for Draft Standard process of TIFF-FX (RFC 2301) itself as well as the reference in implementers-guide I-D and ITU-T T.37. After the meeting, Hiroshi Tamura asked RFC editors and IANA administrators for their action. Also, content-negotiation I-D was assigned RFC number and was published. It is RFC 3297. --------------------------------------------------------------------- The I-Ds for which IETF Last Call was finished --------------------------------------------------------------------- Hiroshi Tamura presented the list of documents whose IETF last call was completed without significative comments: - draft-ietf-fax-gateway-protocol-08.txt - draft-ietf-fax-gateway-options-05.txt - draft-ietf-fax-service-v2-05.txt Regarding service-v2-05 I-D, it refer DSN (RFC 1894 update) and TIFF-FX (draft-ietf-fax-tiff-fx-11.txt). Greg Vaudreuil reported the status of DSN (see slides). After IANA questions were answered in April, and an extended implementation report was submitted in early June, the document is currently on IESG table, without any apparent outstanding issues. The ADs will check its status, too. The draft-ietf-fax-tiff-fx-11.txt I-D is waiting for the supplementary implementation report to be published (see later on). We confirmed, even if the targeted I-D refers other I-Ds, it may finish IETF Last Call and move to RFC-editors' queue. In that case, it will be published as RFC after all the reference I-Ds become RFC. In fact, service-v2-05 I-D will finish IETF Last Call sooner or later, while it refers DSN and TIFF-FX. --------------------------------------------------------------------- The I-D which IESG is reviewing (Before IETF Last Call) --------------------------------------------------------------------- Hiroshi Tamura presented one I-D on the IESG queue (Area Directors review stage): - draft-ietf-fax-timely-delivery-05.txt There were no comments and modifications since the last meetings. The WG Last Call was already finished. Thus, we just wait for the ADs review and for the reference to draft-vaudreuil-1983ext-01.txt to be solved. The 1983ext I-D status was also updated by Greg Vaudreuil. The situation is very similar to DNS. There are no outstanding issues. After the meeting, Greg Vaudreuil and Hiroshi Tamura agreed that FAX WG will do the WG Last Call after it is reposted, as it is already expired. --------------------------------------------------------------------- TIFF-FX implementation report --------------------------------------------------------------------- Hiroshi Tamura introduced it. There is already the original report in IETF site. This was for the additional (new) report to be submitted. He explained (see slides) that the CIAJ (Communications and Information network Association of Japan), whose members practically contain all the fax manufactures in Japan, agreed to perform an extended further TIFF-FX implementation test, to supplement the original report. CIAJ already succeeded IFax and TIFF-FX testing in 1999 and 2001 for Profile S, F and J. The participats are Oki Data, Canon, Kyocera Mita, Sharp, Toshiba-Tec, NEC, Fuji-Xerox, Brother, Matsushita, Minolta, Murata and Ricoh. The testing for Profile C, L and M is planned. Some testings for Profile C was done successfully last month, and the remains will be done by the end of August. CIAJ requires the new report should be supplementary to the orignal report. It will include specified product name, supported tag information, license validation for some profiles It will be submitted by the end of September. Patrik Faltstrom, Area Director, explicitly reminded that the license statement should specify that the company has exercised the proof of "independent licensing" in implementing their products. The chairs should be careful for it. --------------------------------------------------------------------- Addressing --------------------------------------------------------------------- -draft-allocchio-gstn-03.txt Claudio Allocchio made a short report about the addressing documents. After the last meeting and the suggestions from the WG, version 03 was published in March. The only difference from version 02 was that the "implementer's note", regarding 'pause' and 'tonewait' was turned into a recommended (SHOULD, MAY) implementation specification. As there were not further comments, and a numver of IDs are starting to use the docuement as a reference, the ADs decided to issue the IETF last call: the request was submitted on July 15th. --------------------------------------------------------------------- FAX in ENUM --------------------------------------------------------------------- Kiyoshi Toyoda reported on the I-D in preparation to register IFax service in ENUM with IANA. The IFax functional specification is different from the normal email service, PSTN-fax service and T.38 fax service. The returned DNS NAPTR record will specify an email address that is to be used for reaching the target system fax mailbox. The email address is used in accordance with "Simple Mode" RFC 2305, "Extended Mode" RFC 2532 or FFPIM. Service name: "ifax" Protocol: smtp URI scheme: "mailto" Intended Usage: COMMON Patrik Faltstrom, as editor of the current ENUM NAPTR record specification, reported the discussion of the preceding day at the ENUM WG, where the final syntax was again discussed. Now the final decision will be taken on the mailing list. Thus, the Ifax ENUM I-D, which Kiyoshi Toyoda prepare, will have to follow the discussion, and conform with it. However, this is not a problem for the IFax case, as we do not require specific hierarchical syntax for the resource record data fields. Patrik and the WG asked Kiyoshi Toyoda now to submit the text of the I-D, and discuss it within the FAX WG, with CC to the ENUM mailing list, although Patrik commented it should be mainly discussed and solved in FAX WG. He promised he will submit it within a short time. --------------------------------------------------------------------- ITU issues --------------------------------------------------------------------- Hiroshi Tamura introduced. The next ITU-T SG16 meeting is held in October 2002. He will report our activities there. Also, As a WG the documents which are referenced by ITU-T documents and need some processing are: "image/tiff" MIME Sub-type Registration "image/tiff-fx" MIME Sub-type Registration Implementers Guide FAX WG are now asking the RFC editors at least for the assignement of the RFC number. He will also report on the status of the TIFF-FX issue, which should progress after the supplementary implementation report is submitted in September. The inputed information will be decided on the mailing list. --------------------------------------------------------------------- SMTP Service Extension for Content Negotiation (ESMTP CONNEG) --------------------------------------------------------------------- Claudio Allocchio summarized the status of the discussion which started on the mailig lists after the IETF last call was issued for the Service Extension for Content Negotiation. The new version is at http://www.brandenburg.com/specifications/draft-ietf-fax-esmtp-conneg-03.txt. It is not yet available at ID repository. On the mailing lists (including the IETF general one), we saw discussion which mainly can be grouped under these three major topics: - is the proposal doing layering violations of the model MTA-MUA? - how the proposal handles the multi-relays case? - which is the most efficient/more elegant specification approach, i.e. use RCPT TO or another sepcific command and then RCPT TO? On the mailing list the dabate did not show yet a clear direction, and the WG discussion should help in clarifying ideas. After Claudio's introduction, Dave Crocker, one of the authors of the I-D, started the debate, thanking Claudio for his very neutral introduction of the topics, and explained the reasons why he is convinced that the current approach taken into the document should be the one to go for. On the layering violations (i.e. the MTA knowing the MUA capabilities and keeping information about it to report back to the sender MUA), Dave suggested that we should be pragmatic, and consider that for most of the cases where Internet Fax is involved, the final MTA and MUA are on the same host, and very often are the same piece of software. This might not be the case in all possible circumstances, but it will quite well fit the model. Furthermore, most of the Ifax traffic would be point to point, without relaying. There were comments reminding that in most of the corporate cases, this might be false, as firewalls and single entrance SMTP relay are in common use, and this might introduce complications into the paradigm. After a discussion about the general model, which showed that there is not a common behaviours expected from the current SMTP messaging system, the WG pointed out that this is not a situation specific to Ifax, but it applies in general to all messaging purposes, incliding VPIM, MIME etc. Solving the basic philosophical problem thus requires the involvement of the whole SMTP area expertise people, and not only the FAX WG people. There was a comment that the debate on this should continue either on the general IETF list, or considered to be moved to the area covered by the proposed WG on "unified messaging" having a BOF later during the week (LEMONAGEe). The discussion then focused on the implementation methods, i.e. should we use an option into the RCPT TO command, and thus use a single command, or should issue first another command, and then when capabilities of the recipient(s) are discovered, only then issue the set of RCPT TO commands? The aim should be the efficiency of the interaction in the transport system between MTAs, and also some MUAs. Dave defended the current specification, where a single command (RCPT TO) is used to ask and discover capabilities of the recipient MUA, while Greg Vaudreuil prefered the idea of another command to be issued before the RCPT TO sequence is started, in order to sort first recipients depending on capabilities. Claudio, removing momentarily his chair hat, also supported the single command, in favour of a more practical, even if probably less elegant, approach. Patrik Faltstrom reminded that Ned Freed commented a lot on this topic, and at the end asked the WG to come to a conclusion on this two alternates. Harald Alvestrand, as a member of the IESG, also reminded that this is the fundamental topic where the IESG should be convinced of the best solution, and also removing his IESG hat for a moment, he instead suggested that two separate commands would do an easier job for implementors. Claudio reminded that there is no apparent prevalent opinion on how the current SMTP system behaves, and reminded that some implementers think the SMTP world is mostly "one recipient per MTA" when there is not a firewall or similar security measures in effect, and "many users per relay MTA" where these measueres are in effect. A query to the ones present in the room showed 1 hand in favour of a simple command (current specification), 2 hands in favour of using 2 separate commands and the vast majority of the WG, which did not make its mind on it yet (the FAX WG is not so good in humming, we use hands). Keeping in mind that also many other people not present in the room have opinions on this topic, the further discussion and decision was moved to the mailing lists involved, including the general IETF list. --------------------------------------------------------------------- FFPIM --------------------------------------------------------------------- Dave Crocker reported the the newest version of the document contained some minor edits (upon suggestions from Dan Wing), and asked to those presents some questions: - Use of ESMTP options as MAY or SHOULD? - FFPIM conformance require RFC2305 and RFC2532 conformance? We decided to vote by a show of hands. The result was "SHOULD" and "require". After the meeting, Hiroshi Tamura again asked them in the mailing list. But, there were no comments. Thus, those are the results. Moreover, the document refers ESMTP CONNEG specification. It was agreed that the CONNEG text should be more detailed in ESMTP CONNEG I-D, and that we should of course adapt it to the output of the dicussion about it. --------------------------------------------------------------------- Closing --------------------------------------------------------------------- FAX WG handed over to VPIM agenda points, and Glenn Parsons, chair of VPIM WG, chaired the rest of the meeting. Note that the FAX and VPIM WGs confirmed they will continue joint meetings until all their work is finished. Thus, we will meet again together in Atlanta, in November 2002. From owner-ietf-fax@mail.imc.org Thu Aug 15 14:28:40 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09069 for ; Thu, 15 Aug 2002 14:28:40 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7FIAO413338 for ietf-fax-bks; Thu, 15 Aug 2002 11:10:24 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7FIANw13334 for ; Thu, 15 Aug 2002 11:10:23 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07676; Thu, 15 Aug 2002 14:08:57 -0400 (EDT) Message-Id: <200208151808.OAA07676@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ietf-fax@imc.org From: The IESG Subject: Protocol Action: A Simple Mode of Facsimile Using Internet Mail to Draft Standard Date: Thu, 15 Aug 2002 14:08:57 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the Internet-Draft 'A Simple Mode of Facsimile Using Internet Mail' as a Draft Standard. This document obsoletes RFC2305. This document is a product of the Internet Fax Working Group. The IESG contact persons are Ned Freed and Patrik Faltstrom. Technical Summary This specification provides for "simple mode" carriage of facsimile data using Internet mail. Extensions to this document will follow. The current specification employs standard protocols and file formats such as TCP/IP, Internet mail protocols, MIME, and Tagged Image File Format (TIFF) for Facsimile. It can send images not only to other Internet-aware facsimile devices but also to Internet-native systems, such as PCs with common email readers which can handle MIME mail and TIFF for Facsimile data. The specification facilitates communication among existing facsimile devices, Internet mail agents, and the gateways which connect them. Working Group Summary This document is a revision of RFC 2305. There have been no technical changes from the previous version. Protocol Quality This specification was reviewed for the IESG by Ned Freed. RFC Editor note: The references Several references in this document need to be updated. In particular, [7] Allocchio, C., "Minimal PSTN address format for Internet mail", draft-ietf-fax-faxaddr-v2-04.txt, June 2001. has been published as RFC 3191, [8] Allocchio, C., "Minimal fax address format for Internet mail", draft-ietf-fax-minaddr-v2-04.txt, June 2001. has been published as RFC 3192, [9] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996. should refer to draft-vaudreuil-1894bis-01.txt, [18] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", RFC 2487, January 1999. should refer to RFC 3207, and [19] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998. should refer to RFC 2633. The acronym "TIFF" in the abstract needs to be expanded to "Tagged Image File Format (TIFF)". From owner-ietf-fax@mail.imc.org Thu Aug 15 18:06:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17823 for ; Thu, 15 Aug 2002 18:06:54 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7FLonS25513 for ietf-fax-bks; Thu, 15 Aug 2002 14:50:49 -0700 (PDT) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7FLolw25509 for ; Thu, 15 Aug 2002 14:50:47 -0700 (PDT) Received: from bbprime.brandenburg.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id PAA16345 for ; Thu, 15 Aug 2002 15:00:49 -0700 Message-Id: <5.1.1.2.2.20020815144927.0332aa90@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Thu, 15 Aug 2002 14:50:16 -0700 To: ietf-fax@imc.org From: Dave Crocker Subject: Re: Protocol Action: A Simple Mode of Facsimile Using Internet Mail to Draft Standard In-Reply-To: <200208151808.OAA07676@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 02:08 PM 8/15/2002 -0400, The IESG wrote: >The IESG has approved the Internet-Draft 'A Simple Mode of Facsimile >Using Internet Mail' as a Draft >Standard. This document obsoletes RFC2305. Congratulations to us all! Draft Standard status is an important milestone, indicating maturity of the protocol. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Fri Aug 16 08:21:52 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13019 for ; Fri, 16 Aug 2002 08:21:51 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7GC30C08755 for ietf-fax-bks; Fri, 16 Aug 2002 05:03:00 -0700 (PDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7GC2xw08750; Fri, 16 Aug 2002 05:02:59 -0700 (PDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7GC2rL02419; Fri, 16 Aug 2002 08:02:54 -0400 (EDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Aug 2002 07:02:53 -0500 Message-ID: <54E40201497DF142B06B27255953F79723F765@il0015exch007.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: receipt@cs.utk.edu, ietf-822@imc.org, vpim@lists.neystadt.org, IETF fax WG Subject: Message Disposition Notification: Second request for implementat ion status Date: Fri, 16 Aug 2002 07:02:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has requested a more detailed implementation report for the advancement of the message disposition notification protocol to Draft Standard. The current documentation of this protocol is , which is intended to replace proposed standard RFC 2298. The current version of the protocol and the submitted interoperability report is based on a call for implementation information solicited and compiled after the London IETF meeting last year. I appreciate the responses to the previous query for information on this protocol late last year. Unfortunately, the bar has been raised on implementation reports and I need more detailed information than was previously collected. If you can authoritatively respond on the capabilities of a contemporary implementation of this protocol, please reply to the questions below. I will compile the responses into documentation sufficient to advance this seemingly mature protocol to draft standard. Information is requested from three classes of systems based on their role in the protocol chain: MDN requesting UA's (including gateways), MDN Generating UA's (including gateways), MDN receiving UA's (Including gateways), and final-delivery MTA's. Thank you. All responses will be appreciated. Greg Vaudreuil P.S., My appologies for cross-posting this message to multiple lists. I want to ensure that we get a responses from the many communities that have made use of this protocol. ---------------------------- Please identify the following line-items in such a reply. 1) Name of software, vendor, and version upon which this response is based a) Approximately when was this feature introduced into a public release? 2) MDN Requesting user agent behaviors a) Client sends disposition-notification-to header: (Y/N) b) Client sends disposition-notifications-options header (Y/N) b1) Client sends request for proprietay options (describe) c) Message disposition header is placed in inner message when used with message partial (Y/N/NA) Please indicate N/A if the UA or gateway does not generate message partial constructs 3) Final MTA behaviors a) Final MTA (Delivery process) copies ORCPT parameter from RCPT-TO command into Original-Recipient header of message upon deposit 4) MDN Generating UA a) MDN report is generated upon request (Y/N). If yes, which fields are populated: Reporting-UA mdn-gateway-field original-recipient-field final-recipient-field original-message-id-field disposition-field failure-field error-field warning-field extension-field b) Which disposition modes are supported / generated: Manual action automatic action MDN-sent-manually MDN-sent-automatically c) Which disposition types are generated displayed deleted d) Are any extension fields generated? 5) MDN Receiving user agent behavior a) Which of the following fields are presented to the user or converted into a foreign format via gateway Reporting-UA mdn-gateway-field original-recipient-field final-recipient-field original-message-id-field disposition-field failure-field error-field warning-field extension-field 6) Interoperability Experience Please list those implementations that are known to interoperate with this implementation. Please describe what if any known interoperability problems are know with the MDN protocol and this implementation. From owner-ietf-fax@mail.imc.org Sun Aug 18 00:25:32 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09640 for ; Sun, 18 Aug 2002 00:25:31 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7I46X113550 for ietf-fax-bks; Sat, 17 Aug 2002 21:06:33 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7I46Vw13546 for ; Sat, 17 Aug 2002 21:06:31 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KLD2Y9PQA80001B1@mauve.mrochek.com> for ietf-fax@imc.org; Sat, 17 Aug 2002 21:06:34 -0700 (PDT) Date: Fri, 16 Aug 2002 11:35:24 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Message Disposition Notification: Second request for implementat ion status In-reply-to: "Your message dated Fri, 16 Aug 2002 07:02:53 -0500" <54E40201497DF142B06B27255953F79723F765@il0015exch007.ih.lucent.com> To: "Vaudreuil, Greg M (Greg)" Cc: receipt@cs.utk.edu, IETF fax WG Message-id: <01KLF2LKOYK60001B1@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Content-transfer-encoding: 7BIT References: <54E40201497DF142B06B27255953F79723F765@il0015exch007.ih.lucent.com> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > Please identify the following line-items in such a reply. > 1) Name of software, vendor, and version upon which this response is based > a) Approximately when was this feature introduced into a public release? SunOne Messaging Server, Sun Microsystems, upcoming release. (Much of this probably applies to earlier releases as well, but I tested things against the current code base for this report.) Integration of MDN support was done incrementally over a number of years so assigning even an approximate date is impossible. > 2) MDN Requesting user agent behaviors > a) Client sends disposition-notification-to header: (Y/N) Yes, the Messenger Express client component has the ability to do this. > b) Client sends disposition-notifications-options header (Y/N) > b1) Client sends request for proprietay options (describe) No, there is presently no way to request specific disposition options. > c) Message disposition header is placed in inner message when used with > message partial (Y/N/NA) Please indicate N/A if the UA or gateway does > not generate message partial constructs Yes, this this done when messages are fragmented. The opposite is also true: These fields are copied from the inner message to the new message while defragmenting. > 3) Final MTA behaviors > a) Final MTA (Delivery process) copies ORCPT parameter from RCPT-TO > command into Original-Recipient header of message upon deposit This is done as long as the number and nature of the recipients permit it. > 4) MDN Generating UA > a) MDN report is generated upon request (Y/N). If yes, which fields are populated: > Reporting-UA > mdn-gateway-field > original-recipient-field > final-recipient-field > original-message-id-field > disposition-field > failure-field > error-field > warning-field > extension-field Facilities for generating MDNs with all of these fields are built in to the product. However, at present the two primary uses are: (1) Displayed MDNs are generated by Messenger Express, which only produces final-recipient-field, original-message-id-field, and disposition-field. (2) Deleted MDNs are generated by the reject sieve action, which only produces original-recipient-field, final-recipient-field, original-message-id-field, and disposition-field. > b) Which disposition modes are supported / generated: > Manual action > automatic action > MDN-sent-manually > MDN-sent-automatically All of these can be generated and will be produced in practice. > c) Which disposition types are generated > displayed > deleted Both displayed and deleted types are generated. > d) Are any extension fields generated? Not at present. > 5) MDN Receiving user agent behavior > a) Which of the following fields are presented to the user or converted > into a foreign format via gateway > Reporting-UA > mdn-gateway-field > original-recipient-field > final-recipient-field > original-message-id-field > disposition-field > failure-field > error-field > warning-field > extension-field All of these fields can be displayed. > 6) Interoperability Experience > Please list those implementations that are known to interoperate with this > implementation. Please describe what if any known interoperability problems > are know with the MDN protocol and this implementation. AFAIK no interoperability problems have been reported. Ned From owner-ietf-fax@mail.imc.org Mon Aug 19 15:26:20 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13678 for ; Mon, 19 Aug 2002 15:26:20 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7JJ5Sk18006 for ietf-fax-bks; Mon, 19 Aug 2002 12:05:28 -0700 (PDT) Received: from ariel.eastgw.xerox.com (ariel.xerox.com [208.140.33.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7JJ5Qn18000 for ; Mon, 19 Aug 2002 12:05:27 -0700 (PDT) Received: from godzilla.ADOC.xerox.com (godzilla.ADOC.xerox.com [13.242.128.10]) by ariel.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id PAA20979; Mon, 19 Aug 2002 15:05:24 -0400 (EDT) Received: from mercury.adoc.xerox.com (mercury [13.242.100.20]) by godzilla.ADOC.xerox.com (8.8.8+Sun/8.8.8/ADOC-HUB-1.7) with ESMTP id MAA17963; Mon, 19 Aug 2002 12:05:24 -0700 (PDT) Received: by mercury.ADOC.xerox.com with Internet Mail Service (5.5.2654.89) id <3VYVVP8S>; Mon, 19 Aug 2002 12:05:23 -0700 Message-ID: <51B8ABCE456FD111899900805F6FD6EE0D912D17@mercury.ADOC.xerox.com> From: "McIntyre, Lloyd" To: "'The IESG'" Cc: RFC Editor , Internet Architecture Board , ietf-fax@imc.org Subject: RE: Protocol Action: A Simple Mode of Facsimile Using Internet Ma il to Draft Standard Date: Mon, 19 Aug 2002 12:04:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I am very confused by this announcement. How is it possible for this advancement to Draft Standard when there are two 2.2.3 stated dependent references, TIFF for Facsimile (a.k.a TIFF-FX) and image/TIFF sub-type, which have not been advanced to Draft Standard? Additionally, there is a third dependent reference (not listed in 2.2.3), image/TIFF-FX sub-type, which has not been advanced to Draft Standard. 2.2.3 Content The data format of the facsimile image is based on the minimum set of TIFF for Facsimile [5], also known as the S profile. Such facsimile data are included in a MIME object by use of the image/TIFF sub-type [12]. Lloyd > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: Thursday, August 15, 2002 11:09 AM > Cc: RFC Editor; Internet Architecture Board; ietf-fax@imc.org > Subject: Protocol Action: A Simple Mode of Facsimile Using > Internet Mail > to Draft Standard > > > > > > The IESG has approved the Internet-Draft 'A Simple Mode of Facsimile > Using Internet Mail' as a Draft > Standard. This document obsoletes RFC2305. > > This document is a product of the Internet Fax Working Group. The > IESG contact persons are Ned Freed and Patrik Faltstrom. > > Technical Summary > > This specification provides for "simple mode" carriage of > facsimile > data using Internet mail. Extensions to this document > will follow. > The current specification employs standard protocols and > file formats > such as TCP/IP, Internet mail protocols, MIME, and Tagged > Image File > Format (TIFF) for Facsimile. It can send images not only to other > Internet-aware facsimile devices but also to > Internet-native systems, > such as PCs with common email readers which can handle > MIME mail and > TIFF for Facsimile data. The specification facilitates > communication > among existing facsimile devices, Internet mail agents, and the > gateways which connect them. > > Working Group Summary > > This document is a revision of RFC 2305. There have been > no technical > changes from the previous version. > > Protocol Quality > > This specification was reviewed for the IESG by Ned Freed. > > RFC Editor note: > > The references > > Several references in this document need to be updated. In particular, > > [7] Allocchio, C., "Minimal PSTN address format for Internet > mail", draft-ietf-fax-faxaddr-v2-04.txt, June 2001. > > has been published as RFC 3191, > > [8] Allocchio, C., "Minimal fax address format for Internet > mail", draft-ietf-fax-minaddr-v2-04.txt, June 2001. > > has been published as RFC 3192, > > [9] Moore, K., and G. Vaudreuil, "An Extensible Message > Format for Delivery Status Notifications", RFC 1894, January > 1996. > > should refer to draft-vaudreuil-1894bis-01.txt, > > [18] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", > RFC 2487, January 1999. > > should refer to RFC 3207, and > > [19] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and > L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, > March 1998. > > should refer to RFC 2633. > > The acronym "TIFF" in the abstract needs to be expanded to > "Tagged Image File Format (TIFF)". > From owner-ietf-fax@mail.imc.org Thu Aug 22 06:22:13 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20610 for ; Thu, 22 Aug 2002 06:22:12 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7MA04R08411 for ietf-fax-bks; Thu, 22 Aug 2002 03:00:04 -0700 (PDT) Received: from mail.notes.ricoh.co.jp (mail.notes.ricoh.co.jp [202.211.49.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7MA02208397 for ; Thu, 22 Aug 2002 03:00:03 -0700 (PDT) Received: from delsol.isd.ricoh.co.jp (IDENT:mirapoint@[133.139.250.75]) by mail.notes.ricoh.co.jp (8.11.6/3.7W) id g7M9lER15032; Thu, 22 Aug 2002 18:47:14 +0900 Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by delsol.isd.ricoh.co.jp (Mirapoint) with ESMTP id ADW99158; Thu, 22 Aug 2002 18:47:13 +0900 (JST) Received: from localhost (tulip.toda.ricoh.co.jp [133.139.60.74]) by lily.toda.ricoh.co.jp (8.9.1/3.7Wlily sendmail.cf v8) with ESMTP id SAA11370; Thu, 22 Aug 2002 18:42:25 +0900 (JST) To: Lloyd.McIntyre@pahv.xerox.com Cc: iesg-secretary@ietf.org, rfc-editor@isi.edu, iab@isi.edu, ietf-fax@imc.org Subject: RE: Protocol Action: A Simple Mode of Facsimile Using Internet Ma il to Draft Standard From: Hiroshi Tamura In-Reply-To: <51B8ABCE456FD111899900805F6FD6EE0D912D17@mercury.ADOC.xerox.com> References: <51B8ABCE456FD111899900805F6FD6EE0D912D17@mercury.ADOC.xerox.com> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020822184713B.tamura@toda.ricoh.co.jp> Date: Thu, 22 Aug 2002 18:47:13 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 26 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lloyd, > How is it possible for this advancement to Draft Standard when there are two > 2.2.3 stated dependent references, TIFF for Facsimile (a.k.a TIFF-FX) and > image/TIFF sub-type, which have not been advanced to Draft Standard? > Additionally, there is a third dependent reference (not listed in 2.2.3), > image/TIFF-FX sub-type, which has not been advanced to Draft Standard. > > The IESG has approved the Internet-Draft 'A Simple Mode of Facsimile > > Using Internet Mail' as a Draft > > Standard. This document obsoletes RFC2305. As the above says, IESG has approved it. And, it goes into RFC-Editor queue. (http://www.rfc-editor.org/queue.html) We know there is a reference issue for Draft Standard. Until two TIFF documents move to new status, it remains in the queue. This is our understanding. Also, service-v2 mentions Profile S, therefore, it is not necessary to refer image/TIFF-FX sub-type. Regards, -- Hiroshi Tamura, Co-chair of IETF-FAX WG tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Tue Aug 27 19:58:40 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17730 for ; Tue, 27 Aug 2002 19:58:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7RNcK705478 for ietf-fax-bks; Tue, 27 Aug 2002 16:38:20 -0700 (PDT) Received: from [165.227.249.18] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7RNcH205470; Tue, 27 Aug 2002 16:38:17 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Tue, 27 Aug 2002 16:38:17 -0700 To: (many IETF mailing lists) From: Paul Hoffman / IMC Subject: Nomcom call for volunteers Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Forwarded for Phil Roberts : The members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee.