None of this experience seems particularly applicable to the question at
hand,
where we are comparing two different mechanisms for exporting only a small
amount of information - SMTP, or some other protocol (of which LDAP is
only a
token example). If an enterprise is reluctant to export "information
about
their users" in general, then they will be about as reluctant to do so
via SMTP
as via some other protocol.
I'm afraid this is another piece of theoretical considerations that fly in
the
face of actual experience. The obvious counterexample is HTTP.
The relevance of HTTP is even less obvious to me because HTTP and directory
services (LDAP or otherwise) tend to be used in very different ways. I don't
see many sites exporting their company directories via either HTTP or LDAP.
Then you haven't looked very hard. The former is quite popular; the latter
practically nonexistant. And the fact that the same information is exposed
either way yet one approach is preferred is directly relevant to the matter
at hand.
Nor do I see how any of this is relevant to the problem of exporting recpient
capability information for content negotiation.
In a rational world it would not be relevant. We don't live in one of those.
I agree that predictability is nice, but that's not something any approach
can
ever guarantee. Indeed, I can argue that a directory approach will lead to
less
predictability, not more, if for no other reason than directory access will
tend to work locally but not remotely. SMTP access with appropriate
caching, on
the other hand, has the potential to work both locally and globally.
The last two statements seem fairly odd. Maybe the problem is the use of the
word "directory" which isn't my favorite word for this anyway. So let's not
call this a directory - let's call it a capability discovery protocol. Now if
the capability discovery protocol is defined in such a way that in order for
your recipients to benefit from content negotiation you have to make it
accessible
(just like if you want to be able to accept mail then you have to make port 25
accessible) then it seems fairly likely that sites that want to enable content
negotation for their recipients will do so.
My point was they may make it available internally but not externally. And
using anything that remotely smells like a directory protocols makes this
outcome far more likely.
On the other hand, port 25 is one
of the few ports that is commonly blocked/filtered for outgoing traffic -
perhaps even more often (and with more drastic filtering) than port 80.
Keith, my point was and is that the minute you start talking about using a
directory protocol -- and I insist on using the term because it's the directory
aspect that's important -- it makes the whole thing problematic in a way that
piggybacking the information on top of other type of protocols does not.
You can talk till you're blue in the face about how this is capabilities
discovery, how that's intrinsicly different from a general directory
protocol, and so on and so forth. It doesn't change the perception that
a protocol intended solely for looking up stuff, no matter how innocuous
that stuff is, no matter how divorced from the cporpoate directory or
whatever it can be made, is somehow more problematic than piggybacking
the exact same information on top of other protocols.
So the argument that a facility that requires direct connection over port 25
(from the origin to the MX server, not necessarily to the final MTA)
in order to work properly (i.e. in order to let the sender control the
conversion) will function both locally and globally seems a bit dubious.
I have pointed out previously that such direct connection isn't required by the
present proposal. So this is nothing but another strawman.
Ned