ned+ietf-smtp(_at_)mrochek(_dot_)com wrote on 13.07.02 in
<01KK1HVAM6PU000O32(_at_)mauve(_dot_)mrochek(_dot_)com>:
I think this is a fine piece of theoretical analysis which unfortunately has
no applicability to the real world. In the real world directory/database
systems that let sites provide Internet-wide access to information about
their users do not deploy.
I'm not sure why this is the case, and indeed I'm fairly sure that there is
no good reason for it, but a vast tract of experience tells me it for-sure
is the case. (Now is not the time to get into whys in more detail.)
I'm pretty sure that *one* important reason is that a "directory service"
actually serves two rather distinct functions, and trying to do both with
the same protocol works fine in an intranet but is insane in the Internet.
Those two functions are
(1) Find out attributes of a particular user (this seems to be what RESCAP
does)
(2) Search for a particular user matching some conditions about his
attributes ("Who is the CEO for Apple?" "Give me a list of all people at
Microsoft named John Smith")
Note that the first does not necessarily (depending on protocol design)
give you any method to, for example, locate valid user addresses to spam.
The second, OTOH, does so by design.
Obviously, you may (in the Internet, as opposed to an intranet) want to be
the restrictions for (1) to be radically different from those for (2). For
example, (1) may be configured explicitely for a few mailboxes and just
use the equivalent of a wildcard MX for the rest ("most accounts here
don't want to receive HTML, but it is ok for our press officer"); whereas
(2) might be configured to just list those few role addresses you want
public contacts to go to (presumably the exact same addresses you list on
your web pages), and not advertize anything at all about any other
address.
MfG Kai