From owner-ietf-fax@mail.imc.org Mon Jul 1 10:08:11 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 KAA06863 for ; Mon, 1 Jul 2002 10:08:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g61DmqE19895 for ietf-fax-bks; Mon, 1 Jul 2002 06:48:52 -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 g61Dmow19882 for ; Mon, 1 Jul 2002 06:48:50 -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 JAA05248; Mon, 1 Jul 2002 09:47:54 -0400 (EDT) Message-Id: <200207011347.JAA05248@ietf.org> To: IETF-Announce: ; Cc: ietf-fax@imc.org From: The IESG SUBJECT: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 01 Jul 2002 09:47:54 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the Internet Fax Working Group to consider SMTP Service Extension for Content Negotiation as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by July 15, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-fax-esmtp-conneg-02.txt From owner-ietf-fax@mail.imc.org Mon Jul 1 17:50:28 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 RAA05912 for ; Mon, 1 Jul 2002 17:50:27 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g61LZBM16215 for ietf-fax-bks; Mon, 1 Jul 2002 14:35:11 -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 g61LZ9w16209 for ; Mon, 1 Jul 2002 14:35:09 -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 RAA04928; Mon, 1 Jul 2002 17:34:24 -0400 (EDT) Message-Id: <200207012134.RAA04928@ietf.org> To: IETF-Announce: ; Cc: ietf-fax@imc.org From: The IESG SUBJECT: CORRECTION: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 01 Jul 2002 17:34:24 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Please note the corrected four week last call date, due to the upcoming 54th IETF. Sorry for any confusion.] The IESG has received a request from the Internet Fax Working Group to consider SMTP Service Extension for Content Negotiation as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by July 29, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-fax-esmtp-conneg-02.txt From owner-ietf-fax@mail.imc.org Mon Jul 1 22:35:42 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 WAA14238 for ; Mon, 1 Jul 2002 22:35:42 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g622L9128310 for ietf-fax-bks; Mon, 1 Jul 2002 19:21:09 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g622L8w28306 for ; Mon, 1 Jul 2002 19:21:08 -0700 (PDT) Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g622L7pj002675 for ; Mon, 1 Jul 2002 19:21:07 -0700 (PDT) Received: from DWINGW2K4 (sjc-vpn2-329.cisco.com [10.21.113.73]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id AFI10434; Mon, 1 Jul 2002 19:22:58 -0700 (PDT) From: "Dan Wing" To: "IETF Internet Fax WG" Subject: FW: CORRECTION: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Date: Mon, 1 Jul 2002 19:21:05 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com] Sent: Monday, July 01, 2002 7:20 PM To: ktoyoda@rdmg.mgcs.mei.co.jp; Dave Crocker; iesg@ietf.org Subject: FW: CORRECTION: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Several issues. Please explain why you require a space in the RCPT modifier; that is, why is the ABNF: "CONNEG =" instead of "CONNEG" "=" or simply "CONNEG=" In section 5, your the word "OPTIONAL" is mispelled. In section 5, is the only valid destination address supposed to be "Postmaster"? The example in section 6 contradicts that. The text throughout the document uses "CONNEG = REQUIRED" and "CONNEG = OPTIONAL" but section 5 says there isn't a space after "=". The text says: The response strings for a temporary failure are "404-4.3.3 CONNEG" and "404 5.3.3 CONNEG". which looks like a cut-and-paste error (4.3.3 -> 5.3.3). In section 5, your failure example is: C: RCPT TO: CONNEG = REQUIRED S: 504 recipient ok I believe the text "recipient ok" is inappropriate here. Perhaps more appropriate would be "recipient okay, but CONNEG unavailable". Further, your ABNF in section 5 does not permit any text after the "504" -- it only permits . I'm guessing section 5 is supposed to be ABNF, but as Dave is the author of ABNF and section 5 doesn't claim to be ABNF, I can't tell what it's supposed to be. Can the document make this clearer? Section 5 seems to prohibit multiline 504 and multiline 404 responses, but such multiline responses are permitted by the underlying RFC2822 specification. Is your specification purposely prohibiting multiline 504 and 404 responses by CONNEG- capable SMTP servers that receive CONNEG=REQUIRED or CONNEG=OPTIONAL ? Section 5 doesn't define the meaning of . I am very unclear on the difference between a client specifying CONNEG=OPTIONAL versus a client specifying no CONNEG parameter at all. You should cite the ENCHANCEDSTATUSCODES RFC. How is this supposed to work with relaying? This needs to be discussed. Is a mail submission agent supposed to open TCP connections to the MX host for the recipient to hope to learn the information, or is it via some other means, or is this not expected to yet work for relaying? Section 6, the examples, do not clearly show that the server isn't sending CRLF between the lines. Lines that are separated by CRLF such as S: 250-ifax1.jp S: 250-DSN S: 250 CONNEG are shown exactly like lines that aren't separated by CRLF such as 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) ) While this is described in the text of the document, the example isn't nearly clear enough. Please add text indicating that the example is broken into multiple lines for clarity in the document, but that the Server transmits only two CRLF lines for the above example: one CRLF at the first line and another CRLF at the last line and no CRLFs are sent in between. This is a serious interoperabilty issue. The ABNF (or whatever is in section 5) isn't clear on this either. The unique way you have separated the Client and Server lines (using blank lines) doesn't help show that CRLF isn't sent on each line (which I'm guessing was the intent of this extra blank line, but the extra blank line was never explained in the document). My specific recommendation is that you change the example to: 6. EXAMPLE An example of ESMTP sequence with successful RCPT-TO response 1 S: 220 ifax1.jp IFAX 2 C: EHLO ifax1.jp 3 S: 250-ifax1.jp 4 S: 250-DSN 5 S: 250 CONNEG 6 C: MAIL FROM: 7 S: 250 sender ok 8 C: RCPT TO: CONNEG = REQUIRED 9 S: 250- recipient ok 10 S: 250 CONNEG (&(image-file-structure=TIFF-minimal) 11 S: (MRC-mode=0)(color=Binary)(|(&(dpi=204) 12 S: (dpi-xyratio=[204/98,204/196]) )(&(dpi=200) 13 S: (dpi-xyratio=[200/100,1]) )(&(dpi=400) 14 S: (dpi-xyratio=1) ) )(|(image-coding=[MH,MR,MMR]) 15 S: (&(image-coding=JBIG)(image-coding-constraint=JBIG-T85) 16 S: (JBIG-stripe-size=128) ) )(paper-size=[letter,A4,B4]) 17 S: (ua-media=stationery) ) 18 C: DATA 19 S: 354 okay, send data 20 C: <> 21 S: 250 message accepted 22 C: QUIT 23 S: 221 goodbye Note that line 9 is terminated with CRLF, but lines 10 through 16 are not terminated by CRLF -- they are only shown wrapped in this document for clarity. The next line that has a CRLF is line 17. Or, if you prefer, add this text above that specific line (which eliminates the need to number them). <> -d -----Original Message----- From: owner-ietf-fax@mail.imc.org [mailto:owner-ietf-fax@mail.imc.org]On Behalf Of The IESG Sent: Monday, July 01, 2002 2:34 PM To: IETF-Announce: Cc: ietf-fax@imc.org Subject: CORRECTION: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard [Please note the corrected four week last call date, due to the upcoming 54th IETF. Sorry for any confusion.] The IESG has received a request from the Internet Fax Working Group to consider SMTP Service Extension for Content Negotiation as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by July 29, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-fax-esmtp-conneg-02.txt From owner-ietf-fax@mail.imc.org Tue Jul 2 02:07:25 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 CAA26451 for ; Tue, 2 Jul 2002 02:07:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g625rLV04233 for ietf-fax-bks; Mon, 1 Jul 2002 22:53:21 -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 g625r9w04215; Mon, 1 Jul 2002 22:53:09 -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 g625rC228738; Tue, 2 Jul 2002 01:53:12 -0400 (EDT) Message-Id: <200207020553.g625rC228738@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: iesg@ietf.org cc: ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Mon, 01 Jul 2002 17:34:24 EDT.") <200207012134.RAA04928@ietf.org> Date: Tue, 02 Jul 2002 01:53:12 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [referencing draft-ietf-fax-esmtp-conneg-02.txt] executive summary: I recommend against approval of this document withut extensive changes. It's not well thought-out (except for the rather narrow application of SMTP to a one-recipient fax gateway) and it seems likely to degrade SMTP interoperabliity if widely adopted. I do suggest some changes which would make it less harmful, but it still needs considerable work to be of general applicability. 1. layering problems this functionality is a poor fit for SMTP because SMTP is the mail *transport* protocol, and as such should not be dealing with content at all, which is a user agent function. I admit that (by design) there is no opportunity for e2e interaction at the user agent level in the current protocols, and also that any mechanism that might be used to advertise user agent capabliities (e.g. rescap) introduces the opportunity for that mechanism to get out-of-sync with the actual capabilities/preferences of the recipient. but what's to stop this mechanism from getting out-of-sync also? it seems like this extension has very limited applicability - it will only work reliably when the SMTP server and user agent or gateway are very closely tied and when the recipient always uses the same UA or UAs of very similar capabilities. (certainly not true of me!) one can argue that extending SMTP to allow it to perform negotiation on behalf of the user agent is no worse than putting that negotiation in a separate protocol. but if we're going to extend SMTP to perform functions on behalf of the user agent, it needs to be made very explicit that this negotiation is being done on behalf of the user agent - and in particular that the negotiation being requested represents the preferences of the *user* (i.e. the sender and/or recipient) rather than some third party. IIRC, this is the same thing that was insisted on for the OPES stuff - the negotiation/transformation needs to have explicit consent from, and be under control of, at least one of the ultimate endpoints (sender or receiver) and it seems to me that it's appropriate to apply the same policy for email. 2. protocol design problem for transformations that should be under control of specific recipients, the protocol is poorly designed. in particular there seems to be no ability to apply content-transformation on a per-recipient basis, to handle the case where different transformations are acceptable to differnet recipients. again, this drastically limits the applicability of the protocol (it won't work well unless all recipients at that SMTP server have the same capability set, which is very unlikely for most conventional SMTP servers) of course it's not easy to get SMTP to handle different client-side transformations for different recipients, since SMTP is designed to transfer the exact same message body (modulo received fields) to each of a set of recipients. this is a different model than used by phone-based facsimile protocols which expect there to be only one recipient of any given transmission, so it's not surprising that the fax-style negotiation doesn't fit well into SMTP. in order to make client-side negotiation a clean fit into SMTP, it is necessary for the client to first query the server for the capabilities of each intended recipient, then to deduce how many total transformations are necessary, then to send one or more transformed versions of the message. for instance, if recipients A, B, E, and F could accept one transformation of the message and recipients B, C, and D could could accept a higher quality transformation of the message, the client might attempt to send the high-quality version to B, C, and D and then send the lower quality version to A, E, and F. but as currently designed the proposed extension doesn't have the necessary protocol hooks to permit this - at least not without a considerable amount of ugliness. overloading the RCPT command to return capabilities breaks the RCPT command and forces the client to do RSET in order to send different versions to different recipients. 3. timing this proposal could not have come at a worse time. putting content negotiation in the transport protocol is likely to result in a significant increase in anomolous behaviors from the mail system which are difficult to diagnose and fix - and the proposal is being introduced at a time when the mail system is already suffering from serious reliabliity problems (often due to ill-conceived measures for blocking spam). at this time, *any* proposal for adding new functionality to SMTP should be viewed with strong reservations, unless it somehow offers an improvement in reliability. a proposal that significantly increases the complexity of SMTP error handling seems unlikely to do that. 4. naming and applicability the protocol claims to be a general-purpose content-negotiation scheme but actually has "fax" assumptions embedded very deeply. first of all, it assumes that there is a linear ordering relationship for document suitability to the recipient. while this might be arguable for facsimile images (even this is debatable given orthogonal attributes like resolution and color), it's certainly not the case for MIME email in general. 5. recommendations a. I strongly recommend that you redesign this extension so that, instead of overloading the RCPT command, you define a separate command to request a recipient's capabilities. e.g. RCAP would return the conneg capability associated with that recipient, if available. there would need to be separate indications for permanent error (perhaps if the recipient addr were invalid), temporary error (e.g. can't do the database lookup), no capabliities available (perhaps not an error, just no information), and a return of capabilities. one nice side-benefit is that it doesn't change the error handling model, because the proposal mentioned above doesn't affect the actual message handling commands at all. (however it does add a few round trip delays) b. the idea that the sender should send the "best" or "highest quality" version needs to be relaxed or generalized, since there's currently no clear notion of what this means. (and thus no way to know whether an implementation conforms to these criteria). c. this extension needs to be made less fax-specific. it needs to be examined with some realistic non-fax-specific test cases, and it needs non-fax conneg examples also. d. there needs to be a good way for the recipient to specify capabilities to the SMTP server, at least for any SMTP server that can serve arbitrary UA recipients. probably this means another extension along with SMTP AUTH. still, this is a big can of worms, because there's never been any ability of a UA to specify something to its inbound SMTP servers before - there's presently not even a good way for a UA to know which server(s?) should be given this information... e. make it absolutely clear that such transformations are only to be made with explicit authorization by the sender and/or recipient. (a dedicated smtp-to-printer hardware device would be considered to have explicit authorization simply because it was purchased for such a purpose, but a SMTP server acting on behalf of a user using a general-purpose MUA would need such authorization) f. the document needs to consider the effect of message forwarding on the returned string - if a recipient has his mail forwarded elsewhere it's not clear what conneg string should be returned. g. the document alludes to the ability to work through intermediaries but this isn't explained anywhere, and it needs to be explained. 6. specific problems > 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-TO. > > If the client issues the CONNEG parameter with > RCPT-TO, then it MUST honor the capabilities specified > in the CONNEG RCPT-TO reply, and transform data that is > sent, so that the target can accept the data. The > client SHOULD transform the data to the "highest" level > of capability of the target. this incorrectly assumes that (a) there is only one target when the client can easily specify multiple RCPT commands, and (b) there is a clear notion of "highest level of capability" for the target. also why is the term "target" used rather than the more traditional "recipient" or "mailbox"? > If the server rejects the RCPT-TO command with a 404 reply, the > client may later reissue the RCPT-TO with the CONNEG parameter. presumably in the context of a different SMTP session? it's not clear... > 4.3 Server Action: > > If the client specifies "CONNEG = REQUIRED" in the RCPT-TO, > but the target does not support the CONNEG parameter, the target > MUST reject the RCPT-TO command with a 504 reply. here there is a potential conflict between various extensions. a RCPT command may fail for any number of reasons. if any of those reasons is a permanent fatal error it should be sufficient for the server to report any one of those errors. it's not reasonable for this extension to pre-empt other error notificaitons. (it may be that other extensions have similar wording, in which case they're similarly flawed) > If the target support the CONNEG parameter, but it can not return > the recepient's capability temporarily, the target MUST reject the > RCPT-TO command with a 404 reply. For example, if the target get > the capability information from a directory, but its connection is > offline, the target MUST reject the RCPT-TO command with a 404 > reply. similarly: if any permanent failure is detected in the RCPT command, the appropriate 5xx response SHOULD probably be returned in preference to any 4xx response. for instance if the recipient's mailbox has been administratively disabled then a 5xx response should be returned rather than a 404 response which would mean "ask me later what kind of media types this recipient can accept"... whereupon the client would do so only to (eventually) find out that it couldn't deliver the message to the recipient anyway. > If the client specifies "CONNEG = OPTIONAL" in the RCPT-TO, the > target MUST process the address and message as if the requested > CONNEG capabilities had not been specified. this doesn't seem to make sense as written. is "CONNEG = OPTIONAL" really supposed to be interpreted the same as omission of the CONNEG parameter? also, I don't think there should be spaces around the = sign - I don't think this is legal syntax for SMTP extensions. > Regardless of the value of the parameter, if the target does > support the CONNEG parameter, then it MUST issue a 250 reply, again, there could be other reasons for permanent or temporary failure of the RCPT command, and the assertion of a CONNEG parameter should not pre-empt the reporting of such failures. > followed by the capabilities of the target that is specified by > the RCPT-TO address. Successful responses to CONNEG RCPT-TO > requests will always be multiple SMTP lines. The first line > is the normal RCPT-TO 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". I wonder here - assuming that this can of worms does not get closed back up, and there might later be demand for other mechanisms to request recipient capabilities (e.g. since this one is not very general), might there be multiple kinds of strings emitted in the RCPT response? e.g. CONNEG and CONNEG2 and FINAL_SOLUTION_CONNEG? and if so should this document insist that CONNEG be last? > If the SMTP server supports ENHANCEDSTATUSCODES, the response > strings for a success are "250-2.1.5 CONNEG" and "250 2.1.5 > CONNEG". 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". are these codes already defined in 1893? (I didn't look) I don't think it's appropriate to dictate extended status codes since their entire purpose is to provide more precision than the SMTP reply codes. there are various sources of permanent failure and various sources of temporary failure and the set of status codes is extensible independently of SMTP reply codes. > 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. CONNEG *what* lines? command lines? response lines? both? > The contents of the capability listing MUST conform to > [RFC2506], [RFC2533] and [RFC2534], and MAY be used to emulate > services, such as the facsimile start-of-session capabilities > negotiation as described in "Content Feature Schema for > Internet Fax". [RFC2879] > > > > > 5. SYNTAX > > Command with "CONNEG": > "RCPT TO:" ("" / "" > / Forward-Path) (SP "CONNEG =" ("REQUIRED" / > "OPTIOANL") CRLF the space doesn't belong after CONNEG, and OPTIONAL is misspelled. > > 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) / it's not appropriate to put literal response codes in the grammar, particularly the extended status codes which might actually need to vary more than is indicated here. much better to have something like: reply: initial-reply *(conneg-reply/other-reply) final-reply initial-reply: reply-code "-" [ status-code ] CRLF conneg-reply: reply-code "-" [ status-code " " ] "CONNEG" capability CRLF other-reply: reply-code "-" [ status-code ] *char CRLF final-reply: reply-code " " [ status-code ] CRLF > > capability = < and [RFC2879] >> > > > > 6. EXAMPLE > > An example of ESMTP sequence with successful RCPT-TO 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 > > 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) ) this needs clarification - it looks like the sender is sending multiple lines without a 250 or CONNEG on each line. it would probably be better to break up this example into several SMTP lines and also to explain that any of those lines can be longer (up to XXX bytes) than shown in the example. > > C: DATA > > S: 354 okay, send data > > C: < Per: > ( image-file-structure=TIFF-minimal > dpi=400 > image-coding=JBIG > size-x=2150 > ) > >> this is confusing - it makes it appear that TIFF-FX is the only content-type acceptable. also TIFF-FX is not the name of the content-type, presumably it's application/tiff-fx or some such. > > S: 250 message accepted > > C: QUIT > > S: 221 goodbye > > > An example of successful RCPT-TO 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) > > > An example of succssful RCPT-TO 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) ) again, this response is confusing because it's line wrapped > > > An example of ESMTP sequence with parmanent failure RCPT-TO > 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 > > S: 504 recipient ok > > C: QUIT > > S: 221 goodbye > > > > An example of an ESMTP sequence with temporary failure RCPT-TO > 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 > > S: 404 recipient ok > > C: QUIT > > S: 221 goodbye > . > . > . > retry according to implementation > > > > An example of an ESMTP sequence with temporary failure RCPT-TO > 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 > > S: 250 recipient ok > > C: DATA > > S: 354 okay, send data > > C: < Per "A Simple Mode of Facsimile Using Internet Mail" > RFC2305 > >> > > 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. seems like you should at least mention SMTP AUTH. > 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. the STARTTLS command could be useful in providing integrity assurance. > 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. From owner-ietf-fax@mail.imc.org Tue Jul 2 03:38:44 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 DAA27631 for ; Tue, 2 Jul 2002 03:38:43 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g627O5c13160 for ietf-fax-bks; Tue, 2 Jul 2002 00:24:05 -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 g627Ntw13138; Tue, 2 Jul 2002 00:23:55 -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 AAA18067; Tue, 2 Jul 2002 00:29:36 -0700 Message-Id: <5.1.1.2.2.20020701232506.0336f140@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Tue, 02 Jul 2002 00:23:43 -0700 To: Keith Moore From: Dave Crocker Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Cc: iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org In-Reply-To: <200207020553.g625rC228738@astro.cs.utk.edu> References: <(Your message of "Mon, 01 Jul 2002 17:34:24 EDT.") <200207012134.RAA04928@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 01:53 AM 7/2/2002 -0400, Keith Moore wrote: >executive summary: I recommend against approval of this document >withut extensive changes. It's not well thought-out What additional thinking out are you looking for? > (except for the rather narrow application of SMTP to a one-recipient fax > gateway) In fact the motivation for it is not necessarily a gateway, but rather any recipient environment that conforms to this profile, including usage that is wholly retained among Internet-capable participants. For that matter, the mechanism applies on a per-recipient basis, so what prompts the claim that it works only for a single recipient? >and it seems likely to degrade SMTP interoperabliity if widely adopted. How will that happen? How is it likely? >1. layering problems > >this functionality is a poor fit for SMTP because SMTP is the >mail *transport* protocol, and as such should not be dealing >with content at all, which is a user agent function. The construct of using SMTP to verify support of a higher level feature is not all that different from DSN. What is the practical problem with applying it here? >but what's to stop this mechanism from getting out-of-sync also? The end-to-end asynchrony and latency for this mechanism certainly do provide an opportunity for a recipient's capabilities to change, after it has advertised a particular set. However the key point to note is that there is no mediating storage/directory service, so the advertisement has a degree of directness not possible through any other mechanism. For recipients concerned about such volatility, all they have to do is refrain from advertising CONNEG support. For senders concerned about such volatility, they should use CONNEG=Required. >it seems like this extension has very limited applicability - it will >only work reliably when the SMTP server and user agent or gateway are >very closely tied and when the recipient always uses the same UA >or UAs of very similar capabilities. (certainly not true of me!) 1. The specification already highlights that it is tailored for rather 'direct' scenarios. 2. Each user can decide what to advertise. If they vary their UA they can choose to advertise a safe and lesser set of capabilities. In any event, it is their choice. The mechanism does not impose any problems that are not inherent in use of multiple UAs. However it DOES permit relatively direct advertising of capabilities, which is currently not feasible. >but if we're going to extend SMTP to perform functions >on behalf of the user agent, it needs to be made very explicit that this >negotiation is being done on behalf of the user agent - and in particular >that the negotiation being requested represents the preferences of the >*user* In what way does that affect the technical specification? That is, how is the current specification deficient, with respect to your concern? >in particular there seems to be no >ability to apply content-transformation on a per-recipient basis, >to handle the case where different transformations are acceptable to >differnet recipients. We must be reading different specifications. Choice of enforcement of this option is per-recipient. Each recipient may generate a capabilities response if they wish a different form of the content. What, exactly, are you looking for that is missing? >of course it's not easy to get SMTP to handle different client-side >transformations for different recipients, since SMTP is designed to >transfer the exact same message body (modulo received fields) to each >of a set of recipients. It sounds as if you are assuming that later transmission of content that is revised according to capabilities information is required (or expected) to be sent using that same address list. That is like requiring that all BCC copies are sent along with the TO and CC copies. In other words, there is not such requirement. It is OK to do it and it is OK not to. Yes, the current CONNECT option is intended to send the same content to all recipients, since that is the style of SMTP. There is nothing preventing later sending an alternative content form to selected recipients. Interestingly, this would not actually create any additional round-trips or additional content transfers. > this is a different model than used by >phone-based facsimile protocols which expect there to be only one >recipient of any given transmission, You might want to take a look at fax broadcasting services. The last-hop telephone portion behaves as you describe, but only after a 'generic' posting process. > so it's not surprising that the fax-style negotiation doesn't fit well > into SMTP. Actually, the proposed scheme permits content transmission tailoring that is considerably more flexible than is typical in the real fax world. >in order to make client-side negotiation a clean fit into SMTP, it is >necessary for the client to first query the server for the capabilities >of each intended recipient, then to deduce how many total transformations >are necessary, then to send one or more transformed versions of the message. Ahh. I see. You want to insist on an interaction scenario that is known to be unacceptable, since it is guaranteed to introduce too much delay before there is any utility at all. > overloading the RCPT >command to return capabilities breaks the RCPT command and forces >the client to do RSET in order to send different versions to >different recipients. If that is what the client chooses to do, then yes. However there are other courses of action available. At the least, note that the content is not sent until the client has CONNEG responses about all of the recipients. >putting content negotiation in the transport protocol is likely >to result in a significant increase in anomolous behaviors >from the mail system which are difficult to diagnose and fix - >and the proposal is being introduced at a time when the mail system >is already suffering from serious reliabliity problems (often due >to ill-conceived measures for blocking spam). How does use of the CONNEG mechanism affect reliability or accountability? > at this time, >*any* proposal for adding new functionality to SMTP should be viewed >with strong reservations, unless it somehow offers an improvement >in reliability. I was not aware that we had any problems being attributed to SMTP options. Please provide some citations, so we can compare their details to the current proposal. >4. naming and applicability > >the protocol claims to be a general-purpose content-negotiation scheme >but actually has "fax" assumptions embedded very deeply. The fax world is the basis for the idea, yes. However the specification has been done so as to be independent of fax, thereby using an approximate model that is known to be useful from the fax world and then applying it for general enhancement of email. >first of all, it assumes that there is a linear ordering relationship >for document suitability to the recipient. Ok. I give up. I have no idea what "linear ordering relationship for document suitability" means. >a. I strongly recommend that you redesign this extension so that, instead >of overloading the RCPT command, you define a separate command to >request a recipient's capabilities. e.g. In spite of the proffered benefits of a separate command, I fail to see how it produces any real benefits. It certainly does not make anything simpler, and it certainly vastly increases relay delay, due to nearly doubling the round-trip exchanges during an SMTP session that uses the option. >one nice side-benefit is that it doesn't change the error handling >model, How does the current proposal change the error handling "model"? >b. the idea that the sender should send the "best" or "highest >quality" version needs to be relaxed or generalized, It already has been relaxed. Note the SHOULD rather than MUST. > since there's currently no clear notion of what this means. Yet we have lived with that notion in multipart/alternative for some years. >c. this extension needs to be made less fax-specific. What, specifically, makes it fax specific, and what changes are you specifically seeking that will be less fax-specific? >it needs to be examined with some realistic non-fax-specific >test cases, and it needs non-fax conneg examples also. Test cases are always a good thing. Feel free to offer some that satisfy your non-faxiness goal. >d. there needs to be a good way for the recipient to specify >capabilities to the SMTP server, at least for any SMTP server >that can serve arbitrary UA recipients. probably this means another >extension along with SMTP AUTH. You want to require that that mechanism be in place before the current specification can be advanced? I think the phrase "chicken and egg" works here. You create a deadly embrace for reaching any utility. >still, this is a big can of worms, because there's never been >any ability of a UA to specify something to its inbound SMTP >servers before - there's presently not even a good way for >a UA to know which server(s?) should be given this information... Think hard. What is likely to drive creation of such a mechanism? Requiring that it be built in the abstract or looking for it to be built in reaction to actual demand? >e. make it absolutely clear that such transformations are only to be >made with explicit authorization by the sender and/or recipient. This sort of parental direction in IETF specifications probably does no harm, but it is difficult to imagine that it does much benefit. >f. the document needs to consider the effect of message forwarding >on the returned string - if a recipient has his mail forwarded >elsewhere it's not clear what conneg string should be returned. There are all sorts of implications in forwarding. In general, forwarding that is not simply SMTP relaying is outside of current IETF specification. Imposing a requirement about it here, without demonstrating actual problems, is a tad extreme. >g. the document alludes to the ability to work through intermediaries >but this isn't explained anywhere, and it needs to be explained. All it says is that it works with SMTP relaying, just as one would expect and SMTP extension tow work. > > 4.2 Client Action: >... >this incorrectly assumes that (a) there is only one target when >the client can easily specify multiple RCPT commands, and >(b) there is a clear notion of "highest level of capability" >for the target. It does not make the assumption you suggest. In fact, I can't imagine how you came to the assessment that it makes that assumption. > > 4.3 Server Action: > > > > If the client specifies "CONNEG = REQUIRED" in the RCPT-TO, > > but the target does not support the CONNEG parameter, the target > > MUST reject the RCPT-TO command with a 504 reply. >... >(it may be that other extensions have similar wording, in which case >they're similarly flawed) It is probably a good idea that we not try to fix SMTP (yet again, given the protracted drums effort.) And it certainly is not a good idea to require that the current specification fix something this vague when no SMTP-related specification is required to. > > If the client specifies "CONNEG = OPTIONAL" in the RCPT-TO, the > > target MUST process the address and message as if the requested > > CONNEG capabilities had not been specified. > >this doesn't seem to make sense as written. is "CONNEG = OPTIONAL" >really supposed to be interpreted the same as omission of the >CONNEG parameter? I think that the text that is in the first paragraph of that section ("but the target does not support the CONNEG parameter") got deleted during revision. In general, those first 3 paragraphs are dealing with lack of support, whereas the following paragraphs are dealing with presence of support. >also, I don't think there should be spaces around the = sign - ack. >I wonder here - assuming that this can of worms does not get closed >back up, and there might later be demand for other mechanisms >to request recipient capabilities (e.g. since this one is not very general), >might there be multiple kinds of strings emitted in the RCPT response? Please indicate what capabilities are missing from this capabilities mechanism that would make it more general and for which there is a demonstrated need. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Tue Jul 2 06:44:12 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 GAA02423 for ; Tue, 2 Jul 2002 06:44:12 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g62AUUC27837 for ietf-fax-bks; Tue, 2 Jul 2002 03:30:30 -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 g62AUSw27823 for ; Tue, 2 Jul 2002 03:30:28 -0700 (PDT) Received: from azteca.isd.ricoh.co.jp (IDENT:mirapoint@[133.139.250.74]) by mail.notes.ricoh.co.jp (8.11.6/3.7W) id g62AUQF27909; Tue, 2 Jul 2002 19:30:26 +0900 Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by azteca.isd.ricoh.co.jp (Mirapoint) with ESMTP id ACZ49113; Tue, 2 Jul 2002 19:30:25 +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 TAA00376; Tue, 2 Jul 2002 19:26:09 +0900 (JST) To: ietf-fax@imc.org cc: ned.freed@mrochek.com, claudio.allocchio@garr.it, vpim@lists.neystadt.org, um@snowshore.com Subject: IETF-FAX WG Draft agenda at Yokohama 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: <20020702192404Q.tamura@toda.ricoh.co.jp> Date: Tue, 02 Jul 2002 19:24:04 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 67 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, Here is the draft agenda for FAX WG at Yokohama. If you have comments, please say by Jul 5. [[[]]] is comment. -- Hiroshi Tamura, Co-chair of IETF-FAX WG tamura@toda.ricoh.co.jp --------------------------------------------------------------------- 1 Agenda Bashing (2 min) 2 The I-Ds which IESG approved and are in RFC editor's queue (1 min) - draft-ietf-fax-implementers-guide-08.txt Reference issue of tiff-fx-reg I-D - draft-ietf-fax-content-negotiation-05.txt - draft-ietf-fax-tiff-regbis-05.txt Urgent Action is necessary for TIFF-FX for Draft Standard. 3 The I-Ds for which IETF Last Call was finished (2 min) - draft-ietf-fax-tiff-fx-reg-01.txt Urgent Action is necessary for TIFF-FX for Draft Standard. - draft-ietf-fax-gateway-protocol-08.txt - draft-ietf-fax-gateway-options-05.txt - draft-ietf-fax-service-v2-05.txt Reference issue of DSN (RFC1894) and TIFF-FX (draft-ietf-fax-tiff-fx-11.txt) 4 The I-D which IESG is reviewing (Before IETF Last Call) (1 min) - draft-ietf-fax-timely-delivery-05.txt Reference issue of draft-vaudreuil-1983ext-01.txt 5 TIFF-FX implementation report (10 min) The original report and the additional (new) report to be submitted. [[[The new report is not submitted here. I introduce the on-going status.]]] 6 SMTP Service Extension for Content Negotiation (25 min) - draft-ietf-fax-esmtp-conneg-02.txt [[[There seems to be lots of discussions.]]] 7 FFPIM (5 min) - draft-ietf-fax-ffpim-01.txt 8 Addressing (5 min) - draft-allocchio-gstn-03.txt 9 FAX in ENUM (5 min) [[[Toyoda-san is preparing for something.]]] [[[Can we add in our milestone?]]] 10 ITU issue (2 min) - Plan for October ITU SG16 meeting Implementers-Guide TIFF-FX issue 11 Confirmation of milestone (2 min) - TIFF-FX for Draft Standard Urgent action need that tiff-fx reg I-D should be Proposed Standard Implementation report - FFPIM - ESMTP CONNEG - Addressing - FAX in ENUM ??? From owner-ietf-fax@mail.imc.org Tue Jul 2 06:44:16 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 GAA02436 for ; Tue, 2 Jul 2002 06:44:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g62AUld27861 for ietf-fax-bks; Tue, 2 Jul 2002 03:30:47 -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 g62AUjw27857 for ; Tue, 2 Jul 2002 03:30:45 -0700 (PDT) Received: from azteca.isd.ricoh.co.jp (IDENT:mirapoint@[133.139.250.74]) by mail.notes.ricoh.co.jp (8.11.6/3.7W) id g62AUQF27905; Tue, 2 Jul 2002 19:30:26 +0900 Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by azteca.isd.ricoh.co.jp (Mirapoint) with ESMTP id ACZ49112; Tue, 2 Jul 2002 19:30:25 +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 TAA00373; Tue, 2 Jul 2002 19:26:08 +0900 (JST) To: gparsons@nortelnetworks.com Cc: vpim@lists.neystadt.org, ietf-fax@imc.org, um@snowshore.com Subject: Re: Draft Agenda for VPIM From: Hiroshi Tamura In-Reply-To: <20020627075755F.tamura@toda.ricoh.co.jp> References: <20020627075755F.tamura@toda.ricoh.co.jp> 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: <20020702181542E.tamura@toda.ricoh.co.jp> Date: Tue, 02 Jul 2002 18:15:42 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 34 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Glenn, > > TUESDAY, July 16, 2002 > > 0900-1130 Morning Sessions > > APP fax&vpim Internet Fax WG & Voice Profile for Internet Mail WG > > > > Anyway, on the meeting agenda, I would propose FAX goes first and that VPIM > > progresses in a similar order of events as we have done previously: > > Your proposal for FAX WG going first is ok for me. I live in Yokohama! > But, some FAX WG members do not stay at hotels and go there > directly from their home. > > Dear Japanese FAX WG members: > If you take the first train in the morning and cannot go there, > please let us know very soon. I received the comments from them personally. They told me they are OK. Let's start FAX WG first. > Regarding FAX WG agenda, I will let you know the next Tuesday, maybe. > The issues are mainly confirmation of status of I-Ds that FAX WG finished, > TIFF-FX, ESMTP CONNEG, Claudio's I-D, FAX in ENUM and ITU. > Please wait. I mail in another thread sooner or later. Regards, -- Hiroshi Tamura, Co-chair of IETF-FAX WG E-mail: tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Tue Jul 2 10:51:42 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 KAA14880 for ; Tue, 2 Jul 2002 10:51:41 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g62EY1g17508 for ietf-fax-bks; Tue, 2 Jul 2002 07:34:01 -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 g62EXaw17468; Tue, 2 Jul 2002 07:33:36 -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 g62EXW202165; Tue, 2 Jul 2002 10:33:33 -0400 (EDT) Message-Id: <200207021433.g62EXW202165@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: Keith Moore , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Tue, 02 Jul 2002 00:23:43 PDT.") <5.1.1.2.2.20020701232506.0336f140@jay.songbird.com> Date: Tue, 02 Jul 2002 10:33:32 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > At 01:53 AM 7/2/2002 -0400, Keith Moore wrote: > >executive summary: I recommend against approval of this document > >withut extensive changes. It's not well thought-out > > What additional thinking out are you looking for? see below. > > (except for the rather narrow application of SMTP to a one-recipient fax > > gateway) > > In fact the motivation for it is not necessarily a gateway, but rather any > recipient environment that conforms to this profile, including usage that > is wholly retained among Internet-capable participants. > > For that matter, the mechanism applies on a per-recipient basis, so what > prompts the claim that it works only for a single recipient? if different recipients have different capabilities, the sender has to either send a single message with a format that is suitable for all recipients, or it has to do a RSET and resend the RCPT commands separately for each version of the message that it sends. nowhere in the document do I see any mention of this, and furthermore it complicates error handling. so I assume that it wasn't adequately considered. > >and it seems likely to degrade SMTP interoperabliity if widely adopted. > > How will that happen? How is it likely? because the proposal complicates the SMTP state machine (especially when you consider the multiple recipient case), it adds additional failure modes, and the error handling is not well described. > >1. layering problems > > > >this functionality is a poor fit for SMTP because SMTP is the > >mail *transport* protocol, and as such should not be dealing > >with content at all, which is a user agent function. > > The construct of using SMTP to verify support of a higher level feature is > not all that different from DSN. now that's a bizarre statement. DSN is a per-mta feature. it is either supported or not supported by an MTA. it doesn't modify content. DSN doesn't reveal anything about a recipient's user agent. > >but what's to stop this mechanism from getting out-of-sync also? > > The end-to-end asynchrony and latency for this mechanism certainly do > provide an opportunity for a recipient's capabilities to change, after it > has advertised a particular set. However the key point to note is that > there is no mediating storage/directory service, so the advertisement has a > degree of directness not possible through any other mechanism. Dave, the document itself recognizes the possibility of a directory service, even listing a specific error code for this case, so your statement is facially false. Furthermore it must be recognized that the vast majority of MTAs do not interact directly with user agents at all, so the "degree of directness" you claim is completely bogus. > For recipients concerned about such volatility, all they have to do is > refrain from advertising CONNEG support. in other words, what you are saying is that this extension has very narrow applicabliity - it is not usable on the vast majority of message transfer agents, but only on those that are tightly coupled with an MUA or gateway that applies to all recipients. so why are we complicating SMTP with an extension that only applies to a very narrow case? is support for fax really so important that we have to extend SMTP in such a way that it's only usable for fax, and in such a way that fax-capable MTAs are a completely different class than other MTAs? > For senders concerned about such > volatility, they should use CONNEG=Required. the volatility isn't really the issue I'm concerned about - the issue is the lack of a standard mechanism for communication of capability sets from the UA (or the user) to the inbound MTA; and more generally, the difficulty of using the CONNEG mechanism to support users who use multiple UAs with different capabilities. at least, the latter scenario doesn't seem to have been considered. > >it seems like this extension has very limited applicability - it will > >only work reliably when the SMTP server and user agent or gateway are > >very closely tied and when the recipient always uses the same UA > >or UAs of very similar capabilities. (certainly not true of me!) > > 1. The specification already highlights that it is tailored for rather > 'direct' scenarios. true, but it also says that indirect ones are possible. > 2. Each user can decide what to advertise. HOW? there's no mechanism defined that allows them to do so. > If they vary their UA they can > choose to advertise a safe and lesser set of capabilities. In any event, > it is their choice. The mechanism does not impose any problems that are > not inherent in use of multiple UAs. However it DOES permit relatively > direct advertising of capabilities, which is currently not feasible. > > > >but if we're going to extend SMTP to perform functions > >on behalf of the user agent, it needs to be made very explicit that this > >negotiation is being done on behalf of the user agent - and in particular > >that the negotiation being requested represents the preferences of the > >*user* > > In what way does that affect the technical specification? because if third parties make unauthorized modifications to messages then the end-to-end integrity of the message is destroyed. is that technical enough for you? > That is, how is the current specification deficient, with respect to your > concern? > > > >in particular there seems to be no > >ability to apply content-transformation on a per-recipient basis, > >to handle the case where different transformations are acceptable to > >differnet recipients. > > We must be reading different specifications. Choice of enforcement of this > option is per-recipient. Each recipient may generate a capabilities > response if they wish a different form of the content. > > What, exactly, are you looking for that is missing? reread my earlier message, and see above. > >of course it's not easy to get SMTP to handle different client-side > >transformations for different recipients, since SMTP is designed to > >transfer the exact same message body (modulo received fields) to each > >of a set of recipients. > > It sounds as if you are assuming that later transmission of content that is > revised according to capabilities information is required (or expected) to > be sent using that same address list. well, by the time the sender knows what the recipients' capabilities are, the receiver already thinks it has the recipient list, and it is expecting a single messgae to be sent to all of those recipients. maybe you need to read the draft you claim to have co-written? > > That is like requiring that all BCC copies are sent along with the TO and > CC copies. > > In other words, there is not such requirement. It is OK to do it and it is > OK not to. > > Yes, the current CONNECT option is intended to send the same content to all > recipients, since that is the style of SMTP. There is nothing preventing > later sending an alternative content form to selected recipients. so you're suggesting that multiple copies of the message be sent to those recipients? > Interestingly, this would not actually create any additional round-trips or > additional content transfers. that's about the most bizarre thing I've ever seen you write... > > > this is a different model than used by > >phone-based facsimile protocols which expect there to be only one > >recipient of any given transmission, > > You might want to take a look at fax broadcasting services. The last-hop > telephone portion behaves as you describe, but only after a 'generic' > posting process. perhaps, and I'm not familiar with these. but my guess is that they don't do per-recipient negotiation on earlier hops. > > so it's not surprising that the fax-style negotiation doesn't fit well > > into SMTP. > > Actually, the proposed scheme permits content transmission tailoring that > is considerably more flexible than is typical in the real fax world. > > > >in order to make client-side negotiation a clean fit into SMTP, it is > >necessary for the client to first query the server for the capabilities > >of each intended recipient, then to deduce how many total transformations > >are necessary, then to send one or more transformed versions of the message. > > Ahh. I see. You want to insist on an interaction scenario that is known > to be unacceptable, since it is guaranteed to introduce too much delay > before there is any utility at all. PIPELINING would make the delay negligible. and it's far preferable to overloading the RCPT command. > > overloading the RCPT > >command to return capabilities breaks the RCPT command and forces > >the client to do RSET in order to send different versions to > >different recipients. > > If that is what the client chooses to do, then yes. However there are > other courses of action available. At the least, note that the content is > not sent until the client has CONNEG responses about all of the recipients. perhaps you'd like to describe those "other courses" which allow the client to meet the requirement that it deliver the highest quality content to each recipient? or for that matter, that allow the client to satisfy mutually conflicting needs of recipients? (e.g. one recipient will only take gif while another will only take jpeg) > >putting content negotiation in the transport protocol is likely > >to result in a significant increase in anomolous behaviors > >from the mail system which are difficult to diagnose and fix - > >and the proposal is being introduced at a time when the mail system > >is already suffering from serious reliabliity problems (often due > >to ill-conceived measures for blocking spam). > > How does use of the CONNEG mechanism affect reliability or accountability? it complicates error handling. > > at this time, > >*any* proposal for adding new functionality to SMTP should be viewed > >with strong reservations, unless it somehow offers an improvement > >in reliability. > > I was not aware that we had any problems being attributed to SMTP > options. Please provide some citations, so we can compare their details to > the current proposal. the problems are with SMTP in general. if you want citations, go read delivery failure notices from a few large mailing lists. > > >4. naming and applicability > > > >the protocol claims to be a general-purpose content-negotiation scheme > >but actually has "fax" assumptions embedded very deeply. > > The fax world is the basis for the idea, yes. However the specification > has been done so as to be independent of fax, thereby using an approximate > model that is known to be useful from the fax world and then applying it > for general enhancement of email. It's evident that not very much thought has been invested in making the non-fax case work. > >first of all, it assumes that there is a linear ordering relationship > >for document suitability to the recipient. > > Ok. I give up. I have no idea what "linear ordering relationship for > document suitability" means. it means that the proposal assumes there is a notion of "higher quality" vs "lower quality" versions of a message that can be determined for all messgaes and that is obvious to an implementor. > >a. I strongly recommend that you redesign this extension so that, instead > >of overloading the RCPT command, you define a separate command to > >request a recipient's capabilities. e.g. > > In spite of the proffered benefits of a separate command, I fail to see how > it produces any real benefits. > > It certainly does not make anything simpler, and it certainly vastly > increases relay delay, due to nearly doubling the round-trip exchanges > during an SMTP session that uses the option. it gets you out of the "oops I don't really want to send this message to that recipient because that recipient needs a different format of the message" trap. as far as round trips, RCAP RCAP RCAP RCPT DATA RCPT DATA RCPT DATA is slightly better than RCPT RCPT RCPT RSET RCPT DATA RCPT DATA RCPT DATA but you really ought to pipeline these things anyway. > >one nice side-benefit is that it doesn't change the error handling > >model, > > How does the current proposal change the error handling "model"? by introducing new error conditions that require different handling than existing errors. > >b. the idea that the sender should send the "best" or "highest > >quality" version needs to be relaxed or generalized, > > It already has been relaxed. Note the SHOULD rather than MUST. it's still a conditional requirement of the specification that is so vaguely defined as to be unimplementable except perhaps for the narrow fax case. different implementors could easily interpret the SHOULD in different ways even absent any conditions that would allow them to disregard the SHOULD. in other words, it doesn't produce predictable behavior. > > since there's currently no clear notion of what this means. > > Yet we have lived with that notion in multipart/alternative for some years. in retrospect we might consider mp/alternative a bug. I don't think citing it adds weight to your argument. > > >c. this extension needs to be made less fax-specific. > > What, specifically, makes it fax specific, and what changes are you > specifically seeking that will be less fax-specific? > > > >it needs to be examined with some realistic non-fax-specific > >test cases, and it needs non-fax conneg examples also. > > Test cases are always a good thing. Feel free to offer some that satisfy > your non-faxiness goal. hey, you're the one making the proposal, seems like it's your job to make sure it really has the applicability that you claim it does. I don't really think the proposal provides enough benefit to make it worthwhile even if it's done right. but rather than rejecting it out of hand (and recognizing that the fax community wants this badly) I'm trying to offer some constructive criticism that would make it less objectionable. > >d. there needs to be a good way for the recipient to specify > >capabilities to the SMTP server, at least for any SMTP server > >that can serve arbitrary UA recipients. probably this means another > >extension along with SMTP AUTH. > > You want to require that that mechanism be in place before the current > specification can be advanced? I think the phrase "chicken and egg" works > here. You create a deadly embrace for reaching any utility. I think it's called 'having a complete specification'. I didn't say anything about having the mechanism deployed, but I do think it needs to be defined. > >still, this is a big can of worms, because there's never been > >any ability of a UA to specify something to its inbound SMTP > >servers before - there's presently not even a good way for > >a UA to know which server(s?) should be given this information... > > Think hard. What is likely to drive creation of such a > mechanism? Requiring that it be built in the abstract or looking for it to > be built in reaction to actual demand? no argument there - but my point is that this is breaking new ground, and as such there are many issues that need to be considered that we haven't thought of before. > > >e. make it absolutely clear that such transformations are only to be > >made with explicit authorization by the sender and/or recipient. > > This sort of parental direction in IETF specifications probably does no > harm, but it is difficult to imagine that it does much benefit. tell that to the OPES people who were trying to push for web proxies that would modify content without either the provider's or consumer's consent. the last thing I want is an ISP advertising content capabilities on my behalf without my authorization - and I can think of some large ones that would do exactly that. I used to think we could rely on each layer to maintain the appropriate degree of transparency for that layer without our demanding that it be so. history has proven me wrong. it needs to be specified. > >f. the document needs to consider the effect of message forwarding > >on the returned string - if a recipient has his mail forwarded > >elsewhere it's not clear what conneg string should be returned. > > There are all sorts of implications in forwarding. In general, forwarding > that is not simply SMTP relaying is outside of current IETF > specification. Imposing a requirement about it here, without demonstrating > actual problems, is a tad extreme. apparently you'd rather just deploy a new protocol extension without even bothering to think about how it affects the infrastructure. let's just say I disagree. > >g. the document alludes to the ability to work through intermediaries > >but this isn't explained anywhere, and it needs to be explained. > > All it says is that it works with SMTP relaying, just as one would expect > and SMTP extension tow work. how does it work with SMTP relaying if there's no defined way to relay the capabilities? either you leave it to the last hop, which (while fine with me) makes the statement kind of trivial, or you do something really ugly... again, a bit of clarification of this statement wouldn't hurt. > > > 4.2 Client Action: > >... > >this incorrectly assumes that (a) there is only one target when > >the client can easily specify multiple RCPT commands, and > >(b) there is a clear notion of "highest level of capability" > >for the target. > > It does not make the assumption you suggest. In fact, I can't imagine how > you came to the assessment that it makes that assumption. well, I can't imagine how you came to a number of the assessments you are claiming. perhaps we live in different universes. > > > > 4.3 Server Action: > > > > > > If the client specifies "CONNEG = REQUIRED" in the RCPT-TO, > > > but the target does not support the CONNEG parameter, the target > > > MUST reject the RCPT-TO command with a 504 reply. > >... > >(it may be that other extensions have similar wording, in which case > >they're similarly flawed) > > It is probably a good idea that we not try to fix SMTP (yet again, given > the protracted drums effort.) And it certainly is not a good idea to > require that the current specification fix something this vague when no > SMTP-related specification is required to. so we should always write new specifications as poorly as existing ones? this wasn't so much of a problem when we didn't have so many extensions - but the more extensions we have the more problems like this we introduce . > > > If the client specifies "CONNEG = OPTIONAL" in the RCPT-TO, the > > > target MUST process the address and message as if the requested > > > CONNEG capabilities had not been specified. > > > >this doesn't seem to make sense as written. is "CONNEG = OPTIONAL" > >really supposed to be interpreted the same as omission of the > >CONNEG parameter? > > I think that the text that is in the first paragraph of that section ("but > the target does not support the CONNEG parameter") got deleted during > revision. In general, those first 3 paragraphs are dealing with lack of > support, whereas the following paragraphs are dealing with presence of support. > > > >also, I don't think there should be spaces around the = sign - > > ack. > > > >I wonder here - assuming that this can of worms does not get closed > >back up, and there might later be demand for other mechanisms > >to request recipient capabilities (e.g. since this one is not very general), > >might there be multiple kinds of strings emitted in the RCPT response? > > Please indicate what capabilities are missing from this capabilities > mechanism that would make it more general and for which there is a > demonstrated need. actually this one is the least of my concerns about the document. if the other problems can be fixed this one is easy... but the fix for this depends to some degree on how you fix the other problems, so I'll defer making suggestions for now. Keith From owner-ietf-fax@mail.imc.org Tue Jul 2 15:08:48 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 PAA09114 for ; Tue, 2 Jul 2002 15:08:47 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g62Ioir05823 for ietf-fax-bks; Tue, 2 Jul 2002 11:50:44 -0700 (PDT) Received: from horsey.gshapiro.net (root@horsey.gshapiro.net [209.220.147.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62Iogw05813 for ; Tue, 2 Jul 2002 11:50:42 -0700 (PDT) Received: from monkeyboy.gshapiro.net ([209.246.26.36]) by horsey.gshapiro.net (8.12.5.Beta0/8.12.5.Beta0) with ESMTP id g62IoRgG030407 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 2 Jul 2002 11:50:29 -0700 (PDT) Received: from monkeyboy.gshapiro.net (gshapiro@localhost [127.0.0.1]) by monkeyboy.gshapiro.net (8.12.3/8.12.3) with ESMTP id g62IocvR006181 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 2 Jul 2002 11:50:38 -0700 (PDT) (envelope-from gshapiro@monkeyboy.gshapiro.net) Received: (from gshapiro@localhost) by monkeyboy.gshapiro.net (8.12.3/8.12.3/Submit) id g62IocjX006178; Tue, 2 Jul 2002 11:50:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15649.62973.894081.566925@monkeyboy.gshapiro.net> Date: Tue, 2 Jul 2002 11:50:37 -0700 From: Gregory Neil Shapiro To: ietf@ietf.org CC: ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard X-Mailer: VM 7.03 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Some comments regarding draft-ietf-fax-esmtp-conneg-02.txt: - It became increasingly difficult to understand as the draft inconsistently refers to the server as both "server" and "target", at times in the same section. It makes it look like there is a third party ("client", "server", and "target"). "server" should be used throughout. - Section 4.3 states: If the target support the CONNEG parameter, but it can not return the recepient's capability temporarily, the target MUST reject the "recipient's" is spelled incorrectly. - Section 4.3 states: If the client specifies "CONNEG = OPTIONAL" in the RCPT-TO, the target MUST process the address and message as if the requested CONNEG capabilities had not been specified. If the server MUST ignore the CONNEG capabilities, then why should the client even both sending it? I think this MUST should be a MAY. - Section 4.3 states: Regardless of the value of the parameter, if the target does support the CONNEG parameter, then it MUST issue a 250 reply, followed by the capabilities of the target that is specified by the RCPT-TO address. I think this should be changed to: Regardless of the value of the parameter, if the target does support the CONNEG parameter and the address is acceptable, then it MUST issue a 250 reply, followed by the capabilities of the target that is specified by the RCPT-TO address. Note the addition of "and the address is acceptable". The draft should not specify that the command "MUST issue a 250 reply" as there may be other reasons outside of the scope of CONNEG not to do so. - Section 4.3 states: If the SMTP server supports ENHANCEDSTATUSCODES, the response strings for a success are "250-2.1.5 CONNEG" and "250 2.1.5 CONNEG". 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". ^^^^^ That last enhanced status code should be 4.3.3, not 5.3.3. - Section 5 states: Command with "CONNEG": "RCPT TO:" ("" / "" / Forward-Path) (SP "CONNEG =" ("REQUIRED" / "OPTIOANL") CRLF * Why is postmaster specifically listed in the syntax? * "OPTIONAL" is spelled wrong in the syntax * Why are spaces required around the CONNEG, the =, and the REQUIRED or OPTIONAL? In all other ESMTP RCPT extensions, spaces separate extensions. As an implementor, I would prefer "CONNEG=REQUIRED", not "CONNEG = REQUIRED". - Section 5 states: 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) / The syntax shown for replies does not allow for any text after the SMTP code. E.g., this would be illegal according to the draft syntax: 250-Recipient Ok 250 CONNEG .... As the only thing the syntax allows to follow the 250- is a CRLF. This applies for all of the replies, not just the 250 case. Note that all of draft examples below break the rules set out by the syntax for replies. - Section 6 states: C: RCPT TO: CONNEG = REQUIRED Again, the spaces make this difficult to parse given that all other ESMTP arguments will not have spaces between the key and value. - Section 6 states: 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) ) That makes it look like the CONNEG response spans 8 lines. If that's the case, any SMTP client should reject it as it doesn't use proper SMTP continuation. This should be: S: 250- recipient ok S: 250-CONNEG (&(image-file-structure=TIFF-minimal) S: 250-CONNEG (MRC-mode=0)(color=Binary)(|(&(dpi=204) S: 250-CONNEG (dpi-xyratio=[204/98,204/196]) )(&(dpi=200) S: 250-CONNEG (dpi-xyratio=[200/100,1]) )(&(dpi=400) S: 250-CONNEG (dpi-xyratio=1) ) )(|(image-coding=[MH,MR,MMR]) S: 250-CONNEG (&(image-coding=JBIG)(image-coding-constraint=JBIG-T85) S: 250-CONNEG (JBIG-stripe-size=128) ) )(paper-size=[letter,A4,B4]) S: 250 CONNEG (ua-media=stationery) ) - Section 6 states: An example of succssful RCPT-TO response when CONNEG-capable server supports ENHANCEDSTATUSCODES. "successful" is spelled incorrectly. 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) ) Again, the same comment as above. - Section 6 states: An example of ESMTP sequence with parmanent failure RCPT-TO response. "permanent" is spelled incorrectly. 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 The comment above should probably indicate that this is a broken client. The client shouldn't be sending the "CONNEG = REQUIRED" since CONNEG was not given in reply to the EHLO command. Also, this is invalid -- the reply to the EHLO command doesn't end the continuation. It should be: C: EHLO ifax1.jp S: 250-ifax1.jp S: 250 DSN Note the DSN line is "250 DSN" instead of "250-DSN" as shown in the example. - Section 6 states: An example of an ESMTP sequence with temporary failure RCPT-TO response when the value of parameter is "REQUIRED": ... C: RCPT TO: CONNEG = REQUIRED S: 404 recipient ok Should the text for a '404' be 'recipient ok'? Perhaps, it should be 'conneg temporary failure'. - Section 7 states: On publicatiom of this document by the RFC Editor, the IANA shall register the Content_Negotiation ESMTP extension defined in section 3. "publication" is spelled incorrectly. - Section 12 states: Copyright (C) The Internet Society (2001). All Rights Reserved. Should this be updated to include 2002? From owner-ietf-fax@mail.imc.org Tue Jul 2 18:12:47 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 SAA18772 for ; Tue, 2 Jul 2002 18:12:47 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g62LsAi18232 for ietf-fax-bks; Tue, 2 Jul 2002 14:54:10 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62Ls9w18228 for ; Tue, 2 Jul 2002 14:54:09 -0700 (PDT) Received: from messagingdirect.com (1Cust14.tnt105.lnd4.uk.uudial.net [213.116.58.14]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g62Ls2d24855; Tue, 2 Jul 2002 15:54:03 -0600 Message-ID: <3D221C44.5F99DED6@messagingdirect.com> Date: Tue, 02 Jul 2002 15:33:56 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 CC: ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard References: <15649.62973.894081.566925@monkeyboy.gshapiro.net> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit More comments about the document. The draft doesn't explain what to do if the same fax messages was sent to multiple recipients with different rendering capabilities. Should it downgrade for the least capable recipient? Or should it use RSET and start multiple mail transactions to differently capable recipients? Correct me if I am wrong, but it seams that extending VRFY command is more appropriate for the purpose than using RCPT. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ From owner-ietf-fax@mail.imc.org Tue Jul 2 20:01:16 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 UAA23699 for ; Tue, 2 Jul 2002 20:01:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g62NjYZ24440 for ietf-fax-bks; Tue, 2 Jul 2002 16:45:34 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62NjVw24434; Tue, 2 Jul 2002 16:45:32 -0700 (PDT) Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17PXKh-00008h-00; Tue, 02 Jul 2002 23:45:19 +0000 Date: Tue, 02 Jul 2002 19:45:19 -0400 From: John C Klensin To: iesg@ietf.org cc: Keith Moore , Dave Crocker , ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Message-ID: <107911393.1025639119@localhost> In-Reply-To: <200207021433.g62EXW202165@astro.cs.utk.edu> References: <200207021433.g62EXW202165@astro.cs.utk.edu> X-Mailer: Mulberry/3.0.0a3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit IESG, I want to partially agree with Keith -- this proposal makes me very nervous and I believe the IETF should share that nervousness. Since Keith and Dave are more than capable of discussing the various issues that have been identifed to the point of clarity, I want to take a slightly different cut at the problem and tentatively suggest a different approach. For me, the root problem here is that the proposal seems to simultaneously say: * The MTA here knows a good deal about the MUAs associated with each of the recipients. * The MTA is able to support a relay function. It appears to me that, even ignoring layering violations, having both of those things be true requires either a good deal of negotiation among a set of relays and the final target host --going beyond the "next relay will take it and accept responsibility" model that some SMTP extensions use, e.g., to support non-7bit-transport-- or there has to be some magic. I don't see either in a quick reading of the document. More generally, I think we should hesitate about SMTP extensions whose purpose is to support a particular application, without understanding all of the implications of generalizing them. I think this is quite similar to one of Keith's points. But I believe it has been a characteristic of much of the fax work so far that relaying is not anticipated (this draft, in repeatedly commenting about "direct" connections, reinforces that belief). Indeed, we have text floating around that suggests that Internet Fax setups be configured to avoid relays, just as we have had similar suggestions about EDI-over-email applications. Sending a virtual fax to a fax broadcast device is another matter, of course: to the degree to which any action takes place in the message content, we've traditionally thought about that as a UA function, with the broadcast device acting as a receiving SMTP, delivering the message to the relevant UA (no matter how automated), which then initiates a completely new SMTP connection (or set of connections). Or we have modelled the broadcast device as a fax-capable SMTP gateway, with some different mail transport on the far side, which completely changes the rules. This is all leading to a constructive suggestion: Unless there is a clear need for an SMTP relay function that follows SMTP rules --e.g., the relay MTA doesn't look at message content at all-- it may be time for a new SMTP extension/ capability announcement to deal with these specialized applications that use SMTP as a message transport but that really aren't email in the normal sense. One version of such an extension would be "NORELAY". An SMTP server advertising it would guarantee, if the client requested that option (presumably on MAIL or a separate command -- this makes no sense on a pre-recipient basis) to either deliver a message or bounce it, but, under no circumstances to relay it off to another SMTP server. Of course, a server advertising that extension (or not) could refuse relaying even if the client didn't request the option: we never require servers to relay. In the presence of such an option, content negotiation that would require that the server know about its local MUAs becomes, IMO, somewhat more plausible. We have always permitted originating and delivery MTAs more flexibility than intermediate ones. In this particular case, if there was no relaying and the capabilities of the receiver were really server capabilities, rather than MUA ones (as would be the case for a dedicated Internet fax device or a distribution system that simulated one), the whole picture could be considerably simplified by treating capability negotiation on a per-SMTP-connection basis, rather than a per-recipient one. Is it possible that something of that nature would make sense? ------------- A few other issues that Keith didn't seem to pick up on (to my surprise): (i) So far, it has been a basic assumption of the ESMTP environment that a server advertising a particular capability does not (I'd have to go back and look, but I think perhaps MUST NOT) reject an attempt to request the desired capability. I understand the reasons here, given the general model, but returning a 504 to "RCPT TO: CONNEG" (implying "REQUIRED") would seem to violate that principle. (ii) In order to facilitate efficient relaying and processing of messages with large numbers of recipients, we permit, indeed almost encourage, SMTP receivers to accept RCPT commands without verification and then to prepare bounce messages if needed. I strongly suspect that there are conforming MTAs that can behave no other way. It seems to me from this specification that a server that advertises CONNEG must not perform this types of deferred operation, at least with regard to that parameter, but must handle errors within the SMTP transaction. If that requirement actually exists, I believe it is very important that the document point it out. Also, if relaying is permitted, then either the first relay in the chain has to have complete knowledge about what will be permitted downstream (and the document doesn't give any indication as to how it would find that out), or emailed rejection messages become an absolute requirement (at least unless no response is issued to any RCPT TO until the final delivery MTA has generated a 250 code and returned that along the line -- I suppose that would be possible, but it would require yet other SMTP extensions to specify the behavior and it would probably be a performance disaster). (iii) I can't reconcile the last statement of section 4.2: If the server returns an EHLO 250 code without CONNEG capabilities, the client MUST work as "a Simple Mode of Facsimile Using Internet Mail" [RFC2305]. With the assertion that this is a general facility, not limited to fax. If it is a duck, let's call it a duck and be done with it. And, if fax is sufficiently special that we need things like this, perhaps it is time to add something like NORELAY, or a FAX extension, to make it clear that what is happening is not normal SMTP. (iv) Like Gregory Neil Shapiro, I'm not sure what a "target" is and I'm not sure the term is used consistently. E.g., in 4.2, it appears as if the "target" is not the receiving SMTP server, but is rather the mailbox (and, presumably, MUA) listed in the RCPT command. But 4.3 says "... the target MUST reject..." which strongly implies an SMTP server action. (v) Just as an editorial matter, but, in order to avoid unnecessary confusion, it would probably be helpful if the document adopted terminology consistent with RFC 2821 (and 821). E.g., there is no such command as "RCPT-TO", the name of the relevant command is "RCPT". -------- To paraphrase advice Dave has given on many other occasions, let's divide this set of issues up and solve the problems that are well-defined and that we know how to solve and leave the rest until there is a demonstrated need. The problem here, as I understand it --both generally and after reading the introduction to this draft-- is fax and fax-like start-of-session capabilities negotiation in a direct connection environment. Let's think about using SMTP extension mechanisms, if necessary, to specify/require that case and just avoid generalizations that require us to deal with all of the poorly-understood (or at least unspecified in this document) relaying, intermediary server, and other issues. john From owner-ietf-fax@mail.imc.org Tue Jul 2 20:35:35 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 UAA25082 for ; Tue, 2 Jul 2002 20:35:35 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g630LfR25477 for ietf-fax-bks; Tue, 2 Jul 2002 17:21:41 -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 g630Lfw25473 for ; Tue, 2 Jul 2002 17:21:41 -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 RAA17568; Tue, 2 Jul 2002 17:27:31 -0700 Message-Id: <5.1.1.2.2.20020702171243.03c21bf8@jay.songbird.com> X-Sender: dhc2@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Tue, 02 Jul 2002 17:15:52 -0700 To: John C Klensin From: Dave Crocker Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Cc: ietf@ietf.org, ietf-fax@imc.org In-Reply-To: <108177848.1025639386@localhost> References: <3D221C44.5F99DED6@messagingdirect.com> <15649.62973.894081.566925@monkeyboy.gshapiro.net> <3D221C44.5F99DED6@messagingdirect.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: At 07:49 PM 7/2/2002 -0400, John C Klensin wrote: >--On Tuesday, 02 July, 2002 15:33 -0600 Alexey Melnikov > wrote: > > Correct me if > > I am wrong, but it seams that extending VRFY command is more > > appropriate for the purpose than using RCPT. > >Hmm. _That_ is an interesting idea, since we have always >permitted VRFY to do somewhat more poking around in real time >than one might normally expect of RCPT (where "poking around" >efforts more often result in a 250 code and an email rejection >if needed). If I understand both your comments and Keith's suggestion, the key is a separate command. It, too, find that aesthetically preferable. The problem is with efficiency. A separate command means 2 commands per recipient and it means at least one synchronization event, between issuance of this new command and issuance of the first RCPT-TO. That's quite a bit of overhead, for something that frequently will have no effect on the content being transferred. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Tue Jul 2 20:58:55 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 UAA25744 for ; Tue, 2 Jul 2002 20:58:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g630j6326256 for ietf-fax-bks; Tue, 2 Jul 2002 17:45:06 -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 g630j5w26251 for ; Tue, 2 Jul 2002 17:45:05 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KJMCBY0GRK001ZTY@mauve.mrochek.com> for ietf-fax@imc.org; Tue, 02 Jul 2002 17:45:06 -0700 (PDT) Date: Tue, 02 Jul 2002 17:20:24 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: "Your message dated Tue, 02 Jul 2002 19:49:46 -0400" <108177848.1025639386@localhost> To: John C Klensin Cc: Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Message-id: <01KJMM5WZSX8001ZTY@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <15649.62973.894081.566925@monkeyboy.gshapiro.net> <3D221C44.5F99DED6@messagingdirect.com> <108177848.1025639386@localhost> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > --On Tuesday, 02 July, 2002 15:33 -0600 Alexey Melnikov > wrote: > > More comments about the document. > > > > The draft doesn't explain what to do if the same fax messages > > was sent to multiple recipients with different rendering > > capabilities. Should it downgrade for the least capable > > recipient? Or should it use RSET and start multiple mail > > transactions to differently capable recipients? Correct me if > > I am wrong, but it seams that extending VRFY command is more > > appropriate for the purpose than using RCPT. > Hmm. _That_ is an interesting idea, since we have always > permitted VRFY to do somewhat more poking around in real time > than one might normally expect of RCPT (where "poking around" > efforts more often result in a 250 code and an email rejection > if needed). While VRFY is, I think, less and less often > supported in a serious way, an SMTP extension that could not be > advertised unless it was supported for this function would get > around that problem. I considered proposing this back when I initially reviewed the document. It is certainly far more aesthetically appealing to me than the RCAP command Keith proposed. However, after looking at the actual use cases I become convinced that this isn't the clear win it appears to be a first glance. The advantage of having a separate command that returns recipient capabilities withing adding that recipient to the set of active recipients is, of course, that you don't have to RSET and start over if you uncover an incompatibility between multiple recipients. But there's a serious side effect: Advance capability retrieval tends to stall the pipeline. And while it is natural to view SMTP as a series of commands and responses, the way modern SMTP clients and servers need to work to be efficient is by sending batches of commands and getting back batches of responses. The naive implementation of capabilities exchange in a separate command then becomes the worst case scenario: If you send a VRFY (or RCAP) prior to sending each RCPT TO you end up with at least one round trip per recipient. Of course you can work around this by sending all the VRFYs/RCAPs in a batch prior to sending any RCPT TO. But the implementation complexity here is starting to be a serious issue. Another alternative would be to allow capabilities retrieval on either RCPT TO or VRFY. But now the client has a lot of options and approaches to choose from, which I don't think is a good thing. I think the determining factor needs to be how clients will actually handle recipients with differing capabilities. If the least common denominator is going to be the dominant approach (and I suspect that it will be) then RCPT TO capabilities return is the simplest and most direct approach. If, on the other hand, messages tailored for a each recipient is going to be the norm, then VRFY is the correct approach. Ned From owner-ietf-fax@mail.imc.org Tue Jul 2 21:21:05 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 VAA26616 for ; Tue, 2 Jul 2002 21:21:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6315TD27526 for ietf-fax-bks; Tue, 2 Jul 2002 18:05:29 -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 g6315Sw27516 for ; Tue, 2 Jul 2002 18:05:28 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KJMCBY0GRK001ZTY@mauve.mrochek.com> for ietf-fax@imc.org; Tue, 02 Jul 2002 18:05:30 -0700 (PDT) Date: Tue, 02 Jul 2002 17:46:34 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: "Your message dated Tue, 02 Jul 2002 17:15:52 -0700" <5.1.1.2.2.20020702171243.03c21bf8@jay.songbird.com> To: Dave Crocker Cc: John C Klensin , ietf@ietf.org, ietf-fax@imc.org Message-id: <01KJMMV7O9PI001ZTY@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <3D221C44.5F99DED6@messagingdirect.com> <15649.62973.894081.566925@monkeyboy.gshapiro.net> <108177848.1025639386@localhost> <5.1.1.2.2.20020702171243.03c21bf8@jay.songbird.com> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Our responses seem to have crossed... > > > I am wrong, but it seams that extending VRFY command is more > > > appropriate for the purpose than using RCPT. > > Hmm. _That_ is an interesting idea, since we have always > > permitted VRFY to do somewhat more poking around in real time > > than one might normally expect of RCPT (where "poking around" > > efforts more often result in a 250 code and an email rejection > > if needed). > If I understand both your comments and Keith's suggestion, the key is a > separate command. > It, too, find that aesthetically preferable. The problem is with efficiency. > A separate command means 2 commands per recipient and it means at least one > synchronization event, between issuance of this new command and issuance of > the first RCPT-TO. You can avoid the need for additional round trips by batching all the capabilities queries with the first RCPT TO. But this results in a rather sharp rise in implementation complexity. > That's quite a bit of overhead, for something that frequently will have no > effect on the content being transferred. Indeed. The average number of recipients for legitimate mail does tend to be quite small, which implies we're optimizing the uncommon case here. Ned From owner-ietf-fax@mail.imc.org Tue Jul 2 21:23:42 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 VAA26813 for ; Tue, 2 Jul 2002 21:23:41 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6319rW27921 for ietf-fax-bks; Tue, 2 Jul 2002 18:09:53 -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 g6319qw27917 for ; Tue, 2 Jul 2002 18:09:52 -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 SAA18853; Tue, 2 Jul 2002 18:15:36 -0700 Message-Id: <5.1.1.2.2.20020702180721.03a95930@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Tue, 02 Jul 2002 18:09:04 -0700 To: ned.freed@mrochek.com From: Dave Crocker Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Cc: John C Klensin , Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org In-Reply-To: <01KJMM5WZSX8001ZTY@mauve.mrochek.com> References: <"Your message dated Tue, 02 Jul 2002 19:49:46 -0400" <108177848.1025639386@localhost> <15649.62973.894081.566925@monkeyboy.gshapiro.net> <3D221C44.5F99DED6@messagingdirect.com> <108177848.1025639386@localhost> 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 05:20 PM 7/2/2002 -0700, ned.freed@mrochek.com wrote: >I think the determining factor needs to be how clients will actually handle >recipients with differing capabilities. If the least common denominator is >going to be the dominant approach (and I suspect that it will be) no surprise that I agree. However... > If, on the other >hand, messages tailored for a each recipient is going to be the norm, then >VRFY is the correct approach. If the sender is concerned about optimizing for each recipient, they can get that effect by reducing to a single RCPT-TO per DATA. So it is not as pretty as the separate command, but it permits roughly the same mode of operation. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Tue Jul 2 21:28: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 VAA27151 for ; Tue, 2 Jul 2002 21:28:57 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g631FE528368 for ietf-fax-bks; Tue, 2 Jul 2002 18:15:14 -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 g631Eww28338; Tue, 2 Jul 2002 18:14:59 -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 g631Eu200430; Tue, 2 Jul 2002 21:14:57 -0400 (EDT) Message-Id: <200207030114.g631Eu200430@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: John C Klensin cc: iesg@ietf.org, Keith Moore , Dave Crocker , ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Tue, 02 Jul 2002 19:45:19 EDT.") <107911393.1025639119@localhost> Date: Tue, 02 Jul 2002 21:14:56 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: a few brief comments on John's comments, not all of which have to do with the conneg-over-smtp draft: - I see two possible paths to "fixing" this proposal 1. do the necessary protocol fixes to make it generally applicable for email 2. make clear that it has only limited applicability for smtp-to-fax gateways, either supporting a single recipient or where all recipients have the same capabilities, and where relaying and forwarding were specifically disallowed. part of making this clear would be to clearly label the extension - not "CONNEG" or "Content_Negotiation" but FAXNEG or "Fax_Negotiation" however if pursuing this path it would still be necessary to leave room for VOICENEG or MIMENEG or whatever, and this still probably means NOT overloading RCPT. I strongly prefer alternative #1, because I believe it leads to a less complex and less costly end-state. In other words I'd far rather have a single SMTP extension that makes sense in an integrated messaging world that can also be used by specialized services, than to have separate extensions for (for lack of a better term) "workstation mail", internet fax, voice mail, etc. I do however recognize that there is probably pressure to do this soon rather than to wait until there can be consensus from all of the various parties. However, for this same reason I doubt that the #2 approach should result in a standards-track document. - I also feel compelled to say that waiting until IETF Last Call to get public review of any SMTP extension from the wider SMTP community is a very questionable strategy. This statement could be generalized by replacing "SMTP" with any other protocol name that has a significant number of implementations and/or installed base. - Regarding the idea for a NORELAY extension: I think we would do well to encourage more direct delivery for all kinds of email. The email system seems to be becoming more fragile all the time, thanks in large part to spam and viruses and (often poorly chosen or misconfigured) countermeasures for these. The more hops that a message has to travel, the lower the probability that it will be delivered. However it's not immediately clear to me how a NORELAY extension helps - will senders (fax or otherwise) really be willing to request it? - In a similar vein, I think we should reconsider the traditional encouragement for SMTP receivers to accept RCPT commands without verification. The reason is that the mail system is now considerably burdened by spam that is often sent to invalid recipient addresses, and which often has an invalid return address. Such messages (and the resulting bounces) clutter up the mail queues and postmaster mailboxes where they're generally discarded because most postmasters don't have time to read them any more. Early detection of invalid recipient addresses allows the message to be immediately rejected rather than bounced, reducing the load on the receiving MTA. What we really should do is encourage MTA implementors to provide the necessary hooks to make possible early detection of bad recipient addresses. - regarding failures due to requesting CONNEG > (i) So far, it has been a basic assumption of the ESMTP > environment that a server advertising a particular capability > does not (I'd have to go back and look, but I think perhaps MUST > NOT) reject an attempt to request the desired capability. I > understand the reasons here, given the general model, but > returning a 504 to "RCPT TO: CONNEG" (implying > "REQUIRED") would seem to violate that principle. perhaps more to the point, I think the current semantics are broken. if the server cannot supply a conneg string for a particular recipient (because it does not have one or because the sender lacks permission or whatever) the only reasonable behavior is for the server to report that fact (which should NOT be a server-reported error) at this point the client can either fail to deliver the message (because it's not willing to downgrade that far) or it can assume that the recipient has only minimal capabliities (e.g. simple mode) and do the required downgrade to that mode. but in the unwilling-to-downgrade case it's the CLIENT's job to assert the error, not the server's job. the client may have to assert the error in any cases, since it may not be possible to reasonably downgrade the message to suit the recipient's capabliities even if the recipient does support CONNEG. having the server assert the error just makes things more complex without adding any real functionality. - Also, unless the client is acting directly on behalf of the recipient (which is not required by the draft) the client is being asked to make a convert-or-fail decision without any reasonable (sender-supplied or standardized) criteria as to what kinds of conversions are acceptable. This seems like another major omission in the current spec. Keith From owner-ietf-fax@mail.imc.org Tue Jul 2 22:04:05 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 WAA28485 for ; Tue, 2 Jul 2002 22:04:04 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g631nLo00737 for ietf-fax-bks; Tue, 2 Jul 2002 18:49:21 -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 g631nHw00722; Tue, 2 Jul 2002 18:49:17 -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 SAA20001; Tue, 2 Jul 2002 18:55:08 -0700 Message-Id: <5.1.1.2.2.20020702183611.0354a798@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Tue, 02 Jul 2002 18:45:32 -0700 To: Keith Moore From: Dave Crocker Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Cc: iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org In-Reply-To: <200207030114.g631Eu200430@astro.cs.utk.edu> References: <(Your message of "Tue, 02 Jul 2002 19:45:19 EDT.") <107911393.1025639119@localhost> 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, At 09:14 PM 7/2/2002 -0400, Keith Moore wrote: > 1. do the necessary protocol fixes to make it generally > applicable for email Given that we DID make this generally applicable for email, someone still needs to list the way(s) the current specifications is deficient in that regard. What capabilities or scenarios need to be support that cannot be with the current specification? > 2. make clear that it has only limited applicability > for smtp-to-fax gateways, Perhaps you missed the portion of my response that pointed out that it is not limited to that use and, in fact, that is not even its primary intended use. If there is something in the specification that indicates otherwise, please point it out. > same capabilities, and where relaying and forwarding > were specifically disallowed. There is a difference between being optimized for single-user and/or single-hop scenarios, versus prohibiting multi-user and/or multi-hop scenarios. As nearly as I can tell, you are missing that difference. > however if pursuing this path it would still be necessary to > leave room for VOICENEG or MIMENEG or whatever, If you would supply some sort of functional description for these, it might be possible to understand how the current specifications fails to satisfy them. I have no idea what you are intending, and therefore cannot even guess at the deficiencies you are implying. >- Also, unless the client is acting directly on behalf of the >recipient (which is not required by the draft) Please specify what you mean by "acting directly on behalf of the recipient" and how the current specification fails to provide the necessary technical specification. If the specification contained whatever language about "acting directly on behalf" you are seeking, how would it change the normative technical specification? > the client >is being asked to make a convert-or-fail decision without >any reasonable (sender-supplied or standardized) criteria as >to what kinds of conversions are acceptable. > >This seems like another major omission in the current spec. You again seem to be missing the fact that that "omission" predates CONNEG and has been part of Internet mail for 8 years. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Tue Jul 2 22:21: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 WAA28926 for ; Tue, 2 Jul 2002 22:21:57 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6326C802375 for ietf-fax-bks; Tue, 2 Jul 2002 19:06:12 -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 g63268w02357; Tue, 2 Jul 2002 19:06:09 -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 g6326A200738; Tue, 2 Jul 2002 22:06:10 -0400 (EDT) Message-Id: <200207030206.g6326A200738@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: Keith Moore , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Tue, 02 Jul 2002 18:45:32 PDT.") <5.1.1.2.2.20020702183611.0354a798@jay.songbird.com> Date: Tue, 02 Jul 2002 22:06:10 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Keith, > > At 09:14 PM 7/2/2002 -0400, Keith Moore wrote: > > 1. do the necessary protocol fixes to make it generally > > applicable for email > > Given that we DID make this generally applicable for email, someone still > needs to list the way(s) the current specifications is deficient in that > regard. What capabilities or scenarios need to be support that cannot be > with the current specification? go back and reread my earlier messages. > > 2. make clear that it has only limited applicability > > for smtp-to-fax gateways, > > Perhaps you missed the portion of my response that pointed out that it is > not limited to that use and, in fact, that is not even its primary intended > use. If there is something in the specification that indicates otherwise, > please point it out. I've done so. go back and reread my earlier mssages. > > same capabilities, and where relaying and forwarding > > were specifically disallowed. > > There is a difference between being optimized for single-user and/or > single-hop scenarios, versus prohibiting multi-user and/or multi-hop > scenarios. As nearly as I can tell, you are missing that difference. the current document leaves relaying and forwarding undefined. this needs to be fixed. it might be a simple fix, but it's still an omission. > > however if pursuing this path it would still be necessary to > > leave room for VOICENEG or MIMENEG or whatever, > > If you would supply some sort of functional description for these, it might > be possible to understand how the current specifications fails to satisfy > them. I have no idea what you are intending, and therefore cannot even > guess at the deficiencies you are implying. I'm not going to waste the time to try to specify something which I'm clearly convinced is a Bad Idea. > >- Also, unless the client is acting directly on behalf of the > >recipient (which is not required by the draft) > > Please specify what you mean by "acting directly on behalf of the > recipient" and how the current specification fails to provide the necessary > technical specification. I've already done so, by saying that the recipient needs a standard way to set the conneg string that is returned. > > the client > >is being asked to make a convert-or-fail decision without > >any reasonable (sender-supplied or standardized) criteria as > >to what kinds of conversions are acceptable. > > > >This seems like another major omission in the current spec. > > You again seem to be missing the fact that that "omission" predates CONNEG > and has been part of Internet mail for 8 years. I'm not aware of a content-specific convert-or-fail decision that has to be made as part of Internet mail, much less one that has been around for 8 years. Keith From owner-ietf-fax@mail.imc.org Tue Jul 2 22:29: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 WAA29184 for ; Tue, 2 Jul 2002 22:29:31 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g632EYP03191 for ietf-fax-bks; Tue, 2 Jul 2002 19:14:34 -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 g632EXw03184 for ; Tue, 2 Jul 2002 19:14:33 -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 g632ER200812; Tue, 2 Jul 2002 22:14:27 -0400 (EDT) Message-Id: <200207030214.g632ER200812@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: ned.freed@mrochek.com, John C Klensin , Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Tue, 02 Jul 2002 18:09:04 PDT.") <5.1.1.2.2.20020702180721.03a95930@jay.songbird.com> Date: Tue, 02 Jul 2002 22:14:27 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > If the sender is concerned about optimizing for each recipient, they can > get that effect by reducing to a single RCPT-TO per DATA. if several recipients have similar capabliities, sending a separate copy of each message hardly seems like an optimization. > So it is not as pretty as the separate command, but it permits roughly the > same mode of operation. overloading RCPT is simply unacceptable. It would be a Bad Idea for any SMTP extension, but this proposal pre-empts RCPT error reporting for a very specific application. Keith From owner-ietf-fax@mail.imc.org Tue Jul 2 22:58: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 WAA00530 for ; Tue, 2 Jul 2002 22:58:29 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g632foc04510 for ietf-fax-bks; Tue, 2 Jul 2002 19:41:50 -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 g632fnw04506 for ; Tue, 2 Jul 2002 19:41:49 -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 TAA21436; Tue, 2 Jul 2002 19:47:33 -0700 Message-Id: <5.1.1.2.2.20020702193306.03284c00@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Tue, 02 Jul 2002 19:39:46 -0700 To: Keith Moore From: Dave Crocker Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Cc: ned.freed@mrochek.com, John C Klensin , Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org In-Reply-To: <200207030214.g632ER200812@astro.cs.utk.edu> References: <(Your message of "Tue, 02 Jul 2002 18:09:04 PDT.") <5.1.1.2.2.20020702180721.03a95930@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: At 10:14 PM 7/2/2002 -0400, Keith Moore wrote: > > If the sender is concerned about optimizing for each recipient, they can > > get that effect by reducing to a single RCPT-TO per DATA. > >if several recipients have similar capabliities, sending a separate >copy of each message hardly seems like an optimization. Keith, the one thing that is certain is that no specification can satisfy requirements that are constantly being changed. You expressed concern about content being tailored to each recipient's capabilities. This proposal supports that. You would prefer to achieve that in a different way, with is certainly your right, but the current specification satisfies it. Now you are expressing concern about content that is tailored to "several recipients" that have "similar" capabilities. That is quite different from anything you have raised before. I am sure that you can discover all sorts of boundary conditions that are unlikely and for which the current specification is not optimized. And, of course, you continue to ignore minor matters of efficiency for what is expected to be the typical cases, namely sending a common set for all of the recipients and sending a single content for a single recipient. > > So it is not as pretty as the separate command, but it permits roughly the > > same mode of operation. > >overloading RCPT is simply unacceptable. Keith, your term "overloading" suggests that RCPT-TO parameters are being invented here. They aren't. In any event technical discussions are facilitated by have a discussion about technical merits. They usually are not facilitated by having participants pretend that they have a veto. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Tue Jul 2 23:09: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 XAA00900 for ; Tue, 2 Jul 2002 23:09:23 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g632sSp04978 for ietf-fax-bks; Tue, 2 Jul 2002 19:54:28 -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 g632sRw04973 for ; Tue, 2 Jul 2002 19:54:27 -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 g632sS200856; Tue, 2 Jul 2002 22:54:28 -0400 (EDT) Message-Id: <200207030254.g632sS200856@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: John C Klensin , ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Tue, 02 Jul 2002 17:15:52 PDT.") <5.1.1.2.2.20020702171243.03c21bf8@jay.songbird.com> Date: Tue, 02 Jul 2002 22:54:28 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > If I understand both your comments and Keith's suggestion, the key is a > separate command. > > It, too, find that aesthetically preferable. The problem is with efficiency. > > A separate command means 2 commands per recipient and it means at least one > synchronization event, between issuance of this new command and issuance of > the first RCPT-TO. The bandwidth required by the extra command is negligible. I don't think the extra command needs to add another synchronization event; offhand it looks like it can piggyback on the event following the MAIL command. Since all downgrade decisions should be made by the client anyway, there's actually no need for the RCAP command to change the state of the SMTP protocol engine. In other words, the client would be be doing MAIL RCAP a RCAP b RCAP c * ( *RCPT DATA . ) instead of MAIL even if another synchronization event were needed, I don't think that's a big price to pay, particularly when the alternative (from a protocol architecture perspective) is to clutter up the RCPT command and (from a implementor perspective) to either a) require a separate RCPT/DATA exchange for each recipient, (far more overhead than your extra synchronization event) b) downgrade to the least common acceptable format for all recipients (assuming there is one - which might be true for fax but is not a reasonable assumption in general), or c) send RSET following all the RCPTs if it is desirable to send different versions to different recipients, followed by another set of RCPT/DATA exchanges - again resulting in far more overhead than a single additional synchronization eent. Keith From owner-ietf-fax@mail.imc.org Tue Jul 2 23:19:22 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 XAA01316 for ; Tue, 2 Jul 2002 23:19:21 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6335Kk05401 for ietf-fax-bks; Tue, 2 Jul 2002 20:05:20 -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 g6335Iw05390 for ; Tue, 2 Jul 2002 20:05:18 -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 g6335F200883; Tue, 2 Jul 2002 23:05:15 -0400 (EDT) Message-Id: <200207030305.g6335F200883@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: ned.freed@mrochek.com cc: Dave Crocker , John C Klensin , ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Tue, 02 Jul 2002 17:46:34 PDT.") <01KJMMV7O9PI001ZTY@mauve.mrochek.com> Date: Tue, 02 Jul 2002 23:05:15 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > You can avoid the need for additional round trips by batching all the > capabilities queries with the first RCPT TO. But this results in a rather sharp > rise in implementation complexity. surely is it less complex than what is required by the current protocol - i.e. doing a RSET followed by additional MAIL and RCPT commands. > > That's quite a bit of overhead, for something that frequently will have no > > effect on the content being transferred. actually I don't see why putting the conneg response in a separate command is "quite a bit of overhead" - the extra bandwidth required for "RCAP " is neglibible, there's no difference in the response at all, and the client logic to deal with separate commands is simpler since the client doesn't have to distinguish ordinary RCPT failures from CONNEG failures. and the client doesn't have to do RSET followed by a separate set of MAIL/RCPT commands for each recipient if for some reason it wants or needs to deliver different versions of the message to different recipients. > Indeed. The average number of recipients for legitimate mail does tend to be > quite small, which implies we're optimizing the uncommon case here. to understand the tradeoff it may be useful to compare each proposal under the same set of scenarios. e.g. a. single recipient b. multiple recipients, all with similar capabilities c. multiple recipients, different capabilities d. multiple recipients, mutually exclusive capabilities with each case evaluated for a. ease/simplicity of implementation, b. necessary round-trip delays, c. future extensibility Keith From owner-ietf-fax@mail.imc.org Tue Jul 2 23:39:22 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 XAA01920 for ; Tue, 2 Jul 2002 23:39:21 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g633Oe906241 for ietf-fax-bks; Tue, 2 Jul 2002 20:24:40 -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 g633Ocw06237 for ; Tue, 2 Jul 2002 20:24:38 -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 g633OY201036; Tue, 2 Jul 2002 23:24:34 -0400 (EDT) Message-Id: <200207030324.g633OY201036@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: ned.freed@mrochek.com cc: John C Klensin , Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Tue, 02 Jul 2002 17:20:24 PDT.") <01KJMM5WZSX8001ZTY@mauve.mrochek.com> Date: Tue, 02 Jul 2002 23:24:34 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > But there's a serious side effect: Advance capability retrieval tends to stall > the pipeline. And while it is natural to view SMTP as a series of commands and > responses, the way modern SMTP clients and servers need to work to be efficient > is by sending batches of commands and getting back batches of responses. > > The naive implementation of capabilities exchange in a separate command then > becomes the worst case scenario: If you send a VRFY (or RCAP) prior to sending > each RCPT TO you end up with at least one round trip per recipient. I don't understand which argument you're making - is it that the naive implementation is slow, or that it's too hard to do an efficient pipelining implementation? as long as RCAP doesn't force any new decision points for the client, I don't see why the efficient pipelining implementation is any more difficult for the RCAP case than the RCPT/RSET case. if RCPT is overloaded then the client sends multiple RCPTs, waits for all of the responses, then decides whether to just send one copy or do RSET/MAIL/etc and send multiple copies. if there's a separate command then the client sends multiple RCAPs, and one RCPT, waits for all of the responses, and then decides whether the version that's right for the first recipient is also appropriate for other recipients. seems like the implementation complexity is about the same in either case. either way the sender wants to divide up the recipients into separate classes and batch up the messages to each. assuming it's trying to optimize, that is. of course the naive/inefficient implementation is quite easy (and equally slow) for both proposals - just use no more than one recipient per SMTP session. but it's hard to see how the client can avoid implementing some kind of logic to convert differently for different recipients, since there's clearly the potential for the recipients' conneg strings to have no format in common. perhaps if the client can only do one or two different kinds of conversion (otherwise it has to bounce) then the decision becomes a bit easier, but this again looks more like a fax-specific facility than a general one. Keith From owner-ietf-fax@mail.imc.org Tue Jul 2 23:50:50 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 XAA02423 for ; Tue, 2 Jul 2002 23:50:49 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g633anx06598 for ietf-fax-bks; Tue, 2 Jul 2002 20:36:49 -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 g633alw06594 for ; Tue, 2 Jul 2002 20:36:47 -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 g633ah201164; Tue, 2 Jul 2002 23:36:43 -0400 (EDT) Message-Id: <200207030336.g633ah201164@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: Keith Moore , ned.freed@mrochek.com, John C Klensin , Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Tue, 02 Jul 2002 19:39:46 PDT.") <5.1.1.2.2.20020702193306.03284c00@jay.songbird.com> Date: Tue, 02 Jul 2002 23:36:43 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > > If the sender is concerned about optimizing for each recipient, they can > > > get that effect by reducing to a single RCPT-TO per DATA. > > > >if several recipients have similar capabliities, sending a separate > >copy of each message hardly seems like an optimization. > > Keith, the one thing that is certain is that no specification can satisfy > requirements that are constantly being changed. > > You expressed concern about content being tailored to each recipient's > capabilities. This proposal supports that. it doesn't support that explicitly, and the only ways that you can do it with your proposal are more complex and/or expensive than the alternative I've suggested. > You would prefer to achieve > that in a different way, with is certainly your right, but the current > specification satisfies it. the current specification allows it, though it doesn't explain how it allows it, and it's incomplete. > Now you are expressing concern about content that is tailored to "several > recipients" that have "similar" capabilities. That is quite different from > anything you have raised before. there are different cases that need to be considered, and I don't claim to have enumerated them all yet. nor do I believe there's a requirement to enumerate all of my concerns with your proposal in a single round-trip. indeed, I'm still trying to articulate some of them. > I am sure that you can discover all sorts of boundary conditions that are > unlikely and for which the current specification is not optimized. and among them, some boundary conditions which are likely and some failure modes which aren't considered. but of course you'll assume that everybody will use the protocol exactly as you intended, even though you didn't bother to even explain how you assumed the protocol would be used. that's no way to write a standard. > And, of course, you continue to ignore minor matters of efficiency for what > is expected to be the typical cases, namely sending a common set for all of > the recipients and sending a single content for a single recipient. I didn't ignore it. but you failed to mention these in the document. and somehow you seem to think it's okay to insist on a minor optimization of saving a round-trip by overloading RCPT when you have the major lossage of having to send separate copies to each recipient when there's no common set available. nor is it clear to me why downgrading to a single common format, just because the sender happened to specify multiple recipients on the TO, cc or bcc field, is acceptable from the sender or recipient's point of view. (last time I sent you a fax you got high quality color, but this time you got low-res black/white ... what gives?) even if it's okay with the fax people I'd take serious issue with this kind of haphazard conversion being applied to ordinary email. > > > So it is not as pretty as the separate command, but it permits roughly the > > > same mode of operation. > > > >overloading RCPT is simply unacceptable. > > Keith, your term "overloading" suggests that RCPT-TO parameters are being > invented here. no, it suggests that overloading the RCPT reply code to indicate a condition other than "this message cannot be sent to this recipient" is a bad idea. > In any event technical discussions are facilitated by have a discussion > about technical merits. They usually are not facilitated by having > participants pretend that they have a veto. nor are they facilitated by having the proposer pretend that His is the unimpeachable Word of God and trying to deflect technical criticisms with personal attacks. Keith From owner-ietf-fax@mail.imc.org Wed Jul 3 00:11:11 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 AAA03136 for ; Wed, 3 Jul 2002 00:11:10 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g633ukF07241 for ietf-fax-bks; Tue, 2 Jul 2002 20:56:46 -0700 (PDT) Received: from turing-police.cc.vt.edu (h80ad2742.async.vt.edu [128.173.39.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g633uMw07219; Tue, 2 Jul 2002 20:56:26 -0700 (PDT) Received: from turing-police.cc.vt.edu (localhost [127.0.0.1]) by turing-police.cc.vt.edu (8.12.4/8.12.4) with ESMTP id g633tCSQ004199; Tue, 2 Jul 2002 23:55:14 -0400 Message-Id: <200207030355.g633tCSQ004199@turing-police.cc.vt.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: Dave Crocker Cc: iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-Reply-To: Your message of "Tue, 02 Jul 2002 18:45:32 PDT." <5.1.1.2.2.20020702183611.0354a798@jay.songbird.com> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face-Viewer: See ftp://cs.indiana.edu/pub/faces/index.html to decode picture X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ (Your message of "Tue, 02 Jul 2002 19:45:19 EDT.") <5.1.1.2.2.20020702183611.0354a798@jay.songbird.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-233041992P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 02 Jul 2002 23:55:12 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==_Exmh_-233041992P Content-Type: text/plain; charset=us-ascii On Tue, 02 Jul 2002 18:45:32 PDT, Dave Crocker said: > > however if pursuing this path it would still be necessary to > > leave room for VOICENEG or MIMENEG or whatever, > > If you would supply some sort of functional description for these, it might > be possible to understand how the current specifications fails to satisfy > them. I have no idea what you are intending, and therefore cannot even > guess at the deficiencies you are implying. I think that's Keith's POINT - that this has gotten to "Last Call" and there's no understanding on the part of the supporters what the "voice" or "mime" communities want, or whether this can/should be extended to address their concerns as well. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_-233041992P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE9InWgcC3lWbTT17ARAuMmAJ0Q9SX00ROO0GJx3YmyzfkPtTP9GQCfRKVw o7KXQgfm4JusjaJRREEo/p0= =KI/C -----END PGP SIGNATURE----- --==_Exmh_-233041992P-- From owner-ietf-fax@mail.imc.org Wed Jul 3 01:09: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 BAA04981 for ; Wed, 3 Jul 2002 01:09:51 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g634uW209241 for ietf-fax-bks; Tue, 2 Jul 2002 21:56:32 -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 g634uVw09237 for ; Tue, 2 Jul 2002 21:56:31 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KJMCBY0GRK001ZTY@mauve.mrochek.com> for ietf-fax@imc.org; Tue, 02 Jul 2002 21:56:34 -0700 (PDT) Date: Tue, 02 Jul 2002 21:21:58 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: "Your message dated Tue, 02 Jul 2002 23:24:34 -0400" <200207030324.g633OY201036@astro.cs.utk.edu> To: Keith Moore Cc: ned.freed@mrochek.com, John C Klensin , Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Message-id: <01KJMUXOR5MO001ZTY@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <01KJMM5WZSX8001ZTY@mauve.mrochek.com> <200207030324.g633OY201036@astro.cs.utk.edu> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > > But there's a serious side effect: Advance capability retrieval tends to stall > > the pipeline. And while it is natural to view SMTP as a series of commands and > > responses, the way modern SMTP clients and servers need to work to be efficient > > is by sending batches of commands and getting back batches of responses. > > The naive implementation of capabilities exchange in a separate command then > > becomes the worst case scenario: If you send a VRFY (or RCAP) prior to sending > > each RCPT TO you end up with at least one round trip per recipient. > I don't understand which argument you're making - is it that the naive > implementation is slow, or that it's too hard to do an efficient > pipelining implementation? Both: The naive implementation has latency problems while the efficient pipelining implementation is more complex than it needs to be. > as long as RCAP doesn't force any new decision points for the client, > I don't see why the efficient pipelining implementation is any more > difficult for the RCAP case than the RCPT/RSET case. Then I suggest you haven't actually looked closely at how you'd actually code this. Two responses for each recipient lead to a bunch of corner cases that have to be dealt with. > if RCPT is overloaded then the client sends multiple RCPTs, waits for > all of the responses, then decides whether to just send one copy or > do RSET/MAIL/etc and send multiple copies. > if there's a separate command then the client sends multiple RCAPs, > and one RCPT, waits for all of the responses, and then decides > whether the version that's right for the first recipient is also > appropriate for other recipients. > seems like the implementation complexity is about the same in either case. Sigh. This is pretty much a strawman argument, but rather than get into that let me simply repeat my earlier conclusion: I believe that if support for sending more than one variant of the same message is likely then a separate command makes sense. If, on the other hand, this is the very uncommon case, then RCPT TO piggybacking is much simpler and a separate command doesn't make sense. Do you really wish to claim otherwise? > but it's hard to see how the client can avoid implementing some > kind of logic to convert differently for different recipients, since > there's clearly the potential for the recipients' conneg strings to > have no format in common. perhaps if the client can only do one > or two different kinds of conversion (otherwise it has to bounce) > then the decision becomes a bit easier, but this again looks more > like a fax-specific facility than a general one. On the contrary, I suspect that this issue can and will be avoided. John phrased it well: Select the least common demoninator that's above a certain threshhold. That sounds like the right implementation strategy to me. Ned From owner-ietf-fax@mail.imc.org Wed Jul 3 01:41:05 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 BAA05663 for ; Wed, 3 Jul 2002 01:41:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g635QkX10578 for ietf-fax-bks; Tue, 2 Jul 2002 22:26:46 -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 g635Qjw10573 for ; Tue, 2 Jul 2002 22:26:45 -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 g635Qf201876; Wed, 3 Jul 2002 01:26:41 -0400 (EDT) Message-Id: <200207030526.g635Qf201876@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: ned.freed@mrochek.com cc: Keith Moore , John C Klensin , Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Tue, 02 Jul 2002 21:21:58 PDT.") <01KJMUXOR5MO001ZTY@mauve.mrochek.com> Date: Wed, 03 Jul 2002 01:26:41 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > I don't understand which argument you're making - is it that the naive > > implementation is slow, or that it's too hard to do an efficient > > pipelining implementation? > > Both: The naive implementation has latency problems while the efficient > pipelining implementation is more complex than it needs to be. okay, I'll certainly grant that the naive implementation has worse latency if you use extra commands. though it seems like if you're going to have the complexity of parsing conneg strings and doing format translation, the additional complexity of pipelining doesn't make it much worse. as for the pipelining, to me the complexity seems about the same either way, but with overloading of RCPT response codes then you're asking the server to declare failure modes that really need to be detected by the client, and having the server report the error doesn't seem to simplify the client logic at all. nor have I managed to find a use case for treating no conneg string as a fatal error, though I don't claim to have exhaustively analyzed all possibilities yet. > > as long as RCAP doesn't force any new decision points for the client, > > I don't see why the efficient pipelining implementation is any more > > difficult for the RCAP case than the RCPT/RSET case. > > Then I suggest you haven't actually looked closely at how you'd actually code > this. Two responses for each recipient lead to a bunch of corner cases that > have to be dealt with. no, I haven't tried to code it in detail yet. but it doesn't seem like rocket science to map a cross product of the 3 or 4 existing RCPT responses that clients need to distinguish, and the 3 or so conditions for RCAP (here is the string, there is no string, tempfail) onto a small number of cases. and the client pretty much has to do that anyway, because there can be failures due to inability to convert even if all RCAPs return a conneg string. > > if RCPT is overloaded then the client sends multiple RCPTs, waits for > > all of the responses, then decides whether to just send one copy or > > do RSET/MAIL/etc and send multiple copies. > > > if there's a separate command then the client sends multiple RCAPs, > > and one RCPT, waits for all of the responses, and then decides > > whether the version that's right for the first recipient is also > > appropriate for other recipients. > > > seems like the implementation complexity is about the same in either case. > > Sigh. This is pretty much a strawman argument, but rather than get into that > let me simply repeat my earlier conclusion: I believe that if support for > sending more than one variant of the same message is likely then a separate > command makes sense. If, on the other hand, this is the very uncommon case, > then RCPT TO piggybacking is much simpler and a separate command doesn't make > sense. > > Do you really wish to claim otherwise? Hmm. If I'm trying to compare protocol and implementation complexity then I care about the amount of code that's required to accomodate all cases even if many of those cases aren't used very often. If I'm thinking about protocol efficiency then I care more about the commonly occuring cases. as for what is a commonly occuring case, I get a different answer depending on whether I think of this as a fax-specific mechanism or a general purpose SMTP mechanism. if it's only fax specific then I suspect the common case is for most messages to have only one recipient, so if the rare multi-recipient message takes a slow path that might not be so bad. if the mechanism is more general purpose then I suspect multi-recipient messages (and widely-varying capabilities) will be much more common and it will be more desirable to avoid sending a separate copy of each message, and this in turn makes reasonable implementations (of either proposal) more complex. The other concern I have is something like "protocol architecture" - will this extension mess up the protocol in such a way that it creates silly states or makes it more difficult to add other kinds of extensions? what I'm discovering is that I'm much more concerned about overloading the RCPT reply/status code rsponses (using them to mean two different) things than I am about piggybacking a conneg string onto the RCPT response. if the conneg response didn't affect the reply and status codes, and if other extensions could also piggyback additional data onto the RCPT response, then I don't think that the fact that additional information is being requested along with RCPT would bother me. the thing that bothers me is that RCPT error codes are being used to signal a case that really has nothing to do with the recipient's ability to receive a message. >t > > but it's hard to see how the client can avoid implementing some > > kind of logic to convert differently for different recipients, since > > there's clearly the potential for the recipients' conneg strings to > > have no format in common. perhaps if the client can only do one > > or two different kinds of conversion (otherwise it has to bounce) > > then the decision becomes a bit easier, but this again looks more > > like a fax-specific facility than a general one. > > On the contrary, I suspect that this issue can and will be avoided. John > phrased it well: Select the least common demoninator that's above a certain > threshhold. That sounds like the right implementation strategy to me. that assumes that there is a LCD, which is not true in general. (though it might be true for a fax-only extension.) and unless the set of permissable content-types is severely restricted, how can the client know what is a reasonable threshhold? Keith From owner-ietf-fax@mail.imc.org Wed Jul 3 02:18: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 CAA18728 for ; Wed, 3 Jul 2002 02:18:40 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6364HM12653 for ietf-fax-bks; Tue, 2 Jul 2002 23:04:17 -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 g6364Fw12634 for ; Tue, 2 Jul 2002 23:04:15 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KJMCBY0GRK001ZTY@mauve.mrochek.com> for ietf-fax@imc.org; Tue, 02 Jul 2002 23:04:18 -0700 (PDT) Date: Tue, 02 Jul 2002 21:57:41 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: "Your message dated Tue, 02 Jul 2002 23:45:41 -0400" <122335932.1025653541@localhost> To: John C Klensin Cc: ned.freed@mrochek.com, Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Message-id: <01KJMXAOJA04001ZTY@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <15649.62973.894081.566925@monkeyboy.gshapiro.net> <3D221C44.5F99DED6@messagingdirect.com> <108177848.1025639386@localhost> <01KJMM5WZSX8001ZTY@mauve.mrochek.com> <122335932.1025653541@localhost> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > Is this complex? Sure it is. But, if one is going to end up > with least common denominator, the limiting (and probably > common) case is to just send that and forget about capabilities > negotiation. Or, if the number of useful differentiated formats > is _very_ small, just sending both with multipart/alternative > might turn out to be easier and cheaper than messing around > trying to find feature intersections. There isn't nearly enough > information in the spec for me to be able to guess if that would > be the case. There shouldn't be if this is a general purpose, > multiple-recipient, capabilities negotiation mechanism but, if > it is, I don't see much hope other than dealing with the > complexity (or deciding we don't need something that general). I guess I remain to be convinced either way: That multiple versions schemes are necessary or that a single version schemes are sufficient. I'd guess there's a sweet spot somewhere in there. Unfortunately in this particular case the location of that spot drives a bunch of design choices. > > I think the determining factor needs to be how clients will > > actually handle recipients with differing capabilities. If the > > least common denominator is going to be the dominant approach > > (and I suspect that it will be) then RCPT TO capabilities > > return is the simplest and most direct approach. If, on the > > other hand, messages tailored for a each recipient is going to > > be the norm, then VRFY is the correct approach. > Ignoring all of the relay issues, which I still don't think the > document addresses, I must say I don't see any of this as particularly useful in a relay scenario. > and the fallback to fax while claiming it > isn't fax-specific, etc., I'd partition the above a bit > differently. I'd guess the dominant approach (especially if one > generalizes beyond fax) is going to be greatest (most capable) > common denominator above a threshold. I.e., if there is some > minimal, default, capability, and some recipients can support > only that (e.g., they don't handle option negotiation at all), > then two messages are going to be sent: one corresponding to the > common feature set of the more capable recipients and one for > the minimal/default feature set. Everyone gets downgraded to > the minimum/default because one recipient isn't highly capable > just doesn't feel commercially viable to me, while assuming a > mix of high-function and low-function hosts does. I certainly agree with the common denominator above a threshhold. But given that a single recipient per destination is likely to be a very common case, I'm less sure that simpler approaches won't be commercially viable. Or perhaps capabilities will be used to reduce the number of variants sent with multipart/alternative. > Other > combinations are possible, but my sense of reality says they > would rapidly turn into message-copy-per-recipient rather than > strange combinatorics on feature sets. It may indeed turn out that per-recipient message copy is the right way to finesse the feature set combination issues. > But, in that "two message" case, one really doesn't want 5yz > codes coming back from the server in response to a RCPT TO. If > the "one digit" rule is observed, there is no way to > differentiate between "bad mailbox" and "bad parameter". If it > is not, and three digits are processed, the server cannot > effectively differentiate between a bad parameter to CONNEG and > one to some other option by the code -- the reply string has to > be parsed, and that leads to bad trouble. So I would think > that a batch of capability-determining commands before the first > RCPT one would be a better idea, complexity notwithstanding. I'm not sure I get what you're driving at here. The client gets to choose whether the server treats a recipient with unknown capabilities as an error or simply by indicating as much. > Again, the way to get most of the complexity out of this, IMO, > is to change the problem. For example, if the server makes the > determination of the common capability set among all recipients > and returns it only once (a bit tricky with the SMTP model, but > not impossible), then the client doesn't have to figure out how > to intersect whatever comes back, break things up into separate > messages, etc. But I don't know if that would do the job; it > certainly doesn't handle a mix of high- and low-function > recipients in a plausible way. I considered proposing this as well, but it seemed to be that knowledge of what the client can actually do may determine how differing feature sets are combined. Ned From owner-ietf-fax@mail.imc.org Wed Jul 3 02:46:29 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 CAA29847 for ; Wed, 3 Jul 2002 02:46:29 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g636WYc18456 for ietf-fax-bks; Tue, 2 Jul 2002 23:32:34 -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 g636WWw18451 for ; Tue, 2 Jul 2002 23:32:33 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KJMCBY0GRK001ZTY@mauve.mrochek.com> for ietf-fax@imc.org; Tue, 02 Jul 2002 23:32:30 -0700 (PDT) Date: Tue, 02 Jul 2002 23:09:19 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: "Your message dated Wed, 03 Jul 2002 01:26:41 -0400" <200207030526.g635Qf201876@astro.cs.utk.edu> To: Keith Moore Cc: ned.freed@mrochek.com, Keith Moore , John C Klensin , Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Message-id: <01KJMYAMO1RS001ZTY@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <01KJMUXOR5MO001ZTY@mauve.mrochek.com> <200207030526.g635Qf201876@astro.cs.utk.edu> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > nor have I managed to find a use case for treating no conneg > string as a fatal error, though I don't claim to have exhaustively > analyzed all possibilities yet. The obvious case would be one where interoperability between sender and recipient has to be guaranteed. Whether this is a case we should care about is another matter. I note in passing that the original proposal required treating the lack of a conneg string as a fatal error. I saw far more utility in allowing the case of no conneg string to be allowed without an error. > > Sigh. This is pretty much a strawman argument, but rather than get into that > > let me simply repeat my earlier conclusion: I believe that if support for > > sending more than one variant of the same message is likely then a separate > > command makes sense. If, on the other hand, this is the very uncommon case, > > then RCPT TO piggybacking is much simpler and a separate command doesn't make > > sense. > > > > Do you really wish to claim otherwise? > Hmm. If I'm trying to compare protocol and implementation complexity then > I care about the amount of code that's required to accomodate all cases even > if many of those cases aren't used very often. If I'm thinking about protocol > efficiency then I care more about the commonly occuring cases. > as for what is a commonly occuring case, I get a different answer depending > on whether I think of this as a fax-specific mechanism or a general purpose > SMTP mechanism. if it's only fax specific then I suspect the common case > is for most messages to have only one recipient, so if the rare multi-recipient > message takes a slow path that might not be so bad. if the mechanism is > more general purpose then I suspect multi-recipient messages (and widely-varying > capabilities) will be much more common and it will be more desirable to > avoid sending a separate copy of each message, and this in turn makes > reasonable implementations (of either proposal) more complex. I'm less sanguine about making this assessment a FAX-vs-other-uses thing, but the bottom line is that I think we're pretty much in agreement here. > what I'm discovering is that I'm much more concerned about overloading > the RCPT reply/status code rsponses (using them to mean two different) > things than I am about piggybacking a conneg string onto the RCPT > response. if the conneg response didn't affect the reply and status > codes, and if other extensions could also piggyback additional data > onto the RCPT response, then I don't think that the fact that additional > information is being requested along with RCPT would bother me. the > thing that bothers me is that RCPT error codes are being used to signal a > case that really has nothing to do with the recipient's ability to > receive a message. Well, it is certainly possible to arrange the additional conneg data so it is identifiable as such. As for not affecting the response, I'm not sure I see the problem: If the client wants an interop guarantee, it requires a conneg response, and handles 4yz and 5yz codes as temporary or permanent failures without regard to what's causing the error. If, on the other hand, it wants conneg info as long as its available, it makes a conneg response optional, in which case the status codes no longer have anyhing to do with conneg information. > > > but it's hard to see how the client can avoid implementing some > > > kind of logic to convert differently for different recipients, since > > > there's clearly the potential for the recipients' conneg strings to > > > have no format in common. perhaps if the client can only do one > > > or two different kinds of conversion (otherwise it has to bounce) > > > then the decision becomes a bit easier, but this again looks more > > > like a fax-specific facility than a general one. > > On the contrary, I suspect that this issue can and will be avoided. John > > phrased it well: Select the least common demoninator that's above a certain > > threshhold. That sounds like the right implementation strategy to me. > that assumes that there is a LCD, which is not true in general. > (though it might be true for a fax-only extension.) > and unless the set of permissable content-types is severely restricted, > how can the client know what is a reasonable threshhold? Such thresholds are driven by the client's own capabilities, not on the capabilities of the recipient. Ned From owner-ietf-fax@mail.imc.org Wed Jul 3 03:15: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 DAA00403 for ; Wed, 3 Jul 2002 03:15:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6372Bi19706 for ietf-fax-bks; Wed, 3 Jul 2002 00:02:11 -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 g63729w19702 for ; Wed, 3 Jul 2002 00:02:09 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KJMCBY0GRK001ZTY@mauve.mrochek.com> for ietf-fax@imc.org; Wed, 03 Jul 2002 00:02:08 -0700 (PDT) Date: Tue, 02 Jul 2002 23:43:22 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: "Your message dated Wed, 03 Jul 2002 13:27:02 +0700" <3076.1025677622@munnari.OZ.AU> To: Robert Elz Cc: Dave Crocker , Keith Moore , ned.freed@mrochek.com, John C Klensin , Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Message-id: <01KJMZBD7UTS001ZTY@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <5.1.1.2.2.20020702193306.03284c00@jay.songbird.com> <" <5.1.1.2.2.20020702180721.03a95930"@jay.songbird.com> <3076.1025677622@munnari.OZ.AU> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > First, let me say that I haven't read the draft, and don't intend to. > So, if you want to ignore my comments (questions really) feel free. Fascinating. Although your detailed understanding of how this works is fairly far off the mark, you nevertheless have suggested a viable approach that I, at least, hadn't considered. > But from what I have picked up from the (smallish) number of messages > from an even smaller set of people (no great surprise, fax is dead > technology, who cares???) on the ietf list in the past day or so, I > surmise that this protocol work something like the following. At least part of the problem is that the potential use of this stuff extend far past FAX. > It sounds as if what is being proposed is that the SMTP client > sends > RCPT TO:
"I want 1200 dpi" It is more like "RCPT TO:
"tell me what address can handle:" > Then the SMTP server says > 250 OK More like: "250 address can handle 1200 dpi". > ... > If this is how it works, I don't understand why people are talking about > doing RSET? Surely the protocol isn't built in a way where the server > says "no" to a request, and yet still includes the address in its list > of recipients. it can say "recipient accepted but capabilities are unknown" > Keith's operational plan can be done by sending RCPT TO (where he would > send RCAP) and terminating the sequence with RSET. This way the RCPT > TO acts just as the RCAP would act in his model (as I understand it). > Sure, it isn't as clean by any means, and makes the server do a little > extra work, as it doesn't know the RCPT TO's aren't real ones when it > receives them, but as a trade off, it seems OK. Ah. Using the first round of RCPT TOs as capabilities checks only and sending the RSET unconditionally is really quite cute. It still has the added complexity of having multiple commands per recipient, but now it is the same command repeated, which eliminates a bunch of the edge conditions and makes the silly states very silly indeed. > Others who prefer just to send and see what arrives, just do that, and > it all works the way they expect, with down grading, so the data only > ever needs to be sent once, or with separation of capabilities in the > cases (I am guessing this probably doesn't happen often, and most times > a server will offer the same capabilities to all addresses it can handle?) I suspect there will be cases where the capabilities will be the same and others where they are quite different. Ned From owner-ietf-fax@mail.imc.org Wed Jul 3 10:09:08 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 KAA15180 for ; Wed, 3 Jul 2002 10:09:08 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g63DqJp18727 for ietf-fax-bks; Wed, 3 Jul 2002 06:52:19 -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 g63DqIw18723 for ; Wed, 3 Jul 2002 06:52:18 -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 g63Dq9229881; Wed, 3 Jul 2002 09:52:09 -0400 (EDT) Message-Id: <200207031352.g63Dq9229881@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: ned.freed@mrochek.com cc: Keith Moore , John C Klensin , Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Tue, 02 Jul 2002 23:09:19 PDT.") <01KJMYAMO1RS001ZTY@mauve.mrochek.com> Date: Wed, 03 Jul 2002 09:52:09 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Well, it is certainly possible to arrange the additional conneg data so it is > identifiable as such. As for not affecting the response, I'm not sure I see the > problem: If the client wants an interop guarantee, it requires a conneg > response, and handles 4yz and 5yz codes as temporary or permanent failures > without regard to what's causing the error. I guess I don't see how this helps the client much, because you can get interop failures even when there is a conneg string for each recipient. So it seems that the proposal could be usefully simplified by removing the OPTIONAL vs REQUIRED flag from the CONNEG parameter, and having the server report back the CONNEG status (yes, no, or tempfail) as part of the response rather than in the reply/status codes. If the client wants an interop guarantee (how does the sender specify this?) then it can reat the absence of the CONNEG string in the response, or the absence of CONNEG in the EHLO response, as a failure. This should really be a client-generated error anyway since there's really no error on the server side. I think this would be a significant improvement - particularly if this extension isn't generalized to support things other than fax and it then becomes necessary to add another extension later for voice mail or whatever. Keith From owner-ietf-fax@mail.imc.org Wed Jul 3 10:15:49 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 KAA16163 for ; Wed, 3 Jul 2002 10:15:48 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g63E1CQ18946 for ietf-fax-bks; Wed, 3 Jul 2002 07:01:12 -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 g63E1Bw18942 for ; Wed, 3 Jul 2002 07:01:11 -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 g63Dtx200588; Wed, 3 Jul 2002 09:55:59 -0400 (EDT) Message-Id: <200207031355.g63Dtx200588@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: ned.freed@mrochek.com cc: Robert Elz , Dave Crocker , Keith Moore , John C Klensin , Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Tue, 02 Jul 2002 23:43:22 PDT.") <01KJMZBD7UTS001ZTY@mauve.mrochek.com> Date: Wed, 03 Jul 2002 09:55:59 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Ah. Using the first round of RCPT TOs as capabilities checks only and sending > the RSET unconditionally is really quite cute. "cute" is rather opposite of the four-letter word I would have chosen. > It still has the added > complexity of having multiple commands per recipient, but now it is the same > command repeated, which eliminates a bunch of the edge conditions and makes the > silly states very silly indeed. well, I'll admit I'm curious - how does using the same command in two different ways eliminate a bunch of edge conditions? (if we had only one command in SMTP and used it over and over would that eliminate even more edge conditions?) really, I don't have a guess as to what you're talking about here, and I am curious. Keith From owner-ietf-fax@mail.imc.org Wed Jul 3 14:11:51 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 OAA25100 for ; Wed, 3 Jul 2002 14:11:51 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g63GdGx27761 for ietf-fax-bks; Wed, 3 Jul 2002 09:39:16 -0700 (PDT) Received: from jsc-ems-vws04.jsc.nasa.gov (jsc-ems-vws04.jsc.nasa.gov [139.169.39.51]) by above.proper.com (8.11.6/8.11.3) with SMTP id g63GdFw27756 for ; Wed, 3 Jul 2002 09:39:15 -0700 (PDT) Received: from 139.169.16.60 by jsc-ems-vws04.jsc.nasa.gov (InterScan E-Mail VirusWall NT); Wed, 03 Jul 2002 11:39:13 -0500 (Central Daylight Time) Received: by jsc-smtp02.jsc.nasa.gov with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 11:39:13 -0500 Message-ID: <1408A865DCF403478A33EE887F87473201C13B4C@jsc-mail03.jsc.nasa.gov> From: "COLES, RICHARD J. (JSC-EV) (LM)" To: "'ned.freed@mrochek.com'" Cc: ietf-fax@imc.org, ietf@ietf.org Subject: RE: Last Call: SMTP Service Extension for Content Negotiation toP roposed Standard Date: Wed, 3 Jul 2002 11:39:12 -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: Sorry for the misquote. Sometimes it's hard to tell who said what in these multi-response messages. Even editing the msg does not always help. I just wanted to be sure that everyone knew how important FAX is to NASA (and, I suppose, to other agencies of the Federal government). Tnx/RJC -----Original Message----- From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com] Sent: Wednesday, July 03, 2002 11:24 AM To: COLES, RICHARD J. (JSC-EV) (LM) Cc: ietf-fax@imc.org; ietf@ietf.org Subject: RE: Last Call: SMTP Service Extension for Content Negotiation toProposed Standard > Ned "sed": > > ...fax is dead technology, who cares??? > FAX is NOT dead at NASA. Actually, I never said anything of the kind, nor did I agree with any such statement. Robert Elz said this. My response was merely that even if you believe this is true the current proposal may still be of importance since it has utility outside of the FAX space. Ned From owner-ietf-fax@mail.imc.org Wed Jul 3 14:11:56 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 OAA25115 for ; Wed, 3 Jul 2002 14:11:55 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g63GlUX28247 for ietf-fax-bks; Wed, 3 Jul 2002 09:47:30 -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 g63GlTw28239 for ; Wed, 3 Jul 2002 09:47:29 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KJMCBY0GRK001ZTY@mauve.mrochek.com> for ietf-fax@imc.org; Wed, 03 Jul 2002 09:47:28 -0700 (PDT) Date: Wed, 03 Jul 2002 09:40:06 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: "Your message dated Wed, 03 Jul 2002 09:55:59 -0400" <200207031355.g63Dtx200588@astro.cs.utk.edu> To: Keith Moore Cc: ned.freed@mrochek.com, Robert Elz , Dave Crocker , Keith Moore , John C Klensin , Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Message-id: <01KJNJR3CIT0001ZTY@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <01KJMZBD7UTS001ZTY@mauve.mrochek.com> <200207031355.g63Dtx200588@astro.cs.utk.edu> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > > Ah. Using the first round of RCPT TOs as capabilities checks only and sending > > the RSET unconditionally is really quite cute. > "cute" is rather opposite of the four-letter word I would have chosen. > > It still has the added > > complexity of having multiple commands per recipient, but now it is the same > > command repeated, which eliminates a bunch of the edge conditions and makes the > > silly states very silly indeed. > well, I'll admit I'm curious - how does using the same command in two different > ways eliminate a bunch of edge conditions? (if we had only one command in SMTP > and used it over and over would that eliminate even more edge conditions?) The edge conditions arise when the responses from the different commands disagree in some way. And this is likely to happen when there are two commands and two different code paths. The usual outcome then is that things which shouldn't make a difference do make a difference, and that then leads to the time honored whine of "but it works when I do it over there so this stuff here must be broken". > really, I don't have a guess as to what you're talking about here, and I am > curious. Apparently you managed to miss the round of SMTP clients that did a VRFY prior to each RCPT TO. Horrible mess, just horrible. Ned From owner-ietf-fax@mail.imc.org Wed Jul 3 14:11:58 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 OAA25127 for ; Wed, 3 Jul 2002 14:11:57 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g63HACx29299 for ietf-fax-bks; Wed, 3 Jul 2002 10:10:12 -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 g63HABw29295 for ; Wed, 3 Jul 2002 10:10:11 -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 g63H2P227285; Wed, 3 Jul 2002 13:02:25 -0400 (EDT) Message-Id: <200207031702.g63H2P227285@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: ned.freed@mrochek.com cc: Keith Moore , Robert Elz , Dave Crocker , John C Klensin , Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Wed, 03 Jul 2002 09:40:06 PDT.") <01KJNJR3CIT0001ZTY@mauve.mrochek.com> Date: Wed, 03 Jul 2002 13:02:24 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > > Ah. Using the first round of RCPT TOs as capabilities checks only and sending > > > the RSET unconditionally is really quite cute. > > > "cute" is rather opposite of the four-letter word I would have chosen. > > > > It still has the added > > > complexity of having multiple commands per recipient, but now it is the same > > > command repeated, which eliminates a bunch of the edge conditions and makes the > > > silly states very silly indeed. > > > well, I'll admit I'm curious - how does using the same command in two different > > ways eliminate a bunch of edge conditions? (if we had only one command in SMTP > > and used it over and over would that eliminate even more edge conditions?) > > The edge conditions arise when the responses from the different commands > disagree in some way. And this is likely to happen when there are two commands > and two different code paths. The usual outcome then is that things which > shouldn't make a difference do make a difference, and that then leads to the > time honored whine of "but it works when I do it over there so this stuff here > must be broken". ah. well it was sort of obvious to me that RCAP responses should be defined to provide no indication whatsoever as to whether the recipient is valid, so you couldn't get a conflict between a RCPT indication and an RCAP indication. on the other hand either command could return a value that would prevent delivery of the message - RCPT could return 5xx and RCAP could return "this recipient supports no content types you've ever heard of", and either one could cause a temporary failure of message delivery. I don't consider that a silly state - it's a natural consequence of being able to specify what content types you're willing to accept. however I really don't have a problem with an option to RCPT to return UA capabilities as long as it is an extensible mechanism (other options could return other information and could be asserted at the same time as CONNEG) and as long as it doesn't affect the response and status codes. Keith From owner-ietf-fax@mail.imc.org Wed Jul 3 14:11:58 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 OAA25133 for ; Wed, 3 Jul 2002 14:11:58 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g63GbqW27609 for ietf-fax-bks; Wed, 3 Jul 2002 09:37:52 -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 g63Gbow27603 for ; Wed, 3 Jul 2002 09:37:50 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KJMCBY0GRK001ZTY@mauve.mrochek.com> for ietf-fax@imc.org; Wed, 03 Jul 2002 09:37:50 -0700 (PDT) Date: Wed, 03 Jul 2002 09:31:50 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: "Your message dated Wed, 03 Jul 2002 09:52:09 -0400" <200207031352.g63Dq9229881@astro.cs.utk.edu> To: Keith Moore Cc: ned.freed@mrochek.com, Keith Moore , John C Klensin , Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Message-id: <01KJNJF5CAEK001ZTY@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <01KJMYAMO1RS001ZTY@mauve.mrochek.com> <200207031352.g63Dq9229881@astro.cs.utk.edu> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > > Well, it is certainly possible to arrange the additional conneg data so it is > > identifiable as such. As for not affecting the response, I'm not sure I see the > > problem: If the client wants an interop guarantee, it requires a conneg > > response, and handles 4yz and 5yz codes as temporary or permanent failures > > without regard to what's causing the error. > I guess I don't see how this helps the client much, because you can get > interop failures even when there is a conneg string for each recipient. It helps the client because it can now distinguish between temporary and permanent conneg failures. > So it seems that the proposal could be usefully simplified by removing the > OPTIONAL vs REQUIRED flag from the CONNEG parameter, and having the server > report back the CONNEG status (yes, no, or tempfail) as part of the > response rather than in the reply/status codes. That would also work, but I don't think it is a useful simplification because it creates even more instances where the command succeeded but the client needed for it to fail. The server side of this is trivial either way. > If the client wants an interop guarantee (how does the sender specify this?) > then it can reat the absence of the CONNEG string in the response, or the > absence of CONNEG in the EHLO response, as a failure. This should really > be a client-generated error anyway since there's really no error on the server > side. > I think this would be a significant improvement - particularly if this extension > isn't generalized to support things other than fax and it then becomes necessary > to add another extension later for voice mail or whatever. I don't think you have sufficiently demontrated the problematic nature of REQUIRED to claim this is a significant improvement. However, absent a convincing argument that such interop guarantees would actually be used, I personally don't have a problem with making this simplification. Ned From owner-ietf-fax@mail.imc.org Wed Jul 3 14:11:59 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 OAA25145 for ; Wed, 3 Jul 2002 14:11:59 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g63GwfV28930 for ietf-fax-bks; Wed, 3 Jul 2002 09:58:41 -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 g63Gwdw28926 for ; Wed, 3 Jul 2002 09:58:39 -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 g63Gu2226331; Wed, 3 Jul 2002 12:56:02 -0400 (EDT) Message-Id: <200207031656.g63Gu2226331@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: ned.freed@mrochek.com cc: Keith Moore , John C Klensin , Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Wed, 03 Jul 2002 09:31:50 PDT.") <01KJNJF5CAEK001ZTY@mauve.mrochek.com> Date: Wed, 03 Jul 2002 12:56:02 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > > Well, it is certainly possible to arrange the additional conneg data so it is > > > identifiable as such. As for not affecting the response, I'm not sure I see the > > > problem: If the client wants an interop guarantee, it requires a conneg > > > response, and handles 4yz and 5yz codes as temporary or permanent failures > > > without regard to what's causing the error. > > > I guess I don't see how this helps the client much, because you can get > > interop failures even when there is a conneg string for each recipient. > > It helps the client because it can now distinguish between temporary and > permanent conneg failures. granted it's necessary for the client to be able to do that, but my point is that having the server report conneg faliures in the RCPT status code doesn't relieve the client of the necessity to detect other conditions resulting from valid conneg strings that can cause delivery failure. it's not as if the client can rely only on the response code to determine how to handle the message. > > So it seems that the proposal could be usefully simplified by removing the > > OPTIONAL vs REQUIRED flag from the CONNEG parameter, and having the server > > report back the CONNEG status (yes, no, or tempfail) as part of the > > response rather than in the reply/status codes. > > That would also work, but I don't think it is a useful simplification because > it creates even more instances where the command succeeded but the client > needed for it to fail. The server side of this is trivial either way. what it accomplishes is to clearly separate different potential sources of failure into different indications. a RCPT status codes indicating failure would mean that the server has a problem with sending the message to the recipient, as distinct from failures caused by the client's inability or unwillingness to deliver the message to the recipient based on the server's conneg report for that recipient. right now we have the situation where the server is essentially being asked to report an error (and an error code) which is really happening on the client. the server doesn't know the reason that the client doesn't want to deliver the message to the recipient, and it shouldn't be expected to report the error (or the enhanced status code) in the absence of such knowledge. that, and once we've established that it's okay to use RCPT to request information about the recipient's UA capabliities and preferences, it's hard to imagine that there won't be a demand to use RCPT to request other information about the recipient's UA or preferences, such as whether the recipient will honor MDN requests, what languages the recipient can read, whether the recipient wants to opt-out of spam, whether the recipient supports vendor-proprietary extension FOO, etc. (I didn't say that I liked all of these ideas, just that these are obvious uses of a facility that lets you query UA capabilities. OTOH I do like some of them.) and if we go down that path we might really regret having allowed CONNEG to alter the RCPT reply code. Keith From owner-ietf-fax@mail.imc.org Wed Jul 3 14:12:00 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 OAA25158 for ; Wed, 3 Jul 2002 14:11:59 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g63HN4929970 for ietf-fax-bks; Wed, 3 Jul 2002 10:23:04 -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 g63HN2w29966 for ; Wed, 3 Jul 2002 10:23:02 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KJMCBY0GRK001ZTY@mauve.mrochek.com> for ietf-fax@imc.org; Wed, 03 Jul 2002 10:23:02 -0700 (PDT) Date: Wed, 03 Jul 2002 10:12:06 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: "Your message dated Wed, 03 Jul 2002 12:56:02 -0400" <200207031656.g63Gu2226331@astro.cs.utk.edu> To: Keith Moore Cc: ned.freed@mrochek.com, Keith Moore , John C Klensin , Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Message-id: <01KJNL06HJR0001ZTY@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <01KJNJF5CAEK001ZTY@mauve.mrochek.com> <200207031656.g63Gu2226331@astro.cs.utk.edu> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > > > > Well, it is certainly possible to arrange the additional conneg data so it is > > > > identifiable as such. As for not affecting the response, I'm not sure I see the > > > > problem: If the client wants an interop guarantee, it requires a conneg > > > > response, and handles 4yz and 5yz codes as temporary or permanent failures > > > > without regard to what's causing the error. > > > I guess I don't see how this helps the client much, because you can get > > > interop failures even when there is a conneg string for each recipient. > > It helps the client because it can now distinguish between temporary and > > permanent conneg failures. > granted it's necessary for the client to be able to do that, but my point > is that having the server report conneg faliures in the RCPT status code > doesn't relieve the client of the necessity to detect other conditions > resulting from valid conneg strings that can cause delivery failure. > it's not as if the client can rely only on the response code to determine > how to handle the message. Sure, but it is only useful to treat such failures as permanent. > > > So it seems that the proposal could be usefully simplified by removing the > > > OPTIONAL vs REQUIRED flag from the CONNEG parameter, and having the server > > > report back the CONNEG status (yes, no, or tempfail) as part of the > > > response rather than in the reply/status codes. > > That would also work, but I don't think it is a useful simplification because > > it creates even more instances where the command succeeded but the client > > needed for it to fail. The server side of this is trivial either way. > what it accomplishes is to clearly separate different potential sources of > failure into different indications. a RCPT status codes indicating failure > would mean that the server has a problem with sending the message to the > recipient, as distinct from failures caused by the client's inability > or unwillingness to deliver the message to the recipient based on the > server's conneg report for that recipient. I remain unconvinced that this is a useful distinction. What REQUIRED says is "I absolutely require CONNEG info and as such a failure to have it is the same to me as any other sort of failure and should be responded to accordingly". > right now we have the situation where the server is essentially being asked > to report an error (and an error code) which is really happening on the client. > the server doesn't know the reason that the client doesn't want to deliver > the message to the recipient, and it shouldn't be expected to report the > error (or the enhanced status code) in the absence of such knowledge. I guess this is a valid assessment, but somehow it doesn't offend me the way it offends you. > that, and once we've established that it's okay to use RCPT to request > information about the recipient's UA capabliities and preferences, > it's hard to imagine that there won't be a demand to use RCPT to request > other information about the recipient's UA or preferences, such as > whether the recipient will honor MDN requests, what languages the > recipient can read, whether the recipient wants to opt-out of spam, > whether the recipient supports vendor-proprietary extension FOO, etc. > (I didn't say that I liked all of these ideas, just that these are > obvious uses of a facility that lets you query UA capabilities. > OTOH I do like some of them.) Language preferences are, I believe, already defined as something you can get out of feature algebra. > and if we go down that path we might really regret having allowed CONNEG > to alter the RCPT reply code. Why? If the client doesn't want CONNEG to alter the status all it has to do is use OPTIONAL rather than REQUIRED. Again, REQUIRED implies that the client is willing to treat different sorts of failures in the same way. Again, I think a means of distinguishing conneg material in the response is a good idea and I'm not opposed to eliminating REQUIRED. But really don't believe REQUIRED causes the problems you think it does. Ned From owner-ietf-fax@mail.imc.org Wed Jul 3 14:12:01 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 OAA25174 for ; Wed, 3 Jul 2002 14:12:00 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g63GRMt26676 for ietf-fax-bks; Wed, 3 Jul 2002 09:27:22 -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 g63GRKw26672 for ; Wed, 3 Jul 2002 09:27:21 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KJMCBY0GRK001ZTY@mauve.mrochek.com> for ietf-fax@imc.org; Wed, 03 Jul 2002 09:27:21 -0700 (PDT) Date: Wed, 03 Jul 2002 09:24:04 -0700 (PDT) From: ned.freed@mrochek.com Subject: RE: Last Call: SMTP Service Extension for Content Negotiation toP roposed Standard In-reply-to: "Your message dated Wed, 03 Jul 2002 09:35:59 -0500" <1408A865DCF403478A33EE887F87473201C13B43@jsc-mail03.jsc.nasa.gov> To: "COLES, RICHARD J. (JSC-EV) (LM)" Cc: ietf-fax@imc.org, ietf@ietf.org Message-id: <01KJNJ24WZLQ001ZTY@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Content-transfer-encoding: 7BIT References: <1408A865DCF403478A33EE887F87473201C13B43@jsc-mail03.jsc.nasa.gov> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > Ned "sed": > > ...fax is dead technology, who cares??? > FAX is NOT dead at NASA. Actually, I never said anything of the kind, nor did I agree with any such statement. Robert Elz said this. My response was merely that even if you believe this is true the current proposal may still be of importance since it has utility outside of the FAX space. Ned From owner-ietf-fax@mail.imc.org Wed Jul 3 14:12:02 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 OAA25186 for ; Wed, 3 Jul 2002 14:12:01 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g63EaBU20517 for ietf-fax-bks; Wed, 3 Jul 2002 07:36:11 -0700 (PDT) Received: from jsc-ems-vws03.jsc.nasa.gov (jsc-ems-vws03.jsc.nasa.gov [139.169.39.50]) by above.proper.com (8.11.6/8.11.3) with SMTP id g63Ea9w20509 for ; Wed, 3 Jul 2002 07:36:09 -0700 (PDT) Received: from 139.169.16.59 by jsc-ems-vws03.jsc.nasa.gov (InterScan E-Mail VirusWall NT); Wed, 03 Jul 2002 09:36:00 -0500 (Central Daylight Time) Received: by jsc-smtp01.jsc.nasa.gov with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 09:36:00 -0500 Message-ID: <1408A865DCF403478A33EE887F87473201C13B43@jsc-mail03.jsc.nasa.gov> From: "COLES, RICHARD J. (JSC-EV) (LM)" To: ietf-fax@imc.org Cc: ietf@ietf.org Subject: RE: Last Call: SMTP Service Extension for Content Negotiation toP roposed Standard Date: Wed, 3 Jul 2002 09:35:59 -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: Ned "sed": > ...fax is dead technology, who cares??? FAX is NOT dead at NASA. We send a LOT of documents to other centers that cannot be sent via e-mail (photocopies of shipping documents, flight manifests, older engineering drawings, etc [things that are not available electronically]). That is why I am so interested in seeing this work completed. I just don't comment much because I don't have anything to say. I am learning this stuff as I go, and not very well [datacomm is not my strongest subject :) - I do video for Shuttle & Space Station, but I recognize a money saver when I see it] My main interest is that it will save NASA (therefore the taxpayers) LOTS of dollars in long distance charges. I would estimate around a million a year, but I have no data to back that up. I will try to get some data if anyone wants to see it (write me privately - if I get enough requests, I will post it, else I will send it privately). So, remember, while you are working on this, you are preparing the way for TAX savings (it's YOUR money). Does that encourage you to continue? And if you REALLY think that fax is dead, why are you working so hard to finish it?? (I know, because the IESG/IMC/etc says to...) Regards to all & a special "howdy" to Dan Wing/RJC Richard Coles Lockheed Martin, in support of NASA/Johnson Space Center/Houston rcoles@ems.jsc.nasa.gov (or as shown above) -----Original Message----- From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com] Sent: Wednesday, July 03, 2002 1:43 AM To: Robert Elz Cc: Dave Crocker; Keith Moore; ned.freed@mrochek.com; John C Klensin; Alexey Melnikov; ietf@ietf.org; ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation toProposed Standard > First, let me say that I haven't read the draft, and don't intend to. > So, if you want to ignore my comments (questions really) feel free. Fascinating. Although your detailed understanding of how this works is fairly far off the mark, you nevertheless have suggested a viable approach that I, at least, hadn't considered. > But from what I have picked up from the (smallish) number of messages > from an even smaller set of people (no great surprise, fax is dead > technology, who cares???) on the ietf list in the past day or so, I > surmise that this protocol work something like the following. < balance of text deleted for Net economy > From owner-ietf-fax@mail.imc.org Wed Jul 3 17:11:26 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 RAA06733 for ; Wed, 3 Jul 2002 17:11:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g63KPm913004 for ietf-fax-bks; Wed, 3 Jul 2002 13:25:48 -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 g63KPlw12996 for ; Wed, 3 Jul 2002 13:25:47 -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 g63KOW203066; Wed, 3 Jul 2002 16:24:32 -0400 (EDT) Message-Id: <200207032024.g63KOW203066@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: ned.freed@mrochek.com cc: Keith Moore , John C Klensin , Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Wed, 03 Jul 2002 10:12:06 PDT.") <01KJNL06HJR0001ZTY@mauve.mrochek.com> Date: Wed, 03 Jul 2002 16:24:32 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > granted it's necessary for the client to be able to do that, but my point > > is that having the server report conneg faliures in the RCPT status code > > doesn't relieve the client of the necessity to detect other conditions > > resulting from valid conneg strings that can cause delivery failure. > > it's not as if the client can rely only on the response code to determine > > how to handle the message. > > Sure, but it is only useful to treat such failures as permanent. how so? if there is a temporary failure to get conneg information, the client might quite reasonably decide to retry later. or if the client can't translate part of the message, it might reasonably decide that delivering the remainder of the message is preferable to bouncing it. > I remain unconvinced that this is a useful distinction. What REQUIRED says is > "I absolutely require CONNEG info and as such a failure to have it is the same > to me as any other sort of failure and should be responded to accordingly". it's still poor separation of function, and it's still asking the server to report a failure condition which the client understands better than the server does. E.g. the server is told to report errors as 4.3.3 or 5.3.3 when codes x.6.1 or x.6.2 or x.6.3 might be more appropriate. The server can't tell the difference between those conditions; the client can. > > right now we have the situation where the server is essentially being asked > > to report an error (and an error code) which is really happening on the client. > > the server doesn't know the reason that the client doesn't want to deliver > > the message to the recipient, and it shouldn't be expected to report the > > error (or the enhanced status code) in the absence of such knowledge. > > I guess this is a valid assessment, but somehow it doesn't offend me > the way it offends you. My offense is for the document taken as a whole, especially the lack of attention to non-fax applications. > > that, and once we've established that it's okay to use RCPT to request > > information about the recipient's UA capabliities and preferences, > > it's hard to imagine that there won't be a demand to use RCPT to request > > other information about the recipient's UA or preferences, such as > > whether the recipient will honor MDN requests, what languages the > > recipient can read, whether the recipient wants to opt-out of spam, > > whether the recipient supports vendor-proprietary extension FOO, etc. > > (I didn't say that I liked all of these ideas, just that these are > > obvious uses of a facility that lets you query UA capabilities. > > OTOH I do like some of them.) > > Language preferences are, I believe, already defined as something you can get > out of feature algebra. perhaps, these were just off the top of my head. and I don't think the feature algebra yet contains everything that a recipient might like to specify. > > and if we go down that path we might really regret having allowed CONNEG > > to alter the RCPT reply code. > > Why? If the client doesn't want CONNEG to alter the status all it has to do is > use OPTIONAL rather than REQUIRED. Again, REQUIRED implies that the client is > willing to treat different sorts of failures in the same way. well, if we had such other features then the client wanting to assert such other features would not be able to assert CONNEG=REQUIRED, it would just have to implement the error detection by itself. > Again, I think a means of distinguishing conneg material in the response is a > good idea and I'm not opposed to eliminating REQUIRED. But really don't believe > REQUIRED causes the problems you think it does. The overall effect of REQUIRED is probably to increase the number of implementation errors and the number of mis-reported delivery failures. It's by no means the worst thing I've ever seen in a protocol, nor is it the worst thing in this proposal. Getting rid of REQUIRED just makes the protocol slightly cleaner. It doesn't get rid of the RSET ugliness, it doesn't address the applicability of this extension to non-fax scenarios, nor the lack of attention to other issues. These other things need to be considered also. But given the importance of SMTP and the fragility of the mail system I think that the fewer warts we add to SMTP the better off we'll be. Keith From owner-ietf-fax@mail.imc.org Wed Jul 3 17:19:46 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 RAA06970 for ; Wed, 3 Jul 2002 17:19:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g63L4FE15712 for ietf-fax-bks; Wed, 3 Jul 2002 14:04:15 -0700 (PDT) Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g63L48w15692 for ; Wed, 3 Jul 2002 14:04:08 -0700 (PDT) Received: from [192.168.1.3] (ool-18e43cab.dyn.optonline.net [24.228.60.171]) by mail2.panix.com (Postfix) with ESMTP id D89EB910C; Wed, 3 Jul 2002 17:00:41 -0400 (EDT) Mime-Version: 1.0 X-Sender: hal9001@popserver.panix.com Message-Id: In-Reply-To: <5.1.1.2.2.20020702180721.03a95930@jay.songbird.com> References: <"Your message dated Tue, 02 Jul 2002 19:49:46 -0400" <108177848.1025639386@localhost> <15649.62973.894081.566925@monkeyboy.gshapiro.net> <3D221C44.5F99DED6@messagingdirect.com> <108177848.1025639386@localhost> <5.1.1.2.2.20020702180721.03a95930@jay.songbird.com> X-Mailer: Eudora Pro 5.1.1b22 PPC (Macintosh) Date: Wed, 3 Jul 2002 16:16:36 -0400 To: ietf@ietf.org, ietf-fax@imc.org From: "Robert A. Rosenberg" Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard 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 18:09 -0700 on 07/02/2002, Dave Crocker wrote about Re: Last Call: SMTP Service Extension for Content Negot: > > If, on the other >>hand, messages tailored for a each recipient is going to be the norm, then >>VRFY is the correct approach. > > >If the sender is concerned about optimizing for each recipient, they can >get that effect by reducing to a single RCPT-TO per DATA. > >So it is not as pretty as the separate command, but it permits roughly the >same mode of operation. This "one address per copy" approach insures that there will ALMOST ALWAYS be wasted processing and message uploading in any situation where knowing the capabilities prior to message transmission would have allowed the piggybacking of additional addresses onto a copy of the message (IOW: 5 message versions going to a total of 25 addresses instead of 25 copies each addressed to one of the 25 addresses saving thus saving 20 message transmissions). You need to decide what the trade-offs are between minimal number of separate copies (with its processing overhead) and the one message copy per address (with its wasting of bandwidth and throttling of delivery speed due to queuing of messages that could have been passed to the server as part of a prior transmission). From owner-ietf-fax@mail.imc.org Wed Jul 3 17:19:56 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 RAA06984 for ; Wed, 3 Jul 2002 17:19:55 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g63L4AU15701 for ietf-fax-bks; Wed, 3 Jul 2002 14:04:10 -0700 (PDT) Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g63L48w15691; Wed, 3 Jul 2002 14:04:08 -0700 (PDT) Received: from [192.168.1.3] (ool-18e43cab.dyn.optonline.net [24.228.60.171]) by mail2.panix.com (Postfix) with ESMTP id B8C3C910F; Wed, 3 Jul 2002 17:00:43 -0400 (EDT) Mime-Version: 1.0 X-Sender: hal9001@popserver.panix.com Message-Id: In-Reply-To: <5.1.1.2.2.20020702183611.0354a798@jay.songbird.com> References: <(Your message of "Tue, 02 Jul 2002 19:45:19 EDT.") <107911393.1025639119@localhost> <5.1.1.2.2.20020702183611.0354a798@jay.songbird.com> X-Mailer: Eudora Pro 5.1.1b22 PPC (Macintosh) Date: Wed, 3 Jul 2002 16:40:36 -0400 To: iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org From: "Robert A. Rosenberg" Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard 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 18:45 -0700 on 07/02/2002, Dave Crocker wrote about Re: Last Call: SMTP Service Extension for Content Negot: > > the client >>is being asked to make a convert-or-fail decision without >>any reasonable (sender-supplied or standardized) criteria as >>to what kinds of conversions are acceptable. >> >>This seems like another major omission in the current spec. > >You again seem to be missing the fact that that "omission" predates CONNEG >and has been part of Internet mail for 8 years. Fixing/Avoiding that "Omission" it seems to me to be the job-of/use-for Multi-Part/Alternate. The Sender creates all the Permutations/Combinations they want and sends the total package. It is then the job of the Recipient to wade through the mess and select the versions that it wants to accept for display/processing. CONNEG appears at its root to be an attempt to avoid the "wasted" bandwidth and processing time/effort to create a M-P/A MIME message most of whose content the Recipient is going to ignore after receipt. It also removes the requirement that the Recipient is even capable of parsing a M-P/A MIME message to locate the "correct" version of FAX which it can understand/process. I apologize if I am stating the obvious but sometimes it is needed to do so to refocus the discussion (the "Forest for the Trees" Phenomenon). From owner-ietf-fax@mail.imc.org Wed Jul 3 17:50: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 RAA08366 for ; Wed, 3 Jul 2002 17:50:23 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g63LXwS17921 for ietf-fax-bks; Wed, 3 Jul 2002 14:33:58 -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 g63LXpw17885; Wed, 3 Jul 2002 14:33:51 -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 OAA23494; Wed, 3 Jul 2002 14:39:45 -0700 Message-Id: <5.1.1.2.2.20020703142511.019f51a0@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Wed, 03 Jul 2002 14:27:58 -0700 To: "Robert A. Rosenberg" From: Dave Crocker Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Cc: iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org In-Reply-To: References: <5.1.1.2.2.20020702183611.0354a798@jay.songbird.com> <(Your message of "Tue, 02 Jul 2002 19:45:19 EDT.") <107911393.1025639119@localhost> <5.1.1.2.2.20020702183611.0354a798@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: At 04:40 PM 7/3/2002 -0400, Robert A. Rosenberg wrote: >CONNEG appears at its root to be an attempt to avoid the "wasted" >bandwidth and processing time/effort to create a M-P/A MIME message most >of whose content the Recipient is going to ignore after receipt. It also >removes the requirement that the Recipient is even capable of parsing a >M-P/A MIME message to locate the "correct" version of FAX which it can >understand/process. Hmmm. As I recall, the specification was not developed with this goal in mind. However I think that you are pointing out a trade-off in the use of ESMTP/CONNECT and Multipart/Alternative that is largely correct. (I say largely rather than completely because there are some feature combinations that define so many combinatorials, they could not be considered for M/A but are straightforward for CONNEG.) Still, you do raise an interesting perspective. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Wed Jul 3 18:23:49 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 SAA10155 for ; Wed, 3 Jul 2002 18:23:48 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g63M8Sv21253 for ietf-fax-bks; Wed, 3 Jul 2002 15:08:28 -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 g63M8Rw21248 for ; Wed, 3 Jul 2002 15:08:27 -0700 (PDT) Received: from GK-VAIO.ninebynine.org ([212.159.33.234]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g63M5T419487; Wed, 3 Jul 2002 15:05:29 -0700 Message-Id: <5.1.0.14.2.20020703211049.03e4dd20@joy.songbird.com> X-Sender: gk-lists@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 03 Jul 2002 21:11:33 +0100 To: ned.freed@mrochek.com From: Graham Klyne Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Cc: ietf@ietf.org, ietf-fax@imc.org In-Reply-To: <01KJNL06HJR0001ZTY@mauve.mrochek.com> References: <"Your message dated Wed, 03 Jul 2002 12:56:02 -0400" <200207031656.g63Gu2226331@astro.cs.utk.edu> <01KJNJF5CAEK001ZTY@mauve.mrochek.com> <200207031656.g63Gu2226331@astro.cs.utk.edu> 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 10:12 AM 7/3/02 -0700, ned.freed@mrochek.com wrote: >Language preferences are, I believe, already defined as something you can get >out of feature algebra. Yup. RFC 2987. #g ------------------- Graham Klyne From owner-ietf-fax@mail.imc.org Wed Jul 3 19:48:19 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 TAA13658 for ; Wed, 3 Jul 2002 19:48:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g63NVrZ29334 for ietf-fax-bks; Wed, 3 Jul 2002 16:31:53 -0700 (PDT) Received: from tap_exchange.toshiba-tap ([203.56.127.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g63NVpw29317 for ; Wed, 3 Jul 2002 16:31:52 -0700 (PDT) Received: by mail.toshiba-tap.com with Internet Mail Service (5.5.2655.55) id <3C8XQGW5>; Thu, 4 Jul 2002 09:31:48 +1000 Message-ID: <41CBB274CC77984D8A365C0A1B79F692214733@mail.toshiba-tap.com> From: Gerry Sancataldo To: "'Robert A. Rosenberg'" , ietf@ietf.org, ietf-fax@imc.org Subject: RE: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Date: Thu, 4 Jul 2002 09:31:46 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C222E9.CC46EDC0" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C222E9.CC46EDC0 Content-Type: text/plain Hi all, I am involved in the technical support/ training area for fax and internet fax devices and would just like to add that typically a message/transaction is directed to one recipient only. (I make no judgement as to other services that may piggyback on SMTP and if they will typically include multiple recipients). As the number of Multi-function devices supporting Internet fax move to an increasing number of options (colour copiers etc supporting Internet fax) I suspect that the onus should be on the recipient client to confirm its capabilities, not the server. I make no judgement as to other services that may piggyback on SMTP and if they will typically include multiple recipients. Cheers, Gerry -----Original Message----- From: Robert A. Rosenberg [mailto:hal9001@panix.com] Sent: Thursday, 4 July 2002 6:17 AM To: ietf@ietf.org; ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard At 18:09 -0700 on 07/02/2002, Dave Crocker wrote about Re: Last Call: SMTP Service Extension for Content Negot: > > If, on the other >>hand, messages tailored for a each recipient is going to be the norm, then >>VRFY is the correct approach. > > >If the sender is concerned about optimizing for each recipient, they can >get that effect by reducing to a single RCPT-TO per DATA. > >So it is not as pretty as the separate command, but it permits roughly the >same mode of operation. This "one address per copy" approach insures that there will ALMOST ALWAYS be wasted processing and message uploading in any situation where knowing the capabilities prior to message transmission would have allowed the piggybacking of additional addresses onto a copy of the message (IOW: 5 message versions going to a total of 25 addresses instead of 25 copies each addressed to one of the 25 addresses saving thus saving 20 message transmissions). You need to decide what the trade-offs are between minimal number of separate copies (with its processing overhead) and the one message copy per address (with its wasting of bandwidth and throttling of delivery speed due to queuing of messages that could have been passed to the server as part of a prior transmission). ------_=_NextPart_001_01C222E9.CC46EDC0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Last Call: SMTP Service Extension for Content Negotiation to = Proposed Standard

Hi all,

I am involved in the technical support/ training area = for fax and internet fax devices and would just like to add that = typically a message/transaction is directed to one recipient = only.

(I make no judgement as to other services that may = piggyback on SMTP and if they will typically include multiple = recipients).

As the number of Multi-function devices supporting = Internet fax move to an increasing number of options (colour copiers = etc supporting Internet fax) I suspect that the onus should be on the = recipient client to confirm its capabilities, not the = server.

I make no judgement as to other services that may = piggyback on SMTP and if they will typically include multiple = recipients.


Cheers,

Gerry

-----Original Message-----
From: Robert A. Rosenberg [mailto:hal9001@panix.com]
Sent: Thursday, 4 July 2002 6:17 AM
To: ietf@ietf.org; ietf-fax@imc.org
Subject: Re: Last Call: SMTP Service Extension for = Content Negotiation
to Proposed Standard



At 18:09 -0700 on 07/02/2002, Dave Crocker wrote = about Re: Last Call:
SMTP Service Extension for Content Negot:

>  >  If, on the other
>>hand, messages tailored for a each recipient = is going to be the norm, then
>>VRFY is the correct approach.
>
>
>If the sender is concerned about optimizing for = each recipient, they can
>get that effect by reducing to a single RCPT-TO = per DATA.
>
>So it is not as pretty as the separate command, = but it permits roughly the
>same mode of operation.

This "one address per copy" approach = insures that there will ALMOST
ALWAYS be wasted processing and message uploading in = any situation
where knowing the capabilities prior to message = transmission would
have allowed the piggybacking of additional = addresses onto a copy of
the message (IOW: 5 message versions going to a = total of 25 addresses
instead of 25 copies each addressed to one of the 25 = addresses saving
thus saving 20 message transmissions). You need to = decide what the
trade-offs are between minimal number of separate = copies (with its
processing overhead) and the one message copy per = address (with its
wasting of bandwidth and throttling of delivery = speed due to queuing
of messages that could have been passed to the = server as part of a
prior transmission).

------_=_NextPart_001_01C222E9.CC46EDC0-- From owner-ietf-fax@mail.imc.org Wed Jul 3 20:47:12 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 UAA16291 for ; Wed, 3 Jul 2002 20:47:12 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g640W9Q04257 for ietf-fax-bks; Wed, 3 Jul 2002 17:32:09 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g640W8w04252 for ; Wed, 3 Jul 2002 17:32:08 -0700 (PDT) Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17PuXV-000986-00; Thu, 04 Jul 2002 00:32:05 +0000 Date: Wed, 03 Jul 2002 20:32:04 -0400 From: John C Klensin To: ned.freed@mrochek.com cc: Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Message-ID: <197128527.1025728324@localhost> In-Reply-To: <01KJMXAOJA04001ZTY@mauve.mrochek.com> References: <15649.62973.894081.566925@monkeyboy.gshapiro.net> <3D221C44.5F99DED6@messagingdirect.com> <108177848.1025639386@localhost> <01KJMM5WZSX8001ZTY@mauve.mrochek.com> <122335932.1025653541@localhost> <01KJMXAOJA04001ZTY@mauve.mrochek.com> X-Mailer: Mulberry/3.0.0a3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit --On Tuesday, 02 July, 2002 21:57 -0700 ned.freed@mrochek.com wrote: >> Is this complex? Sure it is. But, if one is going to end up >> with least common denominator, the limiting (and probably >> common) case is to just send that and forget about >> capabilities negotiation. Or, if the number of useful >> differentiated formats is _very_ small, just sending both >> with multipart/alternative might turn out to be easier and >> cheaper than messing around trying to find feature >> intersections. There isn't nearly enough information in the >> spec for me to be able to guess if that would be the case. >> There shouldn't be if this is a general purpose, >> multiple-recipient, capabilities negotiation mechanism but, if >> it is, I don't see much hope other than dealing with the >> complexity (or deciding we don't need something that general). > > I guess I remain to be convinced either way: That multiple > versions schemes are necessary or that a single version > schemes are sufficient. I'd guess there's a sweet spot > somewhere in there. Unfortunately in this particular case the > location of that spot drives a bunch of design choices. I agree completely. >> Ignoring all of the relay issues, which I still don't think >> the document addresses, > > I must say I don't see any of this as particularly useful in a > relay scenario. I don't either. My concern is that it is fairly poorly defined in relay scenarios -- partially, I assume, because its utility is, at best, unclear -- but that the document says it applies to relays. That leaves us in what may be an "almost nothing but edge cases" situation, which is typically a bad way to be doing standards. If we can't see enough utility for relay situations to justify working out the cases --and I can't-- then why not ban the relay cases until and unless someone demonstrates that they are relevant is does the work. >> and the fallback to fax while claiming it >> isn't fax-specific, etc., I'd partition the above a bit >> differently. I'd guess the dominant approach (especially if >> one generalizes beyond fax) is going to be greatest (most >> capable) common denominator above a threshold. I.e., if >> there is some minimal, default, capability, and some >> recipients can support only that (e.g., they don't handle >> option negotiation at all), then two messages are going to be >> sent: one corresponding to the common feature set of the more >> capable recipients and one for the minimal/default feature >> set. Everyone gets downgraded to the minimum/default because >> one recipient isn't highly capable just doesn't feel >> commercially viable to me, while assuming a mix of >> high-function and low-function hosts does. > > I certainly agree with the common denominator above a > threshhold. But given that a single recipient per destination > is likely to be a very common case, I'm less sure that simpler > approaches won't be commercially viable. Or perhaps > capabilities will be used to reduce the number of variants > sent with multipart/alternative. Makes sense. Makes much more sense if relaying is banned. Otherwise, "one recipient per destination" slides over really easily into "send everything to her, and let her deal with splitting the stuff up by destinations and capabilities", and that introduces all the complexity. That still leaves "one virtual fax, one recipient" (and, by definition, one destination) as a probably-very common case, given real-world fax behavior today. Also given that behavior, that case is certainly commercially viable. But this is awfully complex for that case: we could generalize it into a single command or capabilities statement. >> Other >> combinations are possible, but my sense of reality says they >> would rapidly turn into message-copy-per-recipient rather than >> strange combinatorics on feature sets. > > It may indeed turn out that per-recipient message copy is the > right way to finesse the feature set combination issues. Of course, that is another generalization of "one virtual fax, one recipient": one message, one recipient, one set of capabilities. And a vastly simplified protocol. >> But, in that "two message" case, one really doesn't want 5yz >> codes coming back from the server in response to a RCPT TO. >> If the "one digit" rule is observed, there is no way to >> differentiate between "bad mailbox" and "bad parameter". If >> it is not, and three digits are processed, the server cannot >> effectively differentiate between a bad parameter to CONNEG >> and one to some other option by the code -- the reply string >> has to be parsed, and that leads to bad trouble. So I would >> think that a batch of capability-determining commands before >> the first RCPT one would be a better idea, complexity >> notwithstanding. > > I'm not sure I get what you're driving at here. The client gets > to choose whether the server treats a recipient with unknown > capabilities as an error or simply by indicating as much. Suppose the client sends RCPT TO: CONNEG=REQUIRED;bazoption=REQUIRED and gets back 504 option parameter stinks - REQUIRED or 504 bad parameter - CONNEG REQUIRED in the one-digit case, it can't distinguish either one from 500 Never heard of foo in the three-digit case, the first 504 variant doesn't give a clue as to the difference between "don't know the client's capabilities" and "REQUIRED is not a valid parameter for bazoption". The second variant is better, but requires parsing of a string whose format is not precisely specified. To some degree, this is a general problem with multiple ESMTP option-parameter sets, but it seems to be that the CONNEG case is a little worse than average. >> Again, the way to get most of the complexity out of this, IMO, >> is to change the problem. For example, if the server makes >> the determination of the common capability set among all >> recipients and returns it only once (a bit tricky with the >> SMTP model, but not impossible), then the client doesn't have >> to figure out how to intersect whatever comes back, break >> things up into separate messages, etc. But I don't know if >> that would do the job; it certainly doesn't handle a mix of >> high- and low-function recipients in a plausible way. > > I considered proposing this as well, but it seemed to be that > knowledge of what the client can actually do may determine how > differing feature sets are combined. Yes, but what a nightmare. To really get it right may require fairly complete knowledge of what the client can actually do _and_ fairly complete knowledge of what the recipient (not just the receiving server) can actually do. In a better world, that requires an MUA-MUA negotiation, but we don't have any semantics for talking about that (especially in SMTP). Of course, forcing the problem into one receiving MUA no relay would permit getting close without giving all of us a bad headache. But I don't know if that is feasible. What I'm getting fairly sure of is that the present document is rather seriously underspecified for the mind-boggling general case. john From owner-ietf-fax@mail.imc.org Wed Jul 3 21:06:15 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 VAA17340 for ; Wed, 3 Jul 2002 21:06:14 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g640qsS06015 for ietf-fax-bks; Wed, 3 Jul 2002 17:52:54 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g640qrw06011 for ; Wed, 3 Jul 2002 17:52:53 -0700 (PDT) Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17PurY-0009BA-00; Thu, 04 Jul 2002 00:52:48 +0000 Date: Wed, 03 Jul 2002 20:52:47 -0400 From: John C Klensin To: ned.freed@mrochek.com, Keith Moore cc: Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Message-ID: <198371544.1025729567@localhost> In-Reply-To: <01KJMYAMO1RS001ZTY@mauve.mrochek.com> References: <01KJMUXOR5MO001ZTY@mauve.mrochek.com> <200207030526.g635Qf201876@astro.cs.utk.edu> <01KJMYAMO1RS001ZTY@mauve.mrochek.com> X-Mailer: Mulberry/3.0.0a3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit --On Tuesday, 02 July, 2002 23:09 -0700 ned.freed@mrochek.com wrote: > Well, it is certainly possible to arrange the additional > conneg data so it is identifiable as such. As for not > affecting the response, I'm not sure I see the problem: If the > client wants an interop guarantee, it requires a conneg > response, and handles 4yz and 5yz codes as temporary or > permanent failures without regard to what's causing the error. > If, on the other hand, it wants conneg info as long as its > available, it makes a conneg response optional, in which case > the status codes no longer have anyhing to do with conneg > information. Ned, purely as a strawman, suppose we turned things around as follows: C: EHLO ... S: 250-Yep we speak that here S: 250-... S: 250-CONNEG C: MAIL FROM: CONNEG S: 250 OK C: RCPT TO: S: 250-OK I actually know her capabilities S: 250-<...capability stuff> S: 250- C: RCPT TO: S: 250 OK but that is a relay site and I dont have a clue Client now figures out that it has one recipient with known capabilities and one with unknown ones. Based on that, it either sends RSET and tries something else, or sends DATA and the default [fax?] format. Considerably cleaner, IMO, than "REQUIRED" on some, "OPTIONAL" on others, etc. This does, however, point out another problem with the general approach, regardless of whether CONNEG appears with MAIL, RCPT, or VRFY. Let's assume the latter, since it doesn't get involved with other semantics, but the other cases are pretty much the same. C: EHLO ... S: 250-OK S: 250- ... S: 250- CONNEG S: 250 SILLYSTATE C: VRFY CONNEG=REQUIRED SILLYSTATE=FALSE S: 250-foo@bar.baz ok. probably. S: 250-CONNEG S: 250- S: 250 CONNEG Looks like an interesting parsing/accumulation problem in the best of cases. Now, of course, this wouldn't occur with the document as written, because it appears to prohibit the use of CONNEG with any other options that might impact the RCPT reply. Another case not analysed and documented? john From owner-ietf-fax@mail.imc.org Wed Jul 3 22:27:39 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 WAA22827 for ; Wed, 3 Jul 2002 22:27:38 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g642CnZ12263 for ietf-fax-bks; Wed, 3 Jul 2002 19:12: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 g642CKw12206; Wed, 3 Jul 2002 19:12:20 -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 TAA32496; Wed, 3 Jul 2002 19:18:15 -0700 Message-Id: <5.1.1.2.2.20020703185729.01b1f0f8@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Wed, 03 Jul 2002 19:12:12 -0700 To: John C Klensin From: Dave Crocker Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Cc: "Robert A. Rosenberg" , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org In-Reply-To: <200697042.1025731892@localhost> References: <5.1.1.2.2.20020703142511.019f51a0@jay.songbird.com> <5.1.1.2.2.20020702183611.0354a798@jay.songbird.com> <(Your message of "Tue, 02 Jul 2002 19:45:19 EDT.") <107911393.1025639119@localhost> <5.1.1.2.2.20020702183611.0354a798@jay.songbird.com> <5.1.1.2.2.20020703142511.019f51a0@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: At 09:31 PM 7/3/2002 -0400, John C Klensin wrote: > Would you >expect the client to work its way through those combinatorics in >real time, yes. no matter what the details are, computing the intersection is not that difficult and the computation of such issues does not take that long. No matter what the computations are. As to the question of real-time generation of the chosen transform(s), that bridge was crossed as soon as the client went down the path of CONNEG. In other words, if the client wants to do ESMTP/CONNEG, it has better be programmed to do the necessary real-time transforms. >Alternately, the client could notice that the different >recipients had different capabilities (_that_ ought to be fairly >easy in real time, especially if each of them announced its >capabilities in the same order and using the same syntax -- >which the spec doesn't seem to require) doesn't use the same syntax? as to order: were we doing data processing of millions of records, fixed position formats might make sense. We don't do it for message or content headers, why should we do it for these attributes? > but the potentially-long SMTP connection >times (in the RSET, figure out the formats and build them while >the SMTP connection is still open, and then send them >separately) or abandoning the connection and starting over and RSET is markedly inefficient, yes. that's clear. my personal expectation is that a client will either be designed to send the least common denominator of the address list response capabilities, or it will send the addresses one per DATA and tailor each. the alternative that has been the subject of such delightful speculation, here, with the RSET required, strikes me as worth very little of any implementor's time. >Just trying to understand the expected situation... The spec is pretty simple, and it is mostly based on a set of previous work involving CONNEG. The situations for the spec's use are also pretty simple. The actual uses will no doubt have some surprises, because new features always have surprises. So what *I* would like to understand is where this is going. There are some small writing errors in the specification that have been noted and will be changed. There are some suggestions for clarification and/or guidance that seem pretty reasonable, to. As to the rest of the discussions about the thread, I have so far failed to detect any analysis that discloses a failure in the specification, of the type: "it won't work". So, as I say, what *I* would like to understand is where this is going. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Wed Jul 3 23:24:46 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 XAA25921 for ; Wed, 3 Jul 2002 23:24:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g643Aaj17985 for ietf-fax-bks; Wed, 3 Jul 2002 20:10:36 -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 g643AYw17972 for ; Wed, 3 Jul 2002 20:10:34 -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 UAA02332; Wed, 3 Jul 2002 20:16:30 -0700 Message-Id: <5.1.1.2.2.20020703194925.0330dd60@jay.songbird.com> X-Sender: dhc2@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Wed, 03 Jul 2002 20:10:20 -0700 To: "Robert A. Rosenberg" From: Dave Crocker Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Cc: ietf@ietf.org, ietf-fax@imc.org In-Reply-To: References: <5.1.1.2.2.20020702180721.03a95930@jay.songbird.com> <"Your message dated Tue, 02 Jul 2002 19:49:46 -0400" <108177848.1025639386@localhost> <15649.62973.894081.566925@monkeyboy.gshapiro.net> <3D221C44.5F99DED6@messagingdirect.com> <108177848.1025639386@localhost> <5.1.1.2.2.20020702180721.03a95930@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: At 04:16 PM 7/3/2002 -0400, Robert A. Rosenberg wrote: >This "one address per copy" approach insures that there will ALMOST >ALWAYS be wasted processing and message uploading in any situation >where knowing the capabilities prior to message transmission would >have allowed the piggybacking of additional addresses onto a copy of >the message If the sender already know the capabilities of the recipient, then the sender does not need to use ESMTP/CONNEG. ESMTP/CONNEG is designed for use when the sender does NOT have that information. There are a number of ways the sender might obtain capabilities before starting this SMTP session. One example is . Another is, no doubt, via some LDAP-based directory. >You need to decide what the >trade-offs are By "you" I assume you mean the aggregation of the implementer and the sending system's administrator. There is no need for this specification to dictate that choice. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Wed Jul 3 23:42: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 XAA26471 for ; Wed, 3 Jul 2002 23:42:23 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g643PZ119910 for ietf-fax-bks; Wed, 3 Jul 2002 20:25:35 -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 g643PYw19904 for ; Wed, 3 Jul 2002 20:25:34 -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 UAA02822; Wed, 3 Jul 2002 20:31:24 -0700 Message-Id: <5.1.1.2.2.20020703201153.034805f0@jay.songbird.com> X-Sender: dhc2@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Wed, 03 Jul 2002 20:25:21 -0700 To: John C Klensin From: Dave Crocker Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Cc: ned.freed@mrochek.com, Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org In-Reply-To: <197128527.1025728324@localhost> References: <01KJMXAOJA04001ZTY@mauve.mrochek.com> <15649.62973.894081.566925@monkeyboy.gshapiro.net> <3D221C44.5F99DED6@messagingdirect.com> <108177848.1025639386@localhost> <01KJMM5WZSX8001ZTY@mauve.mrochek.com> <122335932.1025653541@localhost> <01KJMXAOJA04001ZTY@mauve.mrochek.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: At 08:32 PM 7/3/2002 -0400, John C Klensin wrote: >I don't either. My concern is that it is fairly poorly defined >in relay scenarios What needs to be defined that is not defined? This is a hop-by-hop protocol, just like all of SMTP. If there is relaying with CONNEG support, then CONNEG is used at each hop. Just like for DSN. Do I think that this is the epitome of efficiency? No. But then, hop-by-hop mechanisms often suffer with respect to some aspects of efficiency. The reason for hop-by-hop is not "efficiency" but rather for reliability/safety. And the current specification is only one way to obtain CONNEG information. If a better one is available and satisfactory, then by all means use it. > -- partially, I assume, because its utility is, at best, unclear right. it is not at all obvious that an organization might want to have a corporate email firewall accept the message with a CONNEG exchange and then relay it through the corporate network to the mailbox. after all, such a scenario for regular email is not all that popular. > If we can't see enough utility for relay situations >to justify working out the cases --and I can't-- then why not >ban the relay cases until and unless someone demonstrates that >they are relevant is does the work. see above. and it strikes me that the idea of having an SMTP option that is prohibited from use in relaying is rather more massively significant than whether this particular option will work well in relaying circumstances. >That still leaves "one virtual fax, one recipient" (and, by >definition, one destination) as a probably-very common case, >given real-world fax behavior today. One might also want to consider that the concept of obtaining per-recipient capabilities rather naturally suggests a tendency to do per-recipient tailoring of content. One does not need any history of fax to note the likelihood of the one-to-one case being dominant. One might even suspect that it is inherent. > Also given that behavior, >that case is certainly commercially viable. But this is >awfully complex for that case: we could generalize it into a >single command or capabilities statement. Complicated? I guess it is not clear what would be simpler and equally useful (as well as equally flexible.) So please, provide an example of this alternative to the current specification that is sufficiently simpler so as to render the current specification inappropriate. It also would be good to make a distinction between working well in the most likely scenario, versus preventing any scenario except the most likely. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Thu Jul 4 00:03: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 AAA27115 for ; Thu, 4 Jul 2002 00:03:40 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g643nXB21357 for ietf-fax-bks; Wed, 3 Jul 2002 20:49: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 g643nWw21350 for ; Wed, 3 Jul 2002 20:49:32 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KJMCBY0GRK001ZTY@mauve.mrochek.com> for ietf-fax@imc.org; Wed, 03 Jul 2002 20:49:35 -0700 (PDT) Date: Wed, 03 Jul 2002 17:18:54 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: "Your message dated Wed, 03 Jul 2002 16:24:32 -0400" <200207032024.g63KOW203066@astro.cs.utk.edu> To: Keith Moore Cc: ned.freed@mrochek.com, Keith Moore , John C Klensin , Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Message-id: <01KJO6VZBYM0001ZTY@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <01KJNL06HJR0001ZTY@mauve.mrochek.com> <200207032024.g63KOW203066@astro.cs.utk.edu> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > > > granted it's necessary for the client to be able to do that, but my point > > > is that having the server report conneg faliures in the RCPT status code > > > doesn't relieve the client of the necessity to detect other conditions > > > resulting from valid conneg strings that can cause delivery failure. > > > it's not as if the client can rely only on the response code to determine > > > how to handle the message. > > > > Sure, but it is only useful to treat such failures as permanent. > how so? Because you said: "other conditions resulting from valid conneg strings that can cause delivery failure." If the conneg result is something you do not like I don't think treating this as a temporary failure in hopes the conneg string will change in the future is either reasonable or appropriate. > if there is a temporary failure to get conneg information, the > client might quite reasonably decide to retry later. or if the client > can't translate part of the message, it might reasonably decide that > delivering the remainder of the message is preferable to bouncing it. That wasn't the case you were talking about. > > I remain unconvinced that this is a useful distinction. What REQUIRED says is > > "I absolutely require CONNEG info and as such a failure to have it is the same > > to me as any other sort of failure and should be responded to accordingly". > it's still poor separation of function, and it's still asking the server > to report a failure condition which the client understands better than the > server does. E.g. the server is told to report errors as 4.3.3 or 5.3.3 > when codes x.6.1 or x.6.2 or x.6.3 might be more appropriate. The server > can't tell the difference between those conditions; the client can. Ah, I see. We've moved from assertions that there were sure to be problems to the nonspecific "poor separation of function". But the entire point of REQUIRED is to say "I don't want these functions separated; conneg failures are just like any other failure to me". So this entire line of argument turns out to be specious. > > > and if we go down that path we might really regret having allowed CONNEG > > > to alter the RCPT reply code. > > Why? If the client doesn't want CONNEG to alter the status all it has to do is > > use OPTIONAL rather than REQUIRED. Again, REQUIRED implies that the client is > > willing to treat different sorts of failures in the same way. > well, if we had such other features then the client wanting to assert such > other features would not be able to assert CONNEG=REQUIRED, it would just > have to implement the error detection by itself. Doesn't follow. If some other functionality is implemented that results in RCPT TO failing in some new way it can return errors in the same way. Of course the error report is limited to a single error condition, but the potential for multiple failures having to be collapsed into a single return value already exists in abundance; the existance of this extension or an arbitrary number of future extensions changes nothing in this regard. > > Again, I think a means of distinguishing conneg material in the response is a > > good idea and I'm not opposed to eliminating REQUIRED. But really don't believe > > REQUIRED causes the problems you think it does. > The overall effect of REQUIRED is probably to increase the number of > implementation errors and the number of mis-reported delivery failures. Well, I've worked out what code is necessary to do this, and IMO this just doesn't rise to the level of complexity for this to be the case. > It's by no means the worst thing I've ever seen in a protocol, nor is > it the worst thing in this proposal. Getting rid of REQUIRED just > makes the protocol slightly cleaner. It doesn't get rid of the RSET > ugliness, it doesn't address the applicability of this extension to > non-fax scenarios, nor the lack of attention to other issues. > These other things need to be considered also. > But given the importance of SMTP and the fragility of the mail system > I think that the fewer warts we add to SMTP the better off we'll be. Keith, I was willing to give you the benefit of the doubt before. But now that your concerns about this have become clear I'm finding I flat out disagree with your assessment of the risks and concerns involved. Ned From owner-ietf-fax@mail.imc.org Thu Jul 4 00:25:18 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 AAA27717 for ; Thu, 4 Jul 2002 00:25:18 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g644Bfm22847 for ietf-fax-bks; Wed, 3 Jul 2002 21:11:41 -0700 (PDT) Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g644Bew22842 for ; Wed, 3 Jul 2002 21:11:40 -0700 (PDT) Received: from [192.168.1.3] (ool-18e43cab.dyn.optonline.net [24.228.60.171]) by mail2.panix.com (Postfix) with ESMTP id C44649075; Thu, 4 Jul 2002 00:11:43 -0400 (EDT) Mime-Version: 1.0 X-Sender: hal9001@popserver.panix.com Message-Id: In-Reply-To: <01KJMZBD7UTS001ZTY@mauve.mrochek.com> References: <5.1.1.2.2.20020702193306.03284c00@jay.songbird.com> <" <5.1.1.2.2.20020702180721.03a95930"@jay.songbird.com> <3076.1025677622@munnari.OZ.AU> <01KJMZBD7UTS001ZTY@mauve.mrochek.com> X-Mailer: Eudora Pro 5.1.1b22 PPC (Macintosh) Date: Wed, 3 Jul 2002 23:59:25 -0400 To: ietf@ietf.org, ietf-fax@imc.org From: "Robert A. Rosenberg" Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard 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 23:43 -0700 on 07/02/2002, ned.freed@mrochek.com wrote about Re: Last Call: SMTP Service Extension for Content Negot: > > Keith's operational plan can be done by sending RCPT TO (where he would >> send RCAP) and terminating the sequence with RSET. This way the RCPT >> TO acts just as the RCAP would act in his model (as I understand it). >> Sure, it isn't as clean by any means, and makes the server do a little >> extra work, as it doesn't know the RCPT TO's aren't real ones when it >> receives them, but as a trade off, it seems OK. > >Ah. Using the first round of RCPT TOs as capabilities checks only and sending >the RSET unconditionally is really quite cute. It still has the added >complexity of having multiple commands per recipient, but now it is the same >command repeated, which eliminates a bunch of the edge conditions >and makes the >silly states very silly indeed. The RSET can be made optional by ONLY sending it if the replies to the RCPT TO requests return a result that requires multiple copies of the message. IOW: If the LCD of all the replies is the BEST version you are capable of sending (such as getting back some "I support color" replies mixed with "B+W-only support" replies when you only have a B+W Fax), then just bypass the RSET and retransmission of the RCPT TOs and go direct to DATA (and collect your $200). From owner-ietf-fax@mail.imc.org Thu Jul 4 00:49:04 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 AAA28275 for ; Thu, 4 Jul 2002 00:49:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g644Wu124058 for ietf-fax-bks; Wed, 3 Jul 2002 21:32:56 -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 g644Wtw24053 for ; Wed, 3 Jul 2002 21:32:55 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KJMCBY0GRK001ZTY@mauve.mrochek.com> for ietf-fax@imc.org; Wed, 03 Jul 2002 21:32:58 -0700 (PDT) Date: Wed, 03 Jul 2002 20:56:21 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: "Your message dated Wed, 03 Jul 2002 20:32:04 -0400" <197128527.1025728324@localhost> To: John C Klensin Cc: ned.freed@mrochek.com, Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Message-id: <01KJO8ERG6OO001ZTY@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <15649.62973.894081.566925@monkeyboy.gshapiro.net> <3D221C44.5F99DED6@messagingdirect.com> <108177848.1025639386@localhost> <01KJMM5WZSX8001ZTY@mauve.mrochek.com> <122335932.1025653541@localhost> <01KJMXAOJA04001ZTY@mauve.mrochek.com> <197128527.1025728324@localhost> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > > > But, in that "two message" case, one really doesn't want 5yz > > > codes coming back from the server in response to a RCPT TO. > > > If the "one digit" rule is observed, there is no way to > > > differentiate between "bad mailbox" and "bad parameter". If > > > it is not, and three digits are processed, the server cannot > > > effectively differentiate between a bad parameter to CONNEG > > > and one to some other option by the code -- the reply string > > > has to be parsed, and that leads to bad trouble. So I would > > > think that a batch of capability-determining commands before > > > the first RCPT one would be a better idea, complexity > > > notwithstanding. > > I'm not sure I get what you're driving at here. The client gets > > to choose whether the server treats a recipient with unknown > > capabilities as an error or simply by indicating as much. > Suppose the client sends > RCPT TO: CONNEG=REQUIRED;bazoption=REQUIRED > and gets back > 504 option parameter stinks - REQUIRED > or > 504 bad parameter - CONNEG REQUIRED If the server after having offering the CONNEG and bazoption extensions subsequent rejects them as "bad", it is broken. Simple as that. And trying to accomodate arbitrary broken server behavior is an exercise in futility. I suspect what you meant is something more along the lines of 504 required information not available for this recipient or 504 required CONNEG information not available for this recipient > in the one-digit case, it can't distinguish either one from > 500 Never heard of foo > in the three-digit case, the first 504 variant doesn't give a > clue as to the difference between "don't know the client's > capabilities" and "REQUIRED is not a valid parameter for > bazoption". The second variant is better, but requires parsing > of a string whose format is not precisely specified. To some > degree, this is a general problem with multiple ESMTP > option-parameter sets, but it seems to be that the CONNEG case > is a little worse than average. But the entire point of REQUIRED is that client is stating categorically that no such distinction needs to be made. The client is saying "CONNEG and bazoption are vital to me, if either of them fails I'm giving up on this recipient and you should too -- give me an error and I'll report that back to the originator". A client that wants to proceed in the case where no CONNEG information, bazoption information, or both are available it has no business using REQUIRED. > Yes, but what a nightmare. To really get it right may require > fairly complete knowledge of what the client can actually do > _and_ fairly complete knowledge of what the recipient (not just > the receiving server) can actually do. In a better world, that > requires an MUA-MUA negotiation, but we don't have any semantics > for talking about that (especially in SMTP). Of course, forcing > the problem into > one receiving MUA > no relay > would permit getting close without giving all of us a bad > headache. But I don't know if that is feasible. What I'm > getting fairly sure of is that the present document is rather > seriously underspecified for the mind-boggling general case. I'm afraid I'm coming to a very different conclusion. I think these discussions have conflated a bunch of different things: (1) Specification bugs that definitely need to be fixed, (2) A single protocol change that definitely should be made -- that of making conneg information and status identifiable as such in the command response, (3) A bunch of concerns about protocol details that aren't standing up to close inspection and which absent a clear consensus for change can remain as-is, and (4) A general concern about the many possible uses for this mechanism that has all of us engaging in futile speculation and which cannot possibly be dealt sensibly with in a specification without actual implementation and use experience. Of course (1) and (2) need to be fixed before proceeding. As for (3) and (4), well, this is why we have a standards process and not a rubber stamp. Ned From owner-ietf-fax@mail.imc.org Thu Jul 4 01:06:15 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 BAA28691 for ; Thu, 4 Jul 2002 01:06:14 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g644pXg25051 for ietf-fax-bks; Wed, 3 Jul 2002 21:51:33 -0700 (PDT) Received: from turing-police.cc.vt.edu (h80ad267c.async.vt.edu [128.173.38.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g644pVw25044 for ; Wed, 3 Jul 2002 21:51:31 -0700 (PDT) Received: from turing-police.cc.vt.edu (localhost [127.0.0.1]) by turing-police.cc.vt.edu (8.12.4/8.12.4) with ESMTP id g644oiSQ021711; Thu, 4 Jul 2002 00:50:45 -0400 Message-Id: <200207040450.g644oiSQ021711@turing-police.cc.vt.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: Dave Crocker cc: ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: Your message of "Wed, 03 Jul 2002 20:25:21 PDT." <5.1.1.2.2.20020703201153.034805f0@jay.songbird.com> From: Valdis.Kletnieks@vt.edu X-URL: http://black-ice.cc.vt.edu/~valdis/ X-Face-Viewer: See ftp://cs.indiana.edu/pub/faces/index.html to decode picture X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ <15649.62973.894081.566925@monkeyboy.gshapiro.net> <3D221C44.5F99DED6@messagingdirect.com> <108177848.1025639386@localhost> <01KJMM5WZSX8001ZTY@mauve.mrochek.com> <122335932.1025653541@localhost> <01KJMXAOJA04001ZTY@mauve.mrochek.com> <5.1.1.2.2.20020703201153.034805f0@jay.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Jul 2002 00:50:44 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 03 Jul 2002 20:25:21 PDT, Dave Crocker said: > One does not need any history of fax to note the likelihood of the > one-to-one case being dominant. One might even suspect that it is inherent. It's dominant/inherent because nobody's figured out how to make a fax machine talk to a conference call. On the other hand, remember that the *SENDER* here is going to be in the e-mail world - and people are *used* to putting half the known world into the cc: list (heck, I had to trim *this* message's list by at least 3 or 4 addresses). I'll give it 15 minutes, tops, before the first user tries to send to more than 5 recipients at once. Under an hour before the first time that more than one recipient is at the same destination.... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech From owner-ietf-fax@mail.imc.org Thu Jul 4 01:09:15 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 BAA28801 for ; Thu, 4 Jul 2002 01:09:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g644sgE25283 for ietf-fax-bks; Wed, 3 Jul 2002 21:54:42 -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 g644sfw25278 for ; Wed, 3 Jul 2002 21:54:41 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KJMCBY0GRK001ZTY@mauve.mrochek.com> for ietf-fax@imc.org; Wed, 03 Jul 2002 21:54:44 -0700 (PDT) Date: Wed, 03 Jul 2002 21:35:01 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: "Your message dated Wed, 03 Jul 2002 20:52:47 -0400" <198371544.1025729567@localhost> To: John C Klensin Cc: ned.freed@mrochek.com, Keith Moore , Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Message-id: <01KJO95RFLD6001ZTY@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <01KJMUXOR5MO001ZTY@mauve.mrochek.com> <200207030526.g635Qf201876@astro.cs.utk.edu> <01KJMYAMO1RS001ZTY@mauve.mrochek.com> <198371544.1025729567@localhost> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > --On Tuesday, 02 July, 2002 23:09 -0700 ned.freed@mrochek.com > wrote: > > Well, it is certainly possible to arrange the additional > > conneg data so it is identifiable as such. As for not > > affecting the response, I'm not sure I see the problem: If the > > client wants an interop guarantee, it requires a conneg > > response, and handles 4yz and 5yz codes as temporary or > > permanent failures without regard to what's causing the error. > > If, on the other hand, it wants conneg info as long as its > > available, it makes a conneg response optional, in which case > > the status codes no longer have anyhing to do with conneg > > information. > Ned, purely as a strawman, suppose we turned things around as > follows: > C: EHLO ... > S: 250-Yep we speak that here > S: 250-... > S: 250-CONNEG > C: MAIL FROM: CONNEG > S: 250 OK > C: RCPT TO: > S: 250-OK I actually know her capabilities > S: 250-<...capability stuff> > S: 250- > C: RCPT TO: > S: 250 OK but that is a relay site and I dont have a clue > Client now figures out that it has one recipient with known > capabilities and one with unknown ones. Based on that, it > either sends RSET and tries something else, or sends DATA and > the default [fax?] format. Considerably cleaner, IMO, than > "REQUIRED" on some, "OPTIONAL" on others, etc. Well, it certainly makes sense if you're eliminating REQUIRED to move CONNEG to the MAIL FROM. But as for eliminating REQUIRED, I can only reiterate what I've said before: I was willing to be convinced there was a problem, but the discussion has done exactly the opposite. The only clearly valid argument I've seen so far for removing REQUIRED is that it may not really be needed and things that aren't needed should not be there. But whether or not it is needed is really a question for the WG. Perhaps those who actually plan to implement CONNEG clients could comment on whether or not they view REQUIRED as something they need. > This does, however, point out another problem with the general > approach, regardless of whether CONNEG appears with MAIL, RCPT, > or VRFY. Let's assume the latter, since it doesn't get involved > with other semantics, but the other cases are pretty much the > same. > C: EHLO ... > S: 250-OK > S: 250- ... > S: 250- CONNEG > S: 250 SILLYSTATE > C: VRFY CONNEG=REQUIRED SILLYSTATE=FALSE > S: 250-foo@bar.baz ok. probably. > S: 250-CONNEG > S: 250- > S: 250 CONNEG > Looks like an interesting parsing/accumulation problem in the > best of cases. Now, of course, this wouldn't occur with the > document as written, because it appears to prohibit the use of > CONNEG with any other options that might impact the RCPT reply. > Another case not analysed and documented? I think what you're driving at is that the CONNEG material needs to appear as a unit and needs to be identifiable as such in the response. If so, this concern was raised previously and I have previously stated that I think it needs to be addressed. It is a simple fix, however. Ned From owner-ietf-fax@mail.imc.org Thu Jul 4 02:29:38 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 CAA08941 for ; Thu, 4 Jul 2002 02:29:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g646DR602676 for ietf-fax-bks; Wed, 3 Jul 2002 23:13:27 -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 g646D4w02590; Wed, 3 Jul 2002 23:13:04 -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 XAA06921; Wed, 3 Jul 2002 23:19:03 -0700 Message-Id: <5.1.0.14.2.20020703224517.01cd3d90@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Wed, 03 Jul 2002 22:51:45 -0700 To: John C Klensin From: Dave Crocker Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Cc: iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org In-Reply-To: <13310286.1025746917@localhost> References: <5.1.1.2.2.20020703185729.01b1f0f8@jay.songbird.com> <5.1.1.2.2.20020703142511.019f51a0@jay.songbird.com> <5.1.1.2.2.20020702183611.0354a798@jay.songbird.com> <(Your message of "Tue, 02 Jul 2002 19:45:19 EDT.") <107911393.1025639119@localhost> <5.1.1.2.2.20020702183611.0354a798@jay.songbird.com> <5.1.1.2.2.20020703142511.019f51a0@jay.songbird.com> <5.1.1.2.2.20020703185729.01b1f0f8@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: At 01:41 AM 7/4/2002 -0400, John C Klensin wrote: > With a >sufficiently complex (non-binary and non-orthogonal) capability >set, I suspect the computation might even turn out to be >NP-hard. With enough thrust, a pig can fly, but that is not a relevant concern for building an airline. The mechanism here provides a means of communicating arbitrary capabilities data. It is one of multiple ways to communicate that data. If you have a concern about the nature and interactions of the data, then that concern needs to be pursued separately from the communication mechanism. It might also be worth noting how thoroughly abstract your concern is. In fact it is so abstract that it does not qualify to call it unfounded. On the average, such generic concerns fail to facilitate forward progress or protocol improvement. Quite the contrary. >A few more constraints, or some explicit guidance that a client >that gets sufficiently confused is quite justified in just >giving up, would go a long way here. Or more thrust. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Thu Jul 4 02:37:48 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 CAA09196 for ; Thu, 4 Jul 2002 02:37:47 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g646N7I04766 for ietf-fax-bks; Wed, 3 Jul 2002 23:23:07 -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 g646N6w04761 for ; Wed, 3 Jul 2002 23:23:06 -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 XAA07128; Wed, 3 Jul 2002 23:29:00 -0700 Message-Id: <5.1.1.2.2.20020703231428.01a16be8@jay.songbird.com> X-Sender: dhc2@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Wed, 03 Jul 2002 23:18:52 -0700 To: John C Klensin From: Dave Crocker Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Cc: ietf@ietf.org, ietf-fax@imc.org In-Reply-To: <12403111.1025746010@localhost> References: <01KJO8ERG6OO001ZTY@mauve.mrochek.com> <15649.62973.894081.566925@monkeyboy.gshapiro.net> <3D221C44.5F99DED6@messagingdirect.com> <108177848.1025639386@localhost> <01KJMM5WZSX8001ZTY@mauve.mrochek.com> <122335932.1025653541@localhost> <01KJMXAOJA04001ZTY@mauve.mrochek.com> <197128527.1025728324@localhost> <01KJO8ERG6OO001ZTY@mauve.mrochek.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: At 01:26 AM 7/4/2002 -0400, John C Klensin wrote: >That is a reasonable position. But I suggest that it implies >either that this material should go to Experimental, rather than >Proposed, or that the mechanism should be defined as applicable >to the cases that are understood and expanded only when the >implications of that expansion are better understood. Or... As nearly as I can tell, your position is that folks can raise a spectre of myriad, unspecified, abstract and unlikely concerns and then use that as a claim that a specification should not go to Proposed... Until this long list of negatives has been disproved. That's very creative. It also is at considerable odds with typical IETF criteria for advancement, John. It is also a heck of a good way to make sure that no proposal ever goes to Proposed. So, please explain what prompts such unique and extraordinary criteria for this simple and mundane proposal? d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Thu Jul 4 02:42:33 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 CAA09306 for ; Thu, 4 Jul 2002 02:42:33 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g646SGp05716 for ietf-fax-bks; Wed, 3 Jul 2002 23:28:16 -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 g646SGw05710 for ; Wed, 3 Jul 2002 23:28:16 -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 XAA07224; Wed, 3 Jul 2002 23:34:09 -0700 Message-Id: <5.1.1.2.2.20020703232510.034bc008@jay.songbird.com> X-Sender: dhc2@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Wed, 03 Jul 2002 23:28:03 -0700 To: Valdis.Kletnieks@vt.edu From: Dave Crocker Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Cc: ietf@ietf.org, ietf-fax@imc.org In-Reply-To: <200207040450.g644oiSQ021711@turing-police.cc.vt.edu> References: <01KJMXAOJA04001ZTY@mauve.mrochek.com> <15649.62973.894081.566925@monkeyboy.gshapiro.net> <3D221C44.5F99DED6@messagingdirect.com> <108177848.1025639386@localhost> <01KJMM5WZSX8001ZTY@mauve.mrochek.com> <122335932.1025653541@localhost> <01KJMXAOJA04001ZTY@mauve.mrochek.com> <5.1.1.2.2.20020703201153.034805f0@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: At 12:50 AM 7/4/2002 -0400, Valdis.Kletnieks@vt.edu wrote: >On Wed, 03 Jul 2002 20:25:21 PDT, Dave Crocker said: > > One does not need any history of fax to note the likelihood of the > > one-to-one case being dominant. One might even suspect that it is > inherent. > >It's dominant/inherent because nobody's figured out how to make a fax machine >talk to a conference call. And the Good Humour Ice Cream truck does a very poor job of serving hot dogs. Oops. That's not it's job. And, by the way, it is inherent because a feature that is designed to obtain per-recipient information is likely to be implemented in a way the delivers per-recipient tailoring. >On the other hand, remember that the *SENDER* here is going to be in the >e-mail world - and people are *used* to putting half the known world into >the cc: list (heck, I had to trim *this* message's list by at least 3 or >4 addresses). The issue is not what the email originator does. The issue is what the sending MTA does. In other words, how it maps the recipient list, generated by the originator, into SMTP commands. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Thu Jul 4 02:43:37 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 CAA09359 for ; Thu, 4 Jul 2002 02:43:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g646UVk05904 for ietf-fax-bks; Wed, 3 Jul 2002 23:30:31 -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 g646UUw05894 for ; Wed, 3 Jul 2002 23:30:30 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KJMCBY0GRK001ZTY@mauve.mrochek.com> for ietf-fax@imc.org; Wed, 03 Jul 2002 23:30:27 -0700 (PDT) Date: Wed, 03 Jul 2002 22:59:44 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: "Your message dated Thu, 04 Jul 2002 01:26:50 -0400" <12403111.1025746010@localhost> To: John C Klensin Cc: ned.freed@mrochek.com, Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Message-id: <01KJOCIFSA84001ZTY@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <15649.62973.894081.566925@monkeyboy.gshapiro.net> <3D221C44.5F99DED6@messagingdirect.com> <108177848.1025639386@localhost> <01KJMM5WZSX8001ZTY@mauve.mrochek.com> <122335932.1025653541@localhost> <01KJMXAOJA04001ZTY@mauve.mrochek.com> <197128527.1025728324@localhost> <01KJO8ERG6OO001ZTY@mauve.mrochek.com> <12403111.1025746010@localhost> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > > (4) A general concern about the many possible > > uses for this mechanism that has all of us engaging in futile > > speculation and which cannot possibly be dealt sensibly with > > in a specification without actual implementation and use > > experience. > That is a reasonable position. But I suggest that it implies > either that this material should go to Experimental, rather than > Proposed, or that the mechanism should be defined as applicable > to the cases that are understood and expanded only when the > implications of that expansion are better understood. Or... Experimental status also occurred to me as a possible approach. > > The only clearly valid argument I've seen so far for removing > > REQUIRED is that it may not really be needed and things that > > aren't needed should not be there. But whether or not it is > > needed is really a question for the WG. Perhaps those who > > actually plan to implement CONNEG clients could comment on > > whether or not they view REQUIRED as something they need. > I, at least, would find such comments helpful. But I'd also > like to hear comments from at least one person responsible for a > general-purpose MTA (as distinct from a fax-over-email engine) > who expects to implement this feature and how they propose to do > so and how this feature fits in. There are two cases here: Client and server implementations. I definitely plan to implement the server side of this proposal. From that perspective all of the proposed variants are easy to implement as long as you have a source of conneg information to tap. I plan to use an LDAP attribute for this purpose. The client side for a general-purpose MTA is much harder, but not because of any aspect of the protocol. The issue I have there is how to match up an arbitrary set of site-provided conversion operations with the current group of recipient feature sets. I don't see a good solution to this other than making the whole thing something the site specifies, and if I do that I see little chance of the capability actually being used by enough sites to justify the cost of implementation. One final comment. A general-purpose MTA using arbitrary site-provided conversion routines doesn't have the luxury of being able to bound the performance or other characteristics of those conversion routines. This makes the entire convert-on-the-fly scenario problematic in ways that don't arise for a device built around a specific, limited and well understood set of on-the-fly converters, regardless of whether that device is a fax machine or something else entirely. Indeed, if I were to implement based on past bad experiences with various general-purpose conversion routines I'd be likely to break the problem down into three steps: (1) Collection of conneg information online, (2) Message splitting and conversion offline, (3) Sending the resulting emssages to their destination. I doubt I'd support using REQUIRED in (1). Ned From owner-ietf-fax@mail.imc.org Thu Jul 4 02:51:12 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 CAA09566 for ; Thu, 4 Jul 2002 02:51:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g646aPp06839 for ietf-fax-bks; Wed, 3 Jul 2002 23:36:25 -0700 (PDT) Received: from turing-police.cc.vt.edu (h80ad267c.async.vt.edu [128.173.38.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g646aNw06825 for ; Wed, 3 Jul 2002 23:36:23 -0700 (PDT) Received: from turing-police.cc.vt.edu (localhost [127.0.0.1]) by turing-police.cc.vt.edu (8.12.4/8.12.4) with ESMTP id g646ZeSQ023523; Thu, 4 Jul 2002 02:35:41 -0400 Message-Id: <200207040635.g646ZeSQ023523@turing-police.cc.vt.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: John C Klensin Cc: ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-Reply-To: Your message of "Thu, 04 Jul 2002 01:26:50 EDT." <12403111.1025746010@localhost> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face-Viewer: See ftp://cs.indiana.edu/pub/faces/index.html to decode picture X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ <3D221C44.5F99DED6@messagingdirect.com> <108177848.1025639386@localhost> <01KJMM5WZSX8001ZTY@mauve.mrochek.com> <122335932.1025653541@localhost> <01KJMXAOJA04001ZTY@mauve.mrochek.com> <197128527.1025728324@localhost> <01KJO8ERG6OO001ZTY@mauve.mrochek.com> <12403111.1025746010@localhost> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1279162412P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 04 Jul 2002 02:35:40 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==_Exmh_-1279162412P Content-Type: text/plain; charset=us-ascii On Thu, 04 Jul 2002 01:26:50 EDT, John C Klensin said: > That is a reasonable position. But I suggest that it implies > either that this material should go to Experimental, rather than > Proposed, or that the mechanism should be defined as applicable Would this address the concerns of everybody? -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_-1279162412P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE9I+y8cC3lWbTT17ARAhiqAKDlNGQw7EsXG2w2m5pi9DAiF2cSZgCdEMaw qFdH0NL8l9+fZVMpCRzGxMw= =9UF1 -----END PGP SIGNATURE----- --==_Exmh_-1279162412P-- From owner-ietf-fax@mail.imc.org Thu Jul 4 12:51: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 MAA21220 for ; Thu, 4 Jul 2002 12:51:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g64GVLv03332 for ietf-fax-bks; Thu, 4 Jul 2002 09:31:21 -0700 (PDT) Received: from turing-police.cc.vt.edu (h80ad2665.async.vt.edu [128.173.38.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g64GVIw03327 for ; Thu, 4 Jul 2002 09:31:19 -0700 (PDT) Received: from turing-police.cc.vt.edu (localhost [127.0.0.1]) by turing-police.cc.vt.edu (8.12.4/8.12.4) with ESMTP id g64GUQSQ028405; Thu, 4 Jul 2002 12:30:27 -0400 Message-Id: <200207041630.g64GUQSQ028405@turing-police.cc.vt.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: Dave Crocker Cc: ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-Reply-To: Your message of "Wed, 03 Jul 2002 23:28:03 PDT." <5.1.1.2.2.20020703232510.034bc008@jay.songbird.com> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face-Viewer: See ftp://cs.indiana.edu/pub/faces/index.html to decode picture X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ <15649.62973.894081.566925@monkeyboy.gshapiro.net> <3D221C44.5F99DED6@messagingdirect.com> <108177848.1025639386@localhost> <01KJMM5WZSX8001ZTY@mauve.mrochek.com> <122335932.1025653541@localhost> <01KJMXAOJA04001ZTY@mauve.mrochek.com> <5.1.1.2.2.20020703201153.034805f0@jay.songbird.com> <5.1.1.2.2.20020703232510.034bc008@jay.songbird.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1098396350P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 04 Jul 2002 12:30:26 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==_Exmh_-1098396350P Content-Type: text/plain; charset=us-ascii On Wed, 03 Jul 2002 23:28:03 PDT, Dave Crocker said: > And, by the way, it is inherent because a feature that is designed to > obtain per-recipient information is likely to be implemented in a way the > delivers per-recipient tailoring. When all you have is a hammer, everything looks like a nail... > The issue is not what the email originator does. The issue is what the > sending MTA does. > > In other words, how it maps the recipient list, generated by the > originator, into SMTP commands. And there is currently disagreement whether to keep using nails, or if bolts would be a better fastening device. My point was that the original "send to one recipient" mindset won't last very long, so whatever mapping we end up using had better not be *too* horrendously inefficient. People *will* end up sending to multiple recipients at a destination (unless we insist that "destination" will be a "personal device" (like a PDA etc) rather than a "mail server". -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_-1098396350P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE9JHgicC3lWbTT17ARAq11AJ0f31JKJ8ar/bRGLiB6UJ7LKVcnIgCfTT4x F/hRoy/QQ935jJL5nuuGzgo= =kcU6 -----END PGP SIGNATURE----- --==_Exmh_-1098396350P-- From owner-ietf-fax@mail.imc.org Thu Jul 4 14:29:42 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 OAA22606 for ; Thu, 4 Jul 2002 14:29:41 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g64IEGJ13138 for ietf-fax-bks; Thu, 4 Jul 2002 11:14:16 -0700 (PDT) Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g64IEEw13132 for ; Thu, 4 Jul 2002 11:14:14 -0700 (PDT) Received: from [192.168.1.3] (ool-18e43cab.dyn.optonline.net [24.228.60.171]) by mail2.panix.com (Postfix) with ESMTP id 2E87F913B; Thu, 4 Jul 2002 14:14:16 -0400 (EDT) Mime-Version: 1.0 X-Sender: hal9001@popserver.panix.com (Unverified) Message-Id: In-Reply-To: <41CBB274CC77984D8A365C0A1B79F692214733@mail.toshiba-tap.com> References: <41CBB274CC77984D8A365C0A1B79F692214733@mail.toshiba-tap.com> X-Mailer: Eudora Pro 5.1.1b22 PPC (Macintosh) Date: Thu, 4 Jul 2002 14:08:38 -0400 To: ietf@ietf.org, ietf-fax@imc.org From: "Robert A. Rosenberg" Subject: RE: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard 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 09:31 +1000 on 07/04/2002, Gerry Sancataldo wrote about RE: Last Call: SMTP Service Extension for Content Negot: >Hi all, > >I am involved in the technical support/ training area for fax and >internet fax devices and would just like to add that typically a >message/transaction is directed to one recipient only. > >(I make no judgement as to other services that may piggyback on SMTP >and if they will typically include multiple recipients). > >As the number of Multi-function devices supporting Internet fax move >to an increasing number of options (colour copiers etc supporting >Internet fax) I suspect that the onus should be on the recipient >client to confirm its capabilities, not the server. > >I make no judgement as to other services that may piggyback on SMTP >and if they will typically include multiple recipients. > > >Cheers, > >Gerry I think you might be looking at the issue from a inaccurate prospective. What is being attempted is to port the "Fax Broadcast" Scenario to delivering the Fax via the Internet as opposed to POTS. In the POTS Broadcast method, each copy is a separate connection and thus any reformatting is done due to the Connect Handshake Capabilities exchange. This tailoring capability needs to be preserved. If you feel (or have some data to support) that only an insignificant number of the total Fax Volume are Broadcast (multi-addressed) Faxes, then that might support your initial statement. From owner-ietf-fax@mail.imc.org Thu Jul 4 14:29:55 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 OAA22621 for ; Thu, 4 Jul 2002 14:29:55 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g64IEHh13145 for ietf-fax-bks; Thu, 4 Jul 2002 11:14:17 -0700 (PDT) Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g64IEFw13137; Thu, 4 Jul 2002 11:14:15 -0700 (PDT) Received: from [192.168.1.3] (ool-18e43cab.dyn.optonline.net [24.228.60.171]) by mail2.panix.com (Postfix) with ESMTP id EBD5D910F; Thu, 4 Jul 2002 14:14:13 -0400 (EDT) Mime-Version: 1.0 X-Sender: hal9001@popserver.panix.com (Unverified) Message-Id: In-Reply-To: <5.1.1.2.2.20020703142511.019f51a0@jay.songbird.com> References: <5.1.1.2.2.20020702183611.0354a798@jay.songbird.com> <(Your message of "Tue, 02 Jul 2002 19:45:19 EDT.") <107911393.1025639119@localhost> <5.1.1.2.2.20020702183611.0354a798@jay.songbird.com> <5.1.1.2.2.20020703142511.019f51a0@jay.songbird.com> X-Mailer: Eudora Pro 5.1.1b22 PPC (Macintosh) Date: Thu, 4 Jul 2002 13:58:59 -0400 To: iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org From: "Robert A. Rosenberg" Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard 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 14:27 -0700 on 07/03/2002, Dave Crocker wrote about Re: Last Call: SMTP Service Extension for Content Negot: >At 04:40 PM 7/3/2002 -0400, Robert A. Rosenberg wrote: > >CONNEG appears at its root to be an attempt to avoid the "wasted" > >bandwidth and processing time/effort to create a M-P/A MIME message most >>of whose content the Recipient is going to ignore after receipt. It also >>removes the requirement that the Recipient is even capable of parsing a >>M-P/A MIME message to locate the "correct" version of FAX which it can >>understand/process. > >Hmmm. As I recall, the specification was not developed with this goal in >mind. However I think that you are pointing out a trade-off in the use of >ESMTP/CONNECT and Multipart/Alternative that is largely correct. > >(I say largely rather than completely because there are some feature >combinations that define so many combinatorials, they could not be >considered for M/A but are straightforward for CONNEG.) > >Still, you do raise an interesting perspective. > >d/ > Thank you. I am looking at the issue from a overview perspective (IOW: How does CONNEG work vs. How would M-P/A work). Since I was not involved in the development of CONNEG, I do not know the intent of the developers - All I can comment on is the effect of its operation in comparison with other methods and state what the EFFECT of the choices made are (while taking the effect as the intent even though this linkage is probably spurious). As to the multiple combinations, that was covered by my " 'wasted' ... processing time/effort". Beyond a certain point, the generation of multiple versions (just to be complete) when only one (or a limited number) are going to ultimately be used is an exercise in futility. The advantage of CONNEG is that you get the information to generate a full list of the different combinations you must produce. The issue is what you do then. Do you generate the requisite number of combinations and send them out as the minimal number of message copies (lumping together those addresses that can share a copy - even if that copy is not an exact match to the full capabilities of the receiver as in the case of sending a B&W Fax to a Color Capable Recipient). IMO, the ultimate aim (even if this is not practical) is to deliver to each recipient the same version of the Fax as they would have received IF they were the only addressee while at the same time generating only the minimum number of copies to allow multi-addressing. IOW: A one copy (/limited number of copies) LCD "solution" is not the "Best" solution since it will produce a Fax that is not the same as would have been delivered if there were no other addresses. From owner-ietf-fax@mail.imc.org Thu Jul 4 15:02:04 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 PAA22965 for ; Thu, 4 Jul 2002 15:02:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g64IlxK15978 for ietf-fax-bks; Thu, 4 Jul 2002 11:47:59 -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 g64Ilvw15973 for ; Thu, 4 Jul 2002 11:47:57 -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 g64IlnZ01345; Thu, 4 Jul 2002 14:47:50 -0400 (EDT) Message-Id: <200207041847.g64IlnZ01345@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: ned.freed@mrochek.com cc: Keith Moore , John C Klensin , Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Wed, 03 Jul 2002 17:18:54 PDT.") <01KJO6VZBYM0001ZTY@mauve.mrochek.com> Date: Thu, 04 Jul 2002 14:47:49 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > > > granted it's necessary for the client to be able to do that, but my point > > > > is that having the server report conneg faliures in the RCPT status code > > > > doesn't relieve the client of the necessity to detect other conditions > > > > resulting from valid conneg strings that can cause delivery failure. > > > > it's not as if the client can rely only on the response code to determine > > > > how to handle the message. > > > > > > Sure, but it is only useful to treat such failures as permanent. > > > how so? > > Because you said: "other conditions resulting from valid conneg strings that > can cause delivery failure." If the conneg result is something you do not like > I don't think treating this as a temporary failure in hopes the conneg string > will change in the future is either reasonable or appropriate. When you said "such failures" I wasn't sure which failures you were talking about - the ones that are caused by server inability to supply a conneg string or those caused by conneg strings that indicate that no conversion is possible. (since the quoted paragraph mentioned both kinds of failure) > > if there is a temporary failure to get conneg information, the > > client might quite reasonably decide to retry later. or if the client > > can't translate part of the message, it might reasonably decide that > > delivering the remainder of the message is preferable to bouncing it. > > That wasn't the case you were talking about. That response was based on a guess as to what you were talking about. I guessed wrong. > > > I remain unconvinced that this is a useful distinction. What REQUIRED says is > > > "I absolutely require CONNEG info and as such a failure to have it is the same > > > to me as any other sort of failure and should be responded to accordingly". > > > it's still poor separation of function, and it's still asking the server > > to report a failure condition which the client understands better than the > > server does. E.g. the server is told to report errors as 4.3.3 or 5.3.3 > > when codes x.6.1 or x.6.2 or x.6.3 might be more appropriate. The server > > can't tell the difference between those conditions; the client can. > > Ah, I see. We've moved from assertions that there were sure to be problems to > the nonspecific "poor separation of function". Admittedly "poor separation of function" is a nonspecific description of the problem, but a more specific description followed which described what I meant. Asking the server to report reply codes and (more importantly) enhanced status codes that don't accurately describe the condition that caused the failure, (and cannot, because the server lacks the information necessary to distinguish those conditions) doesn't seem like good protocol design to me. The words "poor separation of function" seem like an accurate description of this kind of design flaw, though I wouldn't expect someone to understand my criticism of the design (or accept the argument for changing it) from those four words alone. > But the entire point of REQUIRED > is to say "I don't want these functions separated; conneg failures are just > like any other failure to me". Admitted that this is the entire point of REQUIRED; the question is whether this is good design or an appropriate feature to include. Using REQUIRED doesn't simplify the design of the client by any significant amount (if at all), and by using REQUIRED a client somewhat impairs its ability to produce meaningful error reports. In short: REQUIRED is not necessary because clients can detect a missing CONNEG string by other means, it doesn't seem to be useful because it doesn't simplify either the client or the server nor make them more efficient, it encourages client implementors to produce less meaningful error reports, and even though the implementation overhead is low, it does add additional baggage to the protocol. The real question is, why do we want this? > > > Why? If the client doesn't want CONNEG to alter the status all it has to do is > > > use OPTIONAL rather than REQUIRED. Again, REQUIRED implies that the client is > > > willing to treat different sorts of failures in the same way. > > > well, if we had such other features then the client wanting to assert such > > other features would not be able to assert CONNEG=REQUIRED, it would just > > have to implement the error detection by itself. > > Doesn't follow. If some other functionality is implemented that results in RCPT > TO failing in some new way it can return errors in the same way. Of course the > error report is limited to a single error condition, but the potential for > multiple failures having to be collapsed into a single return value already > exists in abundance; the existance of this extension or an arbitrary number of > future extensions changes nothing in this regard. I agree that we already have the potential for RCPT to report several kinds of errors, though I do think adding new conditions is likely to contribute to less precise error reporting. And prior to this proposal all of the errors reported by the server have been for conditions which were better detected by the server - this proposal is new in that it asks the server to report an error for a condition which is better detected by the client. > > > Again, I think a means of distinguishing conneg material in the response is a > > > good idea and I'm not opposed to eliminating REQUIRED. But really don't believe > > > REQUIRED causes the problems you think it does. > > > The overall effect of REQUIRED is probably to increase the number of > > implementation errors and the number of mis-reported delivery failures. > > Well, I've worked out what code is necessary to do this, and IMO this just > doesn't rise to the level of complexity for this to be the case. The code to implement REQUIRED on either the client or server end is trivial. On the other hand, the effort required for a new implementor to understand SMTP and how this extension interacts with all of the other ones is nontrivial. On numerous occasions we've both seen that even somewhat mature implementations frequently misunderstand far less subtle aspects of email protocols than those being discussed here. This proposal introduces new opportunities for misunderstanding. Some of them are due to the way that the protocol extension works, others are due to the description (or lack thereof) of how the extension is to be used. I believe that every new bit of complexity that we add to SMTP requires significant justification, whether that complexity is measured in lines of code, in lines of text that implementors have to understand, or (especially!) in undocumented assumptions on the part of the designer that implementors have to figure out. And every bit of unnecessary complexity we can remove from a proposed extension is worthwhile. We might disagree on the relative merits of a particular feature, and some of that is to be expected. But when we get into extended arguments about a single aspect of the design we should not lose sight of the overall picture: We need for email to work reliably. In various ways this proposal adds unnecessary complexity, and lacks the degree of background explanation that is necessary to allow implementors to understand how to use it, especially for non-fax cases. If it seems like I'm attacking the proposal harshly, it's only because I'm painfully aware of how often SMTP is misimplemented, and because I think that these discussions should have been had in the broader SMTP implementor community long before IETF-wide Last Call. Keith From owner-ietf-fax@mail.imc.org Thu Jul 4 15:31:17 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 PAA23374 for ; Thu, 4 Jul 2002 15:31:16 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g64JFUk18416 for ietf-fax-bks; Thu, 4 Jul 2002 12:15:30 -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 g64JF9w18396; Thu, 4 Jul 2002 12:15:09 -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 g64JFAZ01465; Thu, 4 Jul 2002 15:15:10 -0400 (EDT) Message-Id: <200207041915.g64JFAZ01465@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Robert A. Rosenberg" cc: iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Thu, 04 Jul 2002 13:58:59 EDT.") Date: Thu, 04 Jul 2002 15:15:10 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > IMO, the ultimate aim (even if this is not practical) is to deliver > to each recipient the same version of the Fax as they would have > received IF they were the only addressee I think this is a reasonable and practical goal. I don't think that recipient A should experience a difference in message quality (or worse, fail to receive the message at all) based on whether or not you cc'ed recipient B. > while at the same time > generating only the minimum number of copies to allow > multi-addressing. I think this is an implementation decision. It should be *possible* to do this (and it is), but it shouldn't be required of implementations. here are a couple of trivial examples of the effect of a "downgrade to LCD format" implementation strategy. assume: recipient A accepts only HTML and plain text recipient B accepts only PDF and plain text an HTML message sent only to A gets delivered as HTML, but if B is cc'ed (or bcc'ed) on the message then both A and B get plain text (if the client knows how to convert HTML to plain text). A is accustomed to receiving HTML from B and is surprised that there's an information loss. more seriously, a PDF message sent only to B gets delivered as PDF, but if A is cc'ed on the message then the message is bounced for both A and B because there's no good way to downgrade PDF to a format acceptable to B (or the client doesn't know how). So far I have not been able to identify conditions for which downgrading to LCD is a viable implementation strategy. My conclusion is that implementations that support CONNEG and that attempt to deliver to mutliple recipients in one transaction MUST be prepared to do RSET and split up the delivery if it becomes evident that delivering the same version of the message to all recipients is not appropriate. Keith From owner-ietf-fax@mail.imc.org Thu Jul 4 15:40:26 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 PAA23515 for ; Thu, 4 Jul 2002 15:40:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g64JPgr19116 for ietf-fax-bks; Thu, 4 Jul 2002 12:25:42 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g64JPew19111 for ; Thu, 4 Jul 2002 12:25:40 -0700 (PDT) Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17QCEV-000Bkv-00; Thu, 04 Jul 2002 19:25:39 +0000 Date: Thu, 04 Jul 2002 15:25:39 -0400 From: John C Klensin To: Dave Crocker cc: ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Message-ID: <62740632.1025796339@localhost> In-Reply-To: <5.1.1.2.2.20020703231428.01a16be8@jay.songbird.com> References: <01KJO8ERG6OO001ZTY@mauve.mrochek.com> <15649.62973.894081.566925@monkeyboy.gshapiro.net> <3D221C44.5F99DED6@messagingdirect.com> <108177848.1025639386@localhost> <01KJMM5WZSX8001ZTY@mauve.mrochek.com> <122335932.1025653541@localhost> <01KJMXAOJA04001ZTY@mauve.mrochek.com> <197128527.1025728324@localhost> <01KJO8ERG6OO001ZTY@mauve.mrochek.com> <5.1.1.2.2.20020703231428.01a16be8@jay.songbird.com> X-Mailer: Mulberry/3.0.0a3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit --On Wednesday, 03 July, 2002 23:18 -0700 Dave Crocker wrote: > At 01:26 AM 7/4/2002 -0400, John C Klensin wrote: >> That is a reasonable position. But I suggest that it implies >> either that this material should go to Experimental, rather >> than Proposed, or that the mechanism should be defined as >> applicable to the cases that are understood and expanded only >> when the implications of that expansion are better >> understood. Or... > > As nearly as I can tell, your position is that folks can raise > a spectre of myriad, unspecified, abstract and unlikely > concerns and then use that as a claim that a specification > should not go to Proposed... Until this long list of > negatives has been disproved. > > That's very creative. It also is at considerable odds with > typical IETF criteria for advancement, John. It is also a > heck of a good way to make sure that no proposal ever goes to > Proposed. > > So, please explain what prompts such unique and extraordinary > criteria for this simple and mundane proposal? Dave, I think this has ceased to be constructive, so I'm going to drop out before the serious name-calling starts. I would suggest, however, that you consider three things: (i) While there are clearly some differences in the two cases, the notion of applying an option very broadly, more broadly than the implications are understood, and then underspecifying it a bit, is exactly one of the things that both of us are objecting to in the IDN situation. Now, we disagree on whether or not the relaying cases (in particular) are poorly understood. As I understand your position, it is that we relay things all of the time, so this is no different and relaying is well-understood. Mine is that we have very few cases in which options, when applied to relaying, more or less assume end-to-end knowledge rather than hop-by-hop processing. And when we do, I suggest the precedent is that we carefully work out exactly what is supposed to happen, with 8BITMIME being a reasonably good example. (ii) Under any theory I can construct of what is going on here, the capabilities inquiry is expected to yield, in the normal case, a statement about the capabilities of the destination user agent. Capabilities of the transport subsystem are not at issue: unlike, e.g., 8BITMIME or various DSN options, these capabilities have to do with message format and content, not transport properties. Asking an MTA about the capabilities and properties of an MUA to which it will channel mail (possibly through some delivery intermediate) is something that, as far as I know, we have never done before. In addition, it is arguably a non-trivial layering violation. Whatever those characteristics imply about this proposal -- as I trust you know, I will not resort to arguments about architectural purity when something legitimate needs to be accomplished and the only plausible way of doing it is architecturally-impure -- I think they don't permit it to be characterized as "simple and mundane". (iii) My understanding of IETF precedents is that we are typically very careful when changes are proposed to widely-deployed and critical infrastructure and applications. We commonly set the bar higher for such things -- publishing as Experimental, requiring implementation experience and/ or much more case analysis for Proposed, etc. -- than we do for now protocols that can't have any spillover impact. Reasonable people can disagree as to whether a new ESTMP option carries with it sufficient interaction risk that it should get this closer scrutiny. But I note that this review process has already identified (and agreed to fix) on place where CONNEG was underspecified relative to other SMTP options. And, of course, RFC 1425, in laying the groundwork for these extensions, says: It must be emphasized that any extension to the SMTP service should not be considered lightly. SMTP's strength comes primarily from its simplicity. Experience with many protocols has shown that: protocols with few options tend towards ubiquity, whilst protocols with many options tend towards obscurity. This means that each and every extension, regardless of its benefits, must be carefully scrutinized with respect to its implementation, deployment, and interoperability costs. In many cases, the cost of extending the SMTP service will likely outweigh the benefit. You will recall that I was not the author of that particular text, and did not think it was necessary. Clearly I was wrong. And I am suggesting that this proposal be scrutinized in that light and that, in that light, _no_ SMTP extension should be added because it is "simple and mundane". john From owner-ietf-fax@mail.imc.org Thu Jul 4 15:51:58 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 PAA23759 for ; Thu, 4 Jul 2002 15:51:58 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g64JaDT20029 for ietf-fax-bks; Thu, 4 Jul 2002 12:36:13 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g64JaBw20024 for ; Thu, 4 Jul 2002 12:36:12 -0700 (PDT) Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17QCOe-000BmL-00; Thu, 04 Jul 2002 19:36:08 +0000 Date: Thu, 04 Jul 2002 15:36:07 -0400 From: John C Klensin To: ned.freed@mrochek.com cc: Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Message-ID: <63368316.1025796967@localhost> In-Reply-To: <01KJOCIFSA84001ZTY@mauve.mrochek.com> References: <15649.62973.894081.566925@monkeyboy.gshapiro.net> <3D221C44.5F99DED6@messagingdirect.com> <108177848.1025639386@localhost> <01KJMM5WZSX8001ZTY@mauve.mrochek.com> <122335932.1025653541@localhost> <01KJMXAOJA04001ZTY@mauve.mrochek.com> <197128527.1025728324@localhost> <01KJO8ERG6OO001ZTY@mauve.mrochek.com> <12403111.1025746010@localhost> <01KJOCIFSA84001ZTY@mauve.mrochek.com> X-Mailer: Mulberry/3.0.0a3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit --On Wednesday, 03 July, 2002 22:59 -0700 ned.freed@mrochek.com wrote: >> I, at least, would find such comments helpful. But I'd also >> like to hear comments from at least one person responsible >> for a general-purpose MTA (as distinct from a fax-over-email >> engine) who expects to implement this feature and how they >> propose to do so and how this feature fits in. > > There are two cases here: Client and server implementations. > > I definitely plan to implement the server side of this > proposal. From that perspective all of the proposed variants > are easy to implement as long as you have a source of conneg > information to tap. I plan to use an LDAP attribute for this > purpose. >... Interesting. Instead of "ask the receiving client", you would rely on a database that proported to know the client's behavior and capabilities. That certainly makes implementation easier and might also deal with the relay situation by permitting the first (and subsequent?) relays to ask the database rather than replying "no clue about the client, I don't deliver to it" (the latter is one of the cases I've been concerned about). However: (i) It would seem to me to be reasonable to write this option down (as an option) rather than leaving implementers guessing. (ii) Given the notorious "wks" experience, with trying to put target host capabilities into an ancillary database, it seems to me that this would further justify experimental status so that we can get some sense as to whether the database would be kept adequately up-to-date. Certainly our experience should cause us to be skeptical about that. > The client side for a general-purpose MTA is much harder, but > not because of any aspect of the protocol. The issue I have > there is how to match up an arbitrary set of site-provided > conversion operations with the current group of recipient > feature sets. I don't see a good solution to this other than > making the whole thing something the site specifies, and if I > do that I see little chance of the capability actually being > used by enough sites to justify the cost of implementation. > > One final comment. A general-purpose MTA using arbitrary > site-provided conversion routines doesn't have the luxury of > being able to bound the performance or other characteristics > of those conversion routines. This makes the entire > convert-on-the-fly scenario problematic in ways that don't > arise for a device built around a specific, limited and well > understood set of on-the-fly converters, regardless of whether > that device is a fax machine or something else entirely. > Indeed, if I were to implement based on past bad experiences > with various general-purpose conversion routines I'd be likely > to break the problem down into three steps: (1) Collection of > conneg information online, (2) Message splitting and > conversion offline, (3) Sending the resulting emssages to > their destination. I doubt I'd support using REQUIRED in (1). I can only agree with both of these comments and complement you on the clarity of your explanation of them. john From owner-ietf-fax@mail.imc.org Thu Jul 4 15:56:18 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 PAA23826 for ; Thu, 4 Jul 2002 15:56:17 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g64JfZF20350 for ietf-fax-bks; Thu, 4 Jul 2002 12:41:35 -0700 (PDT) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g64JfXw20345 for ; Thu, 4 Jul 2002 12:41:34 -0700 (PDT) Received: from marajade.sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g64JfNW02343 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Thu, 4 Jul 2002 15:41:24 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id g64Jf41V003273; Thu, 4 Jul 2002 15:41:05 -0400 Message-Id: <200207041941.g64Jf41V003273@marajade.sandelman.ottawa.on.ca> To: "COLES, RICHARD J. (JSC-EV) (LM)" CC: ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation toP roposed Standard In-reply-to: Your message of "Wed, 03 Jul 2002 09:35:59 CDT." <1408A865DCF403478A33EE887F87473201C13B43@jsc-mail03.jsc.nasa.gov> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 04 Jul 2002 15:41:03 -0400 From: Michael Richardson Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- >>>>> "JSC-EV)" == JSC-EV) (LM writes: JSC-EV)> FAX is NOT dead at NASA. JSC-EV)> We send a LOT of documents to other centers that cannot be sent via e-mail JSC-EV)> (photocopies of shipping documents, flight manifests, older engineering JSC-EV)> drawings, etc [things that are not available electronically]). That is why JSC-EV)> I am so interested in seeing this work completed. Do you really send faxes? Is this what you really want to do? I mean to say you want to negotiate 9600 baud connections over the Internet using some kind of VoIP? Or do you mean that you want a way to send a binary piece of data (representing an image) from one party to another in an automated, batch oriented way. Perhaps I can introduce you to a protocol called "FTP". It has rather interesting authentication features that are in widespread use. If you prefer, there is another protocol called "HTTP" that might help. I've heard it is pretty popular now. If you want batch transfer with retries, there is also UUCP-over-TCP. Port 540. ==== Seriously, we need *LESS* junk sent by email, not more. The whole FAX over email problem is simply endemic of the fact that we have no(%) *end-user* to *end-user* file transfer protocols. (To be useful, we would ideally need a global PKI, but we can certainly start simpler) ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPSSkzYqHRg3pndX9AQH6yQP/Xl9CsNfTw61qTlWJkNtxzgwt2iqi9Ncf ONvV2fP+f9gU1/bH/kCnrzkiHWEc+hiDiAlvI9VSkSZvhukG+mXhO3B2fkcycPeo nySP//5NbtUbuc0XwAYzHZj9Uru/E6Skgz97Ar/OxjdXXQ6KohLEfNxGwgAryOPo og/ePO4AB3E= =YPaY -----END PGP SIGNATURE----- From owner-ietf-fax@mail.imc.org Thu Jul 4 16:55:22 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 QAA24705 for ; Thu, 4 Jul 2002 16:55:21 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g64KdGu24543 for ietf-fax-bks; Thu, 4 Jul 2002 13:39:16 -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 g64KdFw24539 for ; Thu, 4 Jul 2002 13:39:15 -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 NAA27967; Thu, 4 Jul 2002 13:45:14 -0700 Message-Id: <5.1.1.2.2.20020704125626.035305b8@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Thu, 04 Jul 2002 13:37:56 -0700 To: John C Klensin From: Dave Crocker Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Cc: ietf@ietf.org, ietf-fax@imc.org In-Reply-To: <62740632.1025796339@localhost> References: <5.1.1.2.2.20020703231428.01a16be8@jay.songbird.com> <01KJO8ERG6OO001ZTY@mauve.mrochek.com> <15649.62973.894081.566925@monkeyboy.gshapiro.net> <3D221C44.5F99DED6@messagingdirect.com> <108177848.1025639386@localhost> <01KJMM5WZSX8001ZTY@mauve.mrochek.com> <122335932.1025653541@localhost> <01KJMXAOJA04001ZTY@mauve.mrochek.com> <197128527.1025728324@localhost> <01KJO8ERG6OO001ZTY@mauve.mrochek.com> <5.1.1.2.2.20020703231428.01a16be8@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: At 03:25 PM 7/4/2002 -0400, John C Klensin wrote: >(i) While there are clearly some differences in the two cases, >the notion of applying an option very broadly, more broadly than >the implications are understood, and then underspecifying it a >bit, is exactly one of the things that both of us are objecting >to in the IDN situation. Well, no. Relative to this discussion, my concern with IDN is that the technical specification has a gaping hole -- it is missing an essential piece of specification detail -- and that that hole pertains specifically to the most important immediate use. So IDN is not about scope. By contrast -- ignoring the few postings from folk who have diligently attended to writing details that need to be fixed -- the focus of concerns from you and Keith has exclusively been about scope that might be or misinterpretations that might me. Notably missing, in fact, has been discussion of technical details, except for some forays into alternative approaches or alternative problem spaces. >As I >understand your position, it is that we relay things all of the >time, so this is no different and relaying is well-understood. Lest one miss the focus of my comment on this, let me repeat it: "If there is relaying with CONNEG support, then CONNEG is used at each hop. Just like for DSN." In other words, we are not breaking any architectural ground here, contrary to the claim that has been made. >Mine is that we have very few cases in which options, when >applied to relaying, more or less assume end-to-end knowledge >rather than hop-by-hop processing. And when we do, I suggest >the precedent is that we carefully work out exactly what is >supposed to happen, with 8BITMIME being a reasonably good >example. CONNEG already covers your concern. If the option is required, then the receiving MTA must commit to supporting it. If it cannot make the commitment, then the address must be failed. If the option is optional, then the sender leaves handling outcome to the receiver. If you have any other relaying concerns, please state them with enough detail to permit technical analysis and response. Otherwise, yours and Keith's concerns reduce to a statement that you have generic fears, without any detailed basis, and that your fears should cause the community to slow-roll this specification. >Asking an MTA about the capabilities and >properties of an MUA to which it will channel mail (possibly >through some delivery intermediate) is something that, as far as >I know, we have never done before. Isn't it wonderful that we sometimes do something new in the IETF? 1. We have already done hop-by-hop options that have end-to-end effect. 2. We have already done CONNEG syntax and semantics. 3. We have already done email-based CONNEG exchanges, though the mysteries of the IETF standardization process are causing that work of more than one year ago to finally get approved by the IESG now. 4. We have already done third-party information disclosure mechanisms. That is, how is this conceptually different from an LDAP lookup? For that matter, how is is different from TCP MSS "disclosure"? It, too, causes the other participant to change what is sent. So, A. Yes, we are defining a way to do something that you cannot do today, B. But the components to that mechanism all have prior existence, C. And the mechanism involved is pretty simple, D. And no one has yet put forward a concrete scenario that demonstrates that the specification is flawed. >(iii) My understanding of IETF precedents is that we are >typically very careful when changes are proposed to >widely-deployed and critical infrastructure and applications. And we are notably more lax when the change is optional and incremental and, therefore, need not be implemented except by those wishing to play in that sandbox. > But I note that this review process has >already identified (and agreed to fix) on place where CONNEG was >underspecified relative to other SMTP options. If you mean something other than have a "context" label in the portion of the response pertaining to the context, then it was not in Ned's summary. If you believe that identification of the need for that label is somehow strategically meaningful, then it sounds as if you expect a degree of perfection for a Proposed Standard that is at variance with IETF norms. For that matter, it suggests that you believe that a Last Call that uncovers the need for any changes automatically forces the specification to go back to square one or be classed as experimental. >You will recall that I was not the author of that particular >text, and did not think it was necessary. Clearly I was wrong. The nice thing about statements of philosophy is that they provide a guiding framework. The not-so-nice thing about them is that they do not provide specific detail. Invoke philosophy in decision making, without having any attendant detail, and all you are doing is being religious. When you produce some technical details that demonstrate how this proposal fails -- or better still, how it damages SMTP operation -- then invoking that higher bit of philosophy will be warranted. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Thu Jul 4 18:31:15 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 SAA26099 for ; Thu, 4 Jul 2002 18:31:14 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g64MEpa01236 for ietf-fax-bks; Thu, 4 Jul 2002 15:14:51 -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 g64MEpw01231 for ; Thu, 4 Jul 2002 15:14:51 -0700 (PDT) Received: from GK-VAIO.ninebynine.org (dyn163-40.sftm-212-159.plus.net [212.159.40.163] (may be forged)) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g64MBo421660; Thu, 4 Jul 2002 15:11:50 -0700 Message-Id: <5.1.0.14.2.20020704231319.04708dd0@joy.songbird.com> X-Sender: gk-lists@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 04 Jul 2002 23:17:25 +0100 To: John C Klensin From: Graham Klyne Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Cc: ietf-fax@imc.org In-Reply-To: <5.1.0.14.2.20020703224517.01cd3d90@jay.songbird.com> References: <13310286.1025746917@localhost> <5.1.1.2.2.20020703185729.01b1f0f8@jay.songbird.com> <5.1.1.2.2.20020703142511.019f51a0@jay.songbird.com> <5.1.1.2.2.20020702183611.0354a798@jay.songbird.com> <(Your message of "Tue, 02 Jul 2002 19:45:19 EDT.") <107911393.1025639119@localhost> <5.1.1.2.2.20020702183611.0354a798@jay.songbird.com> <5.1.1.2.2.20020703142511.019f51a0@jay.songbird.com> <5.1.1.2.2.20020703185729.01b1f0f8@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: I am pretty confident this is not the case with CONNEG feature matching. At worst, I think it's polynomial in the size of the feature expression, and typically closer to linear. The worst-case arises when expressions contain repeated conjunctions of disjunctions which lead to a multiplicity of conjunctions when reduced to the disjunctive normal form. #g -- At 01:41 AM 7/4/2002 -0400, John C Klensin wrote: > With a >sufficiently complex (non-binary and non-orthogonal) capability >set, I suspect the computation might even turn out to be >NP-hard. ------------------- Graham Klyne From owner-ietf-fax@mail.imc.org Thu Jul 4 19:40:33 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 TAA27753 for ; Thu, 4 Jul 2002 19:40:32 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g64NOff07388 for ietf-fax-bks; Thu, 4 Jul 2002 16:24:41 -0700 (PDT) Received: from tap_exchange.toshiba-tap ([203.56.127.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g64NOdw07384 for ; Thu, 4 Jul 2002 16:24:40 -0700 (PDT) Received: by mail.toshiba-tap.com with Internet Mail Service (5.5.2655.55) id <3HN7V5G6>; Fri, 5 Jul 2002 09:24:36 +1000 Message-ID: <41CBB274CC77984D8A365C0A1B79F69221473C@mail.toshiba-tap.com> From: Gerry Sancataldo To: "'Robert A. Rosenberg'" , ietf@ietf.org, ietf-fax@imc.org Subject: RE: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Date: Fri, 5 Jul 2002 09:24:27 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C223B1.F088B5B0" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C223B1.F088B5B0 Content-Type: text/plain hmm, Fax broadcasts are traditionally done to a set group of recipients (e.g. a companies interstate offices) as traditional fax based devices require these destinations to be pre-programmed in the device phonebook, these phone books entries in many cases can be set up with the recipient capabilities also defined for that individual recipient (e.g. resolution, compression , page size etc). Let's not forget that broadcasting is loosing popularity as mail merge to network fax / email provides more effective broadcasting due to the ability to address a specific individual as a recipient. I am currently surveying a number of sites (Australian) that are currently using Internet Fax and preliminary data indicates that over 98% of traffic is to a single recipient. However, I do acknowledge that this may not be the case in other countries or in the future as Internet fax capable devices become more affordable. Gerry -----Original Message----- From: Robert A. Rosenberg [mailto:hal9001@panix.com] Sent: Friday, 5 July 2002 4:09 AM To: ietf@ietf.org; ietf-fax@imc.org Subject: RE: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard At 09:31 +1000 on 07/04/2002, Gerry Sancataldo wrote about RE: Last Call: SMTP Service Extension for Content Negot: >Hi all, > >I am involved in the technical support/ training area for fax and >internet fax devices and would just like to add that typically a >message/transaction is directed to one recipient only. > >(I make no judgement as to other services that may piggyback on SMTP >and if they will typically include multiple recipients). > >As the number of Multi-function devices supporting Internet fax move >to an increasing number of options (colour copiers etc supporting >Internet fax) I suspect that the onus should be on the recipient >client to confirm its capabilities, not the server. > >I make no judgement as to other services that may piggyback on SMTP >and if they will typically include multiple recipients. > > >Cheers, > >Gerry I think you might be looking at the issue from a inaccurate prospective. What is being attempted is to port the "Fax Broadcast" Scenario to delivering the Fax via the Internet as opposed to POTS. In the POTS Broadcast method, each copy is a separate connection and thus any reformatting is done due to the Connect Handshake Capabilities exchange. This tailoring capability needs to be preserved. If you feel (or have some data to support) that only an insignificant number of the total Fax Volume are Broadcast (multi-addressed) Faxes, then that might support your initial statement. ------_=_NextPart_001_01C223B1.F088B5B0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Last Call: SMTP Service Extension for Content Negotiation to = Proposed Standard

hmm,

Fax broadcasts are traditionally done to a set group = of recipients (e.g. a companies interstate offices) as traditional fax = based devices require these destinations to be pre-programmed in the = device phonebook, these phone books entries in many cases can be set up = with the recipient capabilities also defined for that individual = recipient (e.g. resolution, compression , page size  = etc).

Let's not forget that broadcasting is loosing = popularity as mail merge to network fax / email provides more effective = broadcasting due to the ability to address a specific individual as a = recipient.

I am currently surveying a number of sites = (Australian) that are currently using Internet Fax and preliminary data = indicates that over 98% of traffic is to a single recipient.

However, I do acknowledge that this may not be the = case in other countries or in the future as Internet fax capable = devices become more affordable.


Gerry

-----Original Message-----
From: Robert A. Rosenberg [mailto:hal9001@panix.com]
Sent: Friday, 5 July 2002 4:09 AM
To: ietf@ietf.org; ietf-fax@imc.org
Subject: RE: Last Call: SMTP Service Extension for = Content Negotiation
to Proposed Standard



At 09:31 +1000 on 07/04/2002, Gerry Sancataldo wrote = about RE: Last
Call: SMTP Service Extension for Content = Negot:

>Hi all,
>
>I am involved in the technical support/ training = area for fax and
>internet fax devices and would just like to add = that typically a
>message/transaction is directed to one recipient = only.
>
>(I make no judgement as to other services that = may piggyback on SMTP
>and if they will typically include multiple = recipients).
>
>As the number of Multi-function devices = supporting Internet fax move
>to an increasing number of options (colour = copiers etc supporting
>Internet fax) I suspect that the onus should be = on the recipient
>client to confirm its capabilities, not the = server.
>
>I make no judgement as to other services that = may piggyback on SMTP
>and if they will typically include multiple = recipients.
>
>
>Cheers,
>
>Gerry

I think you might be looking at the issue from a = inaccurate
prospective. What is being attempted is to port the = "Fax Broadcast"
Scenario to delivering the Fax via the Internet as = opposed to POTS.
In the POTS Broadcast method, each copy is a = separate connection and
thus any reformatting is done due to the Connect = Handshake
Capabilities exchange. This tailoring capability = needs to be
preserved. If you feel (or have some data to = support) that only an
insignificant number of the total Fax Volume are = Broadcast
(multi-addressed) Faxes, then that might support = your initial
statement.

------_=_NextPart_001_01C223B1.F088B5B0-- From owner-ietf-fax@mail.imc.org Fri Jul 5 09:24:19 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 JAA23985 for ; Fri, 5 Jul 2002 09:24:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g65D7WK11833 for ietf-fax-bks; Fri, 5 Jul 2002 06:07:32 -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 g65D7Vw11829 for ; Fri, 5 Jul 2002 06:07:31 -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 JAA23111; Fri, 5 Jul 2002 09:06:40 -0400 (EDT) Message-Id: <200207051306.JAA23111@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ietf-fax@imc.org From: The IESG Subject: Protocol Action: Tag Image File Format Fax eXtended (TIFF-FX) -image/tiff-fx MIME Sub-type Registration to Proposed Standard Date: Fri, 05 Jul 2002 09:06:40 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the Internet-Draft 'Tag Image File Format Fax eXtended (TIFF-FX) -image/tiff-fx MIME Sub-type Registration' as a Proposed Standard. This document is the product of the Internet Fax Working Group. The IESG contact persons are Ned Freed and Patrik Faltstrom Technical Summary The IESG has approved the Internet-Draft 'Tag Image File Format Fax eXtended (TIFF-FX) -image/tiff-fx MIME Sub-type Registration' as a Proposed Standard. This document is the product of the Internet Fax Working Group. The IESG contact persons are Ned Freed and Patrik Faltstrom Technical Summary This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for Internet Fax [TIFF-FX] and its extensions. Working Group Summary The group came to consensus on the documents as written. Moreover, these documents are also to a large degree agreed to by the ITU study group that is defining similar functionality in the ITU protocol suite. Protocol Quality The specification was reviewed for the IESG by Ned Freed. RFC Editor note: Please change the "Encoding Considerations" in section 7 to read: Encoding Considerations: This media type consists of binary data. The base64 encoding should be used on transports that cannot accomodate binary data directly. Please add a "Security Considerations" section between sections 7 and 8 of the current document. The contents of this section should read: The security considerations for this media type are discussed in the security considerations section of the media type registration from that appears in section 7. From owner-ietf-fax@mail.imc.org Fri Jul 5 12:41:19 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 MAA03448 for ; Fri, 5 Jul 2002 12:41:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g65GO9N29323 for ietf-fax-bks; Fri, 5 Jul 2002 09:24:09 -0700 (PDT) Received: from s1.uklinux.net (mail.uklinux.net [80.84.72.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g65GO0w29301 for ; Fri, 5 Jul 2002 09:24:08 -0700 (PDT) Received: from helicon.office-logic.com ([213.121.243.39]) (authenticated) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id g65GNU601679; Fri, 5 Jul 2002 17:23:34 +0100 Envelope-To: ietf-fax@imc.org Date: Fri, 5 Jul 2002 17:22:10 +0100 From: Brian Stafford To: ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Message-ID: <20020705162210.GC29395@helicon.office-logic.com> References: <200207011347.JAA05248@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200207011347.JAA05248@ietf.org>; from iesg-secretary@ietf.org on Mon, Jul 01, 2002 at 14:47:54 +0100 X-Mailer: Balsa 1.3.6 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi all, Nothing like a good bun fight to grab my attention ;) Having followed this discussion with interest and having tried to follow the technical side of the argument, I find myself agreeing with Keith Moore's notion of using an RCAP (or whatever) command to determine recipient mailbox capabilities. I don't know if the following contributes anything or nothing to the debate, hopefully it is food for thought. Apologies for any repitition or lack of clarity in what follows, it's late afternoon here and I'm writing quickly. Using RCAP leads, I feel, to a simpler client and clearer error reports. The loss of performance due to issuing two commands per recipient is not really releveant here, IMO. If I were to design a client that transmits a message in various formats to a number of recipients, I would first collect the CONNEG capabilities using an RCAP command for each recipient. I do not care whether the recipient mailbox is valid, all I want is the CONNEG string. I feel that it is necessary that RCAP should be issued before MAIL FROM:. The error code for RCAP is simple and clear, either CONNEG was available or it wasn't and, in particular, it is not affected by the server's ability to relay or deliver to that mailbox (I can see no reason that prevents RCAP from supplying valid CONNEG strings for non-existent mailboxes, perhaps this is even desirable sometimes). Furthermore there is no need for a REQUIRED/OPTIONAL or similar parameter to RCAP. Having obtained all recipient capabilities, the client can make a decision either to remove the failing RCAP recipients from the list and report an error for them - the temporary RCAP failures can obviously be retried later - or to send them the LCD version of the document. The decision on how to proceed has been determined entirely by the client based on information supplied by the server. The server has not tried in any way to second guess the client's intentions or apply any particular intelligence to the situation. Based on CONNEG capabilities, or lack of them, the client can now either generate (or select the best versions from a previously delivered multipart/alternative document, say) for each recipient. At worst a different document is sent to each recipient, at best the same document is sent to all of them. The client can now simply progress to issuing a separate transaction (i.e. MAIL FROM ... RCPT TO ... DATA) for each version of the document and the associated recipients. Error handling for MAIL FROM etc. is identical to the normal case when RCAP is not used. PIPELINING won't affect things much here, all the RCAPs can be pipelined and the client pauses after issuing the last RCAP until it has all the responses, then proceeds with MAIL for the first version of the document. RSET is never required in this scenario (barring errors that make it necessary). I also like RCAP because it does not overload two potential failure modes (CONNEG not available vs recipient not available) on one error code (extended or not). By contrast with the sceanrio outlined above, overloading RCPT means that the client cannot determine what document to send until the entire recipient list is sent (using RCPT) at which point there is no going back, either RSET is issued and we start again with one or more transactions determined by the number of document versions needed or the LCD document is sent with all the problems raised elsewhere in this thread. Even with an overloaded RCPT command, I'd probably design a client to issue MAIL, RCPT ... CONNEG=whatever, ... pause just before DATA and if more than one document version is needed RSET and proceed with a number of transactions as outlined above. Given the extra work MAIL, RCPT and RSET must do and when all I want is the CONNEG string, I'd personally rather have the simpler, more lightweight RCAP command available. More importantly, because the server potentially has to choose which error to report from recipient failure vs conneg failure (not an easy choice, I'm sure) I feel that overloading RCPT leads to loss of useful information at the client. On balance, I would rather code for the "edge cases" over two commands than present potentially ambiguous and misleading reports to the message sender. Just my 0.02 Euros worth. Of course, I may be way off the mark - I am prepared to be convinced that the extended RCPT command is the better choice but so far RCAP seems preferable to me. Brian Stafford From owner-ietf-fax@mail.imc.org Fri Jul 5 13:36:18 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 NAA05855 for ; Fri, 5 Jul 2002 13:36:17 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g65HLQD04441 for ietf-fax-bks; Fri, 5 Jul 2002 10:21:26 -0700 (PDT) Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g65HLPw04435 for ; Fri, 5 Jul 2002 10:21:25 -0700 (PDT) Received: from [192.168.1.3] (ool-18e43cab.dyn.optonline.net [24.228.60.171]) by mail1.panix.com (Postfix) with ESMTP id E2981487D4; Fri, 5 Jul 2002 13:21:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: hal9001@popserver.panix.com Message-Id: In-Reply-To: <41CBB274CC77984D8A365C0A1B79F69221473C@mail.toshiba-tap.com> References: <41CBB274CC77984D8A365C0A1B79F69221473C@mail.toshiba-tap.com> X-Mailer: Eudora Pro 5.1.1b22 PPC (Macintosh) Date: Fri, 5 Jul 2002 12:32:54 -0400 To: ietf@ietf.org, ietf-fax@imc.org From: "Robert A. Rosenberg" Subject: RE: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard 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 09:24 +1000 on 07/05/2002, Gerry Sancataldo wrote about RE: Last Call: SMTP Service Extension for Content Negot: >I am currently surveying a number of sites (Australian) that are >currently using Internet Fax and preliminary data indicates that >over 98% of traffic is to a single recipient. While not attempting to attack your methodology, limiting the "universe" to those using Internet Fax raises in my mind the possibility/probability of getting an inaccurate view due to a number of considerations. As to your comment about "Pre Build Broadcast Lists" (which I did not quote), again you are restricting your universe. I've seen some types of broadcasts (such as some implementations of Fax-On-Demand) where the response is delayed for "Batch Processing." In that case the Broadcast list (none of whose numbers are known to the sender prior to the request) is dynamically build based on the requests and then sorted to group all the Faxes to the same Phone Number into one transmission (to make maximum usage of the connection) which only occurs on a scheduled basis. From owner-ietf-fax@mail.imc.org Fri Jul 5 13:36:25 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 NAA05873 for ; Fri, 5 Jul 2002 13:36:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g65HLRf04446 for ietf-fax-bks; Fri, 5 Jul 2002 10:21:27 -0700 (PDT) Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g65HLQw04442 for ; Fri, 5 Jul 2002 10:21:26 -0700 (PDT) Received: from [192.168.1.3] (ool-18e43cab.dyn.optonline.net [24.228.60.171]) by mail1.panix.com (Postfix) with ESMTP id 0B0B84878D; Fri, 5 Jul 2002 13:21:28 -0400 (EDT) Mime-Version: 1.0 X-Sender: hal9001@popserver.panix.com Message-Id: In-Reply-To: <01KJOCIFSA84001ZTY@mauve.mrochek.com> References: <15649.62973.894081.566925@monkeyboy.gshapiro.net> <3D221C44.5F99DED6@messagingdirect.com> <108177848.1025639386@localhost> <01KJMM5WZSX8001ZTY@mauve.mrochek.com> <122335932.1025653541@localhost> <01KJMXAOJA04001ZTY@mauve.mrochek.com> <197128527.1025728324@localhost> <01KJO8ERG6OO001ZTY@mauve.mrochek.com> <12403111.1025746010@localhost> <01KJOCIFSA84001ZTY@mauve.mrochek.com> X-Mailer: Eudora Pro 5.1.1b22 PPC (Macintosh) Date: Fri, 5 Jul 2002 12:57:17 -0400 To: ietf@ietf.org, ietf-fax@imc.org From: "Robert A. Rosenberg" Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard 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 22:59 -0700 on 07/03/2002, ned.freed@mrochek.com wrote about Re: Last Call: SMTP Service Extension for Content Negot: >One final comment. A general-purpose MTA using arbitrary site-provided >conversion routines doesn't have the luxury of being able to bound the >performance or other characteristics of those conversion routines. This makes >the entire convert-on-the-fly scenario problematic in ways that >don't arise for >a device built around a specific, limited and well understood set of >on-the-fly >converters, regardless of whether that device is a fax machine or something >else entirely. Indeed, if I were to implement based on past bad experiences >with various general-purpose conversion routines I'd be likely to break the >problem down into three steps: (1) Collection of conneg information >online, (2) >Message splitting and conversion offline, (3) Sending the resulting >emssages to >their destination. I doubt I'd support using REQUIRED in (1). As I said in another reply, one POSSIBLE solution to this problem is to go for a methodology where the CLIENT does the transforms and ships one copy of the message as Multi-Part/Alternate with ALL the transforms to the MTA. The MTA then decides what Transforms are needed (based on the CONNEG info) and grabs out those that are needed from the M-P/A set. This removes the Real-Time transform overhead by off-loading it to the Client. It is, of course, based on a model where the number of different transforms are limited AND can be enumerated in the absence of info on the capabilities of the designated recipients. From owner-ietf-fax@mail.imc.org Fri Jul 5 13:36:31 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 NAA05886 for ; Fri, 5 Jul 2002 13:36:31 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g65HLPm04434 for ietf-fax-bks; Fri, 5 Jul 2002 10:21:25 -0700 (PDT) Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g65HLNw04426; Fri, 5 Jul 2002 10:21:23 -0700 (PDT) Received: from [192.168.1.3] (ool-18e43cab.dyn.optonline.net [24.228.60.171]) by mail1.panix.com (Postfix) with ESMTP id DF31E487B7; Fri, 5 Jul 2002 13:21:24 -0400 (EDT) Mime-Version: 1.0 X-Sender: hal9001@popserver.panix.com Message-Id: In-Reply-To: <200207041915.g64JFAZ01465@astro.cs.utk.edu> References: <200207041915.g64JFAZ01465@astro.cs.utk.edu> X-Mailer: Eudora Pro 5.1.1b22 PPC (Macintosh) Date: Fri, 5 Jul 2002 12:45:34 -0400 To: iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org From: "Robert A. Rosenberg" Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit At 15:15 -0400 on 07/04/2002, Keith Moore wrote about Re: Last Call: SMTP Service Extension for Content Negot: >> IMO, the ultimate aim (even if this is not practical) is to deliver >> to each recipient the same version of the Fax as they would have >> received IF they were the only addressee > >I think this is a reasonable and practical goal. I don't think that >recipient A should experience a difference in message quality >(or worse, fail to receive the message at all) based on whether or >not you cc'ed recipient B. > >> while at the same time >> generating only the minimum number of copies to allow >> multi-addressing. > >I think this is an implementation decision. It should be *possible* >to do this (and it is), but it shouldn't be required of implementations. Bad phrasing on my part (I had intended the minimal message count to be a target not a cast-in-stone requirement). If you must degrade into one message per address mode - so be it - BUT I think that if you are going to do so, you are cheaping out by not trying to add some minimal logic to run the chain of pending copies to see if any can be satisfied by the current version. I'm not asking for a full matrix analysis (which is the "Best"/"Optimum" Method) - just take them in order of the addresses and run the pending chain. This will probably not create the minimal count (except by luck) but can still reduce the count somewhat. >here are a couple of trivial examples of the effect of a "downgrade to >LCD format" implementation strategy. > >assume: > >recipient A accepts only HTML and plain text >recipient B accepts only PDF and plain text > >an HTML message sent only to A gets delivered as HTML, but if B is cc'ed >(or bcc'ed) on the message then both A and B get plain text (if the >client knows how to convert HTML to plain text). A is accustomed >to receiving HTML from B and is surprised that there's an information >loss. No - This is a standard M-P/A situation and should be sent to both as such (just as if the original message was generated by the MUA and packaged as M-P/A [which is the normal action of most of the MUAs I know unless the user has overridden the send both option). > >more seriously, a PDF message sent only to B gets delivered as PDF, but >if A is cc'ed on the message then the message is bounced for both A and >B because there's no good way to downgrade PDF to a format acceptable >to B (or the client doesn't know how). This is a more complex case. It would/could be solvable by a Smart MUA that acted the same as the HTML/Plain case by sending/creating as M-P/A with Text/Plain and application/PDF versions. The "Best" solution is if the MUA could also deliver a HTML copy (which would be packaged between the Text and the PDF in the stacking order). Note: I am assuming a 2 stage MUA where the messages are created and queued for delivery and upon connect, the MUA can drop out (if it wants) unneeded alternatives (instead of doing the transforms in real time). I see no reason that the M-P/A creation (with optional deletion prior to transmit) could not be a viable alternative for real-time transforms (at least in the case where the number of different variations is limited/minimal such as in the above case or in the case of a Fax where you must convert Color to B&W and/or support 2 or 3 resolutions). I am working in a Blue Sky mode with these comments and I'm just tossing out a best functionality case which must/will be modified by implementation and real-world constraints. > >So far I have not been able to identify conditions for which downgrading >to LCD is a viable implementation strategy. My conclusion is that >implementations that support CONNEG and that attempt to deliver to >mutliple recipients in one transaction MUST be prepared to do RSET and >split up the delivery if it becomes evident that delivering the same >version of the message to all recipients is not appropriate. > >Keith Note: I am offering all of the above ideas/processing methods as suggestions for possible listings of ways to reach the goal of delivering the message to the recipient as if in a one-to-one mode while trying to minimize the overhead that is associated with one-to-one mode by leveraging the processing overhead of the message generation/uploading for additional addressees. As someone who has not been associated with the evolution of this effort I think my "new perspectives" can, at times, point out methodologies that might not be obvious those who have participated in its design. OTOH, I may be totally of base and my ideas may have already been raised and considered . From owner-ietf-fax@mail.imc.org Fri Jul 5 14:22:43 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 OAA08625 for ; Fri, 5 Jul 2002 14:22:43 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g65I8bH08330 for ietf-fax-bks; Fri, 5 Jul 2002 11:08:37 -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 g65I8Sw08304; Fri, 5 Jul 2002 11:08:28 -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 g65I8SZ03429; Fri, 5 Jul 2002 14:08:28 -0400 (EDT) Message-Id: <200207051808.g65I8SZ03429@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Robert A. Rosenberg" cc: iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Fri, 05 Jul 2002 12:45:34 EDT.") Date: Fri, 05 Jul 2002 14:08:28 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > >here are a couple of trivial examples of the effect of a "downgrade to > >LCD format" implementation strategy. > > > >assume: > > > >recipient A accepts only HTML and plain text > >recipient B accepts only PDF and plain text > > > >an HTML message sent only to A gets delivered as HTML, but if B is cc'ed > >(or bcc'ed) on the message then both A and B get plain text (if the > >client knows how to convert HTML to plain text). A is accustomed > >to receiving HTML from B and is surprised that there's an information > >loss. > > No - This is a standard M-P/A situation and should be sent to both as > such (just as if the original message was generated by the MUA and > packaged as M-P/A [which is the normal action of most of the MUAs I > know unless the user has overridden the send both option). I don't follow your reference to multipart/alternative. The source message in the example is HTML only. And I don't think anyone has proposed that the SMTP client performing a conversion should use multipart/alternative to include both the old and the versions - if nothing else, the fax stuff that is driving this has had the ability to use multipart/alternative for 10+ years and they obviously don't consider it sufficient for their purposes. Also, B might not want HTML, not even in a multipart/alternative - and it seems quite reasonable to me that B would specify this (since I don't want it either). The fact that many MUAs generate multipart/alternative with text+html by default should not be cited as if it were a desirable practice. > >more seriously, a PDF message sent only to B gets delivered as PDF, but > >if A is cc'ed on the message then the message is bounced for both A and > >B because there's no good way to downgrade PDF to a format acceptable > >to B (or the client doesn't know how). > > This is a more complex case. It would/could be solvable by a Smart > MUA that acted the same as the HTML/Plain case by sending/creating as > M-P/A with Text/Plain and application/PDF versions. The "Best" > solution is if the MUA could also deliver a HTML copy (which would be > packaged between the Text and the PDF in the stacking order). senders' MUAs are irrelevant to this discussion, unless they also perform conversion based on SMTP CONNEG responses (which would reqiure them to connect directly to recipients' ultimate MTAs - not likely) the scenario is this - some MTA gets a message, it looks at the recipient capabilities, and decides that it needs to convert the message to make it acceptable to the recipients. the point of my examples is to demonstrate that there will be cases where there is no single message format that is acceptable to all recipients, which implies that any MTA which attempts to deliver to more than one recipient at a time (and which uses CONNEG) must be prepared to handle the case where different behavior is applied to different recipients - and this further requires RSET and/or close-connection-and-retry logic. (even with a close RSET should be strongly recommended) Keith From owner-ietf-fax@mail.imc.org Fri Jul 5 19:37:53 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 TAA24919 for ; Fri, 5 Jul 2002 19:37:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g65NN8G04780 for ietf-fax-bks; Fri, 5 Jul 2002 16:23: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 g65NMdw04732; Fri, 5 Jul 2002 16:22:39 -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 QAA07861; Fri, 5 Jul 2002 16:28:45 -0700 Message-Id: <5.1.1.2.2.20020705161234.03b3a008@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Fri, 05 Jul 2002 16:13:53 -0700 To: "Robert A. Rosenberg" From: Dave Crocker Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Cc: iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org In-Reply-To: References: <5.1.1.2.2.20020703142511.019f51a0@jay.songbird.com> <5.1.1.2.2.20020702183611.0354a798@jay.songbird.com> <(Your message of "Tue, 02 Jul 2002 19:45:19 EDT.") <107911393.1025639119@localhost> <5.1.1.2.2.20020702183611.0354a798@jay.songbird.com> <5.1.1.2.2.20020703142511.019f51a0@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: At 01:58 PM 7/4/2002 -0400, Robert A. Rosenberg wrote: >IMO, the ultimate aim (even if this is not practical) is to deliver to >each recipient the same version of the Fax as they would have received IF >they were the only addressee while at the same time generating only the >minimum number of copies to allow multi- That is a worthy and reasonable use for this capability. And, of course yes, it motivated creating this option. However that level of "perfection" is not required. There is nothing wrong with a service model that is satisfied with sending the least common denominator. The choice is the sender's. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Fri Jul 5 20:14:35 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 UAA25842 for ; Fri, 5 Jul 2002 20:14:35 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g6600su07872 for ietf-fax-bks; Fri, 5 Jul 2002 17:00:54 -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 g6600nw07860; Fri, 5 Jul 2002 17:00:49 -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 g6600mZ04440; Fri, 5 Jul 2002 20:00:49 -0400 (EDT) Message-Id: <200207060000.g6600mZ04440@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: "Robert A. Rosenberg" , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Fri, 05 Jul 2002 16:13:53 PDT.") <5.1.1.2.2.20020705161234.03b3a008@jay.songbird.com> Date: Fri, 05 Jul 2002 20:00:48 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > >IMO, the ultimate aim (even if this is not practical) is to deliver to > >each recipient the same version of the Fax as they would have received IF > >they were the only addressee while at the same time generating only the > >minimum number of copies to allow multi- > > That is a worthy and reasonable use for this capability. And, of course > yes, it motivated creating this option. > > However that level of "perfection" is not required. There is nothing wrong > with a service model that is satisfied with sending the least common > denominator. > > The choice is the sender's. as long as the sender gets to specify the conditions under which the conversion is done, that seems just fine - it is no different than allowing the the sender to personally look at a set of potential recipients' capabilities and decide what the minimum requirements for reception (and therefore the LCD format) should be. however the current proposal doesn't really give the sender a way to specify that threshhold - unless, perhaps, the negotiation/conversion is performed by an MTA that is under control of the sender (in which case the threshold could be specified by explicit configuration) and that MTA has the abliity to speak SMTP directly with MTAs that know the recipients' capabilities. in other words, enabling the sender to make the choice is not compatible with the vast majority of the deployed email infrastructure (even assuming that those MTAs are extended to support this extension) Keith From owner-ietf-fax@mail.imc.org Fri Jul 5 20:23:17 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 UAA26034 for ; Fri, 5 Jul 2002 20:23:17 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g660AAW08504 for ietf-fax-bks; Fri, 5 Jul 2002 17:10:10 -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 g660A8w08493; Fri, 5 Jul 2002 17:10:08 -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 RAA09024; Fri, 5 Jul 2002 17:16:12 -0700 Message-Id: <5.1.1.2.2.20020705170321.038b54e0@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Fri, 05 Jul 2002 17:04:42 -0700 To: Keith Moore From: Dave Crocker Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Cc: Dave Crocker , "Robert A. Rosenberg" , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org In-Reply-To: <200207060000.g6600mZ04440@astro.cs.utk.edu> References: <(Your message of "Fri, 05 Jul 2002 16:13:53 PDT.") <5.1.1.2.2.20020705161234.03b3a008@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: At 08:00 PM 7/5/2002 -0400, Keith Moore wrote: >however the current proposal doesn't really give the sender a way >to specify that threshhold - unless, perhaps, the negotiation/conversion The protocol is MTA-MTA. You are discussing UA-MTA. That's a different protocol. Feel free to draft a version. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Fri Jul 5 21:00: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 VAA26918 for ; Fri, 5 Jul 2002 21:00:51 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g660lKs10810 for ietf-fax-bks; Fri, 5 Jul 2002 17:47:20 -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 g660l3w10785; Fri, 5 Jul 2002 17:47:03 -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 g660l3Z04545; Fri, 5 Jul 2002 20:47:03 -0400 (EDT) Message-Id: <200207060047.g660l3Z04545@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: Keith Moore , Dave Crocker , "Robert A. Rosenberg" , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Fri, 05 Jul 2002 17:04:42 PDT.") <5.1.1.2.2.20020705170321.038b54e0@jay.songbird.com> Date: Fri, 05 Jul 2002 20:47:02 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > >however the current proposal doesn't really give the sender a way > >to specify that threshhold - unless, perhaps, the negotiation/conversion > > > The protocol is MTA-MTA. indeed, but you said that the choice of whether to downgrade to LCD is the sender's choice, which is kind of an odd statement when in the vast majority of cases the sender doesn't have any control over the MTA's decision-making process, and you haven't suggested a mechanism to do this. > You are discussing UA-MTA. That's a different protocol. Feel free to > draft a version. I'm not discussing a different protocol, I'm discussing a characteristic of your proposal with respect to a claim that you made about your proposal. Ketih From owner-ietf-fax@mail.imc.org Fri Jul 5 21:07:27 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 VAA27232 for ; Fri, 5 Jul 2002 21:07:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g660s6Y11329 for ietf-fax-bks; Fri, 5 Jul 2002 17:54:06 -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 g660s4w11316; Fri, 5 Jul 2002 17:54:04 -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 SAA10254; Fri, 5 Jul 2002 18:00:12 -0700 Message-Id: <5.1.1.2.2.20020705175314.01a2ec58@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Fri, 05 Jul 2002 17:53:31 -0700 To: Keith Moore From: Dave Crocker Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Cc: iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org In-Reply-To: <200207060047.g660l3Z04545@astro.cs.utk.edu> References: <(Your message of "Fri, 05 Jul 2002 17:04:42 PDT.") <5.1.1.2.2.20020705170321.038b54e0@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: At 08:47 PM 7/5/2002 -0400, Keith Moore wrote: > > >however the current proposal doesn't really give the sender a way > > >to specify that threshhold - unless, perhaps, the negotiation/conversion > > > > > > The protocol is MTA-MTA. > >indeed, but you said that the choice of whether to downgrade to LCD >is the sender's choice, sending MTA. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Fri Jul 5 21:15: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 VAA27441 for ; Fri, 5 Jul 2002 21:15:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6612Fk12068 for ietf-fax-bks; Fri, 5 Jul 2002 18:02:15 -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 g6612Aw12048; Fri, 5 Jul 2002 18:02:10 -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 g6612BZ04648; Fri, 5 Jul 2002 21:02:11 -0400 (EDT) Message-Id: <200207060102.g6612BZ04648@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: Keith Moore , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Fri, 05 Jul 2002 17:53:31 PDT.") <5.1.1.2.2.20020705175314.01a2ec58@jay.songbird.com> Date: Fri, 05 Jul 2002 21:02:11 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > > >however the current proposal doesn't really give the sender a way > > > >to specify that threshhold - unless, perhaps, the negotiation/conversion > > > > > > > > > The protocol is MTA-MTA. > > > >indeed, but you said that the choice of whether to downgrade to LCD > >is the sender's choice, > > sending MTA. ah, that's a slightly different thing. but I really don't think it's a good idea to have MTA making value judgements about the suitability of converting (whether or not using an LCD strategy) in the absence of explicit direction from either sender or recipient. Keith From owner-ietf-fax@mail.imc.org Sat Jul 6 03:51:05 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 DAA14166 for ; Sat, 6 Jul 2002 03:51:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g667bR318239 for ietf-fax-bks; Sat, 6 Jul 2002 00:37:27 -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 g667bPw18235 for ; Sat, 6 Jul 2002 00:37:25 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KJQY46W680001ZTY@mauve.mrochek.com> for ietf-fax@imc.org; Sat, 06 Jul 2002 00:37:13 -0700 (PDT) Date: Fri, 05 Jul 2002 23:01:31 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: "Your message dated Thu, 04 Jul 2002 15:36:07 -0400" <63368316.1025796967@localhost> To: John C Klensin Cc: ned.freed@mrochek.com, Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Message-id: <01KJR7EX5EYO001ZTY@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <15649.62973.894081.566925@monkeyboy.gshapiro.net> <3D221C44.5F99DED6@messagingdirect.com> <108177848.1025639386@localhost> <01KJMM5WZSX8001ZTY@mauve.mrochek.com> <122335932.1025653541@localhost> <01KJMXAOJA04001ZTY@mauve.mrochek.com> <197128527.1025728324@localhost> <01KJO8ERG6OO001ZTY@mauve.mrochek.com> <12403111.1025746010@localhost> <01KJOCIFSA84001ZTY@mauve.mrochek.com> <63368316.1025796967@localhost> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > --On Wednesday, 03 July, 2002 22:59 -0700 ned.freed@mrochek.com > wrote: > >> I, at least, would find such comments helpful. But I'd also > >> like to hear comments from at least one person responsible > >> for a general-purpose MTA (as distinct from a fax-over-email > >> engine) who expects to implement this feature and how they > >> propose to do so and how this feature fits in. > > > > There are two cases here: Client and server implementations. > > > > I definitely plan to implement the server side of this > > proposal. From that perspective all of the proposed variants > > are easy to implement as long as you have a source of conneg > > information to tap. I plan to use an LDAP attribute for this > > purpose. > >... > Interesting. Instead of "ask the receiving client", you would > rely on a database that proported to know the client's behavior > and capabilities. That certainly makes implementation easier > and might also deal with the relay situation by permitting the > first (and subsequent?) relays to ask the database rather than > replying "no clue about the client, I don't deliver to it" (the > latter is one of the cases I've been concerned about). However: > (i) It would seem to me to be reasonable to write this option > down (as an option) rather than leaving implementers guessing. Writing it down would be fine with me, although to be honest this struck me as the obvious way to do it. OTOH, there certainly have been cases in the past when I refrained from documenting what I thought was obvious in one of my own drafts, only to find it was nothing of the sort. > (ii) Given the notorious "wks" experience, with trying to put > target host capabilities into an ancillary database, it seems to > me that this would further justify experimental status so that > we can get some sense as to whether the database would be kept > adequately up-to-date. Certainly our experience should cause us > to be skeptical about that. I think the differences between this and wks far outweigh the similarities. Specifically, the major problem with wks records was that the authority over/responsibility for wks records and authority over/responsibility for the aspects of systems wks describes tended to be disjoint. Back in the days when I maintained a reasonably heftly DNS zone I never had enough time to keep wks records up to date with all the changes the various sysadmins kept making, and after a while I stopped trying. And of course the sysadmins didn't have the means to maintain this information in the DNS themselves. The situation with an LDAP directory used for messaging is quite different. Such directories often already maintain a bunch of user-settable information (e.g., filtering rules, personal address book) and typically provide the means (e.g., a web interface) for users to maintain and modify that information themselves. Of course having such a capability doesn't mean users will actually take the time to use it. I suspect that's going to be very dependent on both need and the quality of the user interface; presenting raw media feature sets definitely isn't the way to go ;-) > > The client side for a general-purpose MTA is much harder, but > > not because of any aspect of the protocol. The issue I have > > there is how to match up an arbitrary set of site-provided > > conversion operations with the current group of recipient > > feature sets. I don't see a good solution to this other than > > making the whole thing something the site specifies, and if I > > do that I see little chance of the capability actually being > > used by enough sites to justify the cost of implementation. > > One final comment. A general-purpose MTA using arbitrary > > site-provided conversion routines doesn't have the luxury of > > being able to bound the performance or other characteristics > > of those conversion routines. This makes the entire > > convert-on-the-fly scenario problematic in ways that don't > > arise for a device built around a specific, limited and well > > understood set of on-the-fly converters, regardless of whether > > that device is a fax machine or something else entirely. > > Indeed, if I were to implement based on past bad experiences > > with various general-purpose conversion routines I'd be likely > > to break the problem down into three steps: (1) Collection of > > conneg information online, (2) Message splitting and > > conversion offline, (3) Sending the resulting emssages to > > their destination. I doubt I'd support using REQUIRED in (1). > I can only agree with both of these comments and complement you > on the clarity of your explanation of them. Thanks! I had a couple of other thoughts about this over the past couple of days: (0) There are/will be additional ways to obtain conneg information: In DSNs or MDNs, through LDAP queries, via RESCAP, or through direct database queries within a single mail system. The database/directory mechanism can be used to advantage in all of these cases. (1) Caching of conneg information is certainly possible and may even be desireable. Indeed, conneg information returned in DSNs or MDNs will have to be cached in order to be useful. This document doesn't discuss caching, and while caching isn't required in the ESMTP context some discussion of it nevertheless makes sense. (2) The use of caches really opens the door to conneg in the context of relays in ways that nothing else does. For example, imagine a relay that doesn't do any content transformation of its own but does do forward conneg requests to populate a cache. It then offers the information it has in that cache when it acts as a server. This may sound kind of cool at first glance, but as the cache comes and goes it would tend to violate the least astonishment principle in fairly major ways. Issues also arise if multiple relays are used, each with a separate cache. Care is needed here to preserve the ability to "rack and stack" mail relays without undue consequences. This isn't a typical cache since the goal isn't to minimize the number of forward queries that are done. The intent here is to provide the information from those queries in a completely different context. The variability problems here can be solved by going to either extreme: Ban caches of this sort entirely or insist that components that actually perform content transformations cache conneg information for a fairly long period. (It should be obvious that having intermediates cache information is risky and doesn't solve the problem.) At first I thought the right answer was to ban this stuff, but on reflection I think the use of DSNs and MDNs to return conneg information argue for a mandatory cache in the transformation agent. Ned From owner-ietf-fax@mail.imc.org Sat Jul 6 04:41:19 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 EAA14762 for ; Sat, 6 Jul 2002 04:41:18 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g668RXO21668 for ietf-fax-bks; Sat, 6 Jul 2002 01:27:33 -0700 (PDT) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g668RVw21661 for ; Sat, 6 Jul 2002 01:27:31 -0700 (PDT) Received: by bulls.mei.co.jp (8.12.2/3.7W/jazz) with ESMTP id g668QoUW011657; Sat, 6 Jul 2002 17:26:50 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/dodgers) with SMTP id g668QpE17778; Sat, 6 Jul 2002 17:26:51 +0900 (JST) Received: from no.name.available by m-bb2.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 6 Jul 2002 08:26:52 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0-1.mgcs.mei.co.jp (8.12.2/3.7W-HUB) with ESMTP id g668NX3o005987; Sat, 6 Jul 2002 17:23:33 +0900 (JST) Received: from mlsv2.rdmg.mgcs.mei.co.jp by mlsv1.mgcs.mei.co.jp (8.9.3/3.7W-MGCS) with ESMTP id RAA10046; Sat, 6 Jul 2002 17:26:51 +0900 (JST) Received: from d23n59.rdmg.mgcs.mei.co.jp by mlsv2.rdmg.mgcs.mei.co.jp (8.12.2/3.7W-RDMG) with SMTP id g668Pwl8008994; Sat, 6 Jul 2002 17:25:58 +0900 (JST) Message-Id: <200207060834.AA01481@d23n59.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Sat, 06 Jul 2002 17:34:40 +0900 To: ned.freed@mrochek.com Cc: ietf@ietf.org, ietf-fax@imc.org Subject: revisions to draft-ietf-fax-esmtp-conneg-02.txt MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.12 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ned.freed@mrochek.com wrote: Date: Wed, 03 Jul 2002 20:56:21 -0700 (PDT) > >I'm afraid I'm coming to a very different conclusion. I think these discussions >have conflated a bunch of different things: (1) Specification bugs that >definitely need to be fixed, (2) A single protocol change that definitely >should be made -- that of making conneg information and status identifiable as >such in the command response, (3) A bunch of concerns about protocol details >that aren't standing up to close inspection and which absent a clear consensus >for change can remain as-is, and (4) A general concern about the many possible >uses for this mechanism that has all of us engaging in futile speculation and >which cannot possibly be dealt sensibly with in a specification without actual >implementation and use experience. > >Of course (1) and (2) need to be fixed before proceeding. As for (3) and (4), >well, this is why we have a standards process and not a rubber stamp. > We have revised the specification to fix (1) and (2), and have put a copy at: Significant points which we changed are as blow. 1. Changed the expression of SYNTAX because the suggesitions below. Dan Wing wrote: >Further, your ABNF in section 5 does not permit any text >after the "504" -- it only permits . Keith Moore wrote: >it's not appropriate to put literal response codes in the grammar, >particularly the extended status codes which might actually need to >vary more than is indicated here. > >much better to have something like: >reply: initial-reply *(conneg-reply/other-reply) final-reply >initial-reply: reply-code "-" [ status-code ] CRLF >conneg-reply: reply-code "-" [ status-code " " ] "CONNEG" capability CRLF >other-reply: reply-code "-" [ status-code ] *char CRLF >final-reply: reply-code " " [ status-code ] CRLF 2. Changed the Example because the ploblem below. Dan Wing wrote: >Section 6, the examples, do not clearly show that the >server isn't sending CRLF between the lines. > 3. Changed the the last statement of section 4.2 because the problem below. Also, changed SYNTAX and REFERENCES to make RFC2534, RFC2879 and RFC2305 non-normative. John C Klensin wrote: >(iii) I can't reconcile the last statement of section 4.2: > > If the server returns an EHLO 250 code without CONNEG > capabilities, the client MUST work as "a Simple Mode of > Facsimile Using Internet Mail" [RFC2305]. > >With the assertion that this is a general facility, not limited >to fax. If it is a duck, let's call it a duck and be done with >it. And, if fax is sufficiently special that we need things >like this, perhaps it is time to add something like NORELAY, or >a FAX extension, to make it clear that what is happening is not >normal SMTP. 4. Changed the word "target" to "server" in section 4.2 and 4.3. because the suggestion below. Gregory Neil Shapiro wrote: >- It became increasingly difficult to understand as the draft inconsistently > refers to the server as both "server" and "target", at times in the same > section. It makes it look like there is a third party ("client", > "server", and "target"). "server" should be used throughout. Most points which I changed are inline below. They are also responses to Wing-san, Shapiro-san, Moore-san and Klensin-san. Dan Wing wrote: >Please explain why you require a space in the RCPT >modifier; that is, why is the ABNF: > > "CONNEG =" > >instead of > > "CONNEG" "=" > >or simply > > "CONNEG=" I changed it to "CONNEG=". > > >In section 5, your the word "OPTIONAL" is mispelled. corrected > >In section 5, is the only valid destination address supposed >to be "Postmaster"? The example in section 6 contradicts >that. No, it is not. There is "Forward-Path". I add the following definition. domain = <> Forward-Path =<> > > >The text throughout the document uses > "CONNEG = REQUIRED" >and > "CONNEG = OPTIONAL" > >but section 5 says there isn't a space after "=". > I eliminated space. > >The text says: > > The response strings for a temporary failure are > "404-4.3.3 CONNEG" and "404 5.3.3 CONNEG". > >which looks like a cut-and-paste error (4.3.3 -> 5.3.3). > Yes, I changed as below. "404 5.3.3 CONNEG" -> "404 4.3.3 CONNEG" > > > >In section 5, your failure example is: > > > C: RCPT TO: CONNEG = REQUIRED > S: 504 recipient ok > >I believe the text "recipient ok" is inappropriate here. Perhaps >more appropriate would be "recipient okay, but CONNEG unavailable". I changed it as below. C: RCPT TO: CONNEG=REQUIRED S: 504 conneg permanent failure > >Further, your ABNF in section 5 does not permit any text >after the "504" -- it only permits . I changed the expression of Reply syntax as below. Reply: initial-reply *conneg-reply final-reply initial-reply = reply-code "-" [ status-code ] [text] CRLF ; text is usually intended for human users. conneg-reply = reply-code "-" [ status-code " " ] "CONNEG" capability CRLF final-reply = reply-code " " [ status-code ] CRLF reply-code = 250/504/404 status code = 2.1.5/5.3.3/4.3.3 text = 1* capability = <> > > >I'm guessing section 5 is supposed to be ABNF, but as Dave >is the author of ABNF and section 5 doesn't claim to be ABNF, >I can't tell what it's supposed to be. Can the document >make this clearer? I added the text blow to SYNTAX section. 5. SYNTAX The syntax for a "Command with CONNEG" and "Reply", using the ABNF notation of [RFC2234], is: > > >Section 5 seems to prohibit multiline 504 and multiline >404 responses, but such multiline responses are permitted >by the underlying RFC2822 specification. Is your specification >purposely prohibiting multiline 504 and 404 responses by CONNEG- >capable SMTP servers that receive CONNEG=REQUIRED or >CONNEG=OPTIONAL ? No, it does not. I changed the expression of Reply syntax. > >Section 5 doesn't define the meaning of . I added the definition. domain = <> Forward-Path =<> > > >I am very unclear on the difference between a client >specifying CONNEG=OPTIONAL versus a client specifying no CONNEG >parameter at all. The text "but the target does not support the CONNEG parameter" got deleted in the paragraph below during revision. If the client specifies "CONNEG = OPTIONAL" in the RCPT-TO, the target MUST process the address and message as if the requested CONNEG capabilities had not been specified. The correct paragraph is below. 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. > > >You should cite the ENCHANCEDSTATUSCODES RFC. I cited it. > > >Section 6, the examples, do not clearly show that the >server isn't sending CRLF between the lines. Lines that are >separated by CRLF such as > > > S: 250-ifax1.jp > S: 250-DSN > S: 250 CONNEG > > >are shown exactly like lines that aren't separated by CRLF such >as > > > > 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) ) > >While this is described in the text of the document, >the example isn't nearly clear enough. > >Please add text indicating that the example is broken into >multiple lines for clarity in the document, but that the >Server transmits only two CRLF lines for the above example: >one CRLF at the first line and another CRLF at the last line >and no CRLFs are sent in between. > >This is a serious interoperabilty issue. The ABNF (or >whatever is in section 5) isn't clear on this either. > >The unique way you have separated the Client and Server >lines (using blank lines) doesn't help show that CRLF isn't >sent on each line (which I'm guessing was the intent of >this extra blank line, but the extra blank line was never >explained in the document). > > > >My specific recommendation is that you change the >example to: > > 6. EXAMPLE > > An example of ESMTP sequence with successful RCPT-TO response > > 1 S: 220 ifax1.jp IFAX > 2 C: EHLO ifax1.jp > 3 S: 250-ifax1.jp > 4 S: 250-DSN > 5 S: 250 CONNEG > 6 C: MAIL FROM: > 7 S: 250 sender ok > 8 C: RCPT TO: CONNEG = REQUIRED > 9 S: 250- recipient ok > 10 S: 250 CONNEG (&(image-file-structure=TIFF-minimal) > 11 S: (MRC-mode=0)(color=Binary)(|(&(dpi=204) > 12 S: (dpi-xyratio=[204/98,204/196]) )(&(dpi=200) > 13 S: (dpi-xyratio=[200/100,1]) )(&(dpi=400) > 14 S: (dpi-xyratio=1) ) )(|(image-coding=[MH,MR,MMR]) > 15 S: (&(image-coding=JBIG)(image-coding-constraint=JBIG-T85) > 16 S: (JBIG-stripe-size=128) ) )(paper-size=[letter,A4,B4]) > 17 S: (ua-media=stationery) ) > 18 C: DATA > 19 S: 354 okay, send data > 20 C: < Per: > ( image-file-structure=TIFF-minimal > dpi=400 > image-coding=JBIG > size-x=2150 > ) > >> > 21 S: 250 message accepted > 22 C: QUIT > 23 S: 221 goodbye > > Note that line 9 is terminated with CRLF, but lines 10 > through 16 are not terminated by CRLF -- they are only shown > wrapped in this document for clarity. The next line that > has a CRLF is line 17. > I adopted the example which Wing-san recomended above. Gregory Neil Shapiro wrote: >- It became increasingly difficult to understand as the draft inconsistently > refers to the server as both "server" and "target", at times in the same > section. It makes it look like there is a third party ("client", > "server", and "target"). "server" should be used throughout. I changed the word "target" to "server" in section 4.2 and 4.3. > >- Section 4.3 states: > > If the target support the CONNEG parameter, but it can not return > the recepient's capability temporarily, the target MUST reject the > >"recipient's" is spelled incorrectly. corrected. > >- Section 4.3 states: > > Regardless of the value of the parameter, if the target does > support the CONNEG parameter, then it MUST issue a 250 reply, > followed by the capabilities of the target that is specified by > the RCPT-TO address. > >I think this should be changed to: > > Regardless of the value of the parameter, if the target does > support the CONNEG parameter and the address is acceptable, > then it MUST issue a 250 reply, followed by the capabilities of > the target that is specified by the RCPT-TO address. > >Note the addition of "and the address is acceptable". The draft should not >specify that the command "MUST issue a 250 reply" as there may be other >reasons outside of the scope of CONNEG not to do so. I adopted the recomendation above. > >- Section 5 states: > > Command with "CONNEG": > "RCPT TO:" ("" / "" > / Forward-Path) (SP "CONNEG =" ("REQUIRED" / > "OPTIOANL") CRLF > >* Why is postmaster specifically listed in the syntax? >* "OPTIONAL" is spelled wrong in the syntax corrected > >- Section 6 states: > > An example of succssful RCPT-TO response when CONNEG-capable > server supports ENHANCEDSTATUSCODES. > >"successful" is spelled incorrectly. corrected > >- Section 6 states: > > An example of ESMTP sequence with parmanent failure RCPT-TO > response. > >"permanent" is spelled incorrectly. corrected > > 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 > >The comment above should probably indicate that this is a broken client. >The client shouldn't be sending the "CONNEG = REQUIRED" since CONNEG was >not given in reply to the EHLO command. > I corrected as below. An example of ESMTP sequence with permanent failure 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 S: 504 conneg permanent failure C: QUIT S: 221 goodbye > >- Section 7 states: > > On publicatiom of this document by the RFC Editor, the IANA > shall register the Content_Negotiation ESMTP extension defined > in section 3. > >"publication" is spelled incorrectly. corrected > >- Section 12 states: > > Copyright (C) The Internet Society (2001). All Rights > Reserved. > >Should this be updated to include 2002? changed it to 2002 Keith Moore wrote: > >> >> 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) / > >it's not appropriate to put literal response codes in the grammar, >particularly the extended status codes which might actually need to >vary more than is indicated here. > >much better to have something like: > >reply: initial-reply *(conneg-reply/other-reply) final-reply > >initial-reply: reply-code "-" [ status-code ] CRLF > >conneg-reply: reply-code "-" [ status-code " " ] "CONNEG" capability CRLF > >other-reply: reply-code "-" [ status-code ] *char CRLF > >final-reply: reply-code " " [ status-code ] CRLF > >> >> capability = <> and [RFC2879] >> I cahnged Syntax of Reply as below. Reply: initial-reply *conneg-reply final-reply initial-reply = reply-code "-" [ status-code ] [text] CRLF ; text is usually intended for human users. conneg-reply = reply-code "-" [ status-code " " ] "CONNEG" capability CRLF final-reply = reply-code " " [ status-code ] CRLF reply-code = 250/504/404 status code = 2.1.5/5.3.3/4.3.3 text = 1* capability = <> > >also TIFF-FX is not the name of the content-type, >presumably it's application/tiff-fx or some such. I changed TIFF-FX to image/tiff. C: < >(iii) I can't reconcile the last statement of section 4.2: > > If the server returns an EHLO 250 code without CONNEG > capabilities, the client MUST work as "a Simple Mode of > Facsimile Using Internet Mail" [RFC2305]. > >With the assertion that this is a general facility, not limited >to fax. If it is a duck, let's call it a duck and be done with >it. And, if fax is sufficiently special that we need things >like this, perhaps it is time to add something like NORELAY, or >a FAX extension, to make it clear that what is happening is not >normal SMTP. I changed the phrase to below. If the server returns an EHLO 250 code without CONNEG capabilities, the client MUST work as if it had not issued CONNEG parameter with RCPT. > >(v) Just as an editorial matter, but, in order to avoid >unnecessary confusion, it would probably be helpful if the >document adopted terminology consistent with RFC 2821 (and 821). >E.g., there is no such command as "RCPT-TO", the name of the >relevant command is "RCPT". I changed RCPT-TO to RCPT. Kiyoshi Toyoda From owner-ietf-fax@mail.imc.org Sat Jul 6 19:08:39 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 TAA02223 for ; Sat, 6 Jul 2002 19:08:38 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g66Mof714058 for ietf-fax-bks; Sat, 6 Jul 2002 15:50:41 -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 g66Modw14046 for ; Sat, 6 Jul 2002 15:50:39 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KJQY46W680001ZTY@mauve.mrochek.com> for ietf-fax@imc.org; Sat, 06 Jul 2002 15:50:40 -0700 (PDT) Date: Sat, 06 Jul 2002 15:22:20 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: "Your message dated Thu, 04 Jul 2002 14:47:49 -0400" <200207041847.g64IlnZ01345@astro.cs.utk.edu> To: Keith Moore Cc: ned.freed@mrochek.com, Keith Moore , John C Klensin , Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Message-id: <01KJS3BFMAKO001ZTY@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <01KJO6VZBYM0001ZTY@mauve.mrochek.com> <200207041847.g64IlnZ01345@astro.cs.utk.edu> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Keith, your long rant about protocol design philosophy contained, as far as I can tell, no additional technical points about the document under discussion. While continuing such a debate might be interesting on some level, I'm afraid I have neither the time nor the interest in doing so now. > If it seems like I'm attacking the proposal harshly, it's only because > I'm painfully aware of how often SMTP is misimplemented, and because > I think that these discussions should have been had in the broader > SMTP implementor community long before IETF-wide Last Call. I'm sorry, but I know of no IETF process requirement that working groups engage in such discussions, nor for that matter do I know of a means a WG has to insure that such discussions take place. (Both of your recent cross-postings to ietf-822 and ietf-smtp respectively have produced, as far as I can tell, not a single message from anyone who travels in those circles exclusively.) You are of course free to follow the discussion on the various relevant WG lists so you may make your comments on their work in a timely fashion. I suspect people would be a lot more receptive to the sorts of changes you've proposed if you adopted this approach. The number of IETF working groups engaged in the SMTP/MIME/RFC[2]822 area isn't particularly large so this really shouldn't be particularly onerous burden to assume. Ned From owner-ietf-fax@mail.imc.org Sun Jul 7 10:41:58 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 KAA22015 for ; Sun, 7 Jul 2002 10:41:58 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g67ENrk10542 for ietf-fax-bks; Sun, 7 Jul 2002 07:23:53 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g67ENpw10536 for ; Sun, 7 Jul 2002 07:23:52 -0700 (PDT) Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.35 #1) id 17RCvL-000Lmp-00; Sun, 07 Jul 2002 14:22:03 +0000 Date: Sun, 07 Jul 2002 10:22:02 -0400 From: John C Klensin To: ned.freed@mrochek.com cc: Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Message-ID: <303760922.1026037322@localhost> In-Reply-To: <01KJR7EX5EYO001ZTY@mauve.mrochek.com> References: <15649.62973.894081.566925@monkeyboy.gshapiro.net> <3D221C44.5F99DED6@messagingdirect.com> <108177848.1025639386@localhost> <01KJMM5WZSX8001ZTY@mauve.mrochek.com> <122335932.1025653541@localhost> <01KJMXAOJA04001ZTY@mauve.mrochek.com> <197128527.1025728324@localhost> <01KJO8ERG6OO001ZTY@mauve.mrochek.com> <12403111.1025746010@localhost> <01KJOCIFSA84001ZTY@mauve.mrochek.com> <63368316.1025796967@localhost> <01KJR7EX5EYO001ZTY@mauve.mrochek.com> X-Mailer: Mulberry/3.0.0a3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit --On Friday, 05 July, 2002 23:01 -0700 ned.freed@mrochek.com wrote: > I had a couple of other thoughts about this over the past > couple of days: > > (0) There are/will be additional ways to obtain conneg > information: In DSNs or MDNs, through LDAP queries, via > RESCAP, or through direct database queries within a single > mail system. The database/directory mechanism can be used > to advantage in all of these cases. > > (1) Caching of conneg information is certainly possible and > may even be desireable. Indeed, conneg information > returned in DSNs or MDNs will have to be cached in order > to be useful. This document doesn't discuss caching, and > while caching isn't required in the ESMTP context some > discussion of it nevertheless makes sense. > > (2) The use of caches really opens the door to conneg in the > context of relays in ways that nothing else does. For > example, imagine a relay that doesn't do any content > transformation of its own but does do forward conneg > requests to populate a cache. It then offers the information it > has in that cache when it acts as a server. This may sound > kind of cool at first glance, but as the cache comes and > goes it would tend to violate the least astonishment > principle in fairly major ways. Issues also arise if > multiple relays are used, each with a separate cache. Care > is needed here to preserve the ability to "rack and stack" > mail relays without undue consequences. > > This isn't a typical cache since the goal isn't to > minimize the number of forward queries that are done. The > intent here is to provide the information from those > queries in a completely different context. > > The variability problems here can be solved by going to > either extreme: Ban caches of this sort entirely or insist > that components that actually perform content > transformations cache conneg information for a fairly long > period. (It should be obvious that having intermediates > cache information is risky and doesn't solve the problem.) At > first I thought the right answer was to ban this stuff, > but on reflection I think the use of DSNs and MDNs to > return conneg information argue for a mandatory cache in > the transformation agent. Ned, Again, the more of these sorts of things get written down, even as experimental alternatives for further explanation, the happier I would get about the whole picture. Beyond a fairly short list of specific problems (which I think are being addressed), my most significant concern about this proposal is that, as it stands, it appears to be a piece of isolated protocol work that gets injected into an [E]SMTP environment that we know to be a little bit fragile. Anything that can be done to limit that fragility or its impact -- restrictions to fax, retrictions of the relay case(s), explanations of plausible ways to apply the protocol in a safe way, etc. -- would, it seems to me, help a great deal. Which of those are chosen seems to me to be less important. But the current document, without any of it, seems to be an invitation to low-quality implementations that conform to creative readings of a syntax and somewhat underspecfied semantics and thereby get the mail environment into trouble. john From owner-ietf-fax@mail.imc.org Sun Jul 7 14:17:05 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 OAA29034 for ; Sun, 7 Jul 2002 14:17:05 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g67I3FO04799 for ietf-fax-bks; Sun, 7 Jul 2002 11:03:15 -0700 (PDT) Received: from 21cn.com ([61.140.60.248]) by above.proper.com (8.11.6/8.11.3) with SMTP id g67I3Dw04793 for ; Sun, 7 Jul 2002 11:03:13 -0700 (PDT) Received: from 21cn.com([10.2.1.1]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm203d288b03; Mon, 08 Jul 2002 02:01:57 +0800 Received: from loki.ietf.org([127.0.0.1]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm33d239965; Thr, 04 Jul 2002 08:00:48 +0800 Received: from loki.ietf.org([132.151.1.177]) by 21cn.com(AIMC 2.9.5.1) with SMTP id jm03d239e15; Thr, 04 Jul 2002 08:00:48 +0800 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id SAA27618 for ietf-outbound.01@loki.ietf.org; Wed, 3 Jul 2002 18:30:23 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id QAA27106 for ; Wed, 3 Jul 2002 16:16:34 -0400 (EDT) Received: by ietf.org (8.9.1a/8.9.1a) id QAA04451 for ietf-mainout; Wed, 3 Jul 2002 16:15:42 -0400 (EDT) X-Authentication-Warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f Received: from jsc-ems-vws04.jsc.nasa.gov (jsc-ems-vws04.jsc.nasa.gov [139.169.39.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23782 for ; Wed, 3 Jul 2002 13:51:18 -0400 (EDT) Received: from 139.169.16.60 by jsc-ems-vws04.jsc.nasa.gov (InterScan E-Mail VirusWall NT); Wed, 03 Jul 2002 11:39:13 -0500 (Central Daylight Time) Received: by jsc-smtp02.jsc.nasa.gov with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 11:39:13 -0500 Message-ID: <1408A865DCF403478A33EE887F87473201C13B4C@jsc-mail03.jsc.nasa.gov> From: "COLES, RICHARD J. (JSC-EV) (LM)" To: "'ned.freed@mrochek.com'" Cc: ietf-fax@imc.org, ietf@ietf.org Subject: RE: Last Call: SMTP Service Extension for Content Negotiation toP roposed Standard Date: Wed, 3 Jul 2002 11:39:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sorry for the misquote. Sometimes it's hard to tell who said what in these multi-response messages. Even editing the msg does not always help. I just wanted to be sure that everyone knew how important FAX is to NASA (and, I suppose, to other agencies of the Federal government). Tnx/RJC -----Original Message----- From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com] Sent: Wednesday, July 03, 2002 11:24 AM To: COLES, RICHARD J. (JSC-EV) (LM) Cc: ietf-fax@imc.org; ietf@ietf.org Subject: RE: Last Call: SMTP Service Extension for Content Negotiation toProposed Standard > Ned "sed": > > ...fax is dead technology, who cares??? > FAX is NOT dead at NASA. Actually, I never said anything of the kind, nor did I agree with any such statement. Robert Elz said this. My response was merely that even if you believe this is true the current proposal may still be of importance since it has utility outside of the FAX space. Ned From owner-ietf-fax@mail.imc.org Sun Jul 7 14:39:06 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 OAA29963 for ; Sun, 7 Jul 2002 14:39:05 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g67IROf08214 for ietf-fax-bks; Sun, 7 Jul 2002 11:27:24 -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 g67IRNw08209 for ; Sun, 7 Jul 2002 11:27:23 -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 LAA24574; Sun, 7 Jul 2002 11:33:10 -0700 Message-Id: <5.1.1.2.2.20020707111350.033f24c0@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Sun, 07 Jul 2002 11:18:16 -0700 To: "COLES, RICHARD J. (JSC-EV) (LM)" From: Dave Crocker Subject: RE: Last Call: SMTP Service Extension for Content Negotiation toP roposed Standard Cc: ietf-fax@imc.org, ietf@ietf.org In-Reply-To: <1408A865DCF403478A33EE887F87473201C13B4C@jsc-mail03.jsc.na sa.gov> 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 11:39 AM 7/3/2002 -0500, COLES, RICHARD J. (JSC-EV) (LM) wrote: >I just wanted to be sure that everyone knew how important FAX is to NASA >(and, I suppose, to other agencies of the Federal government). Right. Folks often do not realize that even Telex is still a critical infrastructure service, for portions of the world. My guess is that we are looking at 10-20 years before fax is truly relegated to a minor role. Fully replacing well-established infrastructures takes a very long time, no matter how quickly a new one emerges. One reason for doing fax over the Internet is for cheaper and faster fax service, but another is to integrate the fax and email communities, as much as is reasonable. (Personally I have a third goal, which is to provide email with a target service level that is more demanding that Internet mail has provided until now and is known to be useful for business; with fax we get that, and we do not need to debate the philosophy of business communications.) d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Sun Jul 7 17:53:42 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 RAA07300 for ; Sun, 7 Jul 2002 17:53:42 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g67Ld1O23465 for ietf-fax-bks; Sun, 7 Jul 2002 14:39:01 -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 g67Lcxw23460 for ; Sun, 7 Jul 2002 14:38:59 -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 g67LcoZ06453; Sun, 7 Jul 2002 17:38:51 -0400 (EDT) Message-Id: <200207072138.g67LcoZ06453@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: ned.freed@mrochek.com cc: Keith Moore , John C Klensin , Alexey Melnikov , ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Sat, 06 Jul 2002 15:22:20 PDT.") <01KJS3BFMAKO001ZTY@mauve.mrochek.com> Date: Sun, 07 Jul 2002 17:38:50 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ned, I do not share your opinion that someone who is interested in a particular technology has an obligation to follow every WG that might try to alter that technology. First of all, it's not obvious which groups might do this-for instance who would guess that the IPv6 folks would be working on a document that affects how SMTP works? Second, there is just too much traffic on many mailing lists to keep track of lists that are peripheral to one's interests. This is a scaling problem, like many others that we face. -Keith From owner-ietf-fax@mail.imc.org Sun Jul 7 18:11:12 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 SAA08052 for ; Sun, 7 Jul 2002 18:11:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g67Luun24810 for ietf-fax-bks; Sun, 7 Jul 2002 14:56:56 -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 g67Lutw24805 for ; Sun, 7 Jul 2002 14:56:55 -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 PAA30738; Sun, 7 Jul 2002 15:03:12 -0700 Message-Id: <5.1.1.2.2.20020707145029.03451648@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Sun, 07 Jul 2002 14:52:36 -0700 To: Keith Moore From: Dave Crocker Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Cc: ietf@ietf.org, ietf-fax@imc.org In-Reply-To: <200207072138.g67LcoZ06453@astro.cs.utk.edu> References: <(Your message of "Sat, 06 Jul 2002 15:22:20 PDT.") <01KJS3BFMAKO001ZTY@mauve.mrochek.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: At 05:38 PM 7/7/2002 -0400, Keith Moore wrote: >I do not share your opinion that someone who is interested in a particular >technology has an obligation to follow every WG that might try to alter >that technology. First of all, it's not obvious which groups might do >this-for instance who would guess that an internet draft filename that contains the string "esmtp" is a pretty good clue. and remember that i-d's are announced, including their abstracts. the abstract for the current specification is pretty straightforward. d/ ps. to the extent that you perceive a larger, IETF-wide coordination issue, i suspect you will get agreement from many people. the hard part is in proposing a solution that those people will also agree with. ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Mon Jul 8 00:49:16 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 AAA23557 for ; Mon, 8 Jul 2002 00:49:15 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g684Wcs25823 for ietf-fax-bks; Sun, 7 Jul 2002 21:32:38 -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 g684WZw25809 for ; Sun, 7 Jul 2002 21:32:35 -0700 (PDT) Received: from azteca.isd.ricoh.co.jp (IDENT:mirapoint@[133.139.250.74]) by mail.notes.ricoh.co.jp (8.11.6/3.7W) id g684WYF23814; Mon, 8 Jul 2002 13:32:34 +0900 Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by azteca.isd.ricoh.co.jp (Mirapoint) with ESMTP id ADA17544; Mon, 8 Jul 2002 13:32:33 +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 NAA02014; Mon, 8 Jul 2002 13:28:13 +0900 (JST) To: ietf-fax@imc.org, gparsons@nortelnetworks.com Cc: ned.freed@mrochek.com, claudio.allocchio@garr.it, vpim@lists.neystadt.org, um@snowshore.com Subject: Re: IETF-FAX WG Draft agenda at Yokohama From: Hiroshi Tamura In-Reply-To: <20020702192404Q.tamura@toda.ricoh.co.jp> References: <20020702192404Q.tamura@toda.ricoh.co.jp> 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: <20020708133241V.tamura@toda.ricoh.co.jp> Date: Mon, 08 Jul 2002 13:32:41 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 70 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, Regarding draft-ietf-fax-tiff-fx-reg-01.txt, IESG has just approved it at the end of Last Week. Thus, I change it to section 2. Also, I increased the estimated time for ESMPT CONNEG and added the url for new version. Glenn, Shall I combine fax-wg agenda and vpim-wg agenda and send it to agenda@ietf.org? Regards, -- Hiroshi Tamura, Ricoh Company, LTD. tamura@toda.ricoh.co.jp --------------------------------------------------------------------- 1 Agenda Bashing (2 min) 2 The I-Ds which IESG approved and are in RFC editor's queue (1 min) - 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 Urgent Action, i.e. Assignment of RFC Number, is necessary for TIFF-FX for Draft Standard. 3 The I-Ds for which IETF Last Call was finished (2 min) - draft-ietf-fax-gateway-protocol-08.txt - draft-ietf-fax-gateway-options-05.txt - draft-ietf-fax-service-v2-05.txt Reference issue of DSN (RFC1894) and TIFF-FX (draft-ietf-fax-tiff-fx-11.txt) 4 The I-D which IESG is reviewing (Before IETF Last Call) (1 min) - draft-ietf-fax-timely-delivery-05.txt Reference issue of draft-vaudreuil-1983ext-01.txt 5 TIFF-FX implementation report (5 min) The original report and the additional (new) report to be submitted. 6 SMTP Service Extension for Content Negotiation (30 min) - draft-ietf-fax-esmtp-conneg-02.txt - http://www.brandenburg.com/specifications/draft-ietf-fax-esmtp-conneg-03.txt 7 FFPIM (5 min) - draft-ietf-fax-ffpim-01.txt 8 Addressing (5 min) - draft-allocchio-gstn-03.txt 9 FAX in ENUM (5 min) 10 ITU issue (2 min) - Plan for October ITU SG16 meeting Implementers-Guide TIFF-FX issue 11 Confirmation of milestone (2 min) - TIFF-FX for Draft Standard Urgent action need that tiff-fx reg I-D should be Proposed Standard Implementation report - FFPIM - ESMTP CONNEG - Addressing - FAX in ENUM ??? From owner-ietf-fax@mail.imc.org Mon Jul 8 01:07: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 BAA24092 for ; Mon, 8 Jul 2002 01:07:57 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g684rSV27055 for ietf-fax-bks; Sun, 7 Jul 2002 21:53:28 -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 g684rRw27050 for ; Sun, 7 Jul 2002 21:53:27 -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 VAA09945; Sun, 7 Jul 2002 21:59:48 -0700 Message-Id: <5.1.1.2.2.20020707214920.01a57880@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Sun, 07 Jul 2002 21:53:10 -0700 To: Hiroshi Tamura From: Dave Crocker Subject: Re: [VPIM] Re: IETF-FAX WG Draft agenda at Yokohama Cc: ietf-fax@imc.org, vpim@lists.neystadt.org, um@snowshore.com In-Reply-To: <20020708133241V.tamura@toda.ricoh.co.jp> References: <20020702192404Q.tamura@toda.ricoh.co.jp> <20020702192404Q.tamura@toda.ricoh.co.jp> 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 01:32 PM 7/8/2002 +0900, Hiroshi Tamura wrote: >6 SMTP Service Extension for Content Negotiation (30 min) >- draft-ietf-fax-esmtp-conneg-02.txt >- http://www.brandenburg.com/specifications/draft-ietf-fax-esmtp-conneg-03.txt > >7 FFPIM (5 min) >- draft-ietf-fax-ffpim-01.txt The latest version of esmtp-conneg has removed all normative references to fax. This change is intended to make the specification be appropriate for general email use. Toyoda-san and I suggest that the requirement for conforming to fax-oriented use of esmtp-conneg, such as with citations to: [RFC2305] Toyoda, K., Ohno, H., Murai, J. and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 2305, March 1998. and [RFC2534] Masinter, L., Holtman, K., Mutz, A. and D. Wing, " Media Features for Display, Print, and Fax", RFC 2534, March 1999. be added to FFPIM. How do folks feel about this? d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Mon Jul 8 10:31: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 KAA16644 for ; Mon, 8 Jul 2002 10:31:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g68EFvq00100 for ietf-fax-bks; Mon, 8 Jul 2002 07:15:57 -0700 (PDT) Received: from CarWash.IncentiveSystems.com (CarWash.IncentiveSystems.com [66.152.247.41]) by above.proper.com (8.11.6/8.11.3) with SMTP id g68EFuw29996 for ; Mon, 8 Jul 2002 07:15:56 -0700 (PDT) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002070810204014780 ; Mon, 08 Jul 2002 10:20:40 -0400 Received: from incentivesystems.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 8 Jul 2002 10:13:37 -0400 Message-ID: <3D299E11.9070608@incentivesystems.com> Date: Mon, 08 Jul 2002 10:13:37 -0400 From: John Stracke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: ietf@ietf.org, ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard References: <41CBB274CC77984D8A365C0A1B79F692214733@mail.toshiba-tap.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jul 2002 14:13:37.0946 (UTC) FILETIME=[A753D7A0:01C22689] Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Gerry Sancataldo wrote: > I am involved in the technical support/ training area for fax and > internet fax devices and would just like to add that typically a > message/transaction is directed to one recipient only. > In part, though, that's because fax machines have limited UIs; they may support one-to-many, but they don't usually make it easy. Fax software typically has better UI support for one-to-many, and I believe fax-over-IP would lead to software displacing fax machines. Fax-over-POTS software doesn't help if you don't have POTS at your desk, which many business users don't; fax-over-IP software would open things up more. So fax-over-IP would probably lead to an increase in the prevalence over one-to-many. -- /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |This is the .sig that says... Ni! | \========================================================/ From owner-ietf-fax@mail.imc.org Mon Jul 8 11:13: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 LAA18847 for ; Mon, 8 Jul 2002 11:13:45 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g68EvIq03663 for ietf-fax-bks; Mon, 8 Jul 2002 07:57:18 -0700 (PDT) Received: from CarWash.IncentiveSystems.com (CarWash.IncentiveSystems.com [66.152.247.41]) by above.proper.com (8.11.6/8.11.3) with SMTP id g68EvHw03653 for ; Mon, 8 Jul 2002 07:57:17 -0700 (PDT) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002070811021722542 ; Mon, 08 Jul 2002 11:02:17 -0400 Received: from incentivesystems.com ([10.10.48.190]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 8 Jul 2002 10:55:14 -0400 Message-ID: <3D29A7D2.1050606@incentivesystems.com> Date: Mon, 08 Jul 2002 10:55:14 -0400 From: John Stracke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf@ietf.org CC: ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard References: <15649.62973.894081.566925@monkeyboy.gshapiro.net> <3D221C44.5F99DED6@messagingdirect.com> <108177848.1025639386@localhost> <01KJMM5WZSX8001ZTY@mauve.mrochek.com> <122335932.1025653541@localhost> <01KJMXAOJA04001ZTY@mauve.mrochek.com> <197128527.1025728324@localhost> <01KJO8ERG6OO001ZTY@mauve.mrochek.com> <12403111.1025746010@localhost> <01KJOCIFSA84001ZTY@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jul 2002 14:55:14.0197 (UTC) FILETIME=[77358450:01C2268F] Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Robert A. Rosenberg wrote: > At 22:59 -0700 on 07/03/2002, ned.freed@mrochek.com wrote about Re: > The MTA then decides what Transforms are > needed (based on the CONNEG info) and grabs out those that are needed > from the M-P/A set. This removes the Real-Time transform overhead by > off-loading it to the Client. It is, of course, based on a model > where the number of different transforms are limited AND can be > enumerated in the absence of info on the capabilities of the > designated recipients. ...and where you're not interested in signing the message. -- /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |This is the .sig that says... Ni! | \========================================================/ From owner-ietf-fax@mail.imc.org Mon Jul 8 12:23:00 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 MAA22876 for ; Mon, 8 Jul 2002 12:23:00 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g68G5Ur08535 for ietf-fax-bks; Mon, 8 Jul 2002 09:05:30 -0700 (PDT) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g68G5Sw08531 for ; Mon, 8 Jul 2002 09:05:28 -0700 (PDT) Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 17Rb0q-0003YB-00; Mon, 08 Jul 2002 17:05:20 +0100 Date: Mon, 8 Jul 2002 17:05:03 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: ietf-fax@imc.org cc: ietf@ietf.org Subject: RE: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-Reply-To: Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-99.4 required=7.0 tests=IN_REP_TO,SUBJ_HAS_SPACES,USER_IN_WHITELIST version=2.31 X-Scanner: exiscan *17Rb0q-0003YB-00*26eUL8Offac* (SECM, UniS) Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > >I am currently surveying a number of sites (Australian) that are > >currently using Internet Fax and preliminary data indicates that > >over 98% of traffic is to a single recipient. Is Internet Fax Spam a significant problem yet? L. From owner-ietf-fax@mail.imc.org Mon Jul 8 13:21:43 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 NAA26286 for ; Mon, 8 Jul 2002 13:21:43 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g68H3aW14699 for ietf-fax-bks; Mon, 8 Jul 2002 10:03:36 -0700 (PDT) Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g68H2Ew14542; Mon, 8 Jul 2002 10:02:15 -0700 (PDT) Received: (from arnt@localhost) by melkebalanse.gulbrandsen.priv.no (8.11.6/8.11.6) id g68H54I11531; Mon, 8 Jul 2002 19:05:04 +0200 Date: Mon, 8 Jul 2002 19:05:04 +0200 From: Arnt Gulbrandsen To: Keith Moore Cc: "Robert A. Rosenberg" , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Message-ID: <20020708190504.R11195@melkebalanse.gulbrandsen.priv.no> References: <200207041915.g64JFAZ01465@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200207041915.g64JFAZ01465@astro.cs.utk.edu> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Keith Moore > > IMO, the ultimate aim (even if this is not practical) is to deliver > > to each recipient the same version of the Fax as they would have > > received IF they were the only addressee > > I think this is a reasonable and practical goal. I don't think that > recipient A should experience a difference in message quality > (or worse, fail to receive the message at all) based on whether or > not you cc'ed recipient B. Negotiation can mean that A and B receive different messages, both stating (in to/cc) that the other received the one they didn't. Sounds very fishy to my ears. The thing sounds as if it's 100% incompatible with S/MIME and other signature mechansisms. Shouldn't that be mentioned in the draft's security considerations section? --Arnt From owner-ietf-fax@mail.imc.org Mon Jul 8 13:49: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 NAA27610 for ; Mon, 8 Jul 2002 13:49:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g68HWDb17379 for ietf-fax-bks; Mon, 8 Jul 2002 10:32:13 -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 g68HWCw17375; Mon, 8 Jul 2002 10:32:12 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KJQY46W680001ZTY@mauve.mrochek.com>; Mon, 08 Jul 2002 10:31:59 -0700 (PDT) Date: Mon, 08 Jul 2002 10:20:21 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: "Your message dated Mon, 08 Jul 2002 19:05:04 +0200" <20020708190504.R11195@melkebalanse.gulbrandsen.priv.no> To: Arnt Gulbrandsen Cc: Keith Moore , "Robert A. Rosenberg" , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org Message-id: <01KJUKRZRYN2001ZTY@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <200207041915.g64JFAZ01465@astro.cs.utk.edu> <20020708190504.R11195@melkebalanse.gulbrandsen.priv.no> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > Keith Moore > > > IMO, the ultimate aim (even if this is not practical) is to deliver > > > to each recipient the same version of the Fax as they would have > > > received IF they were the only addressee > > > > I think this is a reasonable and practical goal. I don't think that > > recipient A should experience a difference in message quality > > (or worse, fail to receive the message at all) based on whether or > > not you cc'ed recipient B. > Negotiation can mean that A and B receive different messages, both stating > (in to/cc) that the other received the one they didn't. Sounds very fishy > to my ears. This is nothing new; situations arise routinely where the header recipient lists don't tell the full story about who did or did not get a message or a particular version of a message. > The thing sounds as if it's 100% incompatible with S/MIME and other > signature mechansisms. Shouldn't that be mentioned in the draft's security > considerations section? On the contrary, far from being incompatible, this facility may actually facilitate the ability to use signatures in situations where it presently isn't possible to use them. Specifically, if a client is aware of a recipient's needs it can tailor a message for that recipient and then sign it after the tailoring is complete. Without this knowledge what tends to happen is that the tailoring is done after the signature is applied, which of course renders the signature invalid. Now you may argue that such transformations are a bad idea. And on a theoretical level I'd agree with you. But on a practical level the need for them is there, and I'd much rather see then done by the client than by some intermediary. The fact that multipart/signed is designed so that signatures can be attached to content on the fly is also useful in this context. As for mentioning any of this in the security considerations section, I have no problem with that. Ned From owner-ietf-fax@mail.imc.org Mon Jul 8 14:27:24 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 OAA00007 for ; Mon, 8 Jul 2002 14:27:24 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g68IA9X20793 for ietf-fax-bks; Mon, 8 Jul 2002 11:10:09 -0700 (PDT) Received: from turing-police.cc.vt.edu (h80ad3787.dhcp.vt.edu [128.173.55.135]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g68I9tw20759; Mon, 8 Jul 2002 11:09:55 -0700 (PDT) Received: from turing-police.cc.vt.edu (localhost [127.0.0.1]) by turing-police.cc.vt.edu (8.12.4/8.12.4) with ESMTP id g68I84V0005245; Mon, 8 Jul 2002 14:08:04 -0400 Message-Id: <200207081808.g68I84V0005245@turing-police.cc.vt.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: ned.freed@mrochek.com Cc: ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-Reply-To: Your message of "Mon, 08 Jul 2002 10:20:21 PDT." <01KJUKRZRYN2001ZTY@mauve.mrochek.com> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face-Viewer: See ftp://cs.indiana.edu/pub/faces/index.html to decode picture X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ <200207041915.g64JFAZ01465@astro.cs.utk.edu> <20020708190504.R11195@melkebalanse.gulbrandsen.priv.no> <01KJUKRZRYN2001ZTY@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-2078677764P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 08 Jul 2002 14:08:04 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==_Exmh_-2078677764P Content-Type: text/plain; charset=us-ascii On Mon, 08 Jul 2002 10:20:21 PDT, ned.freed@mrochek.com said: > On the contrary, far from being incompatible, this facility may actually > facilitate the ability to use signatures in situations where it presently isn't > possible to use them. Specifically, if a client is aware of a recipient's needs > it can tailor a message for that recipient and then sign it after the > tailoring is complete. Without this knowledge what tends to happen is that the > tailoring is done after the signature is applied, which of course renders the > signature invalid. Unfortunately, the draft as written doesn't provide a mechanism to push that information back as far as the sending MUA - you could only get this to work if the MUA included its own sender-side MTA functionality (which would be at odds with the push to use port 587 and the practice of many ISP's of blocking outbound to port 25 except from their mail servers). -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_-2078677764P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE9KdUEcC3lWbTT17ARArs5AKCLJa/smrdprgGBufaT5PCbSZGFFQCdHemU twx0R0fi3uZProK+M4ZitPY= =34HE -----END PGP SIGNATURE----- --==_Exmh_-2078677764P-- From owner-ietf-fax@mail.imc.org Mon Jul 8 16:18:26 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 QAA06910 for ; Mon, 8 Jul 2002 16:18:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g68K1pA00616 for ietf-fax-bks; Mon, 8 Jul 2002 13:01:51 -0700 (PDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g68K1nw00605 for ; Mon, 8 Jul 2002 13:01:49 -0700 (PDT) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g68K0aF21303; Mon, 8 Jul 2002 16:00:36 -0400 Message-Id: <5.1.0.14.2.20020708154917.04648498@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 08 Jul 2002 16:07:25 -0400 To: "Toyoda, Kiyoshi" From: Richard Shockey Subject: Re: [Enum] SchemaSet strawman Cc: , enum@ietf.org, ietf-fax@imc.org In-Reply-To: <200205280600.AA01259@d23n59.rdmg.mgcs.mei.co.jp> References: <5.1.0.14.2.20020527125808.021ed588@popd.ix.netcom.com> <5.1.0.14.2.20020527125808.021ed588@popd.ix.netcom.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: At 03:00 PM 5/28/2002 +0900, Toyoda, Kiyoshi wrote: >Shockey-san, > >I would like to propose ifax services of ENUM. I comment >below. > >R >I want to use ENUM for two services of IFAX. One is a service to get >simply e-mail address of destination. Another is a service to get >URI of directory server such as LDAP which has the e-mail address >and capability of destination IFAX. I think that the former service >will be acceptable easier by IFAX WG and ENUM WG than latter. So, >I made a simple draft below at first. Please comment. Some how this got lost in my email shuffle but my comments are below.... If you have been following the ENUM list we are now discussing the syntax for expressing your requirements... I suggest looking at: Title : The E.164 to URI DDDS Application Author(s) : P. Faltstrom, M. Mealling Filename : draft-ietf-enum-rfc2916bis-01.txt Pages : 18 Date : 05-Jul-02 This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC WWWW. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC WWWW. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-rfc2916bis-01.txt It proposes a syntax in ABNF format ervice_field = "E2U" + 1*("+" enumservice) enumservice = service [":" protocol] service = 1*32(ALPHA / DIGIT) protocol = 1*32(ALPHA / DIGIT) BTW we are meeting on Tuesday to discuss this proposal and others and there is similar work going on in VPIM as well... A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Voice Profile for Internet Mail Working Group of the IETF. Title : Voice Message Routing Service Author(s) : G. Vaudreuil Filename : draft-ietf-vpim-routing-03.txt Pages : 11 Date : 03-Jul-02 Voice messaging is traditionally addressed using telephone number addressing. This document describes two techniques for routing voice messages based on a telephone number. The VPIM Directory service provides a directory mechanism to lookup a VPIM email address with a telephone number and confirm that the address is both valid and the associated with the intended recipient. However this service will take time become widely deployed in the nearest term. This document also describes a more limited send-and-pray service useful simply to route and deliver messages using only the ENUM telephone number resolution service and the existing DNS mail routing facilies. Please send comments on this document to the VPIM working group mailing list A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-vpim-routing-03.txt >------------------------------------------------------------------- >Network Working Group K. Toyoda, MGCS >Internet Draft > May 2002 >Expires: November 2002 > > > > IFAX service of ENUM I think the timing for this is now perfect with the establishment of a IANA registration procedure for the syntax in 2916bis. The comments of the FAX WG would be most appreciated. > > > > S > >Abstract > > This document describes the functional specification > and the definition of the ENUM NAPTR record, for IFax > service. IFax is "Facsimile using Internet Mail". For > this use, the DNS returns the email address of the > referenced IFax system. > > >1. Functional Specification > > An IFax client makes an Enum DNS query with the target > system's telephone number. The returned NAPTR record > specifies an email address that is to be used for reaching > the target system. The email address is then used in > accordance with "Simple Mode of Facsimile using Internet > Mail" [RFC2305] or "Extended Facsimile using Internet > Mail" [RFC2532] > >2. Definition of NAPTR record >2.1 Service Name > Service Name = "ifax" > The scope of this service is facsimile using Internet mail. > It includes "Simple Mode of Facsimile using Internet Mail" > and "Extended Facsimile using Internet Mail". "Full Mode > Fax Profile for Internet Mail" is applied when it is > approved as an Internet standards-track specification. > >2.2 URI Scheme > Scheme = "mailto" > > The URI Scheme is "mailto" because facsimile using > Internet Mail is a profile for standard Internet mail and > uses standard Internet mail addressing. > > Example > $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa > IN NAPTR 10 10 "u" "E2U+ifax" "!^.*$!mailto:paf@ifax.net!" this looks right with the service being ifax and the protocol being mailto in the syntax proposed IN NAPTR 10 10 "u" "E2U+ifax:smtp" "!^.*$!mailto:paf@ifax.net!" but you can now specify a different transport method if you chose such as IN NAPTR 10 10 "u" "E2U+ifax:ipp" "!^.*$!ipp://username/ifax.net!" if you wish.... or IN NAPTR 10 10 "u" "E2U+ifax:T38" "!^.*$h323:user@faxserver.ifax.net!" as different examples. >2. >6. 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 > > > >Kiyoshi Toyoda >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From owner-ietf-fax@mail.imc.org Mon Jul 8 18:33:46 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 SAA14700 for ; Mon, 8 Jul 2002 18:33:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g68MIuV10836 for ietf-fax-bks; Mon, 8 Jul 2002 15:18:56 -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 g68MIMw10797; Mon, 8 Jul 2002 15:18:22 -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 g68MIEt00306; Mon, 8 Jul 2002 18:18:15 -0400 (EDT) Message-Id: <200207082218.g68MIEt00306@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Arnt Gulbrandsen cc: Keith Moore , "Robert A. Rosenberg" , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Mon, 08 Jul 2002 19:05:04 +0200.") <20020708190504.R11195@melkebalanse.gulbrandsen.priv.no> Date: Mon, 08 Jul 2002 18:18:14 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Negotiation can mean that A and B receive different messages, both stating > (in to/cc) that the other received the one they didn't. Sounds very fishy > to my ears. That's an interesting point. However it's always been possible for recipients listed in the to/cc fields to receive different versions of the message, for some of those listed to not receive the message at all, or for additional recipients to receive the message. Keith From owner-ietf-fax@mail.imc.org Mon Jul 8 19:08:51 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 TAA16218 for ; Mon, 8 Jul 2002 19:08:51 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g68Mt1P14503 for ietf-fax-bks; Mon, 8 Jul 2002 15:55:01 -0700 (PDT) Received: from tap_exchange.toshiba-tap ([203.56.127.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g68Mt0w14498 for ; Mon, 8 Jul 2002 15:55:00 -0700 (PDT) Received: by mail.toshiba-tap.com with Internet Mail Service (5.5.2655.55) id <3HN7WG9X>; Tue, 9 Jul 2002 08:54:57 +1000 Message-ID: <41CBB274CC77984D8A365C0A1B79F69221475A@mail.toshiba-tap.com> From: Gerry Sancataldo To: "'Lloyd Wood'" , ietf-fax@imc.org Cc: ietf@ietf.org Subject: RE: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Date: Tue, 9 Jul 2002 08:54:52 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C226D2.78ADD100" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C226D2.78ADD100 Content-Type: text/plain We have received no reports in Australia/NZ to date of Internet fax spam. Gerry -----Original Message----- From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] Sent: Tuesday, 9 July 2002 2:05 AM To: ietf-fax@imc.org Cc: ietf@ietf.org Subject: RE: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard > >I am currently surveying a number of sites (Australian) that are > >currently using Internet Fax and preliminary data indicates that > >over 98% of traffic is to a single recipient. Is Internet Fax Spam a significant problem yet? L. ------_=_NextPart_001_01C226D2.78ADD100 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Last Call: SMTP Service Extension for Content Negotiation to = Proposed Standard

We have received no reports in Australia/NZ to date = of Internet fax spam.

Gerry

-----Original Message-----
From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk]
Sent: Tuesday, 9 July 2002 2:05 AM
To: ietf-fax@imc.org
Cc: ietf@ietf.org
Subject: RE: Last Call: SMTP Service Extension for = Content Negotiation
to Proposed Standard




> >I am currently surveying a number of sites = (Australian) that are
> >currently using Internet Fax and = preliminary data indicates that
> >over 98% of traffic is to a single = recipient.

Is Internet Fax Spam a significant problem = yet?

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><= ;L.Wood@surrey.ac.uk>

------_=_NextPart_001_01C226D2.78ADD100-- From owner-ietf-fax@mail.imc.org Tue Jul 9 06:01:39 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 GAA18119 for ; Tue, 9 Jul 2002 06:01:38 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g699j1j14393 for ietf-fax-bks; Tue, 9 Jul 2002 02:45:01 -0700 (PDT) Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g699iWw14343; Tue, 9 Jul 2002 02:44:32 -0700 (PDT) Received: (from arnt@localhost) by melkebalanse.gulbrandsen.priv.no (8.11.6/8.11.6) id g699lXA11668; Tue, 9 Jul 2002 11:47:33 +0200 Date: Tue, 9 Jul 2002 11:47:33 +0200 From: Arnt Gulbrandsen To: ned.freed@mrochek.com Cc: Keith Moore , "Robert A. Rosenberg" , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Message-ID: <20020709114733.I11574@melkebalanse.gulbrandsen.priv.no> References: <200207041915.g64JFAZ01465@astro.cs.utk.edu> <20020708190504.R11195@melkebalanse.gulbrandsen.priv.no> <01KJUKRZRYN2001ZTY@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01KJUKRZRYN2001ZTY@mauve.mrochek.com> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ned.freed@mrochek.com > > Negotiation can mean that A and B receive different messages, both stating > > (in to/cc) that the other received the one they didn't. Sounds very fishy > > to my ears. > > This is nothing new; situations arise routinely where the header recipient > lists don't tell the full story about who did or did not get a message Agreed. It's nothing new -- just more of a bad thing. I suppose it's okay, though. If to/cc never were truly reliable, making them even less reliable is no big deal. Even if it's the first time a Proposed Standard does it. > or a > particular version of a message. Hm? I know that some mailing lists do rather a lot of header field rewriting and/or append a new signature. Are there other examples? > > The thing sounds as if it's 100% incompatible with S/MIME and other > > signature mechansisms. Shouldn't that be mentioned in the draft's security > > considerations section? ... > As for mentioning any of this in the security considerations section, I > have no problem with that. Good. That's what I want. --Arnt From owner-ietf-fax@mail.imc.org Tue Jul 9 06:09:11 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 GAA18278 for ; Tue, 9 Jul 2002 06:09:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g699s2315132 for ietf-fax-bks; Tue, 9 Jul 2002 02:54:02 -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 g699s1w15128; Tue, 9 Jul 2002 02:54:01 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KJVIRWXG68001ZTY@mauve.mrochek.com>; Tue, 09 Jul 2002 02:53:59 -0700 (PDT) Date: Tue, 09 Jul 2002 02:48:04 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: "Your message dated Tue, 09 Jul 2002 11:47:33 +0200" <20020709114733.I11574@melkebalanse.gulbrandsen.priv.no> To: Arnt Gulbrandsen Cc: ned.freed@mrochek.com, Keith Moore , "Robert A. Rosenberg" , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org Message-id: <01KJVJ2IFTRA001ZTY@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <200207041915.g64JFAZ01465@astro.cs.utk.edu> <20020708190504.R11195@melkebalanse.gulbrandsen.priv.no> <01KJUKRZRYN2001ZTY@mauve.mrochek.com> <20020709114733.I11574@melkebalanse.gulbrandsen.priv.no> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > ned.freed@mrochek.com > > > Negotiation can mean that A and B receive different messages, both stating > > > (in to/cc) that the other received the one they didn't. Sounds very fishy > > > to my ears. > > > > This is nothing new; situations arise routinely where the header recipient > > lists don't tell the full story about who did or did not get a message > Agreed. It's nothing new -- just more of a bad thing. > I suppose it's okay, though. If to/cc never were truly reliable, making > them even less reliable is no big deal. Even if it's the first time a > Proposed Standard does it. Hardly the first time. MIME itself has the notion of downgrading from 8bit to 7bit or from binary to 8bit. > > or a > > particular version of a message. > Hm? I know that some mailing lists do rather a lot of header field > rewriting and/or append a new signature. Are there other examples? Sure. There's plenty of content conversion/charset conversion/reformatting/virus removal, etc. etc. etc. going on out there already. Ned From owner-ietf-fax@mail.imc.org Tue Jul 9 07:26:43 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 HAA19917 for ; Tue, 9 Jul 2002 07:26:43 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g69BBno26314 for ietf-fax-bks; Tue, 9 Jul 2002 04:11:49 -0700 (PDT) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g69BBlw26310 for ; Tue, 9 Jul 2002 04:11:47 -0700 (PDT) Received: by bulls.mei.co.jp (8.12.5/3.7W/bulls) with ESMTP id g69BBIqU015912; Tue, 9 Jul 2002 20:11:18 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/dodgers) with SMTP id g69BBHi03964; Tue, 9 Jul 2002 20:11:17 +0900 (JST) Received: from no.name.available by m-bb2.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 9 Jul 2002 11:11:19 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0-1.mgcs.mei.co.jp (8.12.2/3.7W-HUB) with ESMTP id g69B7swR016490; Tue, 9 Jul 2002 20:07:54 +0900 (JST) Received: from mlsv2.rdmg.mgcs.mei.co.jp by mlsv1.mgcs.mei.co.jp (8.9.3/3.7W-MGCS) with ESMTP id UAA21037; Tue, 9 Jul 2002 20:11:18 +0900 (JST) Received: from d23n59.rdmg.mgcs.mei.co.jp by mlsv2.rdmg.mgcs.mei.co.jp (8.12.2/3.7W-RDMG) with SMTP id g69BAMl8020909; Tue, 9 Jul 2002 20:10:22 +0900 (JST) Message-Id: <200207091119.AA01500@d23n59.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Tue, 09 Jul 2002 20:19:10 +0900 To: Richard Shockey Cc: , ietf-fax@imc.org Subject: Re: [Enum] SchemaSet strawman In-Reply-To: <5.1.0.14.2.20020708154917.04648498@popd.ix.netcom.com> References: <5.1.0.14.2.20020708154917.04648498@popd.ix.netcom.com> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.12 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Richard Shockey wrote: > >Some how this got lost in my email shuffle but my comments are below.... > >If you have been following the ENUM list we are now discussing the syntax >for expressing your requirements... I suggest looking at: Thank you for your suggestion. I have looked at the draft and add ":smtp" to the exmaple as below. I prefer "ABNF Syntax for enumservice Faltstrom/Mealling" to "ABNF Syntax for enumservice Brandner/Stastny/Conroy". Example $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa IN NAPTR 10 10 "u" "E2U+ifax:smtp" "!^.*$!mailto:paf@ifax.net!" > > >Title : The E.164 to URI DDDS Application > Author(s) : P. Faltstrom, M. Mealling > Filename : draft-ietf-enum-rfc2916bis-01.txt > Pages : 18 > Date : 05-Jul-02 > >This document discusses the use of the Domain Name System (DNS) for >storage of E.164 numbers. More specifically, how DNS can be used for >identifying available services connected to one E.164 number. It >specifically obsoletes RFC 2916 to bring it in line with the Dynamic >Delegation Discovery System (DDDS) Application specification found in >the document series specified in RFC WWWW. It is very important to >note that it is impossible to read and understand this document >without reading the documents discussed in RFC WWWW. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-enum-rfc2916bis-01.txt > >It proposes a syntax in ABNF format > >ervice_field = "E2U" + 1*("+" enumservice) >enumservice = service [":" protocol] >service = 1*32(ALPHA / DIGIT) >protocol = 1*32(ALPHA / DIGIT) > > >BTW we are meeting on Tuesday to discuss this proposal and others and there >is similar work going on in VPIM as well... You mean the meeting of FAX&VPIM WG? > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Voice Profile for Internet Mail Working >Group of the IETF. > > Title : Voice Message Routing Service > Author(s) : G. Vaudreuil > Filename : draft-ietf-vpim-routing-03.txt > Pages : 11 > Date : 03-Jul-02 > >Voice messaging is traditionally addressed using telephone number >addressing. This document describes two techniques for routing voice >messages based on a telephone number. The VPIM Directory service >provides a directory mechanism to lookup a VPIM email address with a >telephone number and confirm that the address is both valid and the >associated with the intended recipient. However this service will >take time become widely deployed in the nearest term. This document >also describes a more limited send-and-pray service useful simply to >route and deliver messages using only the ENUM telephone number >resolution service and the existing DNS mail routing facilies. >Please send comments on this document to the VPIM working group >mailing list > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-vpim-routing-03.txt > > > Kiyoshi Toyoda From owner-ietf-fax@mail.imc.org Wed Jul 10 16:03:31 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 QAA17537 for ; Wed, 10 Jul 2002 16:03:30 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6AJkN512665 for ietf-fax-bks; Wed, 10 Jul 2002 12:46:23 -0700 (PDT) Received: from jsc-ems-vws03.jsc.nasa.gov (jsc-ems-vws03.jsc.nasa.gov [139.169.39.50]) by above.proper.com (8.11.6/8.11.3) with SMTP id g6AJkLw12659 for ; Wed, 10 Jul 2002 12:46:22 -0700 (PDT) Received: from 139.169.16.59 by jsc-ems-vws03.jsc.nasa.gov (InterScan E-Mail VirusWall NT); Wed, 10 Jul 2002 14:10:32 -0500 (Central Daylight Time) Received: by jsc-smtp01.jsc.nasa.gov with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Jul 2002 14:10:32 -0500 Message-ID: <1408A865DCF403478A33EE887F87473201C13B71@jsc-mail03.jsc.nasa.gov> From: "COLES, RICHARD J. (JSC-EV) (LM)" To: "'Dave Crocker'" Cc: ietf-fax@imc.org, ietf@ietf.org Subject: RE: Last Call: SMTP Svc Ext Date: Wed, 10 Jul 2002 14:10:28 -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: Dave, Thanks for the vote of confidence. I have replied to a few people privately (including Messrs. Hodaka, Abley & Richardson , et al), all of whom wrote to suggest scanning the document, then sending it e-mail. One respondent chided me for being for being "US-centric". I work at a Federal Government installation. How am I supposed to think? Mongolian-centric? (don't answer that...) I know that many of you on the list are not in the US. Claudio is not even in the Western Hemisphere. That does not mean that I am ignoring their needs, just as I don't want them to ignore my needs. Even so, I would like to thank all of them for their suggestions, but I will also list below the reasons (for everyone else) why we don't do much scanning. First, I must admit that I think a small percentage of people around NASA (including their contractors) have the attitude of "we have always done it this way", thus they are not interested in change. I am not one of them. If I was, I would not be on this list. Second, we do not have a lot of scanners in our network (not much requirement for them), so we must either buy one (not easy to do with our current budget), or find someone to do it for us. These people are few & far between, and usually too busy to assist us, or they are doing so much scanning of their own that they tie up their equipment. And for security reasons, NASA (at least in Houston) does not like for us to use each other's computers without the "owner" being present. Either way, this ties up 2 people for one scanning job. And that slows things down quite a bit versus faxing a document to the end user. Third, and possibly the most significant reason is that we send things that are one-time-only requirements. If we know in advance that we need to send this to a lot of others, we could scan it & create a PDF, instead of POLL faxing. Polling would take longer, depending on the number of recipients. The delay to the users on the bottom of a long POLL list could be excessive, thus scanning might be a good alternative. However, this is a very rare case around here (in my experience). Fourth is storage space. If we scanned every document we thought we might need, it would require a StorageTek data warehouse like the one used in the Harrison Ford movie "Clear & Present Danger". Most of the documents we would be scanning will never need to be sent to anyone via e-mail. All of that scanning would be a waste of labor in a tight-budget environment. Fifth. Most of the people to whom the document is sent require a hard-copy for a data package or some other file, so they would print the electronic document on the other end, anyway. Fax is a lot faster than scanning on this end of an e-mail & printing on the other end. I must admit that the resolution from the sender's 600 dpi scanner & the recipient's 1200 dpi laser printer is probably better than the average fax, but we must always be aware of the extra time requirements for e-mail transmission versus fax. Sometimes, the document is needed so quickly on the other end that scanning here & printing there could cost us a launch deadline (an extreme example, to be sure, but a possibility, nonetheless). So, I will repeat a previous posting: NASA needs FAX. Think of the money to be saved, everywhere in the world, when governments & businesses (and individuals) can send fax via the Net & not pay long-distance rates. Thanks again & regards to all, Richard Coles -----Original Message----- From: Dave Crocker [mailto:dcrocker@brandenburg.com] Sent: Sunday, July 07, 2002 1:18 PM To: COLES, RICHARD J. (JSC-EV) (LM) Cc: ietf-fax@imc.org; ietf@ietf.org Subject: RE: Last Call: SMTP Service Extension for Content Negotiation toP roposed Standard At 11:39 AM 7/3/2002 -0500, COLES, RICHARD J. (JSC-EV) (LM) wrote: >I just wanted to be sure that everyone knew how important >FAX is to NASA (and, I suppose, to other agencies of the >Federal government). Right. Folks often do not realize that even Telex is still a critical infrastructure service, for portions of the world. My guess is that we are looking at 10-20 years before fax is truly relegated to a minor role. Fully replacing well-established infrastructures takes a very long time, no matter how quickly a new one emerges. One reason for doing fax over the Internet is for cheaper and faster fax service, but another is to integrate the fax and email communities, as much as is reasonable. (Personally I have a third goal, which is to provide email with a target service level that is more demanding that Internet mail has provided until now and is known to be useful for business; with fax we get that, and we do not need to debate the philosophy of business communications.) d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Wed Jul 10 19:10:49 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 TAA22932 for ; Wed, 10 Jul 2002 19:10:49 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6ALh7D21526 for ietf-fax-bks; Wed, 10 Jul 2002 14:43:07 -0700 (PDT) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6ALh6w21513 for ; Wed, 10 Jul 2002 14:43:06 -0700 (PDT) Received: (ole@localhost) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id OAA07265; Wed, 10 Jul 2002 14:42:59 -0700 (PDT) X-Authentication-Warning: wells.cisco.com: ole set sender to ole@cisco.com using -f Date: Wed, 10 Jul 2002 14:42:59 -0700 (PDT) From: "Ole J. Jacobsen" Reply-To: Ole Jacobsen To: "COLES, RICHARD J. (JSC-EV) (LM)" cc: "'Dave Crocker'" , Subject: RE: Last Call: SMTP Svc Ext In-Reply-To: <1408A865DCF403478A33EE887F87473201C13B71@jsc-mail03.jsc.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: One note: Use of fax varies from country to country. In Japan, every business from the corner noodle shop to the major corporations have "fax maps" -- an image either on paper or stored in memory that shows the location of the business relative to major streets, train stations and so on. This is because of the strange house numbering system they use, and it is unlikely to change in the near future. I realize that the images could be transmitted in many other file formats, but I don't see this changing for the noodle shop unless fax is somehow forced out. On the other hand, Japan has an impressive record on replacing technologies quickly. Ole Ole J. Jacobsen Editor and Publisher The Internet Protocol Journal Office of the CTO, Cisco Systems Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: ole@cisco.com URL: http://www.cisco.com/ipj **** July 8 - 21: in Japan iMode phone +81 90 33 37 93 11 **** Short messages to: From owner-ietf-fax@mail.imc.org Fri Jul 12 06:32:55 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 GAA15632 for ; Fri, 12 Jul 2002 06:32:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6CAFuD11843 for ietf-fax-bks; Fri, 12 Jul 2002 03:15:56 -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 g6CABnw10052; Fri, 12 Jul 2002 03:11:49 -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 g6CABjF01310; Fri, 12 Jul 2002 19:11:45 +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 ADP01558; Fri, 12 Jul 2002 19:11:42 +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 TAA03154; Fri, 12 Jul 2002 19:07:19 +0900 (JST) To: iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org Cc: dcrocker@brandenburg.com, ktoyoda@rdmg.mgcs.mei.co.jp Subject: Keywords for "SMTP Service Extension for Content Negotiation" 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: <20020712191142T.tamura@toda.ricoh.co.jp> Date: Fri, 12 Jul 2002 19:11:42 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 32 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, There will be lots of discussion at FAX WG meeting in Yokohama. For your convenience, I summarize the keywords at very random, although they may not be covered. - fax-specific or not - multi-recipient - LCD - new command RCAP?? - RSET - VRFY - consideration of relay - content transforamation - only CONNEG or CONNEG=REQUIRED/OPTIONAL - interoprability with existing environment - how to handle with response/status code - real-time - bandwidth - multipart/alternative - security - Experimental or Proposed Standard - ... - ... Toyoda-san and Dave: Could you please consider some of them at your presentation? Regards, -- Hiroshi Tamura, Co-chair of IETF-FAX WG tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Fri Jul 12 21:36:46 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 VAA23488 for ; Fri, 12 Jul 2002 21:36:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6D1Dcn06550 for ietf-fax-bks; Fri, 12 Jul 2002 18:13:38 -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 g6D1Dbw06546 for ; Fri, 12 Jul 2002 18:13:37 -0700 (PDT) Received: from GK-VAIO.ninebynine.org ([61.193.174.82]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g6D1AH407697; Fri, 12 Jul 2002 18:10:17 -0700 Message-Id: <5.1.0.14.2.20020709194434.00a21ac0@joy.songbird.com> X-Sender: gk-lists@joy.songbird.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 09 Jul 2002 19:49:47 +0100 To: Keith Moore From: Graham Klyne Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Cc: ietf-fax@imc.org In-Reply-To: <200207060000.g6600mZ04440@astro.cs.utk.edu> References: <(Your message of "Fri, 05 Jul 2002 16:13:53 PDT.") <5.1.1.2.2.20020705161234.03b3a008@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: At 08:00 PM 7/5/02 -0400, Keith Moore wrote: >in other words, enabling the sender to make the choice is not >compatible with the vast majority of the deployed email >infrastructure (even assuming that those MTAs are extended to >support this extension) Having the sender make the final choice of format is fundamental to the content negotiation work completed so far for Internet fax, and is very much in line with the fax service model that we are trying to emulate. (I assume that the main goal of the SMTP extension is to optimize this service model in the case where direct connection is available to a relay that can directly discover the final recipients' capabilities.) #g ------------------- Graham Klyne From owner-ietf-fax@mail.imc.org Fri Jul 12 21:36:51 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 VAA23504 for ; Fri, 12 Jul 2002 21:36:51 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6D1Ddb06556 for ietf-fax-bks; Fri, 12 Jul 2002 18:13:39 -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 g6D1Dcw06551 for ; Fri, 12 Jul 2002 18:13:38 -0700 (PDT) Received: from GK-VAIO.ninebynine.org ([61.193.174.82]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g6D1AL407704; Fri, 12 Jul 2002 18:10:21 -0700 Message-Id: <5.1.0.14.2.20020709200424.00a3a360@joy.songbird.com> X-Sender: gk-lists@joy.songbird.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 09 Jul 2002 20:11:13 +0100 To: ned.freed@mrochek.com From: Graham Klyne Subject: Caching capability information Cc: ietf-fax@imc.org In-Reply-To: <01KJR7EX5EYO001ZTY@mauve.mrochek.com> References: <"Your message dated Thu, 04 Jul 2002 15:36:07 -0400" <63368316.1025796967@localhost> <15649.62973.894081.566925@monkeyboy.gshapiro.net> <3D221C44.5F99DED6@messagingdirect.com> <108177848.1025639386@localhost> <01KJMM5WZSX8001ZTY@mauve.mrochek.com> <122335932.1025653541@localhost> <01KJMXAOJA04001ZTY@mauve.mrochek.com> <197128527.1025728324@localhost> <01KJO8ERG6OO001ZTY@mauve.mrochek.com> <12403111.1025746010@localhost> <01KJOCIFSA84001ZTY@mauve.mrochek.com> <63368316.1025796967@localhost> 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 11:01 PM 7/5/02 -0700, ned.freed@mrochek.com wrote: >I had a couple of other thoughts about this over the past couple of days: > >(0) There are/will be additional ways to obtain conneg information: In > DSNs or MDNs, through LDAP queries, via RESCAP, or through direct > database queries within a single mail system. The database/directory > mechanism can be used to advantage in all of these cases. > >(1) Caching of conneg information is certainly possible and may even > be desireable. Indeed, conneg information returned in DSNs or MDNs will > have to be cached in order to be useful. This document doesn't discuss > caching, and while caching isn't required in the ESMTP context some > discussion of it nevertheless makes sense. > >(2) The use of caches really opens the door to conneg in the context > of relays in ways that nothing else does. For example, imagine a relay > that doesn't do any content transformation of its own but does do forward > conneg requests to populate a cache. It then offers the information it > has in that cache when it acts as a server. This may sound kind of cool > at first glance, but as the cache comes and goes it would tend to > violate the least astonishment principle in fairly major ways. > Issues also arise if multiple relays are used, each with a separate > cache. Care is needed here to preserve the ability to "rack and stack" > mail relays without undue consequences. > > This isn't a typical cache since the goal isn't to minimize the number > of forward queries that are done. The intent here is to provide the > information from those queries in a completely different context. > > The variability problems here can be solved by going to either > extreme: Ban caches of this sort entirely or insist that components > that actually perform content transformations cache conneg information > for a fairly long period. (It should be obvious that having intermediates > cache information is risky and doesn't solve the problem.) At first I > thought the right answer was to ban this stuff, but on reflection I think > the use of DSNs and MDNs to return conneg information argue for a > mandatory cache in the transformation agent. It's not relevant to the current draft under discussion, but I'd like to flag that the (UA-driven) content negotiation approach (awaiting RFC publication) overcomes these caching concerns. Indeed the design presumes caching to achieve 1-round-trip performance, but can correct itself (using a second R-T) if the cached information turns out to be incorrect. #g ------------------- Graham Klyne From owner-ietf-fax@mail.imc.org Fri Jul 12 21:36: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 VAA23528 for ; Fri, 12 Jul 2002 21:36:57 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6D1Doa06579 for ietf-fax-bks; Fri, 12 Jul 2002 18:13:50 -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 g6D1Dnw06568 for ; Fri, 12 Jul 2002 18:13:49 -0700 (PDT) Received: from GK-VAIO.ninebynine.org ([61.193.174.82]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g6D1AR407715; Fri, 12 Jul 2002 18:10:27 -0700 Message-Id: <5.1.0.14.2.20020709201837.00a3b110@joy.songbird.com> X-Sender: gk-lists@joy.songbird.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 09 Jul 2002 20:23:10 +0100 To: Dave Crocker From: Graham Klyne Subject: Re: [VPIM] Re: IETF-FAX WG Draft agenda at Yokohama Cc: Hiroshi Tamura , ietf-fax@imc.org, vpim@lists.neystadt.org, um@snowshore.com In-Reply-To: <5.1.1.2.2.20020707214920.01a57880@jay.songbird.com> References: <20020708133241V.tamura@toda.ricoh.co.jp> <20020702192404Q.tamura@toda.ricoh.co.jp> <20020702192404Q.tamura@toda.ricoh.co.jp> 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: Dave, If you were to do this, I think you'd also need to state, reasonably tightly, the conditions under which the esmtp negotiation would be used rather than the UA-based negotiation. I fear possible confusion or fragmentated deployments could be caused if two negotiation mechanisms are referenced in FFPIM. #g -- At 09:53 PM 7/7/02 -0700, Dave Crocker wrote: >At 01:32 PM 7/8/2002 +0900, Hiroshi Tamura wrote: >>6 SMTP Service Extension for Content Negotiation (30 min) >>- draft-ietf-fax-esmtp-conneg-02.txt >>- >>http://www.brandenburg.com/specifications/draft-ietf-fax-esmtp-conneg-03.txt >> >>7 FFPIM (5 min) >>- draft-ietf-fax-ffpim-01.txt > >The latest version of esmtp-conneg has removed all normative references to >fax. This change is intended to make the specification be appropriate for >general email use. > >Toyoda-san and I suggest that the requirement for conforming to >fax-oriented use of esmtp-conneg, such as with citations to: > > [RFC2305] Toyoda, K., Ohno, H., Murai, J. and D. Wing, > "A Simple Mode of Facsimile Using Internet Mail", > RFC 2305, March 1998. >and > [RFC2534] Masinter, L., Holtman, K., Mutz, A. and D. Wing, " > Media Features for Display, Print, and Fax", > RFC 2534, March 1999. > >be added to FFPIM. > >How do folks feel about this? > >d/ > >---------- >Dave Crocker >Brandenburg InternetWorking >tel +1.408.246.8253; fax +1.408.850.1850 > >---------------------------------------------------------- >This message was sent to you, since you are subscribed to >vpim@lists.neystadt.org. You can manage your subscription at >http://www.neystadt.org/cgi-bin/majordomo ------------------- Graham Klyne From owner-ietf-fax@mail.imc.org Sat Jul 13 00:03:25 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 AAA27660 for ; Sat, 13 Jul 2002 00:03:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6D3mct16634 for ietf-fax-bks; Fri, 12 Jul 2002 20:48:38 -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 g6D3maw16628 for ; Fri, 12 Jul 2002 20:48:36 -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 g6D3mct17674; Fri, 12 Jul 2002 23:48:38 -0400 (EDT) Message-Id: <200207130348.g6D3mct17674@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Graham Klyne cc: Keith Moore , ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Tue, 09 Jul 2002 19:49:47 BST.") <5.1.0.14.2.20020709194434.00a21ac0@joy.songbird.com> Date: Fri, 12 Jul 2002 23:48:38 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > At 08:00 PM 7/5/02 -0400, Keith Moore wrote: > >in other words, enabling the sender to make the choice is not > >compatible with the vast majority of the deployed email > >infrastructure (even assuming that those MTAs are extended to > >support this extension) > > Having the sender make the final choice of format is fundamental to the > content negotiation work completed so far for Internet fax, and is very > much in line with the fax service model that we are trying to emulate. okay, but I don't think that's clear from reading the document. and like I said, it won't work for current typical SMTP deployments - for those the MTA making the decision is almost certainly going to be distant from the recipient. and given the huge problems with viruses and spam, I don't think we're likely to see a movement to open up direct access to SMTP servers. actually I have to wonder - will network admins open up port 25 even to allow incoming traffic to go directly to their internet fax machines when they won't do so for SMTP servers on general-purpose hosts? in any network of sufficient size it seems like it would be a major pain to keep track of which hosts were fax machines and which were something else. far easier to just require all port 25 traffic to go through a firewall of some kind. Keith From owner-ietf-fax@mail.imc.org Sat Jul 13 00:59:29 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 AAA29394 for ; Sat, 13 Jul 2002 00:59:29 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6D4j9H19357 for ietf-fax-bks; Fri, 12 Jul 2002 21:45:09 -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 g6D4i6w19337; Fri, 12 Jul 2002 21:44:06 -0700 (PDT) Received: from BBFUJIP.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 VAA23954; Fri, 12 Jul 2002 21:50:37 -0700 Message-Id: <5.1.0.14.2.20020713100917.083f42e0@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 13 Jul 2002 12:04:48 +0900 To: Hiroshi Tamura From: Dave Crocker Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" Cc: iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org, ktoyoda@rdmg.mgcs.mei.co.jp In-Reply-To: <20020712191142T.tamura@toda.ricoh.co.jp> 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 07:11 PM 7/12/2002 +0900, Hiroshi Tamura wrote: >There will be lots of discussion at FAX WG meeting in Yokohama. >For your convenience, I summarize the keywords at very random, >although they may not be covered. Tamura-san, thank you very much for listing these terms. It is easy to forget that these terms are not familiar to everyone. Also, the discussion has sometimes been confusing I encourage people to list additional terms that should be explained. Here are my own, personal comments and explanations. I think some are simple, but others might be controversial. Also there might be more than one explanation. I encourage others to offer their own versions: >- fax-specific or not It is strange, but I think this is the most difficult term. When we talk about T.30, it is easy to know what it means to say "fax-specific". When we talk about FFPIM, perhaps it is not so easy. For the IETF Fax working group, I believe "fax-specific" refers to features and functions that emulate T.30. That is, we are trying to make Internet mail provide the same service as T.30. So, "fax-specific" refers to email enhancements that permit email to work like fax. >- multi-recipient Internet mail permits a message to be addressed to more than one person. For example, see the To and CC fields of this message. T.30 permits addressing a single receiving device. Some fax store-and-forward services permit the sender to specify more than one receiver. This is multi-recipient. >- LCD Least Common Denominator. So, we are borrowing a term from math, to apply to our discussion of ESMTP/CONNEG, it is possible to receive CONNEG parameters for multiple recipients. If the recipients have different capabilities, what capabilities should the sender use? One possibility is to end the current SMTP session and then send each recipient the best content they can receive. Another possibility is to find the "intersection" of capabilities for all the recipients and send this "least common denominator" or "most common format" to all of the recipients at once. >- new command RCAP?? The current ESMTP/CONNEG specification uses the RCPT command for finding each recipient's capabilities. Moore-san prefers to have the capabilities query be in a separate command. For convenience, he has given this command a name, RCAP. So, the name refers to an idea that Moore-san has. There is no written specification for that command. In my opinion, the current specification is satisfactory. >- RSET >- VRFY These are SMTP commands. RSET ends the current SMTP session. The command means "reset". VRFY lets a client SMTP ask a server SMTP to "verify" the validity of an address, before using it. This command is no longer very popular, because it provides an easy way for spam senders to test for new addresses. >- consideration of relay Facsimile is direct, point-to-point. The sending device and the receiving device are connected to each other at the same time. They talk with each other directly. Internet mail is store-and-forward. The sender and the receiver are not required to be connected to the Internet at the same time. The email may go through intermediate email services, when moving from the sender to the receiver. (For example, it may go from a department's SMTP mail system to the enterprise system; the enterprise system may send it to the receiving enterprise's system; the receiving system may then send it to the receiver's department email server.) This is like packet switching. Each intermediate system is "relaying" the email. The primary difference between relaying versus direct is that relaying might take much longer. Therefore the sender does not know when it will receive a response. On the Internet, a direct connection usually has a response time of a few minutes, maximum. Normally it is much shorter, of course. For email relaying, response time can be days, not minutes. This difference in latency requires different design choices. >- content transforamation Converting content from TIF to JPEG, and JPEG to GIF are examples of content transformation. Converting from UTF-8 to UTF-16 is also an example of content transformation. >- only CONNEG or CONNEG=REQUIRED/OPTIONAL I do not know what "only CONNEG" means, here. >- interoprability with existing environment When we add a new feature, how does it affect the old operation? Sometimes adding a new features makes the old system stop working. For MIME, the goal was to add a new feature that made no change to email transport and also would not break an old email user agent. The goal with ESMTP options is to make old operations behave the old way, but permit participants who support a new option to use them with each other. >- how to handle with response/status code I believe this refers to a concern that ESMTP/CONNEG uses extended ESMTP response/status codes in an usual way. The concern is not widely held. >- real-time I think that we use this term very informally in the Fax working group discussions. Probably it simply means "quickly". Perhaps we can simply use it to mean "within the limits of T.30 timeouts" -- 2 seconds? For the design of human interaction, real-time usually mean 1/2 second, or less. For the design or high performance system, it can refer to milliseconds or microseconds. >- bandwidth The amount of data that can be send within a period of time. The bandwidth of a T1 (or E1) line is very much greater than a dial-up connection. >- multipart/alternative The MIME standard for Internet mail specifies a means of attaching one or more segments (body-parts) of content. Multipart/mixed is used for specifying multiple attachments that are not related to each other. Multipart/alternate is use to specify multiple attachments that are different versions of the same content. For example, one might be ASCII; another might be HTML, and another might be PDF. When the sender does not know the capabilities of the recipient, the sender can use multipart/alternative to send more than one version of the content. The sender is guessing that the receiver can process at least one of the forms. >- security Gomen nasai. This is a very big topic, of course. I think the discussion of security for ESMTP/CONNEG only has the concern about violating privacy. By using this option, the receiving server is divulging features of the recipient. It is possible that such information is private, or that distribution of such information must be restricted. >- Experimental or Proposed Standard The IETF standards process has 3 classes of categorization: And Experimental document is NOT on the standards track. The document is published for the benefit of the community and the author is requesting feedback, especially comments about experiments that use the specification. A Best Current Practises categorization refers to documents that describes operations and administration procedures. They do not define protocols, they define the USE of protocols and procedures. The IETF standards track has 3 levels: Proposed, Draft and (full) Standard. Proposed is the first level. A document must be complete, for the task it defines and must have no known errors. However the specification usually does not have to be implemented and tested. Implementation and testing are required to reach Draft standard. In the discussion for ESMTP/CONNEG, some participants are concerned that the option may cause bad effects on normal SMTP usage. They believe that the specification should be classed as Experimental until it is tested. My own comments about this are that all new protocols carry some risk. The pressure to select Experimental (non-standards) status usually is reserved for specifications that are complicated and poorly understand, or for specifications that have an inherently high degree of risk. In my opinion, ESMTP/CONNEG is a simple option with little risk. I believe that we DO need to learn to use it. It DOES add some complexity and it extends use of the ESMTP option feature in some way. However I believe that the risks involve efficiency, not core functionality. That is, I believe that implementors must learn to make the option work well, but that the option should be relatively safe. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Sat Jul 13 03:27:42 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 DAA13923 for ; Sat, 13 Jul 2002 03:27:42 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6D7C7J04600 for ietf-fax-bks; Sat, 13 Jul 2002 00:12:07 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6D7C5w04589; Sat, 13 Jul 2002 00:12:05 -0700 (PDT) Received: from ns.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 3.35 #1) id 17TH48-000AgV-00; Sat, 13 Jul 2002 07:11:41 +0000 Date: Sat, 13 Jul 2002 03:11:13 -0400 From: John C Klensin To: Dave Crocker , Hiroshi Tamura cc: iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org, ktoyoda@rdmg.mgcs.mei.co.jp Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" Message-ID: <2679395.1026529873@localhost> In-Reply-To: <5.1.0.14.2.20020713100917.083f42e0@jay.songbird.com> References: <5.1.0.14.2.20020713100917.083f42e0@jay.songbird.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit --On Saturday, 13 July, 2002 12:04 +0900 Dave Crocker wrote: >> - consideration of relay > > Facsimile is direct, point-to-point. The sending device and > the receiving device are connected to each other at the same > time. They talk with each other directly. > > Internet mail is store-and-forward. The sender and the > receiver are not required to be connected to the Internet at > the same time. The email may go through intermediate email > services, when moving from the sender to the receiver. (For > example, it may go from a department's SMTP mail system to the > enterprise system; the enterprise system may send it to the > receiving enterprise's system; the receiving system may then > send it to the receiver's department email server.) This is > like packet switching. Each intermediate system is "relaying" > the email. It is like packet switching except, of course, in the packet case, each packet is typically a fragment or component of a message. The message, or data stream, is sent one packet at a time; it is not completely assembled at each intermediate host and then forwarded after it is complete. With email, each relay host obtains, assembles, and stores the entire message, only then initiating a new transaction to forward it. That difference is significant for a few purposes, insignificant for most, but we should be careful to not push analogies to packet-switching too far. > The primary difference between relaying versus direct is that > relaying might take much longer. Therefore the sender does not > know when it will receive a response. I would disagree. The primary difference I see between relaying and direct is that, in a direct arrangement (characteristic of e.g., HTTP) the originating sending system can ask the ultimate receiving one a question by, well, asking. In the relay case, such questions can only be asked of an intermediate system, which must respond based on indirect information (which it finds in a database, see below) or by acting as proxy for a remote system, using information it has not obtained yet. Some illustrations: Q: Can mail be delivered to this address? Direct answer: "yes" or "no" Relay answer: "I have no idea, but I will accept responsibility for the mail and promise to forward it to someone else who will accept responsibility. For each of us, we understand that "accepting responsibility" means that we will either deliver the mail to the final recipient, deliver it to someone else who agrees to accept responsibility, or return an error message which will, of necessity, come out-of-band relative to the original connection". Note: contrast this with TCP, where the packet-switching model and the nature of the protocol permits getting the possibly-analogous "yes, the destination host will accept traffic on that port" answer back before any data packets are sent. Q: Does the recipient support this data format? Direct answer: "Yes" or "How about one of the following?" Relay answer 1: "The database says you should try..." (see below) Relay answer 2: "I don't have a clue, but I will accept the message on the assumption that it does, and pass it on, either to that destination or to some other site willing to take responsibility. If it turns out the recipient cannot accept the format, I (or one of the systems to which responsibility has been passed) will (preferentially) convert the format to something that can be accepted or (less preferred) bounce it with an out-of-band message." Those seem fairly different to me, much more different than "slower". In fact, I think that difference is part of what this discussion is about: if the only difference were "might take longer", I don't think we would be having this (part of) the discussion at all. john A footnote on the "find out from a database" issue. The more I think about it, the more I conclude that the database lookup (LDAP or otherwise) is the only rational way of implementing the desired functionality here in a case that might involve relaying. To the extent that speedy and confirmed delivery are often cited as important values in fax, the "maybe it will get delivered as requested, maybe it will be downgraded, maybe the format will be influenced by the format requirements of other recipients, and maybe the message will be bounced in a form that is hard or impossible for the originating (or early relay) MTA to detect" alternatives are unreasonable. But, if database lookup is the only plausible implementation that is consistent with the underlying design requirements, then we should not be looking at capabilities negotiation in the SMTP stream. Instead, we should be looking at a piece of protocol by which the sending system (probably the MUA, rather than the MTA) can figure out the capabilities of the recipient(s) and then prepare the message, make address grouping decisions, etc., cleanly. It seems to me that would be more clear, would put the responsibility back on the MUA or local system which has maximum information about sender intent, would avoid layering violations and other complications, and generally be a cleaner and more efficient model. From owner-ietf-fax@mail.imc.org Sat Jul 13 04:25:08 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 EAA16841 for ; Sat, 13 Jul 2002 04:25:07 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6D88Om14381 for ietf-fax-bks; Sat, 13 Jul 2002 01:08:24 -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 g6D88Nw14372 for ; Sat, 13 Jul 2002 01:08:23 -0700 (PDT) Received: from BBFUJIP.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 BAA27499; Sat, 13 Jul 2002 01:14:42 -0700 Message-Id: <5.1.0.14.2.20020713164134.08305958@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 13 Jul 2002 16:55:41 +0900 To: Graham Klyne From: Dave Crocker Subject: Re: [VPIM] Re: IETF-FAX WG Draft agenda at Yokohama Cc: Hiroshi Tamura , ietf-fax@imc.org, vpim@lists.neystadt.org, um@snowshore.com In-Reply-To: <5.1.0.14.2.20020709201837.00a3b110@joy.songbird.com> References: <5.1.1.2.2.20020707214920.01a57880@jay.songbird.com> <20020708133241V.tamura@toda.ricoh.co.jp> <20020702192404Q.tamura@toda.ricoh.co.jp> <20020702192404Q.tamura@toda.ricoh.co.jp> 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: Graham, At 08:23 PM 7/9/2002 +0100, Graham Klyne wrote: >If you were to do this, I think you'd also need to state, reasonably >tightly, the conditions under which the esmtp negotiation would be used >rather than the UA-based negotiation. ... >>>At 09:53 PM 7/7/02 -0700, Dave Crocker wrote: >>Toyoda-san and I suggest that the requirement for conforming to >>fax-oriented use of esmtp-conneg, such as with citations to: >>... >>be added to FFPIM. I agree with your concerns. So let me wander through some initial thoughts on the matter: 1. I consider FFPIM to be our final effort at achieving a "complete" emulation of facsimile through an email profile. Therefore I suggest that we try to incorporate as much as we can, although I acknowledge the inherent project management danger in ever making such an open-ended statement. 2. Both the UA and the SMTP mechanisms use the same CONNEG information structure. So the difference, here, is about the mechanism for exchanging things. (I am being simplistic, but I think it reasonable for this level of discussion.) 3. Given that we are standardizing two ways of achieving the same content tailoring -- or rather, two ways of carrying the same content tailoring guidance -- I believe it can only be a Good Thing to try to guide and resolve the choice within a single document. In fact, we might even get some integration. So the first thing we need to do is to specify the fax-specific content details. This is the detail in the two RFCs. It should be the same capabilities information for both mechanisms. My immediate thought is to couple together the use of the two mechanisms. Try to use the SMTP mechanism and fall-back to the UA mechanism, because the SMTP mechanism is likely to work more quickly. (These are all MAY, rather than SHOULD or MUST specifications. The goal is to specify a means of integrating them, rather than to mandate the One True Way.) So, we list each mechanism. Then we list a way to use them in a complementary fashion. (And we might even make a non-normative comment about other possible means, such as a hypothetical LDAP-based query.) Perhaps we need to make a statement about precedence for using information obtained through different means. Come to think of it, we probably need to do that anyhow. OK. That's enough theorizing, for starters. Reactions? d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Sat Jul 13 04:25:17 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 EAA16863 for ; Sat, 13 Jul 2002 04:25:17 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6D88VM14421 for ietf-fax-bks; Sat, 13 Jul 2002 01:08:31 -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 g6D88Uw14414 for ; Sat, 13 Jul 2002 01:08:30 -0700 (PDT) Received: from BBFUJIP.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 BAA27506; Sat, 13 Jul 2002 01:15:13 -0700 Message-Id: <5.1.0.14.2.20020713165715.083c3ea0@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 13 Jul 2002 16:57:35 +0900 To: Keith Moore From: Dave Crocker Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard Cc: Graham Klyne , Keith Moore , ietf-fax@imc.org In-Reply-To: <200207130348.g6D3mct17674@astro.cs.utk.edu> References: <(Your message of "Tue, 09 Jul 2002 19:49:47 BST.") <5.1.0.14.2.20020709194434.00a21ac0@joy.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: At 11:48 PM 7/12/2002 -0400, Keith Moore wrote: >okay, but I don't think that's clear from reading the document. Keith, if you have wording changes to suggest, please feel free to offer them. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Sat Jul 13 07:23:05 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 HAA20877 for ; Sat, 13 Jul 2002 07:23:05 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6DB15K01557 for ietf-fax-bks; Sat, 13 Jul 2002 04:01:05 -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 g6DAxXw01278; Sat, 13 Jul 2002 03:59:33 -0700 (PDT) Received: from BBFUJIP.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 EAA30001; Sat, 13 Jul 2002 04:06:09 -0700 Message-Id: <5.1.0.14.2.20020713171652.08336708@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 13 Jul 2002 17:43:03 +0900 To: John C Klensin From: Dave Crocker Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" Cc: iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org In-Reply-To: <2679395.1026529873@localhost> References: <5.1.0.14.2.20020713100917.083f42e0@jay.songbird.com> <5.1.0.14.2.20020713100917.083f42e0@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: At 03:11 AM 7/13/2002 -0400, John C Klensin wrote: >--On Saturday, 13 July, 2002 12:04 +0900 Dave Crocker > > Internet mail is store-and-forward. ... This is like packet > switching. Each intermediate system is "relaying" the email. > >It is like packet switching except, of course, in the packet case, each >packet is typically a fragment or component of a message. "Typically", perhaps, but it is not true for all packet switching systems and it is not part of the formal definition of packet-switching. Packet switching is about independent addressing (and usually independent routing) and handling of discrete chunks of data. It is not about the relationships among that data. To that extent, Internet mail is quite similar to lower-level packet switching. (I say it is exactly the same, but therein lies a debate that some of us have enjoyed for a few years -- errr, decades -- and it is not pertinent to the specification under review.) > The message, or data stream, is sent one packet at a time; it is not > completely assembled at each intermediate host and then forwarded after > it is complete. On the contrary, Arpanet IMP packet switching did fragmentation and reassembly in the net, not in the hosts. (Any further debate on this issue might be interesting, but it, too, is not relevant to the current topic.) > > The primary difference between relaying versus direct is that > > relaying might take much longer. Therefore the sender does not > > know when it will receive a response. > >I would disagree. The primary difference I see between relaying >and direct is that, in a direct arrangement (characteristic of >e.g., HTTP) the originating sending system can ask the ultimate >receiving one a question by, well, asking. The UA-based CONNEG mechanism does query/response between two UAs that are connected only by the store-and-forward email service. There is nothing that dictates that application-level query/response exchanges be conducted over connection-oriented, direct or real-time associations. Just to underscore how fuzzy all this gets: HTTP relies on the underlying store and forward of IP. Email UAs rely on the underlying store and forward of SMTP. And, of course, SMTP also relies on the store and forward of IP. More importantly, these concerns are essential matters for successful implementation, deployment and use. But they have nothing to do with core architectural principals. With respect to direct vs. relay, the architectural difference between a UA-UA exchange and an HTTP exchange is remarkably small, especially given that HTTP usage pretends it has no context. These differences get even smaller with the introduction of caching servers, and the like, because they introduce a very high degree of indirection between consumer and provider. >A footnote on the "find out from a database" issue. The more I >think about it, the more I conclude that the database lookup >(LDAP or otherwise) is the only rational way of implementing the >desired functionality here in a case that might involve relaying. Yes, it is an appealing model, except that LDAP has yet to achieve Internet-scale deployment and use. Consequently it is not wise to make a new service dependent on it. It is also worth noting that such a model requires real-time connectivity. An email-based mechanism can operate with asynchronous access. It makes far more sense to postulate a range of choices -- including directly asking the own of the information via a UA mechanism, as well as direct intermediaries via ESMTP/CONNEG -- and incorporate LDAP when it starts being a serious global service. >To the extent that speedy and confirmed delivery are often cited >as important values in fax, the "maybe it will get delivered as >requested, ... is hard or >impossible for the originating (or early relay) MTA to detect" >alternatives are unreasonable. To the extent that a higher degrees of certainty is required, then the operational components should be configured to provide it. Using LDAP does not provide any guarantees of proper or speedy performance, any more than using UA- or SMTP-based content negotiations guarantees the lack. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Sat Jul 13 09:09: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 JAA22999 for ; Sat, 13 Jul 2002 09:09:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6DCi0R06959 for ietf-fax-bks; Sat, 13 Jul 2002 05:44:00 -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 g6DChww06952 for ; Sat, 13 Jul 2002 05:43: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 g6DChtt07793; Sat, 13 Jul 2002 08:43:55 -0400 (EDT) Message-Id: <200207131243.g6DChtt07793@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: Keith Moore , Graham Klyne , ietf-fax@imc.org Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard In-reply-to: (Your message of "Sat, 13 Jul 2002 16:57:35 +0900.") <5.1.0.14.2.20020713165715.083c3ea0@jay.songbird.com> Date: Sat, 13 Jul 2002 08:43:55 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Keith, if you have wording changes to suggest, please feel free to offer them. Dave, This document cannot be fixed by a few simple wording changes, and your continued insistence that I only provide input in the form that you prefer (and that makes the document look better than it is) is, well, ridiculous. I've said on multiple occasions that the simplest fix is to stop claiming that the document is a general-purpose content negotiation mechanism for SMTP, and to rename the keywords etc. appropriately to reflect that. This wouldn't fix all of the problems with the document, but it's the single change that would have the greatest positive effect. Naturally a general-purpose content-negotiation mechanism would be much better. But we should be honest with ourselves that the current SMTP infrastructure doesn't lend itself to that. Keith From owner-ietf-fax@mail.imc.org Sat Jul 13 10:17:01 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 KAA24316 for ; Sat, 13 Jul 2002 10:17:00 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6DDpn411036 for ietf-fax-bks; Sat, 13 Jul 2002 06:51:49 -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 g6DDpDw11014; Sat, 13 Jul 2002 06:51:13 -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 g6DDp3t16723; Sat, 13 Jul 2002 09:51:03 -0400 (EDT) Message-Id: <200207131351.g6DDp3t16723@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: Hiroshi Tamura , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org, ktoyoda@rdmg.mgcs.mei.co.jp Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" In-reply-to: (Your message of "Sat, 13 Jul 2002 12:04:48 +0900.") <5.1.0.14.2.20020713100917.083f42e0@jay.songbird.com> Date: Sat, 13 Jul 2002 09:51:03 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > >- new command RCAP?? > > The current ESMTP/CONNEG specification uses the RCPT command for finding > each recipient's capabilities. > > Moore-san prefers to have the capabilities query be in a separate > command. For convenience, he has given this command a name, RCAP. So, the > name refers to an idea that Moore-san has. There is no written > specification for that command. In my opinion, the current specification > is satisfactory. this is a little misleading. if a message is being sent to more than one recipient then there is a possibility that different recipients will need different versions of the content, or that some recipients will be unable to accept the content at all. if the message being transmitted is a fax and all recipients are capable of fax, then perhaps it is acceptable to downgrade the message to a lower quality fax format which is acceptable to all. however this is not always possible for recipients in general - a SMTP server is allowed to support CONNEG if some, none, or all of its recipients support fax reception. the use of the RCPT response to tell the client of the recipient's capabilities is odd because it asserts that the client intends to deliver a message to each of several recipients before the client actually knows whether it can deliver the same version of the message to each recipient, or whether it can deliver any version of that message to the recipient. so as the proposal is written, any client which attempts to deliver a message to multiple recipients in a single transaction must be prepared to abort the current SMTP transaction (presumably by using RSET) after sending multiple RCPTs, to divide up the RCPTs according to which version of the message each is capable of receiving, and to start some number of new transactions for that purpose. if nothing else, that seems a bit confusing and it introduces the potential for implementation errors. it's been claimed that using RCPT in this way is faster that using a separate command, though I haven't actually seen an analysis of this. I wonder if such analysis is based on an assumption that it will usually be possible to downgrade the message to a common format that is acceptable to all recipients, and I wonder if that will actually be true in practice. but even if performance considerations justify using RCPT instead of a separate command, it would still be appropriate to document the need for clients to abort the current transaction if not all recipients can accept the same format. the current proposal fails to mention this at all. this would be easy to fix. another problem with RCPT is that it expects the server to return status codes for error conditions that can only be distinguished on the client. RCAP is just one of several ideas that have been suggested to do content negotiation in a way that is simpler, more robust, and less confusing to implementors than the current proposal. Dave is correct that there is no formal proposal for RCAP - though since the entire reason for proposing RCAP is to have something simpler, a detailed proposal hardly seems necessary to describe it. Anyone with a good understanding of SMTP should be able to evaluate the relative merits of the current proposal, RCAP, and the other suggestions without having a detailed proposal for each one. The following description for RCAP should be enough: 1. the command looks like this: RCAP 2. the server responds with one of the following 2xx-recipient capabilities are as follows: 2xx- 2xx 2yy recipient has no specified capabilities 2zz no information available about recipient capabilities 4xx recipient capabilities are temporarily unavailable 5xx error (for example, syntax error) specific values for 2xx, 2yy, 2zz, 4xx, 5xx are to be determined. 3. if the server supports the ENHANCEDSTATUS codes extension then the most appropriate enhanced status code should follow the 2xx, 2yy, 2zz, 4xx, or 5xx response code in the manner specified in RFC 2034. 4. the RCAP command is acceptable at any time that MAIL or RCPT would be acceptable. clients MAY issue RCAP before or after MAIL, and they MAY issue RCAP and RCPT commands in any order. (though generally it makes more sense to issue RCAP for a recipient before sending RCPT for that recipient) The RCAP response MUST be the same regardless of whether the command is issued before or after MAIL, or before or after RCPT. 5. the RCAP command has no effect other than to query the server about a recipient's capabilities. 6. the RCAP command does not indicate whether a recipient address is valid or whether delivery of a message to the recipient will succeed. any response - 2xx, 2yy, 2zz, 4xx, 5xx - is potentially valid even for a nonexistent recipient or one which is not allowed to receive mail. for example, an SMTP server for a webmail environment which provided the same capabilities for all recipients could return 2xx and the same conneg string for any recipient address, regardless of whether that recipient were valid. Keith From owner-ietf-fax@mail.imc.org Sat Jul 13 10:36:12 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 KAA24859 for ; Sat, 13 Jul 2002 10:36:12 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6DECck11606 for ietf-fax-bks; Sat, 13 Jul 2002 07:12:38 -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 g6DECPw11590; Sat, 13 Jul 2002 07:12:25 -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 g6DECLt19474; Sat, 13 Jul 2002 10:12:21 -0400 (EDT) Message-Id: <200207131412.g6DECLt19474@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: John C Klensin cc: Dave Crocker , Hiroshi Tamura , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org, ktoyoda@rdmg.mgcs.mei.co.jp Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" In-reply-to: (Your message of "Sat, 13 Jul 2002 03:11:13 EDT.") <2679395.1026529873@localhost> Date: Sat, 13 Jul 2002 10:12:21 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > A footnote on the "find out from a database" issue. The more I > think about it, the more I conclude that the database lookup > (LDAP or otherwise) is the only rational way of implementing the > desired functionality here in a case that might involve relaying. I'm reaching the same conclusion. > But, if database lookup is the only plausible implementation that > is consistent with the underlying design requirements, then we > should not be looking at capabilities negotiation in the SMTP > stream. Instead, we should be looking at a piece of protocol by > which the sending system (probably the MUA, rather than the MTA) > can figure out the capabilities of the recipient(s) and then > prepare the message, make address grouping decisions, etc., > cleanly. It seems to me that would be more clear, would put the > responsibility back on the MUA or local system which has maximum > information about sender intent, would avoid layering violations > and other complications, and generally be a cleaner and more > efficient model. I generally agree, or at least I think it's worth considering this alternative. Which makes more sense: - explicitly configuring every general-purpose SMTP server that acts as a mail exchanger (and that supports conneg) to talk to a database for each of the recipient domains that it serves? or - defining a standard recipient capability query mechanism (say, something like rescap) and having a standard way to advertise via DNS which servers to use to find capabilities for recipients at a particular mail domain (say, something like SRV records) Problem is, you get different answers depending on whether: - you build appliances that receive fax over the internet (in which case it's simpler to just implement one server process and you'd rather avoid imposing the burden of extra DNS setup on your customers), or - you build or operate general-purpose SMTP servers (in which case you might rather avoid having to explicitly configure those servers, and also avoid having your SMTP servers wait on more database queries) The two approaches are not mutually exclusive, but if we wanted to support both query methods then it would be good idea to understand how they interact sooner rather than later. Keith From owner-ietf-fax@mail.imc.org Sat Jul 13 10:42:37 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 KAA25008 for ; Sat, 13 Jul 2002 10:42:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6DEGJh11737 for ietf-fax-bks; Sat, 13 Jul 2002 07:16:19 -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 g6DEGHw11725; Sat, 13 Jul 2002 07:16:17 -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 g6DEGFt19998; Sat, 13 Jul 2002 10:16:15 -0400 (EDT) Message-Id: <200207131416.g6DEGFt19998@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: John C Klensin , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" In-reply-to: (Your message of "Sat, 13 Jul 2002 17:43:03 +0900.") <5.1.0.14.2.20020713171652.08336708@jay.songbird.com> Date: Sat, 13 Jul 2002 10:16:15 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > The UA-based CONNEG mechanism does query/response between two UAs that are > connected only by the store-and-forward email service. There is nothing > that dictates that application-level query/response exchanges be conducted > over connection-oriented, direct or real-time associations. perhaps not, but once a message is relayed, the conversion (and the decision of whether to deliver the message) is no longer under control of the sender - actually the most likely scenario when using the conneg proposal with the current infrastructure is that the message will be delivered, without conversion, regardless of recipient capabilities. I thought that this is what the fax people wanted to avoid? From owner-ietf-fax@mail.imc.org Sat Jul 13 12:41: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 MAA27375 for ; Sat, 13 Jul 2002 12:41:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6DGOgq20532 for ietf-fax-bks; Sat, 13 Jul 2002 09:24:42 -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 g6DGOfw20525 for ; Sat, 13 Jul 2002 09:24:41 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KK1EZ83F2O000O32@mauve.mrochek.com> for ietf-fax@imc.org; Sat, 13 Jul 2002 09:24:41 -0700 (PDT) Date: Sat, 13 Jul 2002 08:55:41 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" In-reply-to: "Your message dated Sat, 13 Jul 2002 03:11:13 -0400" <2679395.1026529873@localhost> To: John C Klensin Cc: Dave Crocker , Hiroshi Tamura , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org, ktoyoda@rdmg.mgcs.mei.co.jp Message-id: <01KK1HVAM6PU000O32@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <5.1.0.14.2.20020713100917.083f42e0@jay.songbird.com> <2679395.1026529873@localhost> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > A footnote on the "find out from a database" issue. The more I > think about it, the more I conclude that the database lookup > (LDAP or otherwise) is the only rational way of implementing the > desired functionality here in a case that might involve relaying. > To the extent that speedy and confirmed delivery are often cited > as important values in fax, the "maybe it will get delivered as > requested, maybe it will be downgraded, maybe the format will be > influenced by the format requirements of other recipients, and > maybe the message will be bounced in a form that is hard or > impossible for the originating (or early relay) MTA to detect" > alternatives are unreasonable. > But, if database lookup is the only plausible implementation that > is consistent with the underlying design requirements, then we > should not be looking at capabilities negotiation in the SMTP > stream. Instead, we should be looking at a piece of protocol by > which the sending system (probably the MUA, rather than the MTA) > can figure out the capabilities of the recipient(s) and then > prepare the message, make address grouping decisions, etc., > cleanly. It seems to me that would be more clear, would put the > responsibility back on the MUA or local system which has maximum > information about sender intent, would avoid layering violations > and other complications, and generally be a cleaner and more > efficient model. I think this is a fine piece of theoretical analysis which unfortunately has no applicability to the real world. In the real world directory/database systems that let sites provide Internet-wide access to information about their users do not deploy. I'm not sure why this is the case, and indeed I'm fairly sure that there is no good reason for it, but a vast tract of experience tells me it for-sure is the case. (Now is not the time to get into whys in more detail.) The IETF has tried to tackle this problem several times, and indeed continues to do so now in the RESCAP WG. But I don't think anyone seriously believes that even if RESCAP produces some specifications it is going to succeed at its intended scale. Frankly, the silence is pretty deafening over there. Lacking direct capabilities to find capabilties information necessarily leads to various piggybacking options, that is, deploy this facility on top of or inside other protocols. This has some of the same characteristics as the everything-over-HTTP approach, but with several important differences: There is a close relationship between the piggybacked data and the intended purpose of the underlying protocols (a relationship that is often lacking with stuff travelling over HTTP) and the operational case for doing this is far more compelling (getting the OK to drill a hole in a firewall for a new protocol is triviality itself compared to the difficulty in setting up even restricted access to directory information). I think the availabilty of capabilities information has the potential to be as important a step as MIME was. As such, I don't begrudge healthy debate about how and where it is done. But let's not forget that the development of MIME was informed by the catastrophic failure of various other schemes for doing multimedia messaging -- some of them more elegant than MIME -- leading to compromises in the design intended to insure deployability. I think the discussion of where and how to do content negotiation needs to be similarly informed by the catastrophic failure of Internet-wide directory services to deploy. Ned From owner-ietf-fax@mail.imc.org Sat Jul 13 14:45:27 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 OAA00164 for ; Sat, 13 Jul 2002 14:45:27 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6DIInr26716 for ietf-fax-bks; Sat, 13 Jul 2002 11:18:49 -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 g6DII5w26690; Sat, 13 Jul 2002 11:18:05 -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 g6DIHwt18033; Sat, 13 Jul 2002 14:17:58 -0400 (EDT) Message-Id: <200207131817.g6DIHwt18033@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: ned+ietf-smtp@mrochek.com cc: John C Klensin , Dave Crocker , Hiroshi Tamura , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org, ktoyoda@rdmg.mgcs.mei.co.jp Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" In-reply-to: (Your message of "Sat, 13 Jul 2002 08:55:41 PDT.") <01KK1HVAM6PU000O32@mauve.mrochek.com> Date: Sat, 13 Jul 2002 14:17:58 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I think this is a fine piece of theoretical analysis which unfortunately has no > applicability to the real world. In the real world directory/database systems > that let sites provide Internet-wide access to information about their users do > not deploy. Widespread deployment of LDAP as a public directory service was hampered by several factors - despite the designers' intention that it be used for publically accessible information it was widely hyped as a generic database access protocol, so an organizations' LDAP servers were typically filled with information that they wouldn't dream of making publically available. Also, there wasn't an obvious global namespace or infrastructure that was easy for LDAP users to tie into, nor any widespread understanding of why it would be a good idea to do so. None of this experience seems particularly applicable to the question at hand, where we are comparing two different mechanisms for exporting only a small amount of information - SMTP, or some other protocol (of which LDAP is only a token example). If an enterprise is reluctant to export "information about their users" in general, then they will be about as reluctant to do so via SMTP as via some other protocol. I do think it's reasonable to assume that any other protocol server is likely to be viewed as a separate maintenance burden that needs to be justified, whereas a wart on the side of SMTP will probably be viewed as just some incremental pain that must be endured. But if large sites end up needing a separate database server anyway to support CONNEG because the MX servers don't have direct knowledge of recipient capabilities, then that separate maintenance burden is there anyway, at least for those sites. I also believe that trying to use LDAP for this purpose would be a marketing disaster - because there is already such a mindset about what LDAP is used for, and what kind of data goes into it, that any proposal to expose this specific piece of information using the LDAP protocol will immediately get attacked by people who are concerned that other informaion often stored in LDAP will be inappropriately leaked. > The IETF has tried to tackle this problem several times, and indeed continues > to do so now in the RESCAP WG. But I don't think anyone seriously believes that > even if RESCAP produces some specifications it is going to succeed at its > intended scale. Frankly, the silence is pretty deafening over there. I suspect the lack of significant interest in rescap is because it lacks a killer app - there are many uses for rescap but no one application for it sees a significant enough win to drive the people who work on that application to contribute to rescap. That and each of those uses involves some deployment pain - and the first one involves significant pain, so nobody wants to be first. Another way of saying this is that (at least in the apps area) we tend to divide our work around product lines - we tend to work on email, fax, voice mail, web replication, instant messaging and so on - and rescap cuts across all of these. (on the other hand, any technology that is initially driven by a narrow set of interests tends to get warped to serve that set of interests at the expense of others, even if the technology was generally useful.) I'm not sure whether this is good or bad, nor whether it is inherent or an artifact of our organizational structure. Mostly I view this as a given. There are exceptions, but they're rare, at least in the apps area. But there's nothing stopping fax people, or email people, or voice mail people from considering a standard protocol for the lookup of recipient capability information and (separately) from considering whether that protocol should be accessed directly or through SMTP. And while I suspect, intuitively, that accessing that information via SMTP is actually a better way to go overall, I'd like to see some more analysis on it rather than a quick dismissal based on experience with LDAP. for instance: One attractive thing about using SMTP is that SMTP servers for small sites can implement CONNEG without a separate server, so the cost is kept low for small sites. Another one is that if there is a separate server then it's probably easier for the mail system administrator to configure his/her MTAs to talk to that server (and to fix bugs in that configuration) than for the mail system administrator to configure DNS so that external queries go to that server. If queries are made via SMTP then the interface to the database is not standardized, so MTA vendors end up supporting multiple interfaces. Some might see this as an advantage, since it allows use of a variety of existing back-ends. Actually enough MTAs support mail forwarding via LDAP (or other database) that getting recipient capabilities from the same source is probably a straightforward extension. And assuming that the SMTP client-SMTP server connection has a significantly longer delay path than the SMTP server-database connection (which seems reasonable) then it could take less time overall to deliver the message via SMTP alone than via SMTP + a database query, provided the queries can be made in the same SMTP session as when the message is delivered. I think there are benefits that favor of a rescap-like approach also. One is that it allows the conversion to be done by the sender's MUA - or at any rate as early as possible - whereas with SMTP this is not always possible because a number of sites either block access to port 25 on nonlocal servers, or impose interception proxies that pretend to be the remote server even if it's really a relay or firewall. I'm very much in favor of having negotiation and transformation work predictably and with accountability to the sender rather than having some random MTA in the chain decide that a conversion is needed. Another is that the mechanism could be used for other things besides just recipient capabilities - say to distribute a recipient's public key, to opt out of spam, etc. These could also be provided via SMTP but some of them absolutely require access by the sender's UA to be useful. Keith From owner-ietf-fax@mail.imc.org Sat Jul 13 15:56:50 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 PAA01692 for ; Sat, 13 Jul 2002 15:56:49 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6DJWDG01752 for ietf-fax-bks; Sat, 13 Jul 2002 12:32:13 -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 g6DJWAw01740 for ; Sat, 13 Jul 2002 12:32:10 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KK1EZ83F2O000O32@mauve.mrochek.com> for ietf-fax@imc.org; Sat, 13 Jul 2002 12:32:10 -0700 (PDT) Date: Sat, 13 Jul 2002 12:08:07 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" In-reply-to: "Your message dated Sat, 13 Jul 2002 14:17:58 -0400" <200207131817.g6DIHwt18033@astro.cs.utk.edu> To: Keith Moore Cc: ned+ietf-smtp@mrochek.com, John C Klensin , Dave Crocker , Hiroshi Tamura , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org, ktoyoda@rdmg.mgcs.mei.co.jp Message-id: <01KK1OFPP92C000O32@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <01KK1HVAM6PU000O32@mauve.mrochek.com> <200207131817.g6DIHwt18033@astro.cs.utk.edu> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > > I think this is a fine piece of theoretical analysis which unfortunately has no > > applicability to the real world. In the real world directory/database systems > > that let sites provide Internet-wide access to information about their users do > > not deploy. > Widespread deployment of LDAP as a public directory service was hampered > by several factors - despite the designers' intention that it be used > for publically accessible information it was widely hyped as a generic > database access protocol, so an organizations' LDAP servers were > typically filled with information that they wouldn't dream of making publically > available. Also, there wasn't an obvious global namespace or infrastructure > that was easy for LDAP users to tie into, nor any widespread understanding of > why it would be a good idea to do so. LDAP is but one example, and in some ways not a good one. There are plenty of others. > None of this experience seems particularly applicable to the question at hand, > where we are comparing two different mechanisms for exporting only a small > amount of information - SMTP, or some other protocol (of which LDAP is only a > token example). If an enterprise is reluctant to export "information about > their users" in general, then they will be about as reluctant to do so via SMTP > as via some other protocol. I'm afraid this is another piece of theoretical considerations that fly in the face of actual experience. The obvious counterexample is HTTP. > I do think it's reasonable to assume that any other protocol server is likely > to be viewed as a separate maintenance burden that needs to be justified, whereas > a wart on the side of SMTP will probably be viewed as just some incremental pain > that must be endured. But if large sites end up needing a separate database server > anyway to support CONNEG because the MX servers don't have direct knowledge of > recipient capabilities, then that separate maintenance burden is there anyway, > at least for those sites. While I obviously cannot speak for all large sites, I can tell you that database usage is sufficiently pervasive inside the sites I'm familiar with that this is basically a nonissue. > I also believe that trying to use LDAP for this purpose would be a marketing > disaster - because there is already such a mindset about what LDAP is used for, > and what kind of data goes into it, that any proposal to expose this specific > piece of information using the LDAP protocol will immediately get attacked > by people who are concerned that other informaion often stored in LDAP will be > inappropriately leaked. Nowhere did I mention using LDAP to expose this information. So this appears to be a complete strawman argument to me. > > The IETF has tried to tackle this problem several times, and indeed continues > > to do so now in the RESCAP WG. But I don't think anyone seriously believes that > > even if RESCAP produces some specifications it is going to succeed at its > > intended scale. Frankly, the silence is pretty deafening over there. > I suspect the lack of significant interest in rescap is because it lacks a > killer app - there are many uses for rescap but no one application for > it sees a significant enough win to drive the people who work on that > application to contribute to rescap. That and each of those uses involves > some deployment pain - and the first one involves significant pain, so nobody > wants to be first. Another way of saying this is that (at least in the apps > area) we tend to divide our work around product lines - we tend to work on > email, fax, voice mail, web replication, instant messaging and so on - and > rescap cuts across all of these. > (on the other hand, any technology that is initially driven by a narrow set > of interests tends to get warped to serve that set of interests at the > expense of others, even if the technology was generally useful.) > I'm not sure whether this is good or bad, nor whether it is inherent or an > artifact of our organizational structure. Mostly I view this as a given. > There are exceptions, but they're rare, at least in the apps area. > But there's nothing stopping fax people, or email people, or voice mail > people from considering a standard protocol for the lookup of recipient > capability information and (separately) from considering whether that > protocol should be accessed directly or through SMTP. And while I suspect, > intuitively, that accessing that information via SMTP is actually a > better way to go overall, I'd like to see some more analysis on it rather > than a quick dismissal based on experience with LDAP. First, this is not a quick dismissal, it is a conclusion based on decades of experience, experiencce in which LDAP only plays a small and relatively recent part. Second, I believe the notion of using a directory for this sort of thing has been discussed in the FAX WG on several occasions. And while it is axiomatic that nothing precludes the WG's having chosen to use a directory, nothing requires that a WG pursue it either. I take the rather stunning lack of interest in this overall approach as yet another sign that it is seen as nonviable. > for instance: > One attractive thing about using SMTP is that SMTP servers for small > sites can implement CONNEG without a separate server, so the cost is > kept low for small sites. Another one is that if there is a separate > server then it's probably easier for the mail system administrator to > configure his/her MTAs to talk to that server (and to fix bugs in > that configuration) than for the mail system administrator to configure > DNS so that external queries go to that server. > If queries are made via SMTP then the interface to the database is not > standardized, so MTA vendors end up supporting multiple interfaces. > Some might see this as an advantage, since it allows use of a variety > of existing back-ends. Actually enough MTAs support mail forwarding > via LDAP (or other database) that getting recipient capabilities from > the same source is probably a straightforward extension. There's no "probably" about it, although it is also true that more generic callouts aren't exactly rocket science to implement. > And assuming that the SMTP client-SMTP server connection has a > significantly longer delay path than the SMTP server-database connection > (which seems reasonable) then it could take less time overall to deliver > the message via SMTP alone than via SMTP + a database query, provided > the queries can be made in the same SMTP session as when the message > is delivered. > I think there are benefits that favor of a rescap-like approach also. > One is that it allows the conversion to be done by the sender's > MUA - or at any rate as early as possible - whereas with SMTP > this is not always possible because a number of sites either > block access to port 25 on nonlocal servers, or impose interception > proxies that pretend to be the remote server even if it's really a > relay or firewall. I'm very much in favor of having negotiation > and transformation work predictably and with accountability to the > sender rather than having some random MTA in the chain decide that > a conversion is needed. I agree that predictability is nice, but that's not something any approach can ever guarantee. Indeed, I can argue that a directory approach will lead to less predictability, not more, if for no other reason than directory access will tend to work locally but not remotely. SMTP access with appropriate caching, on the other hand, has the potential to work both locally and globally. Ned From owner-ietf-fax@mail.imc.org Sat Jul 13 16:18: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 QAA02153 for ; Sat, 13 Jul 2002 16:18:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6DJu7U04622 for ietf-fax-bks; Sat, 13 Jul 2002 12:56:07 -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 g6DJu2w04604; Sat, 13 Jul 2002 12:56:02 -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 g6DJtut18263; Sat, 13 Jul 2002 15:55:56 -0400 (EDT) Message-Id: <200207131955.g6DJtut18263@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: ned.freed@mrochek.com cc: Keith Moore , ned+ietf-smtp@mrochek.com, John C Klensin , Dave Crocker , Hiroshi Tamura , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org, ktoyoda@rdmg.mgcs.mei.co.jp Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" In-reply-to: (Your message of "Sat, 13 Jul 2002 12:08:07 PDT.") <01KK1OFPP92C000O32@mauve.mrochek.com> Date: Sat, 13 Jul 2002 15:55:56 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > None of this experience seems particularly applicable to the question at hand, > > where we are comparing two different mechanisms for exporting only a small > > amount of information - SMTP, or some other protocol (of which LDAP is only a > > token example). If an enterprise is reluctant to export "information about > > their users" in general, then they will be about as reluctant to do so via SMTP > > as via some other protocol. > > I'm afraid this is another piece of theoretical considerations that fly in the > face of actual experience. The obvious counterexample is HTTP. The relevance of HTTP is even less obvious to me because HTTP and directory services (LDAP or otherwise) tend to be used in very different ways. I don't see many sites exporting their company directories via either HTTP or LDAP. Nor do I see how any of this is relevant to the problem of exporting recpient capability information for content negotiation. > > I do think it's reasonable to assume that any other protocol server is likely > > to be viewed as a separate maintenance burden that needs to be justified, whereas > > a wart on the side of SMTP will probably be viewed as just some incremental pain > > that must be endured. But if large sites end up needing a separate database server > > anyway to support CONNEG because the MX servers don't have direct knowledge of > > recipient capabilities, then that separate maintenance burden is there anyway, > > at least for those sites. > > While I obviously cannot speak for all large sites, I can tell you that > database usage is sufficiently pervasive inside the sites I'm familiar with > that this is basically a nonissue. Well, I guess it hinges on what is meant by "large". Are there a significant number of sites "large" enough to not have their MX servers deliver directly to recipient mailboxes, but not "large" enough to be already using a database to store recipient information? I suspect the answer is yes because there are other reasons besides scale that a site would not have its MX servers deliver directly to recipient mailboxes. Inbound firewalls are fairly common, and some of them operate as relays. > First, this is not a quick dismissal, it is a conclusion based on decades of > experience, experiencce in which LDAP only plays a small and relatively recent > part. not to dismiss your experience at all - but your stated justification didn't seem (to me) to be particularly relevant. > Second, I believe the notion of using a directory for this sort of thing has > been discussed in the FAX WG on several occasions. And while it is axiomatic > that nothing precludes the WG's having chosen to use a directory, nothing > requires that a WG pursue it either. I take the rather stunning lack of > interest in this overall approach as yet another sign that it is seen as > nonviable. again, is this a fax-specific extension or is it supposed to be generally applicable? I'll readily admit that fax machines don't need a directory. but should the level of interest within the fax group be used as a measure of the merit of the idea for other uses of email? > > I think there are benefits that favor of a rescap-like approach also. > > > One is that it allows the conversion to be done by the sender's > > MUA - or at any rate as early as possible - whereas with SMTP > > this is not always possible because a number of sites either > > block access to port 25 on nonlocal servers, or impose interception > > proxies that pretend to be the remote server even if it's really a > > relay or firewall. I'm very much in favor of having negotiation > > and transformation work predictably and with accountability to the > > sender rather than having some random MTA in the chain decide that > > a conversion is needed. > > I agree that predictability is nice, but that's not something any approach can > ever guarantee. Indeed, I can argue that a directory approach will lead to less > predictability, not more, if for no other reason than directory access will > tend to work locally but not remotely. SMTP access with appropriate caching, on > the other hand, has the potential to work both locally and globally. The last two statements seem fairly odd. Maybe the problem is the use of the word "directory" which isn't my favorite word for this anyway. So let's not call this a directory - let's call it a capability discovery protocol. Now if the capability discovery protocol is defined in such a way that in order for your recipients to benefit from content negotiation you have to make it accessible (just like if you want to be able to accept mail then you have to make port 25 accessible) then it seems fairly likely that sites that want to enable content negotation for their recipients will do so. On the other hand, port 25 is one of the few ports that is commonly blocked/filtered for outgoing traffic - perhaps even more often (and with more drastic filtering) than port 80. So the argument that a facility that requires direct connection over port 25 (from the origin to the MX server, not necessarily to the final MTA) in order to work properly (i.e. in order to let the sender control the conversion) will function both locally and globally seems a bit dubious. Keith From owner-ietf-fax@mail.imc.org Sat Jul 13 16:32: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 QAA02524 for ; Sat, 13 Jul 2002 16:32:57 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6DKILE06014 for ietf-fax-bks; Sat, 13 Jul 2002 13:18:21 -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 g6DKIKw06010 for ; Sat, 13 Jul 2002 13:18:20 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KK1EZ83F2O000O32@mauve.mrochek.com> for ietf-fax@imc.org; Sat, 13 Jul 2002 13:18:19 -0700 (PDT) Date: Sat, 13 Jul 2002 13:04:52 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" In-reply-to: "Your message dated Sat, 13 Jul 2002 15:55:56 -0400" <200207131955.g6DJtut18263@astro.cs.utk.edu> To: Keith Moore Cc: ned.freed@mrochek.com, Keith Moore , ned+ietf-smtp@mrochek.com, John C Klensin , Dave Crocker , Hiroshi Tamura , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org, ktoyoda@rdmg.mgcs.mei.co.jp Message-id: <01KK1Q1Y0NYC000O32@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <01KK1OFPP92C000O32@mauve.mrochek.com> <200207131955.g6DJtut18263@astro.cs.utk.edu> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > > > None of this experience seems particularly applicable to the question at hand, > > > where we are comparing two different mechanisms for exporting only a small > > > amount of information - SMTP, or some other protocol (of which LDAP is only a > > > token example). If an enterprise is reluctant to export "information about > > > their users" in general, then they will be about as reluctant to do so via SMTP > > > as via some other protocol. > > > > I'm afraid this is another piece of theoretical considerations that fly in the > > face of actual experience. The obvious counterexample is HTTP. > The relevance of HTTP is even less obvious to me because HTTP and directory > services (LDAP or otherwise) tend to be used in very different ways. I don't > see many sites exporting their company directories via either HTTP or LDAP. Then you haven't looked very hard. The former is quite popular; the latter practically nonexistant. And the fact that the same information is exposed either way yet one approach is preferred is directly relevant to the matter at hand. > Nor do I see how any of this is relevant to the problem of exporting recpient > capability information for content negotiation. In a rational world it would not be relevant. We don't live in one of those. > > I agree that predictability is nice, but that's not something any approach can > > ever guarantee. Indeed, I can argue that a directory approach will lead to less > > predictability, not more, if for no other reason than directory access will > > tend to work locally but not remotely. SMTP access with appropriate caching, on > > the other hand, has the potential to work both locally and globally. > The last two statements seem fairly odd. Maybe the problem is the use of the > word "directory" which isn't my favorite word for this anyway. So let's not > call this a directory - let's call it a capability discovery protocol. Now if > the capability discovery protocol is defined in such a way that in order for > your recipients to benefit from content negotiation you have to make it accessible > (just like if you want to be able to accept mail then you have to make port 25 > accessible) then it seems fairly likely that sites that want to enable content > negotation for their recipients will do so. My point was they may make it available internally but not externally. And using anything that remotely smells like a directory protocols makes this outcome far more likely. > On the other hand, port 25 is one > of the few ports that is commonly blocked/filtered for outgoing traffic - > perhaps even more often (and with more drastic filtering) than port 80. Keith, my point was and is that the minute you start talking about using a directory protocol -- and I insist on using the term because it's the directory aspect that's important -- it makes the whole thing problematic in a way that piggybacking the information on top of other type of protocols does not. You can talk till you're blue in the face about how this is capabilities discovery, how that's intrinsicly different from a general directory protocol, and so on and so forth. It doesn't change the perception that a protocol intended solely for looking up stuff, no matter how innocuous that stuff is, no matter how divorced from the cporpoate directory or whatever it can be made, is somehow more problematic than piggybacking the exact same information on top of other protocols. > So the argument that a facility that requires direct connection over port 25 > (from the origin to the MX server, not necessarily to the final MTA) > in order to work properly (i.e. in order to let the sender control the > conversion) will function both locally and globally seems a bit dubious. I have pointed out previously that such direct connection isn't required by the present proposal. So this is nothing but another strawman. Ned From owner-ietf-fax@mail.imc.org Sat Jul 13 16:48:28 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 QAA02732 for ; Sat, 13 Jul 2002 16:48:27 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6DKXFC06519 for ietf-fax-bks; Sat, 13 Jul 2002 13:33:15 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6DKXDw06514; Sat, 13 Jul 2002 13:33:14 -0700 (PDT) Received: from ns.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 3.35 #1) id 17TTZj-000DJ1-00; Sat, 13 Jul 2002 20:33:08 +0000 Date: Sat, 13 Jul 2002 16:33:03 -0400 From: John C Klensin To: ned+ietf-smtp@mrochek.com cc: Dave Crocker , Hiroshi Tamura , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org, ktoyoda@rdmg.mgcs.mei.co.jp Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" Message-ID: <4839986.1026577983@localhost> In-Reply-To: <01KK1HVAM6PU000O32@mauve.mrochek.com> References: <01KK1HVAM6PU000O32@mauve.mrochek.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ned, Keith, and others, I'm going to try to respond to several messages in one, please bear with me. Also, please note that I've had more than my share of terrible ideas and it is quite possible that the notion of a MUA getting information out of a directory about recipient capabilities is another one. --On Saturday, 13 July, 2002 08:55 -0700 ned+ietf-smtp@mrochek.com wrote: >> A footnote on the "find out from a database" issue. The more I >> think about it, the more I conclude that the database lookup >> (LDAP or otherwise) is the only rational way of implementing >> the desired functionality here in a case that might involve >> relaying. To the extent that speedy and confirmed delivery are >>... >> But, if database lookup is the only plausible implementation >> that is consistent with the underlying design requirements, >> then we should not be looking at capabilities negotiation in >> the SMTP stream. Instead, we should be looking at a piece of >> protocol by which the sending system (probably the MUA, rather >>... > I think this is a fine piece of theoretical analysis which > unfortunately has no applicability to the real world. In the > real world directory/database systems that let sites provide > Internet-wide access to information about their users do not > deploy. Well, it depends on how important they are. And, while it may be tautological, the observation that these things have not deployed is an indication that they haven't been important enough, given deployment and maintenance costs and security risks. Of course, we do have one wildly-successful counterexample and, while I hate to even mention it as a possibility, if this capability is important enough, and it were the right answer (I have serious doubts about both), nothing prevents us from thinking about a mail-capabilities RR. It would be a bad idea if only because the capabilities are really an MUA issue and the DNS identifies MTAs (today), but... >... > The IETF has tried to tackle this problem several times, and > indeed continues to do so now in the RESCAP WG. But I don't > think anyone seriously believes that even if RESCAP produces > some specifications it is going to succeed at its intended > scale. Frankly, the silence is pretty deafening over there. I certainly agree. > Lacking direct capabilities to find capabilties information > necessarily leads to various piggybacking options, that is, > deploy this facility on top of or inside other protocols. This > has some of the same characteristics as the > everything-over-HTTP approach, but with several important > differences: There is a close relationship between the > piggybacked data and the intended purpose of the underlying > protocols (a relationship that is often lacking with stuff > travelling over HTTP) and the operational case for doing this > is far more compelling (getting the OK to drill a hole in a > firewall for a new protocol is triviality itself compared to > the difficulty in setting up even restricted access to > directory information). Yes, but as Keith points out (more politely), using the general organizational directory for this purpose would be madness. I hope you didn't assume I was proposing it. But the "piggyback everything, rather than think about new protocols" approach (which I don't think you believe in either, at least in the limiting case) leads to a different sort of madness, one which often manifests itself as "give up on all other application protocols and just use HTTP" (or, more recently, SIP). > I think the availabilty of capabilities information has the > potential to be as important a step as MIME was. As such, I > don't begrudge healthy debate about how and where it is done. > But let's not forget that the development of MIME was informed > by the catastrophic failure of various other schemes for doing > multimedia messaging -- some of them more elegant than MIME -- > leading to compromises in the design intended to insure > deployability. I think the discussion of where and how to do > content negotiation needs to be similarly informed by the > catastrophic failure of Internet-wide directory services to > deploy. That should clearly inform many of the things that we do, but we should learn the right lessons. Just as "firewalls get in the way of anything new, therefore we should run all new protocols and services over HTTP" is typically a wrong answer, developing a paranoid fear of directory-like services. Prior attempts have been over-ambitious for what they promised to deliver relative to what people needed. Or they have failed for other reasons. But it may be that the lesson is "more focused and less ambitious and general purpose approaches", rather than discarding the bathwater, the baby, and anything that vaguely resembles either because, e.g., it is wet. So, given that I'm already generating plausibly-bad ideas, think about a strawman. Suppose we said "if you want to use email capabilities, you need to be able to establish a connection to the final recipient" (whatever that means). This is, of course, a variation on the "no relay" scheme. But then suppose that, instead of piggybacking on top of SMTP, we required that the destination host have an A RR, or a very specific and slightly peculiar SRV RR, or something similar, such that the client MUA could open a connection to it, ask "what sort of fax capabilities are you willing to provide to a message coming from foo.bar.baz to username@your.domain", and get back a quick answer. At the price of a new RR type, it could even be done over UDP, on a "get an answer or give it up and send the minimum" basis. Or, at the price of committing an obscenity, it could be done pretty easily over HTTP or SIP. The UDP approach, and probably the other two, would almost certainly be faster than getting anywhere near an LDAP server. Those approaches are consistent with what I intended to imply by "...LDAP (or something else)". It would require some configuration, but so does piggypbacking on SMTP. Is it important enough to deploy? I don't know. But, if it isn't, is this capability really worth cluttering up SMTP? Remember that quote from RFC 1425 and its successors... your name is on that document too. You also wrote: > Second, I believe the notion of using a directory for this sort > of thing has been discussed in the FAX WG on several occasions. > And while it is axiomatic that nothing precludes the WG's > having chosen to use a directory, nothing requires that a WG > pursue it either. I take the rather stunning lack of interest > in this overall approach as yet another sign that it is seen as > nonviable. Since I have been paying only intermittent attention to the Fax WG, I missed those discussions. But most of the discussions (about other topics) I remember from that WG were focused, appropriately, on fax. One of the reasons we do IETF last calls, IMO, is to be sure that applicable considerations outside the scope of the WG are exposed and aired. So, unless you are convinced that the WG carefully and accurately balanced the general (1425/1869, etc) argument against SMTP extensions on behalf of the overall community, I'd be interested in their reasons for rejecting alternate approaches but might not find them compelling. To conclude, Keith wrote: > The two approaches are not mutually exclusive, but if we wanted > to support both query methods then it would be good idea to > understand how they interact sooner rather than later. And it is a good idea to weigh the strengths and weakness of each, in an overall Internet and email context, not just a fax one (unless this capability is to be narrowed to fax applications). That is why, regardless of the outcome of this discussion, I think it is a good use of time and appreciate your willingness to engage in it without dismissing the issues as spurious. john From owner-ietf-fax@mail.imc.org Sat Jul 13 16:58: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 QAA02880 for ; Sat, 13 Jul 2002 16:58:36 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g6DKgU706873 for ietf-fax-bks; Sat, 13 Jul 2002 13:42:30 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6DKgSw06869; Sat, 13 Jul 2002 13:42:28 -0700 (PDT) Received: from ns.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 3.35 #1) id 17TTii-000DKW-00; Sat, 13 Jul 2002 20:42:25 +0000 Date: Sat, 13 Jul 2002 16:42:21 -0400 From: John C Klensin To: Keith Moore , Dave Crocker cc: Hiroshi Tamura , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org, ktoyoda@rdmg.mgcs.mei.co.jp Subject: Re: RCAP mini-spec (was: Re: Keywords for "SMTP Service Extension for Content Negotiation" ) Message-ID: <5397851.1026578541@localhost> In-Reply-To: <200207131351.g6DDp3t16723@astro.cs.utk.edu> References: <200207131351.g6DDp3t16723@astro.cs.utk.edu> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit --On Saturday, 13 July, 2002 09:51 -0400 Keith Moore wrote: >... > 4. the RCAP command is acceptable at any time that MAIL or RCPT > would be acceptable. clients MAY issue RCAP before or after > MAIL, and they MAY issue RCAP and RCPT commands in any order. > (though generally it makes more sense to issue RCAP for a > recipient before sending RCPT for that recipient) > The RCAP response MUST be the same regardless of whether the > command is issued before or after MAIL, or before or after RCPT. Keith, I don't assume this would be heavily used, but, as with SIZE, I can imagine some sites being willing to accept more complex formats from some senders than from others. Of course, such mechanisms are easily thwarted in the absence of SMTP authentication or trusted transport (and would not be available with some of the other proposals). But, unless you have a substantive reason for permitting RCAP before MAIL, it would seem desirable to force it to come after MAIL, thereby preserving this implementation option at substantially no cost. john From owner-ietf-fax@mail.imc.org Sat Jul 13 17:28:03 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 RAA03481 for ; Sat, 13 Jul 2002 17:28:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6DLBJw08066 for ietf-fax-bks; Sat, 13 Jul 2002 14:11:19 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6DLBGw08058; Sat, 13 Jul 2002 14:11:16 -0700 (PDT) Received: from ns.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 3.35 #1) id 17TUAe-000DPI-00; Sat, 13 Jul 2002 21:11:17 +0000 Date: Sat, 13 Jul 2002 17:11:13 -0400 From: John C Klensin To: Dave Crocker , John C Klensin cc: iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" Message-ID: <7130026.1026580273@localhost> In-Reply-To: <5.1.0.14.2.20020713171652.08336708@jay.songbird.com> References: <5.1.0.14.2.20020713171652.08336708@jay.songbird.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dave, You are, I think, equating packet fragmentation and reassembly to email messages. IMO, that is bogus (and, as you point out, this argument is decades old and I believe it has been bogus for at least that long), unless you constrain those packets to reliable delivery and permit them to be very large. I.e., the only reasonable comparison is to a collection of packets in a a connection-mode (or other serialized and reliable) context. It was in that context that I used the term "message" -- typically a multipacket entity in the TCP and IP layers just as an email message consists of a series of SMTP turnarounds over TCP. In that context, I stand by my assertion. And the reassembly of packets (as distinct from data streams/ messages) in the ARPANet is, I'm sure, fascinating to the few people on this distribution who didn't know about it and care. john --On Saturday, 13 July, 2002 17:43 +0900 Dave Crocker wrote: > > At 03:11 AM 7/13/2002 -0400, John C Klensin wrote: >> --On Saturday, 13 July, 2002 12:04 +0900 Dave Crocker >> > Internet mail is store-and-forward. ... This is like packet >> switching. Each intermediate system is "relaying" the email. >> >> It is like packet switching except, of course, in the packet >> case, each packet is typically a fragment or component of a >> message. > > "Typically", perhaps, but it is not true for all packet > switching systems and it is not part of the formal definition > of packet-switching. > > Packet switching is about independent addressing (and usually > independent routing) and handling of discrete chunks of data. > It is not about the relationships among that data. To that > extent, Internet mail is quite similar to lower-level packet > switching. > > (I say it is exactly the same, but therein lies a debate that > some of us have enjoyed for a few years -- errr, decades -- and > it is not pertinent to the specification under review.) > > >> The message, or data stream, is sent one packet at a time; >> it is not completely assembled at each intermediate host >> and then forwarded after it is complete. > > On the contrary, Arpanet IMP packet switching did fragmentation > and reassembly in the net, not in the hosts. (Any further > debate on this issue might be interesting, but it, too, is not > relevant to the current topic.) > > >> > The primary difference between relaying versus direct is that >> > relaying might take much longer. Therefore the sender does >> > not know when it will receive a response. >> >> I would disagree. The primary difference I see between >> relaying and direct is that, in a direct arrangement >> (characteristic of e.g., HTTP) the originating sending system >> can ask the ultimate receiving one a question by, well, asking. > > The UA-based CONNEG mechanism does query/response between two > UAs that are connected only by the store-and-forward email > service. There is nothing that dictates that application-level > query/response exchanges be conducted over connection-oriented, > direct or real-time associations. > > Just to underscore how fuzzy all this gets: HTTP relies on the > underlying store and forward of IP. Email UAs rely on the > underlying store and forward of SMTP. And, of course, SMTP > also relies on the store and forward of IP. > > More importantly, these concerns are essential matters for > successful implementation, deployment and use. But they have > nothing to do with core architectural principals. > > With respect to direct vs. relay, the architectural difference > between a UA-UA exchange and an HTTP exchange is remarkably > small, especially given that HTTP usage pretends it has no > context. These differences get even smaller with the > introduction of caching servers, and the like, because they > introduce a very high degree of indirection between consumer > and provider. > > >> A footnote on the "find out from a database" issue. The more I >> think about it, the more I conclude that the database lookup >> (LDAP or otherwise) is the only rational way of implementing >> the desired functionality here in a case that might involve >> relaying. > > Yes, it is an appealing model, except that LDAP has yet to > achieve Internet-scale deployment and use. Consequently it is > not wise to make a new service dependent on it. > > It is also worth noting that such a model requires real-time > connectivity. An email-based mechanism can operate with > asynchronous access. > > It makes far more sense to postulate a range of choices -- > including directly asking the own of the information via a UA > mechanism, as well as direct intermediaries via ESMTP/CONNEG -- > and incorporate LDAP when it starts being a serious global > service. > > >> To the extent that speedy and confirmed delivery are often >> cited as important values in fax, the "maybe it will get >> delivered as requested, ... is hard or >> impossible for the originating (or early relay) MTA to detect" >> alternatives are unreasonable. > > To the extent that a higher degrees of certainty is required, > then the operational components should be configured to provide > it. Using LDAP does not provide any guarantees of proper or > speedy performance, any more than using UA- or SMTP-based > content negotiations guarantees the lack. > > d/ > > ---------- > Dave Crocker > Brandenburg InternetWorking > tel +1.408.246.8253; fax +1.408.850.1850 > > > From owner-ietf-fax@mail.imc.org Sat Jul 13 17:28: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 RAA03495 for ; Sat, 13 Jul 2002 17:28:14 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6DLBbS08099 for ietf-fax-bks; Sat, 13 Jul 2002 14:11:37 -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 g6DLBVw08081; Sat, 13 Jul 2002 14:11:31 -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 g6DLBOt18421; Sat, 13 Jul 2002 17:11:24 -0400 (EDT) Message-Id: <200207132111.g6DLBOt18421@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: ned.freed@mrochek.com cc: Keith Moore , ned+ietf-smtp@mrochek.com, John C Klensin , Dave Crocker , Hiroshi Tamura , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org, ktoyoda@rdmg.mgcs.mei.co.jp Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" In-reply-to: (Your message of "Sat, 13 Jul 2002 13:04:52 PDT.") <01KK1Q1Y0NYC000O32@mauve.mrochek.com> Date: Sat, 13 Jul 2002 17:11:24 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > > > None of this experience seems particularly applicable to the question at hand, > > > > where we are comparing two different mechanisms for exporting only a small > > > > amount of information - SMTP, or some other protocol (of which LDAP is only a > > > > token example). If an enterprise is reluctant to export "information about > > > > their users" in general, then they will be about as reluctant to do so via SMTP > > > > as via some other protocol. > > > > > > I'm afraid this is another piece of theoretical considerations that fly in the > > > face of actual experience. The obvious counterexample is HTTP. > > > The relevance of HTTP is even less obvious to me because HTTP and directory > > services (LDAP or otherwise) tend to be used in very different ways. I don't > > see many sites exporting their company directories via either HTTP or LDAP. > > Then you haven't looked very hard. The former is quite popular; the latter > practically nonexistant. And the fact that the same information is exposed > either way yet one approach is preferred is directly relevant to the matter > at hand. what can I say - most of the company directories I've seen are not publically accessible. I don't doubt that many companies use HTTP to provide internal access; whether they make them available to the general public (which is what I meant by "export") is a different question. > > > I agree that predictability is nice, but that's not something any approach can > > > ever guarantee. Indeed, I can argue that a directory approach will lead to less > > > predictability, not more, if for no other reason than directory access will > > > tend to work locally but not remotely. SMTP access with appropriate caching, on > > > the other hand, has the potential to work both locally and globally. > > > The last two statements seem fairly odd. Maybe the problem is the use of the > > word "directory" which isn't my favorite word for this anyway. So let's not > > call this a directory - let's call it a capability discovery protocol. Now if > > the capability discovery protocol is defined in such a way that in order for > > your recipients to benefit from content negotiation you have to make it accessible > > (just like if you want to be able to accept mail then you have to make port 25 > > accessible) then it seems fairly likely that sites that want to enable content > > negotation for their recipients will do so. > > My point was they may make it available internally but not externally. And > using anything that remotely smells like a directory protocols makes this > outcome far more likely. ah. okay, I think we're in agreement about that (and that was very similar to my point about LDAP) - though whether this capabliity discovery protocol smells like a directory protocol may to some degree be a matter of social engineering, aka marketing. > > On the other hand, port 25 is one > > of the few ports that is commonly blocked/filtered for outgoing traffic - > > perhaps even more often (and with more drastic filtering) than port 80. > > Keith, my point was and is that the minute you start talking about using a > directory protocol -- and I insist on using the term because it's the directory > aspect that's important -- it makes the whole thing problematic in a way that > piggybacking the information on top of other type of protocols does not. well, if *we* insist on calling it a directory protocol then of course people will confuse it with other things they call directories. On the other hand sites seem happy to consider exporting limited information via DNS, and extensive information via HTTP, SOAP, .NET, or whatever. So if the marketing lingo has to be "recipient capability web service" or some such, so be it. (as long as we don't actually *use* SOAP or .NET... :) as to whether rescap would be branded a directory - the number of people who kept insisting that it should be LDAP was fairly significant, indicating that many people couldn't readily distinguish the two problems. this even though one of the major reasons for making rescap a separate protocol was to distinguish it from directories and specifically to have a mechanism tailor-made for exporting public information. but frankly part of that problem was that some LDAP people were seeing rescap as a competitor/threat to LDAP. as you say, it's not a sane world. URNs have an even worse mis-perception problem, they always have, and it's not clear what to do about it. > You can talk till you're blue in the face about how this is capabilities > discovery, how that's intrinsicly different from a general directory > protocol, and so on and so forth. It doesn't change the perception that > a protocol intended solely for looking up stuff, no matter how innocuous > that stuff is, no matter how divorced from the cporpoate directory or > whatever it can be made, is somehow more problematic than piggybacking > the exact same information on top of other protocols. okay, I'll concede the point that there's this dark cloud over things that (in the minds of network administrators) resemble directories. I don't think that should by itself stop working groups from using things that resemble directories if that's the right technical solution, but it's useful to be aware of it. it does I think illustrate that good technical design is not always sufficient - unless we somehow convey to users an understanding of new protocols, how they're meant to be used, the risks associated with using them, etc. And we haven't been very effective at that since the 'net grew up... > > So the argument that a facility that requires direct connection over port 25 > > (from the origin to the MX server, not necessarily to the final MTA) > > in order to work properly (i.e. in order to let the sender control the > > conversion) will function both locally and globally seems a bit dubious. > > I have pointed out previously that such direct connection isn't required by the > present proposal. So this is nothing but another strawman. ah, but either the client has a direct connection to the MX or it has to relay the message to some MTA which may or may not be under control of the client. so the relaying case introduces the same problem that OPES had when it was first proposed - that of having an intermediary make transformations to the content that aren't authorized by either party of the conversation. Keith From owner-ietf-fax@mail.imc.org Sat Jul 13 17:47:19 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 RAA03970 for ; Sat, 13 Jul 2002 17:47:18 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6DLUHf08884 for ietf-fax-bks; Sat, 13 Jul 2002 14:30:17 -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 g6DLU4w08866; Sat, 13 Jul 2002 14:30:04 -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 g6DLTwt18587; Sat, 13 Jul 2002 17:29:58 -0400 (EDT) Message-Id: <200207132129.g6DLTwt18587@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: John C Klensin cc: Keith Moore , Dave Crocker , Hiroshi Tamura , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org, ktoyoda@rdmg.mgcs.mei.co.jp Subject: Re: RCAP mini-spec (was: Re: Keywords for "SMTP Service Extension for Content Negotiation" ) In-reply-to: (Your message of "Sat, 13 Jul 2002 16:42:21 EDT.") <5397851.1026578541@localhost> Date: Sat, 13 Jul 2002 17:29:58 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > 4. the RCAP command is acceptable at any time that MAIL or RCPT > > would be acceptable. clients MAY issue RCAP before or after > > MAIL, and they MAY issue RCAP and RCPT commands in any order. > > (though generally it makes more sense to issue RCAP for a > > recipient before sending RCPT for that recipient) > > The RCAP response MUST be the same regardless of whether the > > command is issued before or after MAIL, or before or after RCPT. > > Keith, I don't assume this would be heavily used, but, as with > SIZE, I can imagine some sites being willing to accept more > complex formats from some senders than from others. Of course, > such mechanisms are easily thwarted in the absence of SMTP > authentication or trusted transport (and would not be available > with some of the other proposals). But, unless you have a > substantive reason for permitting RCAP before MAIL, it would seem > desirable to force it to come after MAIL, thereby preserving this > implementation option at substantially no cost. my assumption was that the return address is essentially useless for determining the kind of content that would be acceptable to the recipient - partially since they are easily forged, and partially since there are various reasons to use a different return address than one's normal email address. SMTP authentication credentials might be useful for determining the conneg string returned, but those would presuambly be presented before MAIL. my reason for allowing RCAP before MAIL was to allow query-only sessions without having to specify a return address that won't get used anyway and just serve to slow the query down. still I don't claim to have nailed down every detail - this is just a "strawman" proposal so that people have something to compare with the proposal that uses RCPT. Keith From owner-ietf-fax@mail.imc.org Sat Jul 13 20:45:34 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 UAA08038 for ; Sat, 13 Jul 2002 20:45:34 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6E0UL717572 for ietf-fax-bks; Sat, 13 Jul 2002 17:30:21 -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 g6E0UIw17561 for ; Sat, 13 Jul 2002 17:30:18 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KK1QGBQWZK0001B1@mauve.mrochek.com> for ietf-fax@imc.org; Sat, 13 Jul 2002 17:30:19 -0700 (PDT) Date: Sat, 13 Jul 2002 14:22:19 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" In-reply-to: "Your message dated Sat, 13 Jul 2002 17:11:24 -0400" <200207132111.g6DLBOt18421@astro.cs.utk.edu> To: Keith Moore Cc: ned.freed@mrochek.com, Keith Moore , ned+ietf-smtp@mrochek.com, John C Klensin , Dave Crocker , Hiroshi Tamura , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org, ktoyoda@rdmg.mgcs.mei.co.jp Message-id: <01KK1YUDHRME0001B1@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <01KK1Q1Y0NYC000O32@mauve.mrochek.com> <200207132111.g6DLBOt18421@astro.cs.utk.edu> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > > > The relevance of HTTP is even less obvious to me because HTTP and directory > > > services (LDAP or otherwise) tend to be used in very different ways. I don't > > > see many sites exporting their company directories via either HTTP or LDAP. > > > > Then you haven't looked very hard. The former is quite popular; the latter > > practically nonexistant. And the fact that the same information is exposed > > either way yet one approach is preferred is directly relevant to the matter > > at hand. > what can I say - most of the company directories I've seen are not publically > accessible. I don't doubt that many companies use HTTP to provide internal > access; whether they make them available to the general public (which is what > I meant by "export") is a different question. I speak as someone who used to sell and support software that did this sort of thing, both via HTTP and LDAP. I saw plenty of examples of public export of directory information, including but not limited to user information, through HTTP, very few through LDAP. I really can't explain the difference. My assessment was and is that a carefully designed LDAP->LDAP gateway is likely to be more secure than a random Web server lashed up to an LDAP server. > as to whether rescap would be branded a directory - the number of people who > kept insisting that it should be LDAP was fairly significant, indicating > that many people couldn't readily distinguish the two problems. this > even though one of the major reasons for making rescap a separate protocol was > to distinguish it from directories and specifically to have a mechanism > tailor-made for exporting public information. but frankly part of that problem > was that some LDAP people were seeing rescap as a competitor/threat to LDAP. As an aside, I think we actually foster this attitude given the degree and tone of pushback that's often present in the IETF. For what may seem like the best of reasons people often have to fight to get their work through the process. But once that's done you're left with people trained to fight. > as you say, it's not a sane world. URNs have an even worse mis-perception > problem, they always have, and it's not clear what to do about it. > > You can talk till you're blue in the face about how this is capabilities > > discovery, how that's intrinsicly different from a general directory > > protocol, and so on and so forth. It doesn't change the perception that > > a protocol intended solely for looking up stuff, no matter how innocuous > > that stuff is, no matter how divorced from the cporpoate directory or > > whatever it can be made, is somehow more problematic than piggybacking > > the exact same information on top of other protocols. > okay, I'll concede the point that there's this dark cloud over things > that (in the minds of network administrators) resemble directories. > I don't think that should by itself stop working groups from using things > that resemble directories if that's the right technical solution, > but it's useful to be aware of it. it does I think illustrate that good > technical design is not always sufficient - unless we somehow convey > to users an understanding of new protocols, how they're meant to be used, > the risks associated with using them, etc. And we haven't been very > effective at that since the 'net grew up... Well, let's be fair here: We can lead the horse to water... I'm probably a bit biased since I wrote a bunch of the text, but I think we did a reasonable job of documenting the risks of active content back when MIME was first specified. And yet active content in the form of email viruses is one of the major operational problems, if not THE operational problem, we face in email today. We did our bit and nobody listened. It's quite a conundrum. Even when we do our job things still go wrong. Some folks argue that things capable of abuse should not be standardized. But there are substantive and possibly even greater risks associated with the lack of standardization as well. > > > So the argument that a facility that requires direct connection over port 25 > > > (from the origin to the MX server, not necessarily to the final MTA) > > > in order to work properly (i.e. in order to let the sender control the > > > conversion) will function both locally and globally seems a bit dubious. > > I have pointed out previously that such direct connection isn't required by the > > present proposal. So this is nothing but another strawman. > ah, but either the client has a direct connection to the MX or it has to > relay the message to some MTA which may or may not be under control of the > client. so the relaying case introduces the same problem that OPES had > when it was first proposed - that of having an intermediary make transformations > to the content that aren't authorized by either party of the conversation. The case I was thinking of was the one where caching of conneg information by intermediaries eventually brings the information back to the server adjacent to the originating client. So the transformation is still done on the originating client or on a server very close to it. I also discussed the situation where conneg transformation is done by a central intermediary in a previous message and concluded that there seemed to be no business case for it. I should also note that the class of tranformations envisioned by OPES is considerably broader than the class of transformations envisioned here. Ned From owner-ietf-fax@mail.imc.org Sat Jul 13 21:20: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 VAA09641 for ; Sat, 13 Jul 2002 21:20:29 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6E164518975 for ietf-fax-bks; Sat, 13 Jul 2002 18:06:04 -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 g6E163w18964; Sat, 13 Jul 2002 18:06:03 -0700 (PDT) Received: from BBFUJIP.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 SAA14872; Sat, 13 Jul 2002 18:12:47 -0700 Message-Id: <5.1.0.14.2.20020714061849.0391a008@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 14 Jul 2002 06:50:34 +0900 To: Keith Moore From: Dave Crocker Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" Cc: iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org In-Reply-To: <200207131351.g6DDp3t16723@astro.cs.utk.edu> References: <(Your message of "Sat, 13 Jul 2002 12:04:48 +0900.") <5.1.0.14.2.20020713100917.083f42e0@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: At 09:51 AM 7/13/2002 -0400, Keith Moore wrote: > > Moore-san prefers to have the capabilities query be in a separate > > command. For convenience, he has given this command a name, RCAP. So, > the > > name refers to an idea that Moore-san has. There is no written > > specification for that command. In my opinion, the current specification > > is satisfactory. ... >if the message being transmitted is a fax and all recipients are capable >of fax, >then perhaps it is acceptable to downgrade the message to a lower quality fax >format which is acceptable to all. Ever since multi-recipient addressing was introduced, we have had downgrading, by virtue of users having to choose the least common denominator approach to sending attachments. So the fact that this new mechanism allows that downgrading to happen later in the transmission sequence should not confuse anyone into thinking that downgrading is a new or unusual requirement. >the use of the RCPT response to tell the client of the recipient's >capabilities >is odd because it asserts that the client intends to deliver a message to >each of several recipients before the client actually knows whether it can >deliver the same version of the message to each recipient, or whether it can >deliver any version of that message to the recipient. "or whether it can"??? There has been no posting that provides a practical basis for such a conclusion. Therefore, any implications of this unproved -- and frankly counter-intuitive and highly unlikely -- assessment has nothing to do with the current specification. >so as the proposal is written, any client which attempts to deliver a message >to multiple recipients in a single transaction must be prepared to abort the >current SMTP transaction (presumably by using RSET) after sending multiple >RCPTs, It is NOT required to do that. Nor is the ability to send an RSET during a session a big deal. In fact, that's what the command is there for. >it's been claimed that using RCPT in this way is faster that using a >separate >command, Faster for single-recipient use, yes. Faster for multi-recipient use, with common format, yes. In both cases there are fewer commands and fewer round-trips than when using a separate capabilities-query language. It does not take deep analysis to know that the current proposal is faster. Faster for the particular scenario you used, with an RCPT? No. That has not been claimed. Using RSET is expensive. A design that calls for its use makes sense only if that use is expected to be atypical. As has been discussed previously use of the current specification is based on the expectation that use of RSET will not be a typical. >another problem with RCPT is that it expects the server to return status codes >for error conditions that can only be distinguished on the client. There is no such expectation: "If the SMTP server supports ENHANCEDSTATUSCODES [RFC1893], the..." Apparently you missed the "If". In any event, i have no idea why the codes are somehow uninterpretable by any system other than the client. At 10:16 AM 7/13/2002 -0400, Keith Moore wrote: > > The UA-based CONNEG mechanism does query/response between two UAs that are > > connected only by the store-and-forward email service. ... > >perhaps not, but once a message is relayed, the conversion (and the decision >of whether to deliver the message) is no longer under control of the sender - I have no idea what you mean by "under control of the sender" nor do I have any idea how the current proposal has any practical difference in control, from any other proposal or idea for content negotiation. >actually the most likely scenario when using the conneg proposal with the >current infrastructure is that the message will be delivered, without >conversion, regardless of recipient capabilities. And I have no idea where this assessment is based on, nor does it make any obvious sense. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Sat Jul 13 21:20:31 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 VAA09654 for ; Sat, 13 Jul 2002 21:20:31 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g6E15rg18956 for ietf-fax-bks; Sat, 13 Jul 2002 18:05:53 -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 g6E15nw18943; Sat, 13 Jul 2002 18:05:49 -0700 (PDT) Received: from BBFUJIP.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 SAA14858; Sat, 13 Jul 2002 18:12:41 -0700 Message-Id: <5.1.0.14.2.20020714060830.0391cc08@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 14 Jul 2002 06:14:20 +0900 To: ietf-fax@imc.org, ietf-smtp@imc.org From: Dave Crocker Subject: Piggybacked, adjunct services Cc: iesg@ietf.org In-Reply-To: <01KK1HVAM6PU000O32@mauve.mrochek.com> References: <"Your message dated Sat, 13 Jul 2002 03:11:13 -0400" <2679395.1026529873@localhost> <5.1.0.14.2.20020713100917.083f42e0@jay.songbird.com> <2679395.1026529873@localhost> 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, Ned's note explains some operational realities and some architectural implications. His note is the clearest, the most pragmatic, and the most compelling statement on this issue that I have seen. It is easy to miss just how important his explanation is. So I am taking the slightly theatrical step of re-posting it, in order to stress the importance of its insight: At 08:55 AM 7/13/2002 -0700, ned.freed@mrochek.com wrote: >In the real world directory/database systems >that let sites provide Internet-wide access to information about their >users do >not deploy. > >I'm not sure why this is the case, and indeed I'm fairly sure that there is no >good reason for it, but a vast tract of experience tells me it for-sure is the >case. (Now is not the time to get into whys in more detail.) > >The IETF has tried to tackle this problem several times, and indeed continues >to do so now in the RESCAP WG. But I don't think anyone seriously believes >that >even if RESCAP produces some specifications it is going to succeed at its >intended scale. Frankly, the silence is pretty deafening over there. > >Lacking direct capabilities to find capabilties information necessarily leads >to various piggybacking options, that is, deploy this facility on top of or >inside other protocols. This has some of the same characteristics as the >everything-over-HTTP approach, but with several important differences: >There is >a close relationship between the piggybacked data and the intended purpose of >the underlying protocols (a relationship that is often lacking with stuff >travelling over HTTP) and the operational case for doing this is far more >compelling (getting the OK to drill a hole in a firewall for a new protocol is >triviality itself compared to the difficulty in setting up even restricted >access to directory information). > >I think the availabilty of capabilities information has the potential to be as >important a step as MIME was. As such, I don't begrudge healthy debate about >how and where it is done. But let's not forget that the development of >MIME was >informed by the catastrophic failure of various other schemes for doing >multimedia messaging -- some of them more elegant than MIME -- leading to >compromises in the design intended to insure deployability. I think the >discussion of where and how to do content negotiation needs to be similarly >informed by the catastrophic failure of Internet-wide directory services to >deploy. > > Ned ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Sun Jul 14 07:05:33 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 HAA01528 for ; Sun, 14 Jul 2002 07:05:33 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6EAh5V10715 for ietf-fax-bks; Sun, 14 Jul 2002 03:43:05 -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 g6EAflw10638; Sun, 14 Jul 2002 03:41:47 -0700 (PDT) Received: from BBFUJIP.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 DAA24332; Sun, 14 Jul 2002 03:48:37 -0700 Message-Id: <5.1.0.14.2.20020714101753.01dbcee8@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 14 Jul 2002 10:19:46 +0900 To: John C Klensin From: Dave Crocker Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" Cc: John C Klensin , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org In-Reply-To: <7130026.1026580273@localhost> References: <5.1.0.14.2.20020713171652.08336708@jay.songbird.com> <5.1.0.14.2.20020713171652.08336708@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: At 05:11 PM 7/13/2002 -0400, John C Klensin wrote: >You are, I think, equating packet fragmentation and reassembly to >email messages. No I was not. I DID, however, note that the issue of fragmentation was a) not part of the definition of packet switching, and b) irrelevant to the use of the term in the current discussion. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Sun Jul 14 09:11:56 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 JAA04609 for ; Sun, 14 Jul 2002 09:11:55 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6ECrUU19828 for ietf-fax-bks; Sun, 14 Jul 2002 05:53:30 -0700 (PDT) Received: from pp-mx0.tokyo.spin.ad.jp (PP-mx0.Tokyo.Spin.AD.JP [165.76.52.9]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6ECrSw19823 for ; Sun, 14 Jul 2002 05:53:28 -0700 (PDT) Received: from localhost (h142-001.tokyu-net.catv.ne.jp [210.149.142.1]) by pp-mx0.tokyo.spin.ad.jp (8.8.8+Spin/3.6W-JENS-stand2(09/30/00)) id VAA04733; Sun, 14 Jul 2002 21:53:05 +0900 (JST) To: ietf-fax@imc.org Cc: claudio.allocchio@garr.it Subject: Your slides, please! 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: <20020714215231T.adm@ifax.attnet.ne.jp> Date: Sun, 14 Jul 2002 21:52:31 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 14 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, Welcome to Japan! Please give your slides to Claudio and me before our meeting, if possible. I am thinking of changing the order of our agenda. It is better that ESMTP CONNEG issue should be the last one. Regards, -- Hiroshi Tamura, Co-chair of IETF-FAX WG tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Sun Jul 14 10:25:19 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 KAA07347 for ; Sun, 14 Jul 2002 10:25:18 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6EE9uK21006 for ietf-fax-bks; Sun, 14 Jul 2002 07:09:56 -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 g6EE9tw21002 for ; Sun, 14 Jul 2002 07:09:55 -0700 (PDT) Received: from GK-VAIO.ninebynine.org ([61.193.174.82]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g6EE6V414023; Sun, 14 Jul 2002 07:06:31 -0700 Message-Id: <5.1.0.14.2.20020714144010.032e3b40@joy.songbird.com> X-Sender: gk-lists@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 14 Jul 2002 15:06:26 +0100 To: Dave Crocker From: Graham Klyne Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" Cc: ietf-fax@imc.org In-Reply-To: <5.1.0.14.2.20020713100917.083f42e0@jay.songbird.com> References: <20020712191142T.tamura@toda.ricoh.co.jp> 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 12:04 PM 7/13/02 +0900, Dave Crocker wrote: >>- fax-specific or not > >It is strange, but I think this is the most difficult term. When we talk >about T.30, it is easy to know what it means to say "fax-specific". When >we talk about FFPIM, perhaps it is not so easy. > >For the IETF Fax working group, I believe "fax-specific" refers to >features and functions that emulate T.30. That is, we are trying to make >Internet mail provide the same service as T.30. So, "fax-specific" refers >to email enhancements that permit email to work like fax. I'm uneasy about (appearing to) equate fax-specific with just T.30 -- I think your last sentence carries the intent if not the desired precision -- maybe: [[ "fax-specific" refers to email enhancements that permit email to negotiate, transmit and confirm the transfer of images in timely fashion, like traditional fax. Traditional email, by contrast, transmits any data and does not impose any requirement that the data can be processed by the recipient or that the recipient confirm its receipt. ]] >>- multi-recipient > >Internet mail permits a message to be addressed to more than one >person. For example, see the To and CC fields of this message. T.30 >permits addressing a single receiving device. Some fax store-and-forward >services permit the sender to specify more than one receiver. This is >multi-recipient. If you mention fax store-and-forward, I'd suggest a comment to the effect that such services behave in a fashion more like ordinary email than fax. (I.e. saying that fax does store and forward like email doesn't of itself mean that providing a fax-like service requires Internet fax should support all fax features for multiple recipients.) >>- LCD > >Least Common Denominator. So, we are borrowing a term from math, to apply >to our discussion of ESMTP/CONNEG, it is possible to receive CONNEG >parameters for multiple recipients. If the recipients have different >capabilities, what capabilities should the sender use? One possibility is >to end the current SMTP session and then send each recipient the best >content they can receive. Another possibility is to find the >"intersection" of capabilities for all the recipients and send this "least >common denominator" or "most common format" to all of the recipients at once. This term has often puzzled me as being incorrect in its mathematical allusion. The terms "greatest common divisor" or "highest common factor" seem more apposite. >>- consideration of relay > >Facsimile is direct, point-to-point. The sending device and the receiving >device are connected to each other at the same time. They talk with each >other directly. > >Internet mail is store-and-forward. The sender and the receiver are not >required to be connected to the Internet at the same time. The email may >go through intermediate email services, when moving from the sender to the >receiver. (For example, it may go from a department's SMTP mail system to >the enterprise system; the enterprise system may send it to the receiving >enterprise's system; the receiving system may then send it to the >receiver's department email server.) This is like packet switching. Each >intermediate system is "relaying" the email. > >The primary difference between relaying versus direct is that relaying >might take much longer. Therefore the sender does not know when it will >receive a response. > >On the Internet, a direct connection usually has a response time of a few >minutes, maximum. Normally it is much shorter, of course. For email >relaying, response time can be days, not minutes. This difference in >latency requires different design choices. I think there's a more fundamental architectural issue that is exploited by traditional fax operating in a non-relay mode: normal operation requires that the sender can receive some indication from the receiver before it starts to send any actual data. >>- interoprability with existing environment > >When we add a new feature, how does it affect the old >operation? Sometimes adding a new features makes the old system stop >working. For MIME, the goal was to add a new feature that made no change >to email transport and also would not break an old email user agent. > >The goal with ESMTP options is to make old operations behave the old way, >but permit participants who support a new option to use them with each other. A further consideration that very strongly influenced the user-agent-based negotiation mechanism is that no messages should be sent in assumption that the receiver is anything other than a plain old fashioned mail client, and that all messages received by such a client could be presented to the recipient user as ordinary email messages. ("No administrative non-messages"). >>- real-time > >I think that we use this term very informally in the Fax working group >discussions. Probably it simply means "quickly". Perhaps we can simply >use it to mean "within the limits of T.30 timeouts" -- 2 seconds? > >For the design of human interaction, real-time usually mean 1/2 second, or >less. For the design or high performance system, it can refer to >milliseconds or microseconds. My working definition of real-time: if some data is received late, then it is wrong. This pointedly doesn't say what it means to be late. >>- bandwidth > >The amount of data that can be send within a period of time. The >bandwidth of a T1 (or E1) line is very much greater than a dial-up connection. A closely related concept is latency: the amount of time that elapses from sending some data to the point that the receiver starts to receive it. #g ------------------- Graham Klyne From owner-ietf-fax@mail.imc.org Sun Jul 14 10:25:49 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 KAA07388 for ; Sun, 14 Jul 2002 10:25:48 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6EEArn21028 for ietf-fax-bks; Sun, 14 Jul 2002 07:10:53 -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 g6EE9vw21007; Sun, 14 Jul 2002 07:09:57 -0700 (PDT) Received: from GK-VAIO.ninebynine.org ([61.193.174.82]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g6EE6Y414032; Sun, 14 Jul 2002 07:06:34 -0700 Message-Id: <5.1.0.14.2.20020714151327.03307dd0@joy.songbird.com> X-Sender: gk-lists@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 14 Jul 2002 15:19:10 +0100 To: ned.freed@mrochek.com From: Graham Klyne Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" Cc: ietf-fax@imc.org, ietf-smtp@imc.org In-Reply-To: <01KK1HVAM6PU000O32@mauve.mrochek.com> References: <"Your message dated Sat, 13 Jul 2002 03:11:13 -0400" <2679395.1026529873@localhost> <5.1.0.14.2.20020713100917.083f42e0@jay.songbird.com> <2679395.1026529873@localhost> 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 08:55 AM 7/13/02 -0700, ned.freed@mrochek.com wrote: >I think the availabilty of capabilities information has the potential to be as >important a step as MIME was. As such, I don't begrudge healthy debate about >how and where it is done. But let's not forget that the development of >MIME was >informed by the catastrophic failure of various other schemes for doing >multimedia messaging -- some of them more elegant than MIME -- leading to >compromises in the design intended to insure deployability. I think the >discussion of where and how to do content negotiation needs to be similarly >informed by the catastrophic failure of Internet-wide directory services to >deploy. (Not to disagree with anything you say...) One of the considerations informing the UA-driven negotiation design was the idea that information obtained from any source other than the final recipient was potentially tentative, and that some kind of closing of the loop was needed to make negotiation reliable. The better the initial information that is available, the more efficient the negotiate-and-transfer process (one round trip). But incorrect initial information doesn't cause the transfer to fail (except possibly for reasons of timing). #g ------------------- Graham Klyne From owner-ietf-fax@mail.imc.org Sun Jul 14 12:57: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 MAA11182 for ; Sun, 14 Jul 2002 12:57:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6EGfct01626 for ietf-fax-bks; Sun, 14 Jul 2002 09:41:38 -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 g6EGfFw01614; Sun, 14 Jul 2002 09:41:15 -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 g6EGewt11486; Sun, 14 Jul 2002 12:40:58 -0400 (EDT) Message-Id: <200207141640.g6EGewt11486@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: ned.freed@mrochek.com cc: Keith Moore , ned+ietf-smtp@mrochek.com, John C Klensin , Dave Crocker , Hiroshi Tamura , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org, ktoyoda@rdmg.mgcs.mei.co.jp Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" In-reply-to: (Your message of "Sat, 13 Jul 2002 14:22:19 PDT.") <01KK1YUDHRME0001B1@mauve.mrochek.com> Date: Sun, 14 Jul 2002 12:40:58 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I'm probably a bit biased since I wrote a bunch of the text, but I think we did > a reasonable job of documenting the risks of active content back when MIME was > first specified. And yet active content in the form of email viruses is one of > the major operational problems, if not THE operational problem, we face in > email today. We did our bit and nobody listened. I have a slightly different take - we did our bit and the major operating system vendor listened and irresponsibly chose to ignore us, putting their desire to have their applications' data formats (including executable content) transferred over email ahead of their customers' need for security. I was explicitly told this by a former program manager for that major operating system vendor, though he didn't seem to think it was irresponsible. He called it a marketing decision. > > ah, but either the client has a direct connection to the MX or it has to > > relay the message to some MTA which may or may not be under control of the > > client. so the relaying case introduces the same problem that OPES had > > when it was first proposed - that of having an intermediary make transformations > > to the content that aren't authorized by either party of the conversation. > > The case I was thinking of was the one where caching of conneg information by > intermediaries eventually brings the information back to the server adjacent to > the originating client. So the transformation is still done on the originating > client or on a server very close to it. I think it's a stretch to believe that caches are going to solve this problem. It's true that if A keeps sending messages to B then eventually A's MTA will be able to cache B's recipient information. But this assumes that the intervening MTAs support CONNEG (and cache CONNEG information) - which itself seems like a stretch because, as you say, there's no business case for them doing conversion. It's also a stretch to believe that this is going to work well for arbitrary pairs of senders and recipients - it might work for those pairs who exchange lots of messages, not so well for those pairs that occasionally exchange messages. And of course there's the problem that CONNEG information can be expected to change over time, but there's no mechanism in the current proposal to timeout caches. Frankly the method of returning capabilities in a bounce message seems more effective and more reliable because it doesn't rely on intermedaries. The only way I see to make the CONNEG SMTP proposal work end-to-end is for all of the intermediate MTAs (those that don't have direct knowledge of the recipient capabilities) to open up SMTP connections to the next hop *in real time* - so when the sender asserts CONNEG in a RCPT command then the MTA has to stop acting like a relayer and start acting like a proxy - finding a MTA for the next hop, opening up a connection, sending EHLO and seeing if it supports CONNEG, sending MAIL and all previous RCPTs, and finally sending the RCPT that has the CONNEG option, just so that it can propagate the CONNEG response back to the sender's UA. Even then it will be very slow, it introduces race conditions due to timeouts, and it still requires all of the intermediate MTAs to support CONNEG in proxy mode. I haven't followed the fax discussions, but weren't the fax people looking for a mechanism that would work predictably and reliably - e.g. if sender and recipient both have (say) high-res capability then the document is always transferred in high-res - and a mechanism that would give the sender the option of requiring that the recipient have certain minimum capabilities before sending the message? (e.g. don't bother sending if recipient doesn't have color?) I just don't see a way to make that work through the existing SMTP infrastructure. Keith From owner-ietf-fax@mail.imc.org Sun Jul 14 13:29:43 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 NAA11949 for ; Sun, 14 Jul 2002 13:29:42 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6EHD1202276 for ietf-fax-bks; Sun, 14 Jul 2002 10:13:01 -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 g6EHCsw02265; Sun, 14 Jul 2002 10:12:54 -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 g6EHCrt15947; Sun, 14 Jul 2002 13:12:53 -0400 (EDT) Message-Id: <200207141712.g6EHCrt15947@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: Keith Moore , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" In-reply-to: (Your message of "Sun, 14 Jul 2002 06:50:34 +0900.") <5.1.0.14.2.20020714061849.0391a008@jay.songbird.com> Date: Sun, 14 Jul 2002 13:12:53 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Ever since multi-recipient addressing was introduced, we have had > downgrading, by virtue of users having to choose the least common > denominator approach to sending attachments. > > So the fact that this new mechanism allows that downgrading to happen later > in the transmission sequence should not confuse anyone into thinking that > downgrading is a new or unusual requirement. Dave, it's a gross exaggeration to claim that the fact that human senders have long found it advantageous to send messages to multiple recipients using a common format of their choosing, that this is a good justification for standardizing the idea that MTAs that are responsible to neither the sender nor the recipient should be able to "downgrade" a message, using arbitrary and unspecified methods, without any knowledge of the consequence of applying conversion to the content, and without any explicit authorization. > >the use of the RCPT response to tell the client of the recipient's > >capabilities > >is odd because it asserts that the client intends to deliver a message to > >each of several recipients before the client actually knows whether it can > >deliver the same version of the message to each recipient, or whether it can > >deliver any version of that message to the recipient. > > "or whether it can"??? There has been no posting that provides a practical > basis for such a conclusion. Yes there has, but perhaps you missed it. Regardless you should be able to figure out that your proposal provides no assurance that downgrading is even possible. just to take a trivial example - the message might contain only audio while one recipient accepts only fax. Another example - the recipient accepts only HTML and plain text, the message is in microsoft word, and while conversion is possible the MTA doesn't know how to do it. so yes, "whether it can" is entirely appropriate wording. > Therefore, any implications of this unproved -- and frankly > counter-intuitive and highly unlikely -- assessment has nothing to do with > the current specification. Dave, the most charitable thing I can say is that you must be living in a different universe. You have consistently responded to valid, well-explained, and defensible technical criticisms by flat-out stating that they don't exist or that they don't make any sense, without any defense. You seem to think that everyone who uses this extension you're propsing will have the same assumptions that you do, and adhered to a set of constraints that exists only in your head. And if you don't understand your own proposal well enough to make intelligent responses to technical criticism then frankly you need to withdraw it and stop wasting our time. Keith From owner-ietf-fax@mail.imc.org Sun Jul 14 14:40:05 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 OAA13613 for ; Sun, 14 Jul 2002 14:40:05 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g6EIMxK05319 for ietf-fax-bks; Sun, 14 Jul 2002 11:22:59 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6EIMvw05315; Sun, 14 Jul 2002 11:22:57 -0700 (PDT) Received: from ns.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 3.35 #1) id 17To1G-000Gpt-00; Sun, 14 Jul 2002 18:22:54 +0000 Date: Sun, 14 Jul 2002 14:22:49 -0400 From: John C Klensin To: Dave Crocker , Keith Moore cc: iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" Message-ID: <8671231.1026656568@[192.168.3.186]> In-Reply-To: <5.1.0.14.2.20020714061849.0391a008@jay.songbird.com> References: <5.1.0.14.2.20020714061849.0391a008@jay.songbird.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit --On Sunday, 14 July, 2002 06:50 +0900 Dave Crocker wrote: >... > Ever since multi-recipient addressing was introduced, we have > had downgrading, by virtue of users having to choose the least > common denominator approach to sending attachments. > > So the fact that this new mechanism allows that downgrading to > happen later in the transmission sequence should not confuse > anyone into thinking that downgrading is a new or unusual > requirement. >... Dave, I want to be sure I understand what you are saying here, because, if I am reading it correctly, I find it astonishing. First of all, I don't find, anywhere in the document, a statement that the originator, in attempting to use CONNEG, is authorizing any intermediate MTA that might touch the message to alter its content. Nor do I find in the "security considerations" an explanation of that authorization and the associated risks. If such text is actually there, then some of what follows may be irrelevant (although it wouldn't convince me it is a good idea). Certainly, originating MUAs downgrade and change formats based on what they, on behalf of the user, believe the recipient will be able to process and have done that for a long time. But they do so before the message enters a transmission stream. We have typically tried to keep that transmission stream as opaque to message content as possible. In recent years, we have made some formal allowances for fixups by originating MTA for low-capability MUAs, but we have rather carefully delimited them (see sections 3.7, 6.1, and 6.3 of RFC 2821 (the references to section 2.4.1 are incorrect and should refer to 6.3)). We also permit downgrading through ESTMP options like 8BITMIME, which is quite explicit that an initiator who asks for this feature is agreeing to a (very specific, known-result) downgrade by relaying systems. But, unless I read the above incorrectly, you are suggesting that * Since the originating MUA clearly has the ability and authority to alter content to reflect its assumptions about receiver capability (before the content is handed off to an SMTP server and placed into the transport stream) * Other alterations to content ("downgrades") are just moving the process "later in the transmission sequence" * Hence intermediate/relay MTAs have the right/authority to make content changes based on their inferences about what the receiver wants. I hope that isn't what you meant, because it is pretty scary. It also creates a contradiction between this draft and RFC 2821 (as well as the way most of us have read 821 for years), raises a collection of security issues (e.g., in-transit downgrading would seem to me to be quite hard on signed content), and so on. Could you explain what you did mean? john From owner-ietf-fax@mail.imc.org Sun Jul 14 15:10:28 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 PAA14227 for ; Sun, 14 Jul 2002 15:10:27 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6EIsYZ06094 for ietf-fax-bks; Sun, 14 Jul 2002 11:54:34 -0700 (PDT) Received: from turing-police.cc.vt.edu (h80ad25dd.async.vt.edu [128.173.37.221]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6EIsMw06081; Sun, 14 Jul 2002 11:54:22 -0700 (PDT) Received: from turing-police.cc.vt.edu (localhost [127.0.0.1]) by turing-police.cc.vt.edu (8.12.5/8.12.5) with ESMTP id g6EIsBCr021519; Sun, 14 Jul 2002 14:54:12 -0400 Message-Id: <200207141854.g6EIsBCr021519@turing-police.cc.vt.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: ned+ietf-smtp@mrochek.com Cc: ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" In-Reply-To: Your message of "Sat, 13 Jul 2002 08:55:41 PDT." <01KK1HVAM6PU000O32@mauve.mrochek.com> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face-Viewer: See ftp://cs.indiana.edu/pub/faces/index.html to decode picture X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ <2679395.1026529873@localhost> <01KK1HVAM6PU000O32@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_847081899P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 14 Jul 2002 14:54:11 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==_Exmh_847081899P Content-Type: text/plain; charset=us-ascii On Sat, 13 Jul 2002 08:55:41 PDT, ned+ietf-smtp@mrochek.com said: > I think this is a fine piece of theoretical analysis which unfortunately has no > applicability to the real world. In the real world directory/database systems > that let sites provide Internet-wide access to information about their users do > not deploy. > > I'm not sure why this is the case, and indeed I'm fairly sure that there is no > good reason for it, but a vast tract of experience tells me it for-sure is the > case. (Now is not the time to get into whys in more detail.) I'll just add 2 words to the "why" and leave it at that: "datamining" "spammers". -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_847081899P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE9McjTcC3lWbTT17ARAqxcAJ0VFDnNiuxnVkuhkkq8M5mCZoX9GQCeNz4q 5sYPPtUWOER/dx9gxplpSkI= =8Pak -----END PGP SIGNATURE----- --==_Exmh_847081899P-- From owner-ietf-fax@mail.imc.org Sun Jul 14 15:53: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 PAA15289 for ; Sun, 14 Jul 2002 15:53:50 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6EJSmi08931 for ietf-fax-bks; Sun, 14 Jul 2002 12:28:48 -0700 (PDT) Received: from turing-police.cc.vt.edu (h80ad25dd.async.vt.edu [128.173.37.221]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6EJSVw08892; Sun, 14 Jul 2002 12:28:31 -0700 (PDT) Received: from turing-police.cc.vt.edu (localhost [127.0.0.1]) by turing-police.cc.vt.edu (8.12.5/8.12.5) with ESMTP id g6EJSFCr021914; Sun, 14 Jul 2002 15:28:16 -0400 Message-Id: <200207141928.g6EJSFCr021914@turing-police.cc.vt.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: Dave Crocker Cc: ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" In-Reply-To: Your message of "Sun, 14 Jul 2002 06:50:34 +0900." <5.1.0.14.2.20020714061849.0391a008@jay.songbird.com> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face-Viewer: See ftp://cs.indiana.edu/pub/faces/index.html to decode picture X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ (Your message of "Sat, 13 Jul 2002 12:04:48 +0900.") <5.1.0.14.2.20020714061849.0391a008@jay.songbird.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_962177079P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 14 Jul 2002 15:28:15 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --==_Exmh_962177079P Content-Type: text/plain; charset=us-ascii On Sun, 14 Jul 2002 06:50:34 +0900, Dave Crocker said: > Ever since multi-recipient addressing was introduced, we have had > downgrading, by virtue of users having to choose the least common > denominator approach to sending attachments. > > So the fact that this new mechanism allows that downgrading to happen later > in the transmission sequence should not confuse anyone into thinking that > downgrading is a new or unusual requirement. My MUA is authorized to make decisions regarding downgrading and choice of C-T-Es for attachments. It listens to my choices regarding base64 versus QP, For the most part, said conversions are lossless (and a few, such as PGP-signing are even information-added), but I have authorized it to do lossy conversions under a a few sets of circumstances, and I *know* about my MUA's actions *before* I hit 'send'. This is not news, and hasn't been for at least a decade. On the other hand, once my MUA hands it to my MTA, *I DO NOT EXPECT THE MTA TO PERFORM LOSSY CONVERSIONS*. Period. End Of Discussion. To quote the 'Security Considerations' of the original draft: 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. Hey hey... What happens if this happens by *ACCIDENT*? Currently, if I think the recipient has color, and I do this, the recipient hopefully gets at least a *warning* "trying to open a color image, converting to gray scale", and can notify me that there was a problem. However, the spec as written doesn't even require that the MTA add a 'X-Downgraded-by:' header, and the recipient has *no clue* that what he received wasn't what I sent. And that, Dave, *IS* a "new and unusual" state of affairs. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_962177079P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE9MdDOcC3lWbTT17ARAvlpAKDPWbCdf9pPf69odeaDZGv/IL8UBQCfRJuY tNa5iVAoWxh1atcLbZtQWx8= =5Hel -----END PGP SIGNATURE----- --==_Exmh_962177079P-- From owner-ietf-fax@mail.imc.org Sun Jul 14 16:13:10 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 QAA15733 for ; Sun, 14 Jul 2002 16:13:10 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g6EJpjv10975 for ietf-fax-bks; Sun, 14 Jul 2002 12:51:45 -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 g6EJphw10966 for ; Sun, 14 Jul 2002 12:51:43 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KK1QGBQWZK0001B1@mauve.mrochek.com> for ietf-fax@imc.org; Sun, 14 Jul 2002 12:51:43 -0700 (PDT) Date: Sun, 14 Jul 2002 12:48:22 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" In-reply-to: "Your message dated Sun, 14 Jul 2002 14:54:11 -0400" <200207141854.g6EIsBCr021519@turing-police.cc.vt.edu> To: ned.freed@mrochek.com Cc: ned+ietf-smtp@mrochek.com, ietf-fax@imc.org, ietf-smtp@imc.org Message-id: <01KK33EBXFUY0001B1@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <5.1.0.14.2.20020713100917.083f42e0@jay.songbird.com> <2679395.1026529873@localhost> <01KK1HVAM6PU000O32@mauve.mrochek.com> <200207141854.g6EIsBCr021519@turing-police.cc.vt.edu> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Private note since this is now entirely off topic... > > I think this is a fine piece of theoretical analysis which unfortunately has no > > applicability to the real world. In the real world directory/database systems > > that let sites provide Internet-wide access to information about their users do > > not deploy. > > > > I'm not sure why this is the case, and indeed I'm fairly sure that there is no > > good reason for it, but a vast tract of experience tells me it for-sure is the > > case. (Now is not the time to get into whys in more detail.) > I'll just add 2 words to the "why" and leave it at that: > "datamining" "spammers". This is the opposite of an explanation, I'm afraid. Techniques for protecting against datamining are well known and widely implemented. In fact it is almost certainly easier to implement them in LDAP than in, say, a Web interface. Yet the former is rarely done, the latter pretty common. Ned From owner-ietf-fax@mail.imc.org Sun Jul 14 16:35:21 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 QAA16242 for ; Sun, 14 Jul 2002 16:35:21 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6EKLkY12109 for ietf-fax-bks; Sun, 14 Jul 2002 13:21:46 -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 g6EKLiw12101 for ; Sun, 14 Jul 2002 13:21:44 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KK1QGBQWZK0001B1@mauve.mrochek.com> for ietf-fax@imc.org; Sun, 14 Jul 2002 13:21:42 -0700 (PDT) Date: Sun, 14 Jul 2002 13:20:41 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" In-reply-to: "Your message dated Sun, 14 Jul 2002 12:48:22 -0700 (PDT)" <01KK33EBXFUY0001B1@mauve.mrochek.com> To: ned.freed@mrochek.com Cc: ietf-fax@imc.org, ietf-smtp@imc.org Message-id: <01KK34GHDJA40001B1@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <5.1.0.14.2.20020713100917.083f42e0@jay.songbird.com> <2679395.1026529873@localhost> <01KK1HVAM6PU000O32@mauve.mrochek.com> <200207141854.g6EIsBCr021519@turing-police.cc.vt.edu> <01KK33EBXFUY0001B1@mauve.mrochek.com> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT My apologies, I intended to edit the cc list but neglected to do so. Ned > Private note since this is now entirely off topic... > > > I think this is a fine piece of theoretical analysis which unfortunately has no > > > applicability to the real world. In the real world directory/database systems > > > that let sites provide Internet-wide access to information about their users do > > > not deploy. > > > > > > I'm not sure why this is the case, and indeed I'm fairly sure that there is no > > > good reason for it, but a vast tract of experience tells me it for-sure is the > > > case. (Now is not the time to get into whys in more detail.) > > I'll just add 2 words to the "why" and leave it at that: > > "datamining" "spammers". > This is the opposite of an explanation, I'm afraid. Techniques for protecting > against datamining are well known and widely implemented. In fact it is almost > certainly easier to implement them in LDAP than in, say, a Web interface. Yet > the former is rarely done, the latter pretty common. > Ned From owner-ietf-fax@mail.imc.org Sun Jul 14 21:14:47 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 VAA23320 for ; Sun, 14 Jul 2002 21:14:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6F0uZl18048 for ietf-fax-bks; Sun, 14 Jul 2002 17:56:35 -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 g6F0uDw18034; Sun, 14 Jul 2002 17:56:13 -0700 (PDT) Received: from BBFUJIP.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 SAA08874; Sun, 14 Jul 2002 18:03:10 -0700 Message-Id: <5.1.0.14.2.20020715093959.01d4f040@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 15 Jul 2002 09:56:00 +0900 To: John C Klensin From: Dave Crocker Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" Cc: iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org In-Reply-To: <8671231.1026656568@[192.168.3.186]> References: <5.1.0.14.2.20020714061849.0391a008@jay.songbird.com> <5.1.0.14.2.20020714061849.0391a008@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: At 02:22 PM 7/14/2002 -0400, John C Klensin wrote: >First of all, I don't find, anywhere in the document, a statement >that the originator, in attempting to use CONNEG, is authorizing >any intermediate MTA that might touch the message to alter its >content. For a specification that is designed to permit a sending agent to know how to tailor the form of a content, it is difficult to imagine what benefit there can be in having that specification contain a statement saying that an implementation is "authorized" to tailor the form of that content. > Nor do I find in the "security considerations" an >explanation of that authorization and the associated risks. You clearly have a better sense of this issue than I do, since I do not see that there is a problem. So, feel free to offer some text. > We have >typically tried to keep that transmission stream as opaque to >message content as possible. Yup. It sure is scary to try to do new things. Except when there is a well-established basis for doing them. I am not inclined to dismiss that established basis solely because it came from a non-IETF effort, particularly given the scale of success of that prior work. >But, unless I read the above incorrectly, you are suggesting that > * Hence intermediate/relay MTAs have the right/authority > to make content changes based on their inferences about > what the receiver wants. Let's try to stay on the current topic. Arguing about generic principles and then trying to dismiss current work based on some subtle variation in interpretations of that abstract discussion is not going to be productive. You might want to review prior work on interprocess communication, which explored trade-offs between a "sender makes right" model and a "receiver makes right system". The significant difference between esmtp/connect and multipart/alternative is exactly this distinction. (Hint: sender makes right has nearly always been the preferred IETF choice. esmtp/conneg is sender makes right.) >Could you explain what you did mean? What I mean is very simple: The behavior that is specified in esmtp/conneg is a careful increment in functionality and is based on extensive prior experience and is known to be useful. ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Sun Jul 14 22:38:02 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 WAA26741 for ; Sun, 14 Jul 2002 22:38:02 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6F2FQ819562 for ietf-fax-bks; Sun, 14 Jul 2002 19:15:26 -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 g6F2F7w19546; Sun, 14 Jul 2002 19:15: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 g6F2F6t21062; Sun, 14 Jul 2002 22:15:06 -0400 (EDT) Message-Id: <200207150215.g6F2F6t21062@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: John C Klensin , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" In-reply-to: (Your message of "Mon, 15 Jul 2002 09:56:00 +0900.") <5.1.0.14.2.20020715093959.01d4f040@jay.songbird.com> Date: Sun, 14 Jul 2002 22:15:06 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > At 02:22 PM 7/14/2002 -0400, John C Klensin wrote: > >First of all, I don't find, anywhere in the document, a statement > >that the originator, in attempting to use CONNEG, is authorizing > >any intermediate MTA that might touch the message to alter its > >content. > > For a specification that is designed to permit a sending agent to know how > to tailor the form of a content, it is difficult to imagine what benefit > there can be in having that specification contain a statement saying that > an implementation is "authorized" to tailor the form of that content. Dave, that may be what your specification is *designed* to do. It is not what your specification *does*, except in the rare case where the sender's UA is able to communicate directly with the recipient's MX. And the sender's UA is the only "agent" that is typically under control of the sender. > > Nor do I find in the "security considerations" an > >explanation of that authorization and the associated risks. > > You clearly have a better sense of this issue than I do, since I do not see > that there is a problem. > > So, feel free to offer some text. How about this: This extension MUST NOT be used by any SMTP client which is not authorized to perform conversion by either the sender or the recipient of the message. > > We have > >typically tried to keep that transmission stream as opaque to > >message content as possible. > > Yup. It sure is scary to try to do new things. > > Except when there is a well-established basis for doing them. > > I am not inclined to dismiss that established basis solely because it came > from a non-IETF effort, particularly given the scale of success of that > prior work. Nor, apparently, are you inclined to cite that established basis. Perhaps it is because it is not applicable? > >But, unless I read the above incorrectly, you are suggesting that > > * Hence intermediate/relay MTAs have the right/authority > > to make content changes based on their inferences about > > what the receiver wants. > > Let's try to stay on the current topic. Yes, lets. Why don't you actually address these technical criticisms of your proposal rather than disingenenously pretending that they don't apply? > What I mean is very simple: > > The behavior that is specified in esmtp/conneg is a careful > increment in functionality and is based on extensive prior experience and > is known to be useful. Dave, unless you can actually cite relevant experience in the field of multi-hop, store-and-forward multimedia messaging, I see no reason why we should not conclude that you have no basis whatsoever for claiming that your current proposal is worth any more consideration. Keith From owner-ietf-fax@mail.imc.org Mon Jul 15 01:07:34 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 BAA01398 for ; Mon, 15 Jul 2002 01:07:33 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g6F4quB22438 for ietf-fax-bks; Sun, 14 Jul 2002 21:52:56 -0700 (PDT) Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6F4qsw22433; Sun, 14 Jul 2002 21:52:54 -0700 (PDT) Received: from [192.168.1.3] (ool-18e43cab.dyn.optonline.net [24.228.60.171]) by mail1.panix.com (Postfix) with ESMTP id 462DC4878B; Mon, 15 Jul 2002 00:52:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: hal9001@popserver.panix.com Message-Id: In-Reply-To: <5.1.0.14.2.20020714061849.0391a008@jay.songbird.com> References: <(Your message of "Sat, 13 Jul 2002 12:04:48 +0900.") <5.1.0.14.2.20020713100917.083f42e0@jay.songbird.com> <5.1.0.14.2.20020714061849.0391a008@jay.songbird.com> X-Mailer: Eudora Pro 5.1.1b22 PPC (Macintosh) Date: Mon, 15 Jul 2002 00:06:57 -0400 To: iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org From: "Robert A. Rosenberg" Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" 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 06:50 +0900 on 07/14/2002, Dave Crocker wrote about Re: Keywords for "SMTP Service Extension for Content N: > >if the message being transmitted is a fax and all recipients are capable >>of fax, >>then perhaps it is acceptable to downgrade the message to a lower quality fax >>format which is acceptable to all. > >Ever since multi-recipient addressing was introduced, we have had >downgrading, by virtue of users having to choose the least common >denominator approach to sending attachments. > >So the fact that this new mechanism allows that downgrading to happen later >in the transmission sequence should not confuse anyone into thinking that >downgrading is a new or unusual requirement. ? There are ways of delaying the downgrading until the recipient has actually received the content (and thus gets the message they would have received if they were the sole addressee). One that is obvious is the use of Multi-Part/Alternative. The sender creates the "downgraded" versions that are acceptable/required and hands the full set off to EACH OF THE RECIPIENTS. Each one then selects the version THEY WANT from the supplied versions without any heavy-handed LCD interference by an intermediary just due to one of the addressees being unwilling/unable to accept one of the "Better" versions. I differentiate this from the type of on-the-fly downgrading that occurs with 8-Bit->QP transforms during relay since the original message CONTENT gets delivered even after the transform (so long as the receiving MUA understands QP) unlike the LCD transform where the original content is replaced with a lower quality LCD version. From owner-ietf-fax@mail.imc.org Mon Jul 15 05:16: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 FAA18422 for ; Mon, 15 Jul 2002 05:16:36 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6F8xjs23709 for ietf-fax-bks; Mon, 15 Jul 2002 01:59:45 -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 g6F8xhw23705 for ; Mon, 15 Jul 2002 01:59:43 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KK3R78E6HS0001B1@mauve.mrochek.com> for ietf-fax@imc.org; Mon, 15 Jul 2002 01:59:37 -0700 (PDT) Date: Mon, 15 Jul 2002 01:39:06 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" In-reply-to: "Your message dated Sun, 14 Jul 2002 12:40:58 -0400" <200207141640.g6EGewt11486@astro.cs.utk.edu> To: Keith Moore Cc: ned.freed@mrochek.com, Keith Moore , ned+ietf-smtp@mrochek.com, John C Klensin , Dave Crocker , Hiroshi Tamura , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org, ktoyoda@rdmg.mgcs.mei.co.jp Message-id: <01KK3UX5K70E0001B1@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <01KK1YUDHRME0001B1@mauve.mrochek.com> <200207141640.g6EGewt11486@astro.cs.utk.edu> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > > The case I was thinking of was the one where caching of conneg information by > > intermediaries eventually brings the information back to the server adjacent to > > the originating client. So the transformation is still done on the originating > > client or on a server very close to it. > I think it's a stretch to believe that caches are going to solve this problem. > It's true that if A keeps sending messages to B then eventually A's MTA will > be able to cache B's recipient information. But this assumes that the > intervening MTAs support CONNEG (and cache CONNEG information) - which itself > seems like a stretch because, as you say, there's no business case for them > doing conversion. What's a stretch is your assumption that caching implies conversion capabilities. They are completely different activities. Conversion by an intermediary is a nasty mess, whereas caching conneg information is trivial. > It's also a stretch to believe that this is going to work well > for arbitrary pairs of senders and recipients - it might work for those pairs who > exchange lots of messages, not so well for those pairs that occasionally exchange > messages. That's certainly a possible outcome. But you can game this in all sorts of ways and reach various different conclusions. > And of course there's the problem that CONNEG information can be > expected to change over time, but there's no mechanism in the current proposal > to timeout caches. I've already indicated that I believe conneg information caches are something that needs to be discussed. > Frankly the method of returning capabilities in a bounce > message seems more effective and more reliable because it doesn't rely on > intermedaries. The problem I see with depending on notifications is another one of those "looks good on paper" things: For whatever reason, support for sophisticated handling of notifications has been slow to materialize in user agents. > The only way I see to make the CONNEG SMTP proposal work end-to-end is for > all of the intermediate MTAs (those that don't have direct knowledge of the > recipient capabilities) to open up SMTP connections to the next hop *in real time* - > so when the sender asserts CONNEG in a RCPT command then the MTA has to stop > acting like a relayer and start acting like a proxy - finding a MTA for the > next hop, opening up a connection, sending EHLO and seeing if it supports > CONNEG, sending MAIL and all previous RCPTs, and finally sending the RCPT > that has the CONNEG option, just so that it can propagate the CONNEG response > back to the sender's UA. Even then it will be very slow, it introduces > race conditions due to timeouts, and it still requires all of the intermediate > MTAs to support CONNEG in proxy mode. This scheme was actually discussed and I believe rejected in the FAX WG some time ago. Regardless, I disagree with your assessment that this is a requirement for the present proposal to be effective. > I haven't followed the fax discussions, but weren't the fax people looking for > a mechanism that would work predictably and reliably - e.g. if sender and > recipient both have (say) high-res capability then the document is always > transferred in high-res - and a mechanism that would give the sender the option > of requiring that the recipient have certain minimum capabilities before sending > the message? (e.g. don't bother sending if recipient doesn't have color?) > I just don't see a way to make that work through the existing SMTP infrastructure. I'm sure there are plenty of places in the present infrastructure where this scheme won't work well. I'm also sure there are plenty of places where it will. My assessment of the notification scheme is roughly the same. And experience should inform us that our ability to predict what portions of the infrastructure will be upgraded is pretty limited. The bottom line is that we're dealing with partial solutions in every case here. This makes it easy to criticize any given scheme. IMO this also makes it very much the WG's call as to how to proceed. Ned From owner-ietf-fax@mail.imc.org Mon Jul 15 09:03:04 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 JAA02898 for ; Mon, 15 Jul 2002 09:03:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6FCkSB12212 for ietf-fax-bks; Mon, 15 Jul 2002 05:46:28 -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 g6FCjnw12125; Mon, 15 Jul 2002 05:45:49 -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 g6FCjbt07614; Mon, 15 Jul 2002 08:45:38 -0400 (EDT) Message-Id: <200207151245.g6FCjbt07614@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: ned.freed@mrochek.com cc: Keith Moore , ned+ietf-smtp@mrochek.com, John C Klensin , Dave Crocker , Hiroshi Tamura , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org, ktoyoda@rdmg.mgcs.mei.co.jp Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" In-reply-to: (Your message of "Mon, 15 Jul 2002 01:39:06 PDT.") <01KK3UX5K70E0001B1@mauve.mrochek.com> Date: Mon, 15 Jul 2002 08:45:37 -0400 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Regarding caching: I see no problem with MTAs that obtain conneg strings from a database caching those lookups. OTOH I think caching is extremely dubious as a mechanism for propagating conneg strings in the direction from the recipient's MTA to the sender's UA, at the rate of one hop per email message transmitted. > The bottom line is that we're dealing with partial solutions in every case > here. This makes it easy to criticize any given scheme. IMO this also makes it > very much the WG's call as to how to proceed. I think this is quite a reasonable statement if we are talking about a fax-specific extension; less reasonable if we are talking about a generic SMTP extension. And regardless, I think more discussion is needed in the document about which parties have the responsibility for conversion (presumably the sender's UA), and which parties have responsibility for providing recipient information (presumably *all* of the listed MXes for that domain) - this in addition to addressing several other issues that have been raised. Keith From owner-ietf-fax@mail.imc.org Mon Jul 15 20:56: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 UAA22078 for ; Mon, 15 Jul 2002 20:56:32 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g6G0c8s12650 for ietf-fax-bks; Mon, 15 Jul 2002 17:38: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 g6G0c7w12645 for ; Mon, 15 Jul 2002 17:38:07 -0700 (PDT) Received: from BBFUJIP.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 RAA13111 for ; Mon, 15 Jul 2002 17:45:12 -0700 Message-Id: <5.1.0.14.2.20020715071730.03b760e0@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 16 Jul 2002 09:37:14 +0900 To: "IETF-FAX" From: Dave Crocker Subject: RE: ffpim revised draft In-Reply-To: References: <5.1.0.14.2.20020318161212.05248d80@127.0.0.1> 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, I am reviewing comments on the current draft of FFPIM and want to ask the working group to resolve any of the normative issues: At 11:08 AM 3/19/2002 -0800, Dan Wing wrote: >Is there really an expectation that TIMELY will be implemented when >DSN hasn't been implemented in all these years? I mean to say, why >does 3.0 require support of TIMELY, but doesn't require support >of NOTARY (DSN)? Dan is asking a very important, basic question: Should FFPIM rely on any features being implemented as ESMTP options? That is, should we permit any FFPIM features that use ESMTP options be a MUST requirement or would it be better (safer) to make them SHOULD or MAY? Features that use ESMTP options are relying on a change to the SMTP infrastructure. All SMTP systems between the originator and the recipient must be changes, for the ESMTP option to work properly. Therefore, an ESMTP option must reach universal deployment, to be of use for the general Internet. As Dan observes, there is significant risk in specifying this dependency. (There is, perhaps, a counter-argument which says that the way to get things implemented is to increase the pressure for them, by making them a MUST. I believe that such "de jure" pressure is usually not successful for IETF standards, but that is only my own opinion.) >Section 5 says that FFPIM is an extension of both RFC2305 and >RFC2532. Does this mean that an FFPIM implementation must >conform to RFC2305 and RFC2532? If so, FFPIM doesn't state >that anywhere but in section 5, which is the security section. OK. I am adding language that says explicitly that FFPIM implementations must conform to RFC2305 and RFC2532. Is this acceptable to the working group? d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Tue Jul 16 00:24: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 AAA28413 for ; Tue, 16 Jul 2002 00:24:54 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g6G497j17188 for ietf-fax-bks; Mon, 15 Jul 2002 21:09:07 -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 g6G489w17159; Mon, 15 Jul 2002 21:08:09 -0700 (PDT) Received: from 208.184.79.252.songbird.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 SMTP id VAA19077; Mon, 15 Jul 2002 21:15:15 -0700 X-Authentication-Warning: joy.songbird.com: 208.184.79.252.songbird.com [208.184.79.252] (may be forged) didn't use HELO protocol Message-Id: <5.1.0.14.2.20020716130629.01de2a08@jay.songbird.com> X-Sender: dave@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 16 Jul 2002 13:07:55 +0900 To: ietf-smtp@imc.org From: Dave Crocker Subject: conneg for better mailing list formats 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: References to the relationship between multipart/alternative and use of Conneg have triggered a possibility that I'd like to explore: We currently have many mailing lists that permit html content and many that do not. Most of the time, the enforcement of that rule is entirely social, ie, non-computer. There is no protocol support for telling senders what content format is preferred or what format(s) are prohibited. Conneg can fix that. Conneg permits the recipient system to state and enforce content format "permissions". Even better, this can combine with multipart/alternative very constructively. The originator sends multipart/alternative content, such as html and text/plain. The sending MTA invokes conneg and sends only the content format that the receiving mailing list server is willing to accept. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Tue Jul 16 21:57:16 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 VAA07799 for ; Tue, 16 Jul 2002 21:57:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6H1VNq10591 for ietf-fax-bks; Tue, 16 Jul 2002 18:31:23 -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 g6H1VMw10587 for ; Tue, 16 Jul 2002 18:31:22 -0700 (PDT) Received: from BBFUJIP.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 SAA20626; Tue, 16 Jul 2002 18:38:33 -0700 Message-Id: <5.1.0.14.2.20020716160513.0300bfc0@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 16 Jul 2002 16:15:12 +0900 To: Graham Klyne From: Dave Crocker Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" Cc: ietf-fax@imc.org In-Reply-To: <5.1.0.14.2.20020714144010.032e3b40@joy.songbird.com> References: <5.1.0.14.2.20020713100917.083f42e0@jay.songbird.com> <20020712191142T.tamura@toda.ricoh.co.jp> 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 03:06 PM 7/14/2002 +0100, Graham Klyne wrote: >I'm uneasy about (appearing to) equate fax-specific with just T.30 -- I >think your last sentence carries the intent if not the desired precision >-- maybe: >[[ >"fax-specific" refers to email enhancements that permit email to >negotiate, transmit and confirm the transfer of images in timely fashion, >like traditional fax. My use of the T.30 term was intentional. I believe it is precise, complete and correct. It is THE technical definition of the world's use of the term "facsimile". Or at least, that is my understanding. If I am wrong, we should get a precise, complete, technical definition that IS correct from the folks who know such things. In other words, my intent was to use "fax" as a technical term, rather than a more general term describing a concept or service. It's not that the latter is irrelevant, but rather that it invites fuzziness and debate. >>>- multi-recipient >> >>Internet mail permits a message to be addressed to more than one >>person. For example, see the To and CC fields of this message. T.30 >>permits addressing a single receiving device. Some fax store-and-forward >>services permit the sender to specify more than one receiver. This is >>multi-recipient. > >If you mention fax store-and-forward, I'd suggest a comment to the effect >that such services behave in a fashion more like ordinary email than fax. Well, no. They negotiate content, during the T.30 phase of communication. And that phase is, of course, strictly one addressee per copy of the content. >>>- LCD >> >>Least Common Denominator. So, we are borrowing a term from math, to >>apply to our discussion of ESMTP/CONNEG, it is possible to receive CONNEG >>parameters for multiple recipients. If the recipients have different >>capabilities, what capabilities should the sender use? One possibility >>is to end the current SMTP session and then send each recipient the best >>content they can receive. Another possibility is to find the >>"intersection" of capabilities for all the recipients and send this >>"least common denominator" or "most common format" to all of the >>recipients at once. > >This term has often puzzled me as being incorrect in its mathematical >allusion. The terms "greatest common divisor" or "highest common factor" >seem more apposite. I agree but dislike those terms. They sound yucky. (Or perhaps it will be more constructive for me to note that they are not in common use and hence will have no intuitive appeal.) Can someone suggest a term that is more palatable? >>The primary difference between relaying versus direct is that relaying >>might take much longer. Therefore the sender does not know when it will >>receive a response. >> >>On the Internet, a direct connection usually has a response time of a few >>minutes, maximum. Normally it is much shorter, of course. For email >>relaying, response time can be days, not minutes. This difference in >>latency requires different design choices. > >I think there's a more fundamental architectural issue that is exploited >by traditional fax operating in a non-relay mode: normal operation >requires that the sender can receive some indication from the receiver >before it starts to send any actual data. You are saying that this is different from getting a 250 in response to an RCPT? How is it different? d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Wed Jul 17 05:21:08 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 FAA10795 for ; Wed, 17 Jul 2002 05:21:07 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6H95qE16966 for ietf-fax-bks; Wed, 17 Jul 2002 02:05:52 -0700 (PDT) Received: from lancelot.crf.canon.fr (lancelot.crf.canon.fr [194.2.158.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6H95ow16962 for ; Wed, 17 Jul 2002 02:05:50 -0700 (PDT) Received: (from smap@localhost) by lancelot.crf.canon.fr (8.11.4/8.11.4) id g6H93fQ03202 for ; Wed, 17 Jul 2002 11:03:41 +0200 (MEST) X-Authentication-Warning: lancelot.crf.canon.fr: smap set sender to using -f Received: from soleil.crf.canon.fr( 194.2.81.249) by lancelot via smap (V2.0beta) id xma003181; Wed, 17 Jul 02 11:03:12 +0200 Received: from crf.canon.fr ([32.238.75.2]) by soleil.crf.canon.fr (Netscape Messaging Server 4.15) with ESMTP id GZDYEX00.AVT; Wed, 17 Jul 2002 11:01:45 +0200 Message-ID: <3D353360.4FA7C077@crf.canon.fr> Date: Wed, 17 Jul 2002 11:05:36 +0200 From: "MAEDA Toru" Organization: Canon Reseach Centre France X-Mailer: Mozilla 4.78 [ja] (Windows NT 5.0; U) X-Accept-Language: ja MIME-Version: 1.0 To: Dave Crocker CC: Graham Klyne , ietf-fax@imc.org Subject: Re: Keywords for "SMTP Service Extension for ContentNegotiation" References: <5.1.0.14.2.20020713100917.083f42e0@jay.songbird.com> <20020712191142T.tamura@toda.ricoh.co.jp> <5.1.0.14.2.20020716160513.0300bfc0@jay.songbird.com> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Dave-san Dave Crocker wrote: > > At 03:06 PM 7/14/2002 +0100, Graham Klyne wrote: > >I'm uneasy about (appearing to) equate fax-specific with just T.30 -- I > >think your last sentence carries the intent if not the desired precision > >-- maybe: > >[[ > >"fax-specific" refers to email enhancements that permit email to > >negotiate, transmit and confirm the transfer of images in timely fashion, > >like traditional fax. > > My use of the T.30 term was intentional. I believe it is precise, complete > and correct. It is THE technical definition of the world's use of the term > "facsimile". > ITU-T T.30 defines only the protocol for Group 3 facsimile. In general, there are many Group 3 facsimie and some Group 4. It is very hard to implement traditional Group 3 facsimle protocol over E-mail environment, realizing capability negotiation and confirmation same level as fax. Regards. Toru Maeda -- *********************************** MAEDA TORU Canon Research Centre France S.A.S. *********************************** From owner-ietf-fax@mail.imc.org Wed Jul 17 23:05:51 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 XAA09137 for ; Wed, 17 Jul 2002 23:05:51 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g6I2lhr09022 for ietf-fax-bks; Wed, 17 Jul 2002 19:47:43 -0700 (PDT) Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6I2lgw09017 for ; Wed, 17 Jul 2002 19:47:42 -0700 (PDT) Received: from [192.168.1.3] (ool-18e43cab.dyn.optonline.net [24.228.60.171]) by mail2.panix.com (Postfix) with ESMTP id 424628F77; Wed, 17 Jul 2002 22:47:45 -0400 (EDT) Mime-Version: 1.0 X-Sender: hal9001@popserver.panix.com Message-Id: In-Reply-To: <5.1.0.14.2.20020716160513.0300bfc0@jay.songbird.com> References: <5.1.0.14.2.20020713100917.083f42e0@jay.songbird.com> <20020712191142T.tamura@toda.ricoh.co.jp> <5.1.0.14.2.20020716160513.0300bfc0@jay.songbird.com> X-Mailer: Eudora Pro 5.1.1b22 PPC (Macintosh) Date: Wed, 17 Jul 2002 22:46:16 -0400 To: Dave Crocker From: "Robert A. Rosenberg" Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" Cc: Graham Klyne , ietf-fax@imc.org 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 16:15 +0900 on 07/16/2002, Dave Crocker wrote about Re: Keywords for "SMTP Service Extension for Content N: > >>>- multi-recipient >>> >>>Internet mail permits a message to be addressed to more than one >>>person. For example, see the To and CC fields of this message. T.30 >>>permits addressing a single receiving device. Some fax store-and-forward >>>services permit the sender to specify more than one receiver. This is >>>multi-recipient. >> >>If you mention fax store-and-forward, I'd suggest a comment to the effect >>that such services behave in a fashion more like ordinary email than fax. > >Well, no. They negotiate content, during the T.30 phase of communication. >And that phase is, of course, strictly one addressee per copy of the content. To evaluate this comparison you have to look at the equivalent situations. The Emailing of a multi-recipient Fax Message is most closely equivalent to using Fax Machine that has an Address book that can assign a delivery list to an entry (IOW: Select this entry and it will dial each phone number in order and deliver a copy of the fax) and will read and cache/buffer the full fax into memory so it can send from the memory instead of reading/feeding the pages in real time [as it is transmitting]. Yes - it will negotiate the content (Speed/Resolution) separately for each connection but then that is what is supported to be happening with a multi-recipient Fax Message. From owner-ietf-fax@mail.imc.org Wed Jul 17 23:44:03 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 XAA09833 for ; Wed, 17 Jul 2002 23:44:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6I3RYS09962 for ietf-fax-bks; Wed, 17 Jul 2002 20:27:34 -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 g6I3RWw09954 for ; Wed, 17 Jul 2002 20:27:32 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KK766SYCRK0001B1@mauve.mrochek.com> for ietf-fax@imc.org; Wed, 17 Jul 2002 20:27:19 -0700 (PDT) Date: Wed, 17 Jul 2002 20:15:06 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" In-reply-to: "Your message dated Wed, 17 Jul 2002 22:35:21 -0400" To: "Robert A. Rosenberg" Cc: Keith Moore , John C Klensin , Dave Crocker , Hiroshi Tamura , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org, ktoyoda@rdmg.mgcs.mei.co.jp Message-id: <01KK7Q77O3KS0001B1@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <01KK1YUDHRME0001B1@mauve.mrochek.com> <200207141640.g6EGewt11486@astro.cs.utk.edu> <01KK3UX5K70E0001B1@mauve.mrochek.com> Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > At 01:39 -0700 on 07/15/2002, ned.freed@mrochek.com wrote about Re: > Keywords for "SMTP Service Extension for Content Ne: > > > Frankly the method of returning capabilities in a bounce > >> message seems more effective and more reliable because it doesn't rely on > >> intermedaries. > > > >The problem I see with depending on notifications is another one of those > >"looks good on paper" things: For whatever reason, support for sophisticated > >handling of notifications has been slow to materialize in user agents. > Agreed. OTOH, since the client is going to have to handle CONNEG in > any case, adding a notification parser to the mix as part of the > CONNEG implementation is a different issue since it is not adding the > notification parser to existent support but adding new support that > INCLUDES a notification parser as part of its implementation > requirements. Note that I am not advocating or rejecting a > notification parser solution but only pointing out what I perceive as > a fallacy in your analysis of the issue. I'm not entirely clear on what you're driving at here, but regardless: My point was and is that resistance against doing certain things in certain ways can be a lot higher than you'd ever expect it to be, to the point where things just don't get implemented or deployed. There are all sorts of good reasons to parse DSNs. But despite the multiple advantages this capability provides it hasn't materialized in a lot of places where you'd expect it to. Indeed, what has happened in some of those cases is that some quite extraordinary kludges have been adopted instead. I'm guilty of this myself to some extent, I guess: MIXER-compliant X.400 gateways require DSN parsing, but back when I coded such things this capability was the absolute last thing I added. I still cannot explain the reluctance. This just isn't rocket science. Ned From owner-ietf-fax@mail.imc.org Wed Jul 17 23:56:38 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 XAA09138 for ; Wed, 17 Jul 2002 23:05:51 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6I2lps09028 for ietf-fax-bks; Wed, 17 Jul 2002 19:47:51 -0700 (PDT) Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6I2low09023; Wed, 17 Jul 2002 19:47:50 -0700 (PDT) Received: from [192.168.1.3] (ool-18e43cab.dyn.optonline.net [24.228.60.171]) by mail2.panix.com (Postfix) with ESMTP id 5C0148EFC; Wed, 17 Jul 2002 22:47:43 -0400 (EDT) Mime-Version: 1.0 X-Sender: hal9001@popserver.panix.com Message-Id: In-Reply-To: <01KK3UX5K70E0001B1@mauve.mrochek.com> References: <01KK1YUDHRME0001B1@mauve.mrochek.com> <200207141640.g6EGewt11486@astro.cs.utk.edu> <01KK3UX5K70E0001B1@mauve.mrochek.com> X-Mailer: Eudora Pro 5.1.1b22 PPC (Macintosh) Date: Wed, 17 Jul 2002 22:35:21 -0400 To: ned.freed@mrochek.com From: "Robert A. Rosenberg" Subject: Re: Keywords for "SMTP Service Extension for Content Negotiation" Cc: Keith Moore , ned.freed@mrochek.com, ned+ietf-smtp@mrochek.com, John C Klensin , Dave Crocker , Hiroshi Tamura , iesg@ietf.org, ietf-fax@imc.org, ietf-smtp@imc.org, ktoyoda@rdmg.mgcs.mei.co.jp 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 01:39 -0700 on 07/15/2002, ned.freed@mrochek.com wrote about Re: Keywords for "SMTP Service Extension for Content Ne: > > Frankly the method of returning capabilities in a bounce >> message seems more effective and more reliable because it doesn't rely on >> intermedaries. > >The problem I see with depending on notifications is another one of those >"looks good on paper" things: For whatever reason, support for sophisticated >handling of notifications has been slow to materialize in user agents. Agreed. OTOH, since the client is going to have to handle CONNEG in any case, adding a notification parser to the mix as part of the CONNEG implementation is a different issue since it is not adding the notification parser to existent support but adding new support that INCLUDES a notification parser as part of its implementation requirements. Note that I am not advocating or rejecting a notification parser solution but only pointing out what I perceive as a fallacy in your analysis of the issue. From owner-ietf-fax@mail.imc.org Thu Jul 18 05:12:55 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 FAA26524 for ; Thu, 18 Jul 2002 05:12:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6I8uI114084 for ietf-fax-bks; Thu, 18 Jul 2002 01:56:18 -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 g6I8uGw14080 for ; Thu, 18 Jul 2002 01:56:16 -0700 (PDT) Date: Thu, 18 Jul 2002 10:31:32 +0100 To: um@snowshore.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: about the charter of Lemonade Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: from: http://www.ietf.org/proceedings/02mar/index.html (VPIM minutes): 3GPP Multimedia Messaging Service - Ileana Leuca gave a presentation that overviewed the choices of messaging technology for the upcoming Release 5. Goal is to merge SMS/EMS with Internet email in the next release. There is a lot of synergy with desired work in Pink Lemonade, and the new WG really needs to investigate PL-MMS interaction. see also: http://www.ietf.org/proceedings/02mar/slides/vpim-3.pdf ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Project Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://security.fi.infn.it/cgi-bin/spgpk.pl?KeyId=0C5C2A09 From owner-ietf-fax@mail.imc.org Mon Jul 22 05:28:38 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 FAA29289 for ; Mon, 22 Jul 2002 05:28:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6M91s527744 for ietf-fax-bks; Mon, 22 Jul 2002 02:01:54 -0700 (PDT) Received: from mac-allocchio3.elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by above.proper.com (8.11.6/8.11.3) with SMTP id g6M91pw27740 for ; Mon, 22 Jul 2002 02:01:52 -0700 (PDT) Received: from mac-allocchio3.elettra.trieste.it (140.105.2.18) by SYNX02 with TCP/IP SMTP; Mon, 22 JUL 02 11:01 CET Date: Mon, 22 Jul 2002 11:01:22 +0200 (CEST) X-X-Sender: To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN From: Claudio Allocchio Subject: short notes from the FAX meeting Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by above.proper.com id g6M91rw27741 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Short notes from the Internet Fax WG meeting Hallo, here are my usual quick short notes about our meeting which was held jointly with the Voice Profile for Internet Mail WG, last Tuesday, July 16 2002. Please drop in your comments/updates. After wecoming the partecipats to his home town Yokohama, Tamura-san proposed to change slightly the order of the agenda discussion, moving the CONNEG and FFPIM topics at the end of the Fax part of the meeting. The change was approved unanimously, in order to allow more space to these topics without compressing the other ones. We also received apologises from Ned Freed who could not be with us, but Patrick Falstrom is here replacing him. Tamura0san 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 and assured the WG that the chairs are taking action with the RFC Editor in order to have the RFC number assigned ASAP (i.e. prior to publication) to the TIFF-FX/TIFF couple of documents. It is needed for reference in oter documents, and by the ITU, too. Following, Tamura-san 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 These ones refer to DSN (RFC1894 update) and to TIFF-FX (draft-ietf-fax-tiff-fx-11.txt). Greg Vaudreuil reported about the status of DSN: after IANA questions were answered in April, and an extended implementation report submitted in early June, the document is currently on IESG table, without any apparent outstanding issue. The AD will check its status, too (see slides). The ID draft-ietf-fax-tiff-fx-11.txt is waitig for the supplementary implementation report to be published (see later on). On the IESG queue (Area Director review stage) we also have draft-ietf-fax-timely-delivery-05.txt. There were no comments and modification since the last meetings, thus we just wait for the AD review and for the reference to draft-vaudreuil-1983ext-01.txt to be solved. The latter status was also updated by Greg: very similar situation than DNS, no outstanding issues, and waiting for AD review before going to the IESG table. The discussion then moved to the TIFF-FX implementation report. The original report and the additional (new) report to be submitted. Tamura-san explained (see slides) that the CIAJ (Communications and Information network Association of Japan), whose members practically contain all the fax manufactures, agreed to perform an extended further IFax and TIFF-FX implementation test, to supplement the original report already submitted in 2001 for Profile S, F and J. In the TIFF-FX and IFax test are taking part 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 testing for Profile C was done successfully last month, and the remains will be done by the end of August. The supplementary report will include Specified product name, Supported tag information, License validation for some profiles, and will be submitted by the end of September. Patrik explicitly reminded that the license statement should specify that the company has exercised also the proof of "independend licensing" in implementing their products. Claudio then made a short report About the addressing (draft-allocchio-gstn-03.txt) 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 reccommended (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. Toyoda-san reported on the ID in preparation to register IFax service in ENUM with IANA. 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 then used in accordance with “Simple Mode” RFC2305, “Extended Mode” RFC2532 or FF 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, and now the final decsion will be taken on the mailing list. Thus the Ifax ENUM ID 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 hyerarchical syntax for the resource record data fields. Patrik and the WG asked the editor now to submit the text of the ID, and discuss it within the FAX WG, with CC to the ENUM mailing list. Toyoda-san will do it within a short time. The next ITU-T SG16 meeting is planned for October 2002. Tamura-san will report there about our activities. As a WG the documents which are referenced by ITU-T documents and need some processing are: “image/tiff” MIME Sub-type Registra “image/tiff-fx” MIME Sub-type Registration Implementers Guide where we are asking the RFC Editor 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. Claudio passed then to summarize 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 (please note the new version at http://www.brandenburg.com/specifications/draft-ietf-fax-esmtp-conneg-03.txt 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 layreing 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 this introduction Dave 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 mihgt not be the case in all possible circumstances, but it will quite well fit the model. Furthermore, most of the Ifax traffic whould be point to point, without relaying. There were comment reminding that in most of the corporate cases, this might turne false, as filrewalls 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 behavihours 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 purpouses, incliding VPIM, MIME etc... Solving the basic philosophycal problem thus requires the involvement of the whole SMTP area epxertise people, and not only the FAX WG. The debate on this should this 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 (lemonade). 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 be issue first another command, and then when capabolities fo 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 singl command (RCPT TO) is used to ask and discover capabilities of the recipient MUA, while Greg 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, approch. Patrik reminded that Ned commented a lot on this topic, and at the end asked the WG to come to a conclusion on this two alternates. Harald, 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 whould 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 this the SMTP world is mostly "one recipient per MTA" when there is not a firewall or similar security measires 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 ming 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. After more that 45 minutes of debate we moved to the next topic, FFPIM. Dave 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? - FPIM conformance require RFC2305 and RFC2532 conformance? as there was no clear opinion of those presents, there questions are now taken to the mailing list for final decsion. More over, the document refers to CONNEG specification. It was agreed that the CONNEG text should be more detailed, and that we should of course adapt it to the output of the dicussion about it. At this point we handed over to VPIM agenda points, and Glenn Parsons chaired the rest of the meeting. Note that the FAX and VPIM WGs confirmed their will to continue with joint meetings until all their work is finished, and thus will meet agin together in Atlanta, in November 2002. ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Project Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://security.fi.infn.it/cgi-bin/spgpk.pl?KeyId=0C5C2A09 From owner-ietf-fax@mail.imc.org Mon Jul 22 07:09:56 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 HAA00862 for ; Mon, 22 Jul 2002 07:09:55 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6MAmtv05035 for ietf-fax-bks; Mon, 22 Jul 2002 03:48:55 -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 g6MAmsw05031 for ; Mon, 22 Jul 2002 03:48:54 -0700 (PDT) Received: from GK-VAIO.ninebynine.org (dyn242-41.sftm-212-159.plus.net [212.159.41.242]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g6MAif431804; Mon, 22 Jul 2002 03:44:41 -0700 Message-Id: <5.1.0.14.2.20020722110958.0381f830@127.0.0.1> X-Sender: gk-lists@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 22 Jul 2002 11:10:47 +0100 To: Claudio Allocchio From: Graham Klyne Subject: Re: short notes from the FAX meeting Cc: In-Reply-To: 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 11:01 AM 7/22/02 +0200, Claudio Allocchio wrote: > - FPIM conformance require RFC2305 and RFC2532 conformance? > >as there was no clear opinion of those presents, there questions are now >taken to the mailing list for final decsion. My recollection was that Dave (the editor) suggested RFC2305/2532 compliance would be required, and that there was no dissent. #g ------------------- Graham Klyne From owner-ietf-fax@mail.imc.org Mon Jul 22 14:20:44 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 OAA24633 for ; Mon, 22 Jul 2002 14:20:44 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g6MHuCa26310 for ietf-fax-bks; Mon, 22 Jul 2002 10:56:12 -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 g6MHuAw26300 for ; Mon, 22 Jul 2002 10:56:10 -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 LAA30122; Mon, 22 Jul 2002 11:03:50 -0700 Message-Id: <5.1.1.2.2.20020722105148.034a64d0@jay.songbird.com> X-Sender: dcrocker@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Mon, 22 Jul 2002 10:55:52 -0700 To: Graham Klyne From: Dave Crocker Subject: Re: short notes from the FAX meeting Cc: Claudio Allocchio , In-Reply-To: <5.1.0.14.2.20020722110958.0381f830@127.0.0.1> References: 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 11:10 AM 7/22/2002 +0100, Graham Klyne wrote: >At 11:01 AM 7/22/02 +0200, Claudio Allocchio wrote: >> - FPIM conformance require RFC2305 and RFC2532 conformance? >> >>as there was no clear opinion of those presents, there questions are now >>taken to the mailing list for final decsion. > >My recollection was that Dave (the editor) suggested RFC2305/2532 >compliance would be required, and that there was no dissent. That is Dave's recollection, also. (To be specific: I considered this requirement to be obviously necessary -- it is difficult to imagine how the new specification would operate, without conformance to its predecessors -- and so I presented this as a "default yes" choice. This was intended to resolve this issue efficiently. Hence, the position was that we would make this change, unless someone objected. I do not recall hearing anyone object. As but a lowly document editor, obviously I do not decide the decision process, and most certainly defer to the wise insight of the working group chairs on this matter... d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.850.1850 From owner-ietf-fax@mail.imc.org Mon Jul 22 20:09: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 UAA24405 for ; Mon, 22 Jul 2002 20:09:22 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6MNmTA11683 for ietf-fax-bks; Mon, 22 Jul 2002 16:48:29 -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 g6MNmRw11679 for ; Mon, 22 Jul 2002 16:48:28 -0700 (PDT) Received: from azteca.isd.ricoh.co.jp (IDENT:mirapoint@[133.139.250.74]) by mail.notes.ricoh.co.jp (8.11.6/3.7W) id g6MNmGF07765; Tue, 23 Jul 2002 08:48:16 +0900 Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by azteca.isd.ricoh.co.jp (Mirapoint) with ESMTP id ADC43345; Tue, 23 Jul 2002 08:48:15 +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 IAA05847; Tue, 23 Jul 2002 08:43:45 +0900 (JST) To: dcrocker@brandenburg.com Cc: GK-lists@ninebynine.org, Claudio.Allocchio@garr.it, ietf-fax@imc.org Subject: Re: short notes from the FAX meeting From: Hiroshi Tamura In-Reply-To: <5.1.1.2.2.20020722105148.034a64d0@jay.songbird.com> References: <5.1.0.14.2.20020722110958.0381f830@127.0.0.1> <5.1.1.2.2.20020722105148.034a64d0@jay.songbird.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: <20020723084815V.tamura@toda.ricoh.co.jp> Date: Tue, 23 Jul 2002 08:48:15 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 30 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dave, Graham, Thanks for your comment. > >> - FPIM conformance require RFC2305 and RFC2532 conformance? > >> > >>as there was no clear opinion of those presents, there questions are now > >>taken to the mailing list for final decsion. > > > >My recollection was that Dave (the editor) suggested RFC2305/2532 > >compliance would be required, and that there was no dissent. > > > That is Dave's recollection, also. That's right. > As but a lowly document editor, obviously I do not decide the decision > process, and most certainly defer to the wise insight of the working group > chairs on this matter... It is the dicision at Yokohama meeting. If there is anyone that objects it, please do soon. But, I do not think anyone does. Regards, -- Hiroshi Tamura, Co-chair of IETF-FAX WG tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Mon Jul 22 20:48:59 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 UAA27458 for ; Mon, 22 Jul 2002 20:48:58 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6N0UTu12606 for ietf-fax-bks; Mon, 22 Jul 2002 17:30:29 -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 g6N0URw12601 for ; Mon, 22 Jul 2002 17:30:27 -0700 (PDT) Received: from azteca.isd.ricoh.co.jp (IDENT:mirapoint@[133.139.250.74]) by mail.notes.ricoh.co.jp (8.11.6/3.7W) id g6N0UQF30313; Tue, 23 Jul 2002 09:30:26 +0900 Received: from lily.toda.ricoh.co.jp (lily.toda.ricoh.co.jp [133.139.60.72]) by azteca.isd.ricoh.co.jp (Mirapoint) with ESMTP id ADC45382; Tue, 23 Jul 2002 09:30:25 +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 JAA05873; Tue, 23 Jul 2002 09:25:55 +0900 (JST) To: Claudio.Allocchio@garr.it Cc: ietf-fax@imc.org Subject: Re: short notes from the FAX meeting From: Hiroshi Tamura In-Reply-To: References: 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: <20020723093031K.tamura@toda.ricoh.co.jp> Date: Tue, 23 Jul 2002 09:30:31 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 69 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hallo Claudio, Thanks for your summary. I can use most of them as it is, for the formal report. Comments below. > Tamura0san 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 > > and assured the WG that the chairs are taking action with the RFC Editor > in order to have the RFC number assigned ASAP (i.e. prior to publication) > to the TIFF-FX/TIFF couple of documents. It is needed for reference in > oter documents, and by the ITU, too. I already contacted RFC editors and IANA administrators They are doing now. Regarding content-negotiaion I-D, sooner or later, it will be published. > Following, Tamura-san 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 > > These ones refer to DSN (RFC1894 update) and to TIFF-FX > (draft-ietf-fax-tiff-fx-11.txt). Greg Vaudreuil reported about the status > of DSN: after IANA questions were answered in April, and an extended > implementation report submitted in early June, the document is > currently on IESG table, without any apparent outstanding issue. The > AD will check its status, too (see slides). 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-Ds will finish IETF Last Call sooner or later, while it refers DSN and TIFF-FX. > On the IESG queue (Area Director review stage) we also have > draft-ietf-fax-timely-delivery-05.txt. There were no comments and > modification since the last meetings, thus we just wait for the AD review > and for the reference to draft-vaudreuil-1983ext-01.txt to be solved. The > latter status was also updated by Greg: very similar situation than DNS, > no outstanding issues, and waiting for AD review before going to the IESG > table. Regarding draft-vaudreuil-1983ext-01, it expired last month. After -02 is issued, FAX WG will do WG Last Call. > After more that 45 minutes of debate we moved to the next topic, FFPIM. > Dave 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? > - FPIM conformance require RFC2305 and RFC2532 conformance? I Already commented in another mail. Yes, requirement is our conclusion. -- Hiroshi Tamura, co-chair of IETF-FAX WG tamura@toda.ricoh.co.jp From owner-ietf-fax@mail.imc.org Tue Jul 23 06:07:28 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 GAA04914 for ; Tue, 23 Jul 2002 06:07:27 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g6N9m0G28772 for ietf-fax-bks; Tue, 23 Jul 2002 02:48:00 -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 g6N9lww28767 for ; Tue, 23 Jul 2002 02:47:58 -0700 (PDT) Date: Tue, 23 Jul 2002 11:47:31 +0100 To: Dave Crocker cc: Graham Klyne , Claudio Allocchio , ietf-fax@imc.org In-Reply-To: <5.1.1.2.2.20020722105148.034a64d0@jay.songbird.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: Re: short notes from the FAX meeting Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > That is Dave's recollection, also. > > (To be specific: I considered this requirement to be obviously necessary > -- it is difficult to imagine how the new specification would operate, > without conformance to its predecessors -- and so I presented this as a > "default yes" choice. This was intended to resolve this issue efficiently. > > Hence, the position was that we would make this change, unless someone > objected. I do not recall hearing anyone object. True ! ... but I just followed the rule "the decisions are taken to the mailing list anyhow" :-) ... yes I'm a nasty burocrat! :-) Notes are there to be corrected and amended, is it? thanks Dave! Claudio PS: other comments? addenda? From owner-ietf-fax@mail.imc.org Wed Jul 24 18:15:47 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 SAA04086 for ; Wed, 24 Jul 2002 18:15:45 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6OLqCa00145 for ietf-fax-bks; Wed, 24 Jul 2002 14:52:12 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6OLqAw00141 for ; Wed, 24 Jul 2002 14:52:10 -0700 (PDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6OLpLp01739; Wed, 24 Jul 2002 17:51:22 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jul 2002 17:51:21 -0400 Message-ID: From: "Glenn Parsons" To: "'IETF VPIM List'" , "'ietf-fax@imc.org'" Subject: FW: IESG comments on NOTARY drafts Date: Wed, 24 Jul 2002 17:51:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2335C.056CBB98" Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C2335C.056CBB98 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2335C.056CBB98" ------_=_NextPart_001_01C2335C.056CBB98 Content-Type: text/plain; charset="iso-8859-1" FYI. The authors are revising the DSN documents based on these comments. Cheers, Glenn. > ---------- > From: ned.freed@mrochek.com > Sent: Tuesday, July 23, 2002 9:53 PM > To: moore@cs.utk.edu; gregv@lucent.com; notifications@cs.utk.edu > Cc: ned.freed@mrochek.com; paf@cisco.com; Parsons, Glenn > [CAR:6L81:EXCH]; Claudio.Allocchio@garr.it; tamura@toda.ricoh.co.jp > Subject: IESG comments on NOTARY drafts > > <> > Attached below is feedback from the IESG about these drafts. Everything > but the final note is editorial in nature. > > Ned > > ------_=_NextPart_001_01C2335C.056CBB98 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: IESG comments on NOTARY drafts

FYI.

The authors are = revising the DSN documents based on these comments.

Cheers,
Glenn.

----------
From:   ned.freed@mrochek.com
Sent:   Tuesday, July 23, 2002 9:53 PM
To:     = moore@cs.utk.edu; gregv@lucent.com; = notifications@cs.utk.edu
Cc:     = ned.freed@mrochek.com; paf@cisco.com; = Parsons, Glenn [CAR:6L81:EXCH]; Claudio.Allocchio@garr.it; = tamura@toda.ricoh.co.jp

Subject: =        IESG = comments on NOTARY drafts

= <<ATT597280.txt>>
Attached below is feedback from the = IESG about these drafts. Everything
but the final note is editorial in = nature.

        =         =         =         Ned


------_=_NextPart_001_01C2335C.056CBB98-- ------_=_NextPart_000_01C2335C.056CBB98 Content-Type: text/plain; name="ATT597280.txt" Content-Disposition: attachment; filename="ATT597280.txt" draft-moore-rfc1891bis-00.txt (1) Needs a table of contents (> 15 pages). (2) Split references into normative & non-normative. (3) The doc does not clearly say if it updates/obsoletes 1891. (An Obsoletes: RFC 1891 needs to be added at the beginning.) (4) MUST (etc) used w/o definition. (5) In subfield MUST NOT be "dns". A MTA-name-type subfield value of "- x-local-hostname" is suggested. The extra dash at the end of the line is wrong; it needs to go and the quote should be moved to the following line. (6) The text introducing section 10 (Appendix) is broken where RFC 1891 has backslashes. NOTE: Formatting rules for RFCs require that no line be longer than 72 characters. Therefore, in the following examples, some SMTP commands longer than 72 characters are printed on two lines, with the first line ending in " command would be sent as a single line (i.e. with no embedded CRLFs), and without the " Both of those single '"'s are '"\"' and have more text after them in RFC 1891. draft-vaudreuil-1892bis-01.txt (1) The doc does not clearly say if it updates/obsoletes 1892. (An Obsoletes: RFC 1892 needs to be added at the beginning.) (2) Split references into normative & non-normative. (I believe all of them are normative, so saying that is sufficient.) (3) The [DRPT] reference needs to be changed to refer to draft-moore-rfc1891bis-01.txt. draft-vaudreuil-1893bis-01.txt (1) The doc does not clearly say if it updates/obsoletes 1893. (An Obsoletes: RFC 1893 needs to be added at the beginning.) (2) Split references into normative & non-normative. (3) The [SMTP-CODES] reference makes no sense in this document and should be removed. (Nothing refers to it.) (4) The [DSN] reference needs to refer to draft-vaudreuil-1894bis-01.txt. draft-vaudreuil-1894bis-01.txt (1) The doc does not clearly say if it updates/obsoletes 1894. (An Obsoletes: RFC 1894 needs to be added at the beginning.) (2) Split references into normative & non-normative. (3) The ABNF in section 2.2.3 is broken. It should read: dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name (4) The field value suggested in section 2.2.3 has changed from "smtp" to "dns", which is a valid correction, but this change isn't noted in the change history. Finally, there's the issue I described in an earlier message regarding the ENVID and ORCPT parameters. Specifically, draft-moore-rfc1891bis-00.txt is quite clear that these fields can contain stuff other than ASCII characters: The syntax for "esmtp-value" in [4] does not allow SP, "=", control characters, or characters outside the traditional ASCII range of 1-127 decimal to be transmitted in an esmtp-value. Because the ENVID and ORCPT parameters may need to convey values outside this range, the esmtp-values for these parameters are encoded as "xtext". However, the corresponding Original-Envelope-Id and Original-Recipient fields defined in draft-vaudreuil-1894bis-01.txt are simply *text. This means some encoding must be allowed for. Absent a specification of the encoding to be used there's no way to insure interoperability. There are two ways to solve this: (1) State that ENVID and ORCPT can only contain ASCII text. (2) State that when ENVID and ORCPT values are placed in a DSN they should be encoded. The obvious encoding to use is xtext. FWIW, my own implementation in PMDF does (2). That's it! ------_=_NextPart_000_01C2335C.056CBB98-- From owner-ietf-fax@mail.imc.org Wed Jul 24 19:32:25 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 TAA05791 for ; Wed, 24 Jul 2002 19:32:24 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6ONE9Y03790 for ietf-fax-bks; Wed, 24 Jul 2002 16:14:09 -0700 (PDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6ONE7w03785 for ; Wed, 24 Jul 2002 16:14:07 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g6ONE9E16332; Wed, 24 Jul 2002 16:14:09 -0700 (PDT) Message-Id: <200207242314.g6ONE9E16332@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3297 on Content Negotiation for Messaging Services based on Email Cc: rfc-editor@rfc-editor.org, ietf-fax@imc.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 24 Jul 2002 16:14:08 -0700 Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart 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 This memo describes a content negotiation mechanism for facsimile, voice and other messaging services that use Internet email. Services such as facsimile and voice messaging need to cope with new message content formats, yet need to ensure that the content of any given message is renderable by the receiving agent. The mechanism described here aims to meet these needs in a fashion that is fully compatible with the current behaviour and expectations of Internet email. This document is a product of the Internet Fax Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020724161051.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3297 --OtherAccess Content-Type: Message/External-body; name="rfc3297.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020724161051.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ietf-fax@mail.imc.org Sun Jul 28 13:34:12 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 NAA00176 for ; Sun, 28 Jul 2002 13:34:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6SHFIL12666 for ietf-fax-bks; Sun, 28 Jul 2002 10:15:18 -0700 (PDT) Received: from bta.net.cn (mcard.bta.net.cn [202.106.46.78]) by above.proper.com (8.11.6/8.11.3) with SMTP id g6SHFCw12662 for ; Sun, 28 Jul 2002 10:15:16 -0700 (PDT) Received: from bta.net.cn([10.1.1.78]) by bta.net.cn(AIMC 2.9.5.2) with SMTP id jmc3d44307c; Mon, 29 Jul 2002 01:15:08 +0800 Received: from above.proper.com([208.184.76.45]) by bta.net.cn(AIMC 2.9.5.2) with SMTP id jm513d3f5a58; Thr, 25 Jul 2002 07:14:46 +0800 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6OLqCa00145 for ietf-fax-bks; Wed, 24 Jul 2002 14:52:12 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6OLqAw00141 for ; Wed, 24 Jul 2002 14:52:10 -0700 (PDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6OLpLp01739; Wed, 24 Jul 2002 17:51:22 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jul 2002 17:51:21 -0400 Message-ID: From: "Glenn Parsons" To: "'IETF VPIM List'" , "'ietf-fax@imc.org'" Subject: FW: IESG comments on NOTARY drafts Date: Wed, 24 Jul 2002 17:51:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2335C.056CBB98" List-Archive: List-ID: List-Unsubscribe: Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C2335C.056CBB98 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2335C.056CBB98" ------_=_NextPart_001_01C2335C.056CBB98 Content-Type: text/plain; charset="iso-8859-1" FYI. The authors are revising the DSN documents based on these comments. Cheers, Glenn. > ---------- > From: ned.freed@mrochek.com > Sent: Tuesday, July 23, 2002 9:53 PM > To: moore@cs.utk.edu; gregv@lucent.com; notifications@cs.utk.edu > Cc: ned.freed@mrochek.com; paf@cisco.com; Parsons, Glenn > [CAR:6L81:EXCH]; Claudio.Allocchio@garr.it; tamura@toda.ricoh.co.jp > Subject: IESG comments on NOTARY drafts > > <> > Attached below is feedback from the IESG about these drafts. Everything > but the final note is editorial in nature. > > Ned > > ------_=_NextPart_001_01C2335C.056CBB98 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: IESG comments on NOTARY drafts

FYI.

The authors are = revising the DSN documents based on these comments.

Cheers,
Glenn.

----------
From:   ned.freed@mrochek.com
Sent:   Tuesday, July 23, 2002 9:53 PM
To:     = moore@cs.utk.edu; gregv@lucent.com; = notifications@cs.utk.edu
Cc:     = ned.freed@mrochek.com; paf@cisco.com; = Parsons, Glenn [CAR:6L81:EXCH]; Claudio.Allocchio@garr.it; = tamura@toda.ricoh.co.jp

Subject: =        IESG = comments on NOTARY drafts

= <<ATT597280.txt>>
Attached below is feedback from the = IESG about these drafts. Everything
but the final note is editorial in = nature.

        =         =         =         Ned


------_=_NextPart_001_01C2335C.056CBB98-- ------_=_NextPart_000_01C2335C.056CBB98 Content-Type: text/plain; name="ATT597280.txt" Content-Disposition: attachment; filename="ATT597280.txt" draft-moore-rfc1891bis-00.txt (1) Needs a table of contents (> 15 pages). (2) Split references into normative & non-normative. (3) The doc does not clearly say if it updates/obsoletes 1891. (An Obsoletes: RFC 1891 needs to be added at the beginning.) (4) MUST (etc) used w/o definition. (5) In subfield MUST NOT be "dns". A MTA-name-type subfield value of "- x-local-hostname" is suggested. The extra dash at the end of the line is wrong; it needs to go and the quote should be moved to the following line. (6) The text introducing section 10 (Appendix) is broken where RFC 1891 has backslashes. NOTE: Formatting rules for RFCs require that no line be longer than 72 characters. Therefore, in the following examples, some SMTP commands longer than 72 characters are printed on two lines, with the first line ending in " command would be sent as a single line (i.e. with no embedded CRLFs), and without the " Both of those single '"'s are '"\"' and have more text after them in RFC 1891. draft-vaudreuil-1892bis-01.txt (1) The doc does not clearly say if it updates/obsoletes 1892. (An Obsoletes: RFC 1892 needs to be added at the beginning.) (2) Split references into normative & non-normative. (I believe all of them are normative, so saying that is sufficient.) (3) The [DRPT] reference needs to be changed to refer to draft-moore-rfc1891bis-01.txt. draft-vaudreuil-1893bis-01.txt (1) The doc does not clearly say if it updates/obsoletes 1893. (An Obsoletes: RFC 1893 needs to be added at the beginning.) (2) Split references into normative & non-normative. (3) The [SMTP-CODES] reference makes no sense in this document and should be removed. (Nothing refers to it.) (4) The [DSN] reference needs to refer to draft-vaudreuil-1894bis-01.txt. draft-vaudreuil-1894bis-01.txt (1) The doc does not clearly say if it updates/obsoletes 1894. (An Obsoletes: RFC 1894 needs to be added at the beginning.) (2) Split references into normative & non-normative. (3) The ABNF in section 2.2.3 is broken. It should read: dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name (4) The field value suggested in section 2.2.3 has changed from "smtp" to "dns", which is a valid correction, but this change isn't noted in the change history. Finally, there's the issue I described in an earlier message regarding the ENVID and ORCPT parameters. Specifically, draft-moore-rfc1891bis-00.txt is quite clear that these fields can contain stuff other than ASCII characters: The syntax for "esmtp-value" in [4] does not allow SP, "=", control characters, or characters outside the traditional ASCII range of 1-127 decimal to be transmitted in an esmtp-value. Because the ENVID and ORCPT parameters may need to convey values outside this range, the esmtp-values for these parameters are encoded as "xtext". However, the corresponding Original-Envelope-Id and Original-Recipient fields defined in draft-vaudreuil-1894bis-01.txt are simply *text. This means some encoding must be allowed for. Absent a specification of the encoding to be used there's no way to insure interoperability. There are two ways to solve this: (1) State that ENVID and ORCPT can only contain ASCII text. (2) State that when ENVID and ORCPT values are placed in a DSN they should be encoded. The obvious encoding to use is xtext. FWIW, my own implementation in PMDF does (2). That's it! ------_=_NextPart_000_01C2335C.056CBB98-- From owner-ietf-fax@mail.imc.org Tue Jul 30 08:42: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 IAA15435 for ; Tue, 30 Jul 2002 08:42:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6UCOal19118 for ietf-fax-bks; Tue, 30 Jul 2002 05:24:36 -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 g6UCOYw19113 for ; Tue, 30 Jul 2002 05:24:34 -0700 (PDT) Date: Tue, 30 Jul 2002 14:23:57 +0100 To: Hiroshi Tamura cc: ietf-fax@imc.org, vpim@lists.neystadt.org In-Reply-To: <20020725100220G.tamura@toda.ricoh.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Claudio Allocchio Subject: Slides, please Sender: owner-ietf-fax@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallo, On Thu, 25 Jul 2002, Hiroshi Tamura wrote: > Could you please send all of our slides of Yokohama meeting? I'm still waiting for the following ones: SNAP Slides in order to submit the full bunch together... If the author can just send them to me... than I'll send the full set to minutes@ietf.org and cc to the WGs lists. Regards, Claudio