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 speak as someone who used to sell and support software that did this sort of
thing, both via HTTP and LDAP. I saw plenty of examples of public export of
directory information, including but not limited to user information, through
HTTP, very few through LDAP.
I really can't explain the difference. My assessment was and is that a
carefully designed LDAP->LDAP gateway is likely to be more secure than a random
Web server lashed up to an LDAP server.
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 an aside, I think we actually foster this attitude given the degree and tone
of pushback that's often present in the IETF. For what may seem like the best
of reasons people often have to fight to get their work through the process.
But once that's done you're left with people trained to fight.
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...
Well, let's be fair here: We can lead the horse to water...
I'm probably a bit biased since I wrote a bunch of the text, but I think we did
a reasonable job of documenting the risks of active content back when MIME was
first specified. And yet active content in the form of email viruses is one of
the major operational problems, if not THE operational problem, we face in
email today. We did our bit and nobody listened.
It's quite a conundrum. Even when we do our job things still go wrong. Some
folks argue that things capable of abuse should not be standardized. But there
are substantive and possibly even greater risks associated with the lack of
standardization as well.
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.
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 also discussed the situation where conneg transformation is done by a central
intermediary in a previous message and concluded that there seemed to be
no business case for it.
I should also note that the class of tranformations envisioned by OPES
is considerably broader than the class of transformations envisioned
here.
Ned