Re: draft-ietf-fax-esmtp-conneg-08.txt
Keith Moore <moore@cs.utk.edu> Sat, 26 July 2003 04:37 UTC
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6Q4bcqt007797 for <ietf-smtp-bks@above.proper.com>; Fri, 25 Jul 2003 21:37:38 -0700 (PDT) (envelope-from owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6Q4bcgk007796 for ietf-smtp-bks; Fri, 25 Jul 2003 21:37:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f
Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6Q4bXqt007791; Fri, 25 Jul 2003 21:37:34 -0700 (PDT) (envelope-from moore@cs.utk.edu)
Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19gGoB-0005I2-00; Fri, 25 Jul 2003 21:37:27 -0700
Date: Sat, 26 Jul 2003 00:36:33 -0400
From: Keith Moore <moore@cs.utk.edu>
To: Hiroshi Tamura <tamura@toda.ricoh.co.jp>
Cc: moore@cs.utk.edu, ietf-smtp@imc.org, ietf-fax@imc.org, dcrocker@brandenburg.com, toyoda.kiyoshi@jp.panasonic.com
Subject: Re: draft-ietf-fax-esmtp-conneg-08.txt
Message-Id: <20030726003633.4be48d49.moore@cs.utk.edu>
In-Reply-To: <20030626.085226.01368429.tamura@toda.ricoh.co.jp>
References: <20030626.085226.01368429.tamura@toda.ricoh.co.jp>
X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>
Sorry to take so long, but I was finally able to read this. I believe the basic design of this extension is sound, in that it requires both consent from the originator and knowledge of recipient capabilities before an intermediary can perform conversion, it allows the originator to each specify what conversions may be performed, and it provides an indication to the recipient when conversions were performed, and by whom. 1. My biggest concern is that for a message for which CONPERM is asserted, either the absence of an unbroken chain of CONPERM-capable relays or the absence of CONNEG for a recipient is (apparently) treated as an indication that the recipient cannot accept any kind of content - forcing a delivery failure. (Either that or the assertion of CONPERM is not only "permission" from the sender for intermediaries to perform content conversion, but also a request that the sender not deliver messages which are not known to be acceptable to the recipient, which seems like an inappropriate binding of two unrelated requests.) This is not backward-compatible with the installed base. The extention should allow sending of the same message to multiple recipients, some of which can be sent through CONPERM-capable servers and some of which cannot, some of which support CONNEG and some of which do not, without requiring the originating MTA or UA to put each recipient's message in a separate envelope and without requiring the originating MTA or UA to know in advance which recipients' delivery paths support CONPERM/CONNEG and which do not. It is especially unreasonable to bounce a message in the absence of CONNEG given that there is currently no standard mechanism by which a recipient can indicate his CONNEG preferences/capabilities to upstream SMTP servers. The current definition of this extension makes it essentially useless when attempting to send mail to any recipient that is not known in advance to support CONPERM/CONNEG. I believe the absence of CONNEG information for a recipient should be treated as if the recipient can support any kind of content, or (more realistically) that the recipient will either perform any needed conversions or bounce the message. This would be compatible with well-established SMTP behavior. The absence of CONPERM in a downstream server should be treated similarly. (Note that the recipient does not require sender authorization to perform conversions on messages he receives; sender authorization should only be required for intermediaries. Therefore conversions _by the recipient_ are still possible even if CONPERM is not asserted by the relay.) 2. Another concern is the handling of messages when the relay which is expected to provide a conversion (in that it has both CONPERM and CONNEG for the recipients) is unable to perform one or more of the conversions required. I believe the appropriate behavior is for a relay to perform those conversions which it is able to perform, and to relay the message (with CONPERM asserted, if possible) to the next hop. It is possible that subsequent hops may be able to perform the other conversions. Only if it is _known_ (via CONNEG) that the message cannot be converted into a form acceptable to a recipient should it be bounced. Indeed, it is in a sender's interest to have his outbound mail transmitted through relays that can convert the sender's unique formats to more commonly-used formats; and it is in the recipient's interests to have his inbound mail MX'ed through relays that are capable of converting common formats to those which he can use. We should not expect all conversions to be performed at the same hop. And in general it seems better to assume that a conversion might be perfomed later than to cause a delivery failure simply because an intermediary cannot perform every conversion that is needed. Perhaps it is assumed that all conversions will be performed "close to" the recipient (perhaps because there are no mechanisms for propagating CONNEG upstream) and thus that there is unlikely to be an opportunity for subsequent conversion. If this is being assumed it should be stated explicitly. However I believe it is unwise to assume this in general, even if it might be likely for the case of an SMTP-to-fax gateway (which seems to be what the authors have in mind). I attempted to do a case analysis for what a sender should do for various combinations of sender and receiver CONNEG and CONPERM capabilities. Notation is as follows: Sender: N = SMTP client supports CONNEG, P = SMTP client supports CONPERM, - = extension not supported Receiver: N = SMTP server supports CONNEG AND reports capabilities for that recipient, P = SMTP server supports CONPERM - = extension not supported All cases assume CONPERM was asserted by the sender in MAIL FROM; otherwise this is treated per RFC 2821 and other SMTP extension specifications. Here's what I came up with: +--------------+-----------------------------+ | | Sender | | | -- -P N- NP | +--------------+-----+--------+-----+--------+ | -- | N/A | relay | N/A | relay | |Receiver -P | N/A | relay | N/A | relay | | N- | N/A | rule A | N/A | rule A | | NP | N/A | rule B | N/A | rule B | +--------------+-----+--------+-----+--------+ cases: N/A = not applicable - out of scope for this specification. relay = relay the message intact, propagating CONPERM if possible. rule A: This is what should happen if the sender is unable to propagate CONPERM because the receiver doesn't support it, but the sender and receiver DO support CONNEG. Since CONPERM cannot be propagated downstream there is no opportunity for further conversion by intermediaries. (Note that recipients do not require sender permission to convert any part of a message; however if via conversion recipients can accept other than their native formats they should include those formats in their CONNEG advertisements.) rule B: This is what should happen if the sender is able to propagate CONPERM to a receiver, AND the receiver supports CONNEG. Therefore there may be additional opportunities for downstream intermediaries to convert the message. rule A should be: for each bodypart: ON (conversion error) bounce entire message IF (recipient supports that format) relay it without change ELSE IF (conversion is known by the relay) convert body part ELSE IF (conversion is prohibited) bounce message ELSE IF (conversion is known to be infeasible) bounce message ELSE bounce message rule B should be: for each bodypart: ON (conversion error) bounce entire message IF (recipient supports that format) relay it without change ELSE IF (conversion is known by the relay) convert body part ELSE IF (conversion is prohibited) bounce message ELSE IF (conversion is known to be infeasible) bounce message ELSE % later conversion is still possible relay body part without change That is, an intermediary should only bounce a message for inability to perform conversion if it _knows_ that subsequent conversion is not possible, and the only way for it to know that is to either have the conversion prohibited in Content-Convert or to be aware of recipient capabilities. (see below for modified logic taking critical content indication into account) (see below for notes on types of conversion errors) 3. I believe that multiple conversions of a single body part should be discouraged, especially if any of those conversions is lossy, because multiple lossy conversions can be very destructive to the content. One way to do this would be to remove Content-Convert fields from any body part once lossy conversion has been applied, or to alter them in such a way that only a lossless subset of the orignally permitted conversions is permitted for subsequent conversions. Examples of lossless vs. lossy conversions: (this could go in an appendix if found to be useful) - simple content-type or format conversions that do not cause significant degradation of the content are not lossy - a change in charset is not lossy if all of the characters in the source message can be represented by exact equivalents in the converted message - a change from one "rich" text format to another, or to plain text, is probably lossy since some formatting errors usually result - a change in image resolution may or may not be lossy depending on whether the resolution is increased or decreased and whether any aliasing that results from over-sampling can be filtered out to a reasonable degree (similarly for audio sampling frequency and video frame rate) - a change from a lossless audio or image codec to a lossy codec, or from one lossy codec to another, is probably lossy. Since the degree of loss depends on both the kind of conversion that is performed and the object being converted, any recommendation to remove or alter Content-Convert should be a MAY or a SHOULD rather than a MUST. 4. There are several types of conversion failures that might require some difference either in handling or in the error code reported: a) Content improperly formatted as received (or inconsistent with content-type or content-features labelling) This is a permanent error. If a DSN is returned, it should have status code 5.6.0 There should be no obligation for a relay to convert improperly labelled content; nor should a relay "guess" at a content-type or appropriate conversion when the content is mislabelled. However, it is permissible for a relay to accomodate slight errors in labelling if it is able to do so. For instance, a relay is allowed to convert a content labelled as papersize letter but formatted for A4 paper, if it is able to do so. b) Conversion infeasible or meaningless or useless (e.g. converting image to audio) This is a permanent error. If a DSN is returned, it should have status code x.y.z. "useless" means the information loss would be so great that the result is unlikely to be usable by the recipient. i.e. you can convert an image to ASCII art (and tools exist to do this) but it's not likely to be useful. similarly, you can extract textual information from GIF annotations or MP3 audio file ID3 tags but that's probably such a tiny fraction of the content that it's not feasible. c) Relay doesn't know how to convert This may or may not result in a delivery failure. If it does result in a delivery failure it is a permanent error. If a DSN is returned it should have status code 5.6.3 (conversion required but not supported). This code should take priority over 5.6.2 or 5.6.1. d) No conversion is possible given sender and recipient constraints This is a permanent error. If a DSN is returned it should have status code 5.6.2 (conversion required and prohibited) if the conversion was prohbited by the sender, or code 5.6.1 (media not supported) if no format was acceptable to the recipient. d) processing error / insufficient resources If the error is repeatable given the same input (maybe it's a bug in the conversion code), it's a permanent error; if the error is due to temporary resource limitations like a shortage of memory or disk, it's a temporary error. Some temporary errors may be reportable during an SMTP session (allowing the sender to retry the transfer at another mail exchanger or at a later time). If a temporary error persists to the point that the relay must declare delivery failure and a DSN is returned it should have status 4.6.5 (conversion failed). If it is a permanent error the status reported in a DSN should be 5.6.5. 5. Interaction with critical-content indication (RFC 3459) needs to be defined. My suggestion is to modify rule A as follows: for each bodypart: ON (conversion_error) { IF (bodypart.Content-Disposition.Handling is OPTIONAL) delete body part ELSE bounce entire message } IF (recipient supports that format) relay it without change ELSE IF (conversion is known by relay) convert body part ELSE IF (bodypart.Content-Disposition.Handling is OPTIONAL) delete body part ELSE bounce entire message and to modify rule B is as follows: for each bodypart: ON (conversion error) { IF (bodypart.Content-Disposition.Handling is OPTIONAL) delete body part ELSE bounce entire message } IF (recipient supports that format) relay it without change ELSE IF (conversion is known by the relay) convert body part ELSE IF (conversion is prohibited) { IF (bodypart.Content-Disposition.Handling is OPTIONAL) delete body part ELSE bounce message } ELSE IF (conversion is known to be infeasible) { IF (bodypart.Content-Disposition.Handling is OPTIONAL) delete body part ELSE bounce message } ELSE % later conversion is still possible relay body part without change 6. Misc things: a. Terminology: For consistency with other email specifications, and to avoid the potential for people (including authors?) to assume that this extension is only for email-to-device applications, please use terms like "recipient" instead of, or as alternatives to, "target" or "system". b. Section 1 states that no MDNs will be issued for successful conversion or conversion-with-loss. It would never be appropriate to issue an MDN for conversions controlled by this specification since MDNs are only issued after delivery of the message, and this specification applies to intermediaries that handle a message prior to delivery. It might, under some circumstances, be appropriate to issue DSNs for those conditions. It is fine if the default behavior is to not do so, but are we confident that there is no need to provide a means of requesting this? (perhaps via a parameter to CONPERM, or to Content-Convert) Granted it's simpler to do without it, but I'd hate to have to define an entirely different extension just to allow conversions to be reported to the sender. This is not a showstopper for me (except that you need to correct MDN to say DSN instead), but I wanted to mention it. c. Use of Content-Previous by recipient-authorized converters: Is it permissible for converters authorized by a recipient and acting on a recipient's behalf (which do not require sender permission) to use Content-Previous to label such conversions and communicate them to the recipient? d. Servers asserting CONPERM without being able to perform conversions: While there are certainly cases where this is appropriate, they seem like fairly narrow cases. For instance, any MTA that has mail forwarding capability probably cannot be certain that any necessary conversions can be performed. e. NIT. Please use "MAIL FROM" rather than "MAIL-FROM" and "RCPT TO" rather than "RCPT-TO" for consistency with RFC[2]821. f. In a couple of places, this spec attempts to impose requirements on servers that are not in-scope for this spec. g. section 5.2 states that the client SHOULD convert the data to the "highest" level of capability of the server. I believe this should instead state that the client SHOULD use the "least lossy" conversion available. For example, there is no point in converting to a high-resolution image format supported by the client when a lower-resolution format is sufficient to convey the image with the same degree of loss. h. if the Content-Convert field is omitted, it should be explicitly stated that no conversions are authorized by the sender. i. Question: Is the Content-Features field applicable to all kinds of content that might be converted? Should section 8 be a SHOULD? ----------------------------------------------------------------------- ----------------------------------------------------------------------- What follows are (very long) specific suggestions for text changes. Bracketed references refer to the items listed above. section 1, paragraph following drawing: SMTP host permission to perform specified content conversions is communicated by message senders, through the ESMTP CONPERM service extension and MIME Content- Convert headers. Target device or system capabilities are communicated in SMTP sessions through the ESMTP CONNEG service extension. suggest [6a]: Permission for an SMTP intermediary to perform specified content conversions is communicated by message senders, through the ESMTP CONPERM service extension and MIME Content-Convert headers. Capabilities of the recipient (which may be a human recipient, a special-purpose device, or gateway) are communicated in SMTP sessions through the ESMTP CONNEG service extension. ------------------------------------------------------------ Conversions are performed by the first ESMTP host that can obtain both the sender's permission and the recipient's capabilities. suggest [2]: Conversions are performed by the first ESMTP host that can obtain both the sender's permission and the recipient's capabilities, and which is capable of performing the necessary conversions. ------------------------------------------------------------ following paragraph Note: The specification does not provide for sending an MDN back to the originator, when a conversion is performed. should be [6b]: Note: The specification does not provide for sending a DSN back to the originator when a conversion is performed. ------------------------------------------------------------ When a relay or client is unable to transmit the message to a next-hop that supports CONPERM or to perform appropriate conversion, then it terminates message transmission and returns a [DSN] to the originator. suggest [1]: When a relay or client is able to determine that some critical content is not usable by the recipient and that no conversion is possible, then it terminates message transmission and returns a [DSN] to the originator. ------------------------------------------------------------ section 3, 3rd paragraph The originator MAY indicate authorization for intermediaries to perform conversions, by using the ESMTP CONPERM service extension when posting a new message. Authorized conversions MUST be specified in MIME Content-Convert headers, in each MIME body-part for which conversions are authorized. suggest this be replaced by [NIT]: The originator MAY indicate authorization for intermediaries to perform conversions, by using the ESMTP CONPERM service extension when posting a new message. Conversions that are authorized by the originator are specified by providing a MIME Content-Convert header in each MIME body-part for which a conversion is authorized. (it's not clear what MUST means here.) and then add [6h] The absence of a Content-Convert header in a body-part indicates that no conversion is authorized. ------------------------------------------------------------ Recipient Action: Recipient capabilities SHOULD be communicated to intermediaries by the ESMTP CONNEG service extension. suggest instead [NIT] Recipient Action: Recipient capabilities, if known, are communicated to intermediaries by the ESMTP CONNEG service extension. (Again, the meaning of SHOULD seems unclear - given that the mechanism for recipients to communicate capabilities to MTAs is not defined by this specification, how can this requirement be met?) you might also consider adding after this: The absence of CONNEG information for a recipient will be taken to mean that no information about recipient capability is available to that server. ------------------------------------------------------------ Intermediary Actions: An intermediary MAY be given CONPERM direction when receiving a message, and MAY be given CONNEG guidance, before sending the message. suggest instead [NIT]: An intermediary MAY be given CONPERM direction when receiving a message, and MAY be given CONNEG guidance, before relaying the message. (since "sending" is closer to "originating" than "relaying") CONPERM and CONNEG operate on a per-message basis. Therefore they are issued through the ESMTP MAIL-FROM request. CONNEG response information is provided on a per-recipient basis, through the response to ESMTP RCPT-TO. suggest instead [NIT]: CONPERM is asserted on a per-message basis. Therefore it are communicated through the ESMTP MAIL FROM request. CONNEG information is provided on a per-recipient basis, through the response to ESMTP RCPT TO. ------------------------------------------------------------ Conversion MUST be performed by the first CONPERM intermediary that obtains CONNEG recipient capability information. suggest instead [2]: Conversion MUST be performed by the first CONPERM intermediary that obtains CONNEG recipient capability information which is able to perform the conversion. ------------------------------------------------------------ A special case of differential capabilities occurs when an intermediary receives capability information about some recipients, but no information about others. An example of this scenario can occur when sending a message to some recipients within one's own organization and other recipients located elsewhere. The intermediary might have capability information about the local recipients, but will not have any for distant recipients. This is treated as a variation of the handling required when the permissible conversions are the null set -- that is, no valid conversions are possible for a recipient. strongly recommend [1]: A special case of differential capabilities occurs when an intermediary receives capability information about some recipients, but no information about others. An example of this scenario can occur when sending a message to some recipients within one's own organization and other recipients located elsewhere. The intermediary might have capability information about the local recipients, but will not have any for distant recipients. In this case, the intermediary MUST attempt to relay the original message (without conversion) to those recipients for which no capability information is not available. (and remove the following paragraph, as it would be redundant) ------------------------------------------------------------ Once an intermediary has performed conversion, it MAY terminate use of CONPERM. However some relay environments, such as those re-directing mail to a new target device, will benefit from further conversion. Intermediaries MAY continue to use CONPERM or MAY re- initiate CONPERM use, when they have knowledge about possible variations in target device. suggest instead [3] (also [2]): If all critical bodyparts in a message have been converted to a format that is acceptable to the recipient (as indicated by CONNEG) the intermediary MAY terminate use of CONPERM when relaying the message. However some relay environments, such as those re-directing mail to a new target device, will benefit from further conversion. Intermediaries MAY continue to use CONPERM when they have knowledge about possible variations in target device. Note that in some cases multiple conversions of a single body part can result in unacceptable loss of information, due to interference between the conversions, even if each individual conversion was apparently successful. An intermediary MAY therefore remove the Content-Convert header from a body part to which a lossy conversion has been performed, or alter the header to permit only a subset of the originally-permitted conversions, if the intermediary believes that subsequent lossy conversions would render the content unusable. ------------------------------------------------------------ 3.1. Sending Permission A message originator that permits content conversion by intermediaries MAY use the CONPERM ESMTP service extension and Content-Convert MIME headers to indicate what conversions are permitted by intermediaries. suggest instead [nit]: A message originator that permits content conversion by intermediaries MAY use the CONPERM ESMTP service extension and Content-Convert MIME headers to indicate what conversions are permitted to be performed by intermediaries. ------------------------------------------------------------ Successful use of CONPERM does not require that conversion take place along the message transfer path. Rather, it requires that conversion take place whenever a next-hop server reports recipient capabilities, through CONNEG, and those capabilities do not include support for the current representation of the content. suggest instead [2]: Successful use of CONPERM does not require that conversion take place along the message transfer path. Rather, it requires that conversion take place whenever a next-hop server reports recipient capabilities, through CONNEG, those capabilities do not include support for the current representation of the content, and the relay is capable of performing an appropriate conversion. ------------------------------------------------------------ An SMTP server MAY offer ESMTP CONPERM, without being able to perform conversions, if it knows that conversions can be performed by the target device or system. suggest instead [6d] An SMTP server MAY offer ESMTP CONPERM, without being able to perform conversions, if it knows that any necessary conversions will be performed by subsequent intermediaries before delivery to the recipient. However this is likely to be applicable only to special-purpose gateways. ------------------------------------------------------------ 3.2. Returning Capabilities A target recipient device or system communicates its content form capabilities to the SMTP service through a means outside the scope of this specification. When an ESMTP server knows a target's capabilities, it MAY offer the CONNEG ESMTP service extension. suggest instead: [6a] A recipient (be it a human, target device, or other system) communicates its content form capabilities to the SMTP service through a means outside the scope of this specification. When an ESMTP server is able to know some of its recipients' capabilities, it MAY offer the CONNEG ESMTP service extension. ------------------------------------------------------------ When a message is being processed according to this specification, if a next-hop ESMTP server responds that it supports CONNEG, then the SMTP client: (1) MUST request CONNEG information (2) MUST perform the requisite conversions, if possible, before sending the message to the next-hop SMTP server (3) MUST fail message processing, if any conversion for the message fails, and MUST return a failure DSN to the originator (4) MUST add a Content-Previous header and a Content- Features header to each MIME body-part that has been converted. change to: [1] [2] [6i] When a message is being processed according to this specification, if a next-hop ESMTP server responds that it supports CONNEG, then the ESMTP client: (1) MUST request CONNEG information for each recipient (2) For each recipient for which CONNEG information is returned by the server, the client MUST perform any conversions needed to make the message usable by that recipient, if the client is able to do so, before relaying the message to the next-hop SMTP server (3) MUST fail message processing for any recipient for which it determines that conversion of all "critical portions" of that message (as defined below) to meet that recipient's requirements is not possible (4) If message processing fails for a recipient, MUST follow the procedures in [SMTP-DSN] for reporting the failure to the originator (e.g. if NOTIFY=failure or was unspecified) (5) MUST add a Content-Previous header and SHOULD add a Content-Features header to each MIME body-part that has been converted. and insert the following text regarding critical content [5]: A "critical portion" of a message is any body part which a) does not have a Content-Disposition header field, OR b) has a Content-Disposition header field with no "Handling" parameter, OR c) has a Content-Disposition header field with a "Handling" parameter with a value other than "OPTIONAL". The "Handling" parameter of the Content-Disposition field is defined in [RFC3459]. and insert the following text regarding conversion errors [4]: Conversion Errors There are several types of conversion failures that might require some difference either in handling or in the error code reported: a) Content improperly formatted as received (or inconsistent with content-type or content-features labelling) This is a permanent error. If a DSN is returned, it should have status code 5.6.0 There should be no obligation for a relay to convert improperly labelled content; nor should a relay "guess" at a content-type or appropriate conversion when the content is mislabelled. However, it is permissible for a relay to accomodate slight errors in labelling if it is able to do so. For instance, a relay is allowed to convert a content labelled as papersize letter but formatted for A4 paper, if it is able to do so. b) Conversion infeasible or meaningless or useless (e.g. converting image to audio) This is a permanent error. If a DSN is returned, it should have status code 5.6.1 (media not supported) "useless" means the information loss would be so great that the result is unlikely to be usable by the recipient. i.e. you can convert an image to ASCII art (and tools exist to do this) but it's not likely to be useful. Similarly, you can extract textual information from GIF annotations or MP3 audio file ID3 tags but that's probably such a tiny fraction of the content that the conversion would not be useful. c) Relay doesn't know how to convert This may or may not result in a delivery failure. If it does result in a delivery failure it is a permanent error. If a DSN is returned it should have status code 5.6.3 (conversion required but not supported). This code should take priority over 5.6.2 or 5.6.1. d) No conversion is possible given sender and recipient constraints This is a permanent error. If a DSN is returned it should have status code 5.6.2 (conversion required and prohibited) if the conversion was prohbited by the sender, or code 5.6.1 (media not supported) if no format was acceptable to the recipient. e) processing error / insufficient resources If the error is repeatable given the same input (perhaps because of a bug in the conversion code), it's a permanent error; if the error is due to temporary resource limitations like a shortage of memory or disk, it's a temporary error. Some temporary errors may be reportable during an SMTP session (allowing the sender to retry the transfer at another mail exchanger or at a later time). If a temporary error persists to the point that the relay must declare delivery failure and a DSN is returned it should have status 4.6.5 (conversion failed). If it is a permanent error the status reported in a DSN should be 5.6.5. and insert the following text regarding message conversions [1][2]: Message Conversions Message conversions SHOULD be performed as follows: FOR (each bodypart in the message): ON (conversion error) { IF (bodypart.Content-Disposition.Handling is OPTIONAL) delete body part ELSE delivery failure for this recipient } IF (recipient supports the source format of the bodypart) copy the body part to the output without conversion ELSE IF (a conversion method is known by the relay) convert the body part ELSE IF (conversion is prohibited) { IF (bodypart.Content-Disposition.Handling is OPTIONAL) delete body part ELSE delivery failure for this recipient } ELSE IF (conversion is known to be infeasible) { IF (bodypart.Content-Disposition.Handling is OPTIONAL) delete body part ELSE delivery failure for this recipient } ELSE IF (server supports CONPERM) { % later conversion is still possible relay body part without change } ELSE { % conversion to recipient's needs is not possible delivery failure for this recipient } (okay, the above text needs work) ------------------------------------------------------------ When performing conversions, the Client MUST either: (1) Send a single copy to the next-hop SMTP server, using a best capabilities that are supported to all recipients along that path, or (2) Separate the transfers, to provide the best conversions possible for subsets of the recipients. If the transfers are separated, then the current session MUST be terminated, and new sessions conducted for each subset. change to: [1] [2] When performing conversions, the Client MUST either: (1) Send a single copy to the next-hop SMTP server, using the least lossy set of conversions that are supported by the Client, and which produce contents usable by all recipients whose mail is to be relayed to that server, or (2) Separate the transfers, to provide the best conversions possible for subsets of the recipients. Note that for any recipient for which CONNEG information is not available, the Client MUST relay the message without change, in which case the Client MUST use option (2). If the transfers are separated, then the current session MUST be terminated, and new sessions conducted for each subset. ------------------------------------------------------------ The conversions that are performed are determined by the intersection of three lists: * Conversions permitted by the sender * Content capabilities of the target * Conversions that can be performed by the SMTP client host Failed Conversion If the result of this intersection is the null set of representations, for an addressee, then delivery to that addressee MUST be handled as a conversion failure. change to: [1] [2] For each body part in a message, the conversions that are performed are determined by the intersection of three lists: * Conversions permitted by the sender * Content capabilities of the target * Conversions that can be performed by the SMTP client host Failed Conversion If the intersection of the first two is the null set of representations, for a recipient, and the body part is not marked as non-critical content (Handling is not OPTIONAL) then delivery to that recipient MUST be handled as a delivery failure for that recipient. If the intersection of the first two is non-null, but the client lacks the information necessary to perform a conversion, but the server supports the CONPERM option, the client MUST relay the content to the server without change. If the intersection of the first two is non-null, but the client lacks the information necessary to perform a conversion, the server does not support the CONPERM option, and the body part is not marked as non-critical, the client MUST treat this as a delivery failure to that recipient. For any body part for which Handling is marked OPTIONAL, and for which recipient capabilities are known and for which conversion would be required, a client MAY omit that body part in th ecopy of the message relayed for that recipient. (the above is an attempt to rewrite the original text, but it seems to me that pseudo-code expresses this both more succinctly and with better precision...) ------------------------------------------------------------ delete this: If the next-hop SMTP host does not indicate that it can represent the target's capabilities through CONNEG, but does respond that it can support CONPERM, then the client SMTP MUST send the existing content, if all other SMTP transmission requirements are satisfied. (I agree with this but I think it is not needed if the other changes I've suggested are made) ------------------------------------------------------------ 3.3. Next-Hop Non-Support of Service If a Client is participating in this service, but the next-hop SMTP server does not support CONPERM and does not support CONNEG, then the SMTP client (1) MUST terminate the session to the next-hop SMTP server, without sending the message (2) MUST return a DSN notification to the originator that content negotiation could not be performed. change to [1] If a Client is participating in this service, but the next-hop SMTP server does not support CONPERM and does not support CONNEG, then the SMTP client MUST relay the message to the SMTP without change ------------------------------------------------------------ If a Client is participating in this service and the next-hop SMTP server supports CONNEG but provides no capabilities for an individual RCPT-TO addressee, then the SMTP client's processing for that recipient MUST be to: (1) Treat the addressee as a conversion failure, and (2) Separate the addressee from the address list that is processed according to CONNEG, and continue to process the addressee according to CONPERM. change to: [1] If a Client is participating in this service and the next-hop SMTP server supports CONNEG but provides no capabilities for an individual RCPT TO addressee, then the SMTP client MUST attempt to relay the message to that recipient without change, as if CONPERM were not asserted for that recipient. This MUST be done in a separate SMTP session. ------------------------------------------------------------ section 4.2. both of these paragraphs should be deleted. the first one is imposing requirements on a server that does't conform to this specification. Server Action: If the client specifies CONPERM in the MAIL-FROM, but the server does not support the CONPERM parameter, the server MUST reject the MAIL-FROM command with a 504- CONPERM reply. the second one is imposing a condition on a server because a client sent it a parameter. if it's really intended to impose a condition on a client, then it needs to be reworded (client MUST NOT send CONPERM unless the server supports it) and moved to a different place in this document. If the client issues the CONPERM parameter in the MAIL-FROM, then the server MUST conform to this specification. Either it MUST relay the message according to CONPERM, or it MUST convert the message according to CONNEG information. ------------------------------------------------------------ section 5.2: If the client issues the CONNEG parameter with RCPT-TO, then it MUST honor the capabilities returned in the CONNEG RCPT-TO replies for that message, and it MUST convert the message content, if the current form of the content is not included in the recipient capabilities. change to: If the client issues the CONNEG parameter with RCPT-TO, then it MUST treat as delivery failures any attempt to relay a message to the recipient for which conversion of any critical content is either prohibited or infeasible. ------------------------------------------------------------ The conversions that are performed are determined by the intersection of the: * Conversions permitted by the sender * Content capabilities of the target * Conversions that can be performed by the SMTP client host If the result of this intersection is the null set of representations, then the Client processing depends upon whether the message is subject to CONPERM processing: (1) If the message is subject to CONPERM, the Client MAY continue to transmit the original content, according to CONPERM. (2) Otherwise, the Client MUST treat the conversion as failed. change to [1] [2]: The conversions that are performed are determined by the intersection of the: * Conversions permitted by the sender * Content capabilities of the target * Conversions that can be performed by the SMTP client host If the result of this intersection is the null set of representations, then the Client processing depends upon whether the message is subject to CONPERM processing: (1) If the message is subject to CONPERM, the Client MAY continue to transmit the original content, according to CONPERM. (2) Otherwise, the Client MUST attempt to relay the message unchanged. ------------------------------------------------------------ If the result of the intersection is not null, the client SHOULD convert the data to the "highest" level of capability of the server. Determination of the level that is highest is left to the discretion of the host performing the conversion. change to: If the result of the intersection is not null, the client SHOULD convert the data in such a way as to cause the least loss of content, within the recipient's capabilities. Determination of the relative amount of loss of different conversions is left to the discretion of the host performing the conversion. ------------------------------------------------------------ Each converted MIME body-part, MUST have a Content- Converted header that indicates the previous body-part form and a Content-Features header, indicating the new body-part form. change to: Each converted MIME body-part, MUST have a Content- Converted header that indicates the previous body-part form and SHOULD have a Content-Features header, indicating the new body-part form. (on the assumption that content-features isn't appropriate for all possible contents) ------------------------------------------------------------ 6. MIME CONTENT-CONVERT HEADER Content-Convert is an optional header field that specifies permitted conversions for the associated content. It MAY be used without the other mechanisms defined in this document. If present, this header MUST be carried unmodified and delivered to the recipient. In its absence the content originator has provided no guidance about content conversions, and intermediaries SHOULD NOT perform content conversion. change this to MUST NOT ------------------------------------------------------------ 8. MIME CONTENT-FEATURES HEADER When an intermediary has performed conversion, the intermediary MUST record details of the result of the conversion that was performed. change to SHOULD ------------------------------------------------------------ finally, in references, [SETS] and [SYN] appear to be the same document.
- draft-ietf-fax-esmtp-conneg-08.txt Hiroshi Tamura
- Re: draft-ietf-fax-esmtp-conneg-08.txt Keith Moore
- Re: draft-ietf-fax-esmtp-conneg-08.txt Keith Moore
- Re: draft-ietf-fax-esmtp-conneg-08.txt Dave Crocker
- Re: draft-ietf-fax-esmtp-conneg-08.txt Pete Resnick
- Re: draft-ietf-fax-esmtp-conneg-08.txt Dave Crocker
- Re: draft-ietf-fax-esmtp-conneg-08.txt Valdis.Kletnieks
- Re: draft-ietf-fax-esmtp-conneg-08.txt Dave Crocker
- Re: draft-ietf-fax-esmtp-conneg-08.txt Hiroshi Tamura
- Re: draft-ietf-fax-esmtp-conneg-08.txt Keith Moore
- Re: draft-ietf-fax-esmtp-conneg-08.txt Dave Crocker
- Re: draft-ietf-fax-esmtp-conneg-08.txt John C Klensin
- Re: draft-ietf-fax-esmtp-conneg-08.txt Valdis.Kletnieks
- Re: draft-ietf-fax-esmtp-conneg-08.txt Dave Crocker