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.