[Top] [All Lists]

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

2003-08-12 11:45:13

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

Then I must question whether such an extension is actually appropriate.
To me the extension as proposed is technically unsound, or at the very
least, it grossly overstates its applicability by claiming to be a
general purpose conversion negotiation mechanism. I've tried to make
suggestions which would make it technically saner and more broadly

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.

For that matter, recipients don't need sender authorization in order
to perform conversions.  Recipients are free to perform whatever
conversions they want and suffer the benefits or consequences.
(assuming, of course, that the message is actually delivered to them) 
So that clearly is not the purpose of this extension.  However the
extension as currently defined can prevent delivery of messages that
would be usable by the recipient if delivered.

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".

Right, but this is slow and unreliable, and not suitable for
intermediaries, and so not relevant here.

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

The scenario is that someone wants to send a message without specific
knowledge of the recipient's capabilities, and without specific
knowledge of intermediary capabilities, and allow for the potential for
intermediaries to convert that message as necessary to accomodate the
recipient's needs, but maximize the chance that the message will be
delivered - rather than having the message delivery fail for lack of an
intermediary that supports the required extension, conversion, or

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.

No, the reason for defining an extension that is entirely incompatble
with the huge installed base needs to be compelling.  

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

It seems entirely appropriate to put some constraints on the ability of
intermediaries to perform conversions.  However I believe the
constraints, as currently defined, are highly undesirable for the vast
majority of SMTP users. 

There are lots of reasons to not simply use the Content-Convert header
as an indicator that conversion is permitted - one being that it makes
much more sense to associate the conversion permission with message
transmission than to make it an attribute of the message itself.

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

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

Let me be clearer then.  This option will harm SMTP mail by adding
complexity to the mail system to add functionality which is, for the
vast majority of purposes, undesirable and harmful.

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

You are calling for a mechanism that is significantly more
complicated. Hence is a requirement for community consensus about
needing that extra capability.

Let's back up.  There are two broad requirements for a Proposed Standard
protocol - one is community consensus, the other is technical soundness.
These are independent of one another - a protocol that is shown to not
be technically sound is not suitable for PS even if there is consensus
support for it.   

I should make clear that my review had three purposes:  
First, to make an assertion about the lack of technical soundness of the
current proposal.  Second, to indicate that I'm withholding my support
toward a consensus for the current version of this document for
technical reasons. Third, to make suggestions for changes (that I think
are NOT significantly more complicated than the current proposal) that
would improve the technical soundness of the proposal, allow it to be
more generally applicable, and allow me (and I suspect others) to
support it.

You are correct that the changes I've suggested, if included, would also
require community consensus for the document to be approved as PS. 
However community consensus is not required on findings about technical

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.

Given that you have yet to make a convincing case that this option is
desirable at all, debating the efficiency of the option seems a bit
premature.  But even so, efficiency is not the only issue.  Even if
there is only one recipient per envelope, a sender using this option is
forced to choose between letting intermediaries perform conversions (but
risking delivery failure of messages that would be readable by the
recipient) on one hand, and not allowing intermediaries to
perform conversions on the other.  The sender does not have the
knowledge to know which choice will maximize the potential for delivery
of a readable message. 

You could of course claim that this is also an efficiency issue - after
all, the sender can always send two messages, one with the option and
one without - but this just seems silly when a small change of the rules
will allow the sender to safely grant conversion permission without fear
that this will cause unnecessary delivery failures.

KM> The current definition of this extension makes it essentially
KM> useless when attempting to send mail to any recipient that is not
KM> known in 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

It's not the same at all.  The worst thing that should happen when
you attach a vCard is a bit of wasted bandwidth and a bit of information
that the recipient cannot use.  Similarly for multipart/alternative.

By contrast the worst thing that can happen when you use CONPERM as
currently defined is that a message that could otherwise have been read
by the recipient is needlessly bounced.

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.

No, that's not what I'm focusing on.  I'm focusing on whether CONPERM is
defined appropriately given the inherent limitations of SMTP and SMTP
option negotiation.

KM> I believe the absence of CONNEG information for a recipient should
KM> be treated as if the recipient can support any kind of content, or
KM> (more realistically) that the recipient will either perform any
KM> needed 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?

You are confusing the assertion of CONPERM by the sender with the
presence/absence of CONNEG by the recipient.   What I'm describing is
(IMHO) the proper behavior for a SMTP client which has accepted CONPERM
responsibility when attempting to relay a message to a recipient that
does not support CONNEG.

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.

I don't think this would be sufficient, because I don't think conversion
permission should be an attribute of the message - it should be an
attribute of the envelope.  And clearly the purpose of CONPERM is to
extend limited permission to intermediaries (not recipients) to perform
conversions - recipients have always been able to do what they wished
with messages independent of sender permission.

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

The service you are supporting is already "accidental", especially
against a backdrop of (I'm guessing) tens of thousands of deployed
SMTP servers that don't support it and have negative incentive to do so.
By allowing each body part to be converted independently, I'm trying to
increase the probability that the service will do something useful in
practice rather than simply bounce messages.  

And as implied in my earlier message, I also believe that it's more
realistic to assume that the intermediaries closer to the sender are
able to adapt the sender's wierd formats to more generic ones, and those
closer to the recipient are able to adapt the generic formats to the
recipient's wierd ones, than to assume that the first intermediary that
supports CONNEG can adapt all of the sender's wierd formats to whatever
the recipient can use.

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

The scenario you propose is only slightly simpler, but far less
functional.  And since you mentioned demonstrated need, I have yet to
see a demonstrated need for an extension that acts as you propose.

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,

You are welcome, and it will be interesting to see the precise cases
where we disagree.  I hope it will illuminate the discussion.

KM> 5. Interaction with critical-content indication (RFC 3459) needs
KM> to be 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.

I certainly agree with the general sentiment.  But I don't think it's
reasonable in this case to ignore critical content indication.

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

To me it seems important to not bounce a message merely because a
non-critical content cannot be converted. 

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.

It seems disingeneous to insist on actual experience for features you
don't want to include, and not insist on actual experience for features
you want.  We never have actual experience for new features.  We have to
resort to analysis, and sometimes intiution, to decide whether we think
they'll work well.  In some cases analysis works better than actual
experience because there are some kinds of actual experience - e.g.
widespread failure of mail delivery - that we wish to avoid.

KM> b. Section 1 states that no MDNs will be issued for successful
KM> 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...".

works for me.

KM> d. Servers asserting CONPERM without being able to perform
KM> 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.

I suggest that a statement be added indicating that this is appropriate
only in narrow cases, and that an example or two be added to illustrate
what such cases might be.

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

Where and how?

I think I mentioned these specifically in the detailed change

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

If there is no Content-Convert field, what is the point of having

you could have CONPERM on a message transmission while still not having
content-convert in each body part.

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

Please explain.

I'm wondering if there are kinds of conversions that could not
adequately be conveyed in content-features.  It's just a question, I
really don't know the answer.

<Prev in Thread] Current Thread [Next in Thread>