Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard

At 01:53 AM 7/2/2002 -0400, Keith Moore wrote:
>executive summary:  I recommend  against approval of this document
>withut extensive changes.  It's not well thought-out

What additional thinking out are you looking for?


>  (except for the rather narrow application of SMTP to a one-recipient fax 
> gateway)

In fact the motivation for it is not necessarily a gateway, but rather any 
recipient environment that conforms to this profile, including usage that 
is wholly retained among Internet-capable participants.

For that matter, the mechanism applies on a per-recipient basis, so what 
prompts the claim that it works only for a single recipient?


>and it seems likely to degrade SMTP interoperabliity if widely adopted.

How will that happen?  How is it likely?


>1. layering problems
>
>this functionality is a poor fit for SMTP because SMTP is the
>mail *transport* protocol, and as such should not be dealing
>with content at all, which is a user agent function.

The construct of using SMTP to verify support of a higher level feature is 
not all that different from DSN.  What is the practical problem with 
applying it here?


>but what's to stop this mechanism from getting out-of-sync also?

The end-to-end asynchrony and latency for this mechanism certainly do 
provide an opportunity for a recipient's capabilities to change, after it 
has advertised a particular set.  However the key point to note is that 
there is no mediating storage/directory service, so the advertisement has a 
degree of directness not possible through any other mechanism.

For recipients concerned about such volatility, all they have to do is 
refrain from advertising CONNEG support.  For senders concerned about such 
volatility, they should use CONNEG=Required.


>it seems like this extension has very limited applicability - it will
>only work reliably when the SMTP server and user agent or gateway are
>very closely tied and when the recipient always uses the same UA
>or UAs of very similar capabilities.  (certainly not true of me!)

1.  The specification already highlights that it is tailored for rather 
'direct' scenarios.

2.  Each user can decide what to advertise.  If they vary their UA they can 
choose to advertise a safe and lesser set of capabilities.  In any event, 
it is their choice.  The mechanism does not impose any problems that are 
not inherent in use of multiple UAs.  However it DOES permit relatively 
direct advertising of capabilities, which is currently not feasible.


>but if we're going to extend SMTP to perform functions
>on behalf of the user agent, it needs to be made very explicit that this
>negotiation is being done on behalf of the user agent - and in particular
>that the negotiation being requested represents the preferences of the
>*user*

In what way does that affect the technical specification?

That is, how is the current specification deficient, with respect to your 
concern?


>in particular there seems to be no
>ability to apply content-transformation on a per-recipient basis,
>to handle the case where different transformations are acceptable to
>differnet recipients.

We must be reading different specifications.  Choice of enforcement of this 
option is per-recipient.  Each recipient may generate a capabilities 
response if they wish a different form of the content.

What, exactly, are you looking for that is missing?


>of course it's not easy to get SMTP to handle different client-side
>transformations for different recipients, since SMTP is designed to
>transfer the exact same message body (modulo received fields) to each
>of a set of recipients.

It sounds as if you are assuming that later transmission of content that is 
revised according to capabilities information is required (or expected) to 
be sent using that same address list.

That is like requiring that all BCC copies are sent along with the TO and 
CC copies.

In other words, there is not such requirement.  It is OK to do it and it is 
OK not to.

Yes, the current CONNECT option is intended to send the same content to all 
recipients, since that is the style of SMTP.  There is nothing preventing 
later sending an alternative content form to selected recipients.

Interestingly, this would not actually create any additional round-trips or 
additional content transfers.


>  this is a different model than used by
>phone-based facsimile protocols which expect there to be only one
>recipient of any given transmission,

You might want to take a look at fax broadcasting services.  The last-hop 
telephone portion behaves as you describe, but only after a 'generic' 
posting process.

>  so it's not surprising that the fax-style negotiation doesn't fit well 
> into SMTP.

Actually, the proposed scheme permits content transmission tailoring that 
is considerably more flexible than is typical in the real fax world.


>in order to make client-side negotiation a clean fit into SMTP, it is
>necessary for the client to first query the server for the capabilities
>of each intended recipient, then to deduce how many total transformations
>are necessary, then to send one or more transformed versions of the message.

Ahh.  I see.  You want to insist on an interaction scenario that is known 
to be unacceptable, since it is guaranteed to introduce too much delay 
before there is any utility at all.


>   overloading the RCPT
>command to return capabilities breaks the RCPT command and forces
>the client to do RSET in order to send different versions to
>different recipients.

If that is what the client chooses to do, then yes.  However there are 
other courses of action available.  At the least, note that the content is 
not sent until the client has CONNEG responses about all of the recipients.


>putting content negotiation in the transport protocol is likely
>to result in a significant increase in anomolous behaviors
>from the mail system which are difficult to diagnose and fix -
>and the proposal is being introduced at a time when the mail system
>is already suffering from serious reliabliity problems (often due
>to ill-conceived measures for blocking spam).

How does use of the CONNEG mechanism affect reliability or accountability?


>   at this time,
>*any* proposal for adding new functionality to SMTP should be viewed
>with strong reservations, unless it somehow offers an improvement
>in reliability.

I was not aware that we had any problems being attributed to SMTP 
options.  Please provide some citations, so we can compare their details to 
the current proposal.


>4. naming and applicability
>
>the protocol claims to be a general-purpose content-negotiation scheme
>but actually has "fax" assumptions embedded very deeply.

The fax world is the basis for the idea, yes.  However the specification 
has been done so as to be independent of fax, thereby using an approximate 
model that is known to be useful from the fax world and then applying it 
for general enhancement of email.


>first of all, it assumes that there is a linear ordering relationship
>for document suitability to the recipient.

Ok.  I give up.  I have no idea what "linear ordering relationship for 
document suitability" means.


>a.  I strongly recommend that you redesign this extension so that, instead
>of overloading the RCPT command, you define a separate command to
>request a recipient's capabilities.  e.g.

In spite of the proffered benefits of a separate command, I fail to see how 
it produces any real benefits.

It certainly does not make anything simpler, and it certainly vastly 
increases relay delay, due to nearly doubling the round-trip exchanges 
during an SMTP session that uses the option.


>one nice side-benefit is that it doesn't change the error handling
>model,

How does the current proposal change the error handling "model"?


>b. the idea that the sender should send the "best" or "highest
>quality" version needs to be relaxed or generalized,

It already has been relaxed.  Note the SHOULD rather than MUST.


>  since there's currently no clear notion of what this means.

Yet we have lived with that notion in multipart/alternative for some years.


>c. this extension needs to be made less fax-specific.

What, specifically, makes it fax specific, and what changes are you 
specifically seeking that will be less fax-specific?


>it needs to be examined with some realistic non-fax-specific
>test cases, and it needs non-fax conneg examples also.

Test cases are always a good thing.  Feel free to offer some that satisfy 
your non-faxiness goal.


>d. there needs to be a good way for the recipient to specify
>capabilities to the SMTP server, at least for any SMTP server
>that can serve arbitrary UA recipients.  probably this means another
>extension along with SMTP AUTH.

You want to require that that mechanism be in place before the current 
specification can be advanced?  I think the phrase "chicken and egg" works 
here.  You create a deadly embrace for reaching any utility.


>still, this is a big can of worms, because there's never been
>any ability of a UA to specify something to its inbound SMTP
>servers before - there's presently not even a good way for
>a UA to know which server(s?) should be given this information...

Think hard.  What is likely to drive creation of such a 
mechanism?  Requiring that it be built in the abstract or looking for it to 
be built in reaction to actual demand?


>e. make it absolutely clear that such transformations are only to be
>made with explicit authorization by the sender and/or recipient.

This sort of parental direction in IETF specifications probably does no 
harm, but it is difficult to imagine that it does much benefit.


>f. the document needs to consider the effect of message forwarding
>on the returned string - if a recipient has his mail forwarded
>elsewhere it's not clear what conneg string should be returned.

There are all sorts of implications in forwarding.  In general, forwarding 
that is not simply SMTP relaying is outside of current IETF 
specification.  Imposing a requirement about it here, without demonstrating 
actual problems, is a tad extreme.


>g. the document alludes to the ability to work through intermediaries
>but this isn't explained anywhere, and it needs to be explained.

All it says is that it works with SMTP relaying, just as one would expect 
and SMTP extension tow work.


> > 4.2 Client Action:
>...
>this incorrectly assumes that (a) there is only one target when
>the client can easily specify multiple RCPT commands, and
>(b) there is a clear notion of "highest level of capability"
>for the target.

It does not make the assumption you suggest.  In fact, I can't imagine how 
you came to the assessment that it makes that assumption.


> > 4.3 Server Action:
> >
> >      If the client specifies "CONNEG = REQUIRED" in the RCPT-TO,
> >      but the target does not support the CONNEG parameter, the target
> >      MUST reject the RCPT-TO command with a 504 reply.
>...
>(it may be that other extensions have similar wording, in which case
>they're similarly flawed)

It is probably a good idea that we not try to fix SMTP (yet again, given 
the protracted drums effort.)  And it certainly is not a good idea to 
require that the current specification fix something this vague when no 
SMTP-related specification is required to.



> >      If the client specifies "CONNEG = OPTIONAL" in the RCPT-TO, the
> >      target MUST process the address and message as if the requested
> >      CONNEG capabilities had not been specified.
>
>this doesn't seem to make sense as written.  is "CONNEG = OPTIONAL"
>really supposed to be interpreted the same as omission of the
>CONNEG parameter?

I think that the text that is in the first paragraph of that section ("but 
the target does not support the CONNEG parameter") got deleted during 
revision.  In general, those first 3 paragraphs are dealing with lack of 
support, whereas the following paragraphs are dealing with presence of support.


>also, I don't think there should be spaces around the = sign -

ack.


>I wonder here - assuming that this can of worms does not get closed
>back up, and there might later be demand for other mechanisms
>to request recipient capabilities (e.g. since this one is not very general),
>might there be multiple kinds of strings emitted in the RCPT response?

Please indicate what capabilities are missing from this capabilities 
mechanism that would make it more general and for which there is a 
demonstrated need.

d/

----------
Dave Crocker  <mailto:[email protected]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.850.1850