Re: [anti-spam-wg@localhost] Spam-RBL, anyone?

["Niall O'Reilly" <]

I'm trying to climb down from my high horse, and try the view from
the level of Sancho Panza.  I invite everyone else to join me.

Mouse contributed:
> Anything that depends on a human is reading the entry for correct
> functioning is arguably broken; the reason for having a strict defined
> format is so that the thing is machine parseable.
This is an excellent starting point for building a new system.
The problems I'm trying to highlight arise from re-building the
system _after_ the data has already been loaded.

Originally, the contact data placed in the various whois databases
was, significantly often, read by humans, and carried "intuitive" as
well as "formal" semantics.  This was fine, because the community of
interest was small enough to have a high level of shared assumptions
about how to interpret and use the data.

Over the years, the need to support increasing automation of network
administration has led to a number of re-workings of the formats and
methods of maintenance used to manage the contact data kept in the
whois servers.  In addition, the semantic payload of some of the
fields has been refined in ways that have seemed appropriate.  This
has, however, occurred without sufficient attention to whether the
data already carried in those fields could support the new semantics.

The result is that, although we can now parse the fields reliably,
we don't have a sufficiently well-agreed and well-documented under-
standing of what are the limits to their use. We are also quite happy
to build robots based on arbitrarily chosen semantics for these fields.

This is not to say that the robot-builders (in interpreting the data)
and network-administrators (in advertising the data) are perversely
assuming semantics which are unreasonable, but rather that none of us
has a map which shows the boundaries.

In such circumstances, misunderstandings are certain to arise.

As one expert put it to me in an off-list message:
> well, the problem quite certainly is more on the side of
> - constraints of the encapsulation or
> - insufficient guidance/documentation on how to code/interpret relevant
>   information
Please, let's not rush into a new _activity_ (such as yet another 
directory
service), before we've _thought_ seriously about the problem (if any) 
which
underlies the divers perceptions apparent (if cloudily) in the recent 
postings.

I've asked for some time at the next Anti-Spam WG meeting.  If we can 
just
identify the issues, and determine one or two next steps, I'll consider 
it
a success.

Best regards,

Niall O'Reilly