Distribution tag

[David Arnold]

-->"Julian" == Julian Boot <julian at dstc.monash.edu.au> writes:
  Julian> "Phillips, Matthew" wrote:

  >> I can't see why producers shouldn't include hints as to how
  >> useful a message is to a given domain of use.  Clients can still
  >> opt to receive everything if they want to.

  Julian> not if those notifications we dropped a few hops ago because
  Julian> a federator used them as "a hint for distribution across
  Julian> federations".

in *general*, this is no different from a federator dropping them
because they were to the "frobnitz" group, which was not forwarded a
few hops ago.

  Julian> this is a general elvin-philosophy: producers should never
  Julian> attempt to second guess how a notification will be used.

that's true.

there's also: producers should feel free to put whatever information
they feel relevant into their notifications.

and: consumers should feel free to subscribe to any property of
available events.

  Julian> The differnce between a Domain tag and a Destination tag is
  Julian> that the former describes something about the producer while
  Julian> the latter describes a property of the consumer.  The latter
  Julian> is Bad(tm) in elvin...

i think this is the core of the issue.

there's nothing wrong with producers adding any information they have
to the notification.  inter-domain links are free to filter whatever
they like, using whatever fields they like.

in this case, the producer is expressing an opinion about the
relevance of the data produced.  it is perhaps poorly expressed, but
the intention is ok, imo.

but ...

a field value of "local" is not very meaningful in a global context.
while in the majority of cases the end result is the same (ie. they'll
get dropped at the admin boundary), if they are not dropped, a value
of "local" (or any other geographically relative term) is meaningless
at best (and misleading at worst).

use of a domain tag is slightly dubious because it reduces anonymity.
it's also not clear that it enables the same conceptual functionality.

use of a security key would allow universal routing, but requires
pre-distribution of the key (unlike a distribution tag).

use of a list of "domains" in which the info was valid/relevant
(ie. "dstc,qld,au,world") *might* achieve what was desired, but it's
not clear if there was an hierarchical containment implicit in the
values from "local" to "world".

  Julian> perhaps bill could explain exactly what goal the
  Julian> Distribution tag is aimed at delivering?

i guess there's some scenario that triggered this request, which might
be worth some more detail.  i'm not convinced that a Usenet-style
"Distribution" tag is a useful addition to Tickertape, at this stage.


perhaps this whole debate is symptomatic of the basic clash between
between filtering and content-based routing?  any gateway that
explicitly filters traffic hinders CBR.  the name of the property used
to do so is not really important.





d