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

> > > 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