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.
what can I say - most of the company directories I've seen are not publically
accessible. I don't doubt that many companies use HTTP to provide internal
access; whether they make them available to the general public (which is what
I meant by "export") is a different question.
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.
ah. okay, I think we're in agreement about that (and that was very similar
to my point about LDAP) - though whether this capabliity discovery protocol
smells like a directory protocol may to some degree be a matter of social
engineering, aka marketing.
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.
well, if *we* insist on calling it a directory protocol then of course people
will confuse it with other things they call directories. On the other
hand sites seem happy to consider exporting limited information via DNS,
and extensive information via HTTP, SOAP, .NET, or whatever. So if the
marketing lingo has to be "recipient capability web service" or some such,
so be it. (as long as we don't actually *use* SOAP or .NET... :)
as to whether rescap would be branded a directory - the number of people who
kept insisting that it should be LDAP was fairly significant, indicating
that many people couldn't readily distinguish the two problems. this
even though one of the major reasons for making rescap a separate protocol was
to distinguish it from directories and specifically to have a mechanism
tailor-made for exporting public information. but frankly part of that problem
was that some LDAP people were seeing rescap as a competitor/threat to LDAP.
as you say, it's not a sane world. URNs have an even worse mis-perception
problem, they always have, and it's not clear what to do about it.
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.
okay, I'll concede the point that there's this dark cloud over things
that (in the minds of network administrators) resemble directories.
I don't think that should by itself stop working groups from using things
that resemble directories if that's the right technical solution,
but it's useful to be aware of it. it does I think illustrate that good
technical design is not always sufficient - unless we somehow convey
to users an understanding of new protocols, how they're meant to be used,
the risks associated with using them, etc. And we haven't been very
effective at that since the 'net grew up...
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.
ah, but either the client has a direct connection to the MX or it has to
relay the message to some MTA which may or may not be under control of the
client. so the relaying case introduces the same problem that OPES had
when it was first proposed - that of having an intermediary make transformations
to the content that aren't authorized by either party of the conversation.
Keith