Re: draft-ietf-fax-esmtp-conneg-08.txt

[Dave Crocker <[e-mail]>]

Keith,

Thanks for the thoughtful and extensive explanation of your concerns.
The following responds to the discussion section of your note.

Separately, I'll start formulating a revised draft, including your
suggestions.


KM> 1. My biggest concern is that for a message for which CONPERM is
KM> asserted, either the absence of an unbroken chain of CONPERM-capable
KM> relays or the absence of CONNEG for a recipient is (apparently) treated
KM> as an indication that the recipient cannot accept any kind of content -
KM> forcing a delivery failure.

The real question about the draft is: What is the purpose of the
proposed mechanism?

As specified, the mechanism is intended to provide a specific
quality-of-service capability.  QOS pertains to a "enforcement".

If the sender is only concerned about communicating their desires to the
recipient, they can do that. They simply include the appropriate
Content-Convert headers, without using the SMTP extension.

If the sender is concerned about obtaining capabilities information
about the recipient, they can do that too, using RFC 3297, "Content
Negotiation for Messaging Services based on Email".

If you believe there is a specific scenario that needs to be supported,
but cannot be, I am not understanding what it is.

Please clarify, and indicate what is the basis for needing it. Let's
keep in mind that adding options mean adding complexity. So, the reason
for the variations needs to be compelling.


KM> (Either that or the assertion of CONPERM is
KM> not only "permission" from the sender for intermediaries to perform
KM> content conversion, but also a request that the sender not deliver
KM> messages which are not known to be acceptable to the recipient, which
KM> seems like an inappropriate binding of two unrelated requests.)

By contrast, I believe they are two sides of the same capability.

The permission being given is constrained. In fact, that is the reason
for putting this into SMTP, rather than simply using the Content-Convert
MIME header, by itself.


KM> This is not backward-compatible with the installed base.

Options often are not backward compatible.  That is why they are
options.


KM>  The extention
KM> should allow sending of the same message to multiple recipients, some of
KM> which can be sent through CONPERM-capable servers and some of which
KM> cannot, some of which support CONNEG and some of which do not,

You are calling for a mechanism that is significantly more complicated.
Hence is a requirement for community consensus about needing that extra
capability. As you note, the mechanism you are calling for can
already be emulated by breaking the transmission down into smaller
groups of addressees, according to the choices you want to apply.

This means that your concern is really about efficiency. Optimizing
"efficiency" of such a mechanism is appropriate only if this
characteristic of the mechanism will greatly affect performance. We have
no indication that this is an issue, here.


KM> The current definition of this extension makes it essentially useless
KM> when attempting to send mail to any recipient that is not known in
KM> advance to support CONPERM/CONNEG.

That's right. Much like the long-standing problem of sending a MIME
attachment for a vcard, if you do not already know that they support
vcard. Or for sending any MIME type, if you do not already know it is
supported.

So, really, you are focusing on the general problem of knowing whether
the SMTP relay chain supports particular SMTP options. That is a
laudable goal, but it is not one we are trying to solve.


KM> I believe the absence of CONNEG information for a recipient should be
KM> treated as if the recipient can support any kind of content, or (more
KM> realistically) that the recipient will either perform any needed
KM> conversions or bounce the message.

Now I am even more confused. What you describe is what we already have,
today. Certainly we do not need an option to provide a mechanism that is
already in use?

If you believe that the value-add is to have the sender indicate what
conversions are "permitted" then the sender should use only the
Content-Convert headers, without the SMTP Conperm/Conneg mechanism.


KM> 2. Another concern is the handling of messages when the relay which is
KM> expected to provide a conversion (in that it has both CONPERM and
KM> CONNEG for the recipients) is unable to perform one or more of the
KM> conversions required.  I believe the appropriate behavior is for a
KM> relay to perform those conversions which it is able to perform,
KM> and to relay the message (with CONPERM asserted, if possible) to 
KM> the next hop.  It is possible that subsequent hops may be able to 
KM> perform the other conversions.

You are suggesting a rather sophisticated environment, with incremental
conversion.  It sounds quite clever.

However trying to support such a loosely-coupled, "accidental" mixture
of services, properly, is far beyond our abilities to specify and
certainly beyond any demonstrated need.


KM> Indeed, it is in a sender's interest to have his outbound
KM> mail transmitted through relays that can convert the sender's unique
KM> formats to more commonly-used formats; and it is in the recipient's
KM> interests to have his inbound mail MX'ed through relays that are capable
KM> of converting common formats to those which he can use.   We should not
KM> expect all conversions to be performed at the same hop.

Right now, Internet mail does not permit conversions to be done anywhere
in the relay chain. I suggest we try to support the simple scenario --
which has already turned out to be far more complex than we first
thought necessary -- before trying to solve the general case, especially
since we have no demonstrated need for it.


KM> Perhaps it is assumed that all conversions will be performed "close to"
KM> the recipient (perhaps because there are no mechanisms for
KM> propagating CONNEG upstream) and thus that there is unlikely to be an
KM> opportunity for subsequent conversion.  If this is being assumed it
KM> should be stated explicitly.

I think you make a very good point. The question really hinges on the
propagation of the CONNEG information. It seems likely that it will not
propagate far. Few hops. So, yes, I think it would help people's
understanding of the specification to add some non-normative discussion
of this.


KM> I attempted to do a case analysis for what a sender should do for
KM> various combinations of sender and receiver CONNEG and CONPERM
KM> capabilities. Notation is as follows:

Keith, this is a wonderful bit of explanatory material and I think it
will help quite a lot to add it to the text.  Thanks!

(Obviously, I disagree with some of its content, but that disagreement
is entirely separate from appreciating the nature of the exercise and
appreciating its general utility. We can haggle over the details,
separately.)



KM> 3. I believe that multiple conversions of a single body part should be
KM> discouraged, especially if any of those conversions is lossy, because
KM> multiple lossy conversions can be very destructive to the content.

Again, excellent point and one that should be added to the document.


KM> 4. There are several types of conversion failures that might require
KM> some difference either in handling or in the error code reported:

ditto.


KM> 5. Interaction with critical-content indication (RFC 3459) needs to be
KM> defined.

Oh boy. You raise an important point. However I really, seriously,
strongly would like to find a way to avoid having options specify
interactions with other options, as much as possible.

At the least, it raises both a concern about creating a "precedence
hierarchy" for options", and a concern about constantly retro-fitting
options to account for new options. grrrr. mumble. fooey!

So, here is what I am going to suggest:

CONPERM/CONNEG concern the presence and enforcement of an SMTP service.
Rejection of the message occurs when that service cannot be continued
through the delivery path. In the context of that description of a
hop-by-hop service enforcement, the MIME body-part information,
contained in Content-Convert headers, is secondary.

By contrast, the Critical Content enhancement to the Content-Handling
MIME header is a label about a final-delivery disposition of the
content.

They have some relationship, but mostly they are separate.  If and when
we see some actual experience with interactions between them, it will be
worth considering adding text to cover the issue.


KM> a. Terminology:  For consistency with other email specifications,
KM>    and to avoid the potential for people (including authors?) to
KM>    assume that this extension is only for email-to-device applications,

The language was chosen to make sure that non-email reception was
supportable. That is, it was meant to be *more* general, not less.

However I do believe that some changes can be made, to use the word
'recipient' more often, and that it will improve the overall tone of the
document.


KM> b. Section 1 states that no MDNs will be issued for successful conversion

Given that it says what is *not* done, it will probably be best to dodge
this debate by changing the reference to say "...that no notification is
issued...".


KM> c. Use of Content-Previous by recipient-authorized converters:
KM>    Is it permissible for converters authorized by a recipient and acting
KM>    on a recipient's behalf (which do not require sender permission)
KM>    to use Content-Previous to label such conversions and communicate
KM>    them to the recipient?

yes.


KM> d. Servers asserting CONPERM without being able to perform conversions:
KM>    While there are certainly cases where this is appropriate, they
KM>    seem like fairly narrow cases.  For instance, any MTA that has
KM>    mail forwarding capability probably cannot be certain that any
KM>    necessary conversions can be performed.

I don't understand what point you are making or what change you are
suggesting for the specification.


KM> e. NIT.  Please use "MAIL FROM" rather than "MAIL-FROM" and "RCPT TO"
KM>    rather than "RCPT-TO" for consistency with RFC[2]821.

ack.


KM> f. In a couple of places, this spec attempts to impose requirements on
KM>    servers that are not in-scope for this spec.

Where and how?


KM> g. section 5.2 states that the client SHOULD convert the data to the
KM>    "highest" level of capability of the server.  I believe this should
KM>    instead state that the client SHOULD use the "least lossy"
KM>    conversion available.
KM>  For example, there is no point in converting
KM>    to a high-resolution image format supported by the client
KM>    when a lower-resolution format is sufficient to convey the image
KM>    with the same degree of loss.

This seems like a useful point to add to the text.  Thanks.


KM> h. if the Content-Convert field is omitted, it should be explicitly
KM>    stated that no conversions are authorized by the sender.

If there is no Content-Convert field, what is the point of having
Conperm/Conneg?


KM> i. Question: Is the Content-Features field applicable to all kinds of
KM>    content that might be converted?  Should section 8 be a SHOULD?

Please explain.


d/
--
 Dave Crocker <mailto:[e-mail]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:[phone]>, <fax:[phone]>