Subject: RE: [Simple] modeling dispatchers in the data model: a proposal formoving forward

From: "Boyer, David G \(Dave\)" <[email-masked]>
Date: Wed, 22 Dec 2004 08:45:49 -0500

Been thinking about this one a bit and I am not sure we need
something like a dispatcher at all.  If PUAs are publishing
stale data I don't see why the composer should deal with it.
One composer may have rules that don't indicate when a presence
document is stale, another one might. The composer will process
the data it receives without judging it's validity.

some comments inline
> 
> > 
> > I think we are working with the wrong publication model to 
> begin with, 
> > which makes override of service elements problematic. The 
> publication 
> > model is that of a presentity employing a set of PUAs with 
> equal rights 
> > -- no one PUA is more authoritative than another. They are all 
> > publishing their own full view of the presentity's service statuses.
> 
> Actually, there does seem to be a hierarchy, namely that "latest is 
> best", or "most frequent publisher wins".

This hierarchy exists for some composers, not all.  Depends entirely
on the rules the composer uses to process the documents.  Latest is best
may be superceeded by a person rule that was invoked that says ignore 
all future state changes until I make myself available again.  This
should be left to implementers.
> 
> > So I think ultimately, we need a new interface to the 
> composer, call it 
> > root account, that gives us a way to "kill" publications that are 
> > publishing stale event state. Perhaps such an interface could be 
> > provided as part of the composer policy or authorization 
> policy, but I 
> > don't think it necessarily requires uniqueness of service URIs.

What is an example of a publisher that is publishing stale event
state?
> 
> I wouldn't think it requires uniqueness. If you can explicitly yank a 
> tuple, you can much more easily, without worrying about URL matching, 
> yank it by its tuple id handle.

What if the tuple contains information concerning two services - voice
and
IM, voice is stale IM is not.  Do you yank the tuple even though some
of it is valid?  Probably another local policy decision.
> 
> I like the 'root' analogy, although I see this more like a filter: An 
> entity representing the presentity (logically similar to the one that 
> publishes rules, for example) would add a filtering policy. 
> Indeed, in 
> many ways it would probably look similar to the current rules, except 
> without reference to a specific receiver. This could be as 
> simple as two 
> sets of XPath expressions that stipulate the tuples to 
> include and those 
> to remove. For those purposes, you probably want a source 
> identifier or 
> a tuple identifier, not something that is subject to change 
> with every 
> reboot of the PUA, like a GRUU.
> 
> We already assume that we have a central rulemaker that issues 
> non-contradictory privacy rules. This same logical entity would then 
> provide the the composition policy rules. (The data model 
> hints at that, 
> but doesn't say much about the identity of the rulemaker.)
> 
Minor nit - the "central" rulemaker can be distributed - filtering
separated
from composition - different vendors may provide these capabilities.
Dave

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple