ietf-smtp
[Top] [All Lists]

Re: Keywords for "SMTP Service Extension for Content Negotiation"

2002-07-15 01:59:48

The case I was thinking of was the one where caching of conneg information 
by
intermediaries eventually brings the information back to the server 
adjacent to
the originating client. So the transformation is still done on the 
originating
client or on a server very close to it.

I think it's a stretch to believe that caches are going to solve this problem.
It's true that if A keeps sending messages to B then eventually A's MTA will
be able to cache B's recipient information.   But this assumes that the
intervening MTAs support CONNEG (and cache CONNEG information) - which itself
seems like a stretch because, as you say, there's no business case for them
doing conversion.

What's a stretch is your assumption that caching implies conversion
capabilities. They are completely different activities. Conversion by an
intermediary is a nasty mess, whereas caching conneg information is trivial.

It's also a stretch to believe that this is going to work well
for arbitrary pairs of senders and recipients - it might work for those pairs 
who
exchange lots of messages, not so well for those pairs that occasionally 
exchange
messages.

That's certainly a possible outcome. But you can game this in all sorts of ways
and reach various different conclusions.

And of course there's the problem that CONNEG information can be
expected to change over time, but there's no mechanism in the current proposal
to timeout caches.

I've already indicated that I believe conneg information caches are something
that needs to be discussed.

Frankly the method of returning capabilities in a bounce
message seems more effective and more reliable because it doesn't rely on
intermedaries.

The problem I see with depending on notifications is another one of those
"looks good on paper" things: For whatever reason, support for sophisticated
handling of notifications has been slow to materialize in user agents.

The only way I see to make the CONNEG SMTP proposal work end-to-end is for
all of the intermediate MTAs (those that don't have direct knowledge of the
recipient capabilities) to open up SMTP connections to the next hop *in real 
time* -
so when the sender asserts CONNEG in a RCPT command then the MTA has to stop
acting like a relayer and start acting like a proxy - finding a MTA for the
next hop, opening up a connection, sending EHLO and seeing if it supports
CONNEG, sending MAIL and all previous RCPTs, and finally sending the RCPT
that has the CONNEG option, just so that it can propagate the CONNEG response
back to the sender's UA.  Even then it will be very slow, it introduces
race conditions due to timeouts, and it still requires all of the intermediate
MTAs to support CONNEG in proxy mode.

This scheme was actually discussed and I believe rejected in the FAX WG
some time ago. Regardless, I disagree with your assessment that this is
a requirement for the present proposal to be effective.

I haven't followed the fax discussions, but weren't the fax people looking for
a mechanism that would work predictably and reliably - e.g. if sender and
recipient both have (say) high-res capability then the document is always
transferred in high-res - and a mechanism that would give the sender the 
option
of requiring that the recipient have certain minimum capabilities before 
sending
the message?  (e.g. don't bother sending if recipient doesn't have color?)
I just don't see a way to make that work through the existing SMTP 
infrastructure.

I'm sure there are plenty of places in the present infrastructure where this
scheme won't work well. I'm also sure there are plenty of places where it will.
My assessment of the notification scheme is roughly the same. And experience
should inform us that our ability to predict what portions of the
infrastructure will be upgraded is pretty limited.

The bottom line is that we're dealing with partial solutions in every case
here. This makes it easy to criticize any given scheme. IMO this also makes it
very much the WG's call as to how to proceed.

                                Ned

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