Subject: RE: [Simple] modeling dispatchers in the data model: a proposal f or moving forward

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Tue, 21 Dec 2004 04:53:27 -0600

Hi Aki,

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

Can you make a concrete proposal. Is this an automatic thing or manual thing
What are the triggers to this animal whatever it is, and who can invoke it

> These steps should guarantee that the watcher can always make 
> a proper 
> selection of which service to invoke. Invoking the service 
> then involves 
> more than a simple "clicking the contact", since in the case 
> of SIP the 
> watcher generally will e.g. construct an SDP offer that matches the 
> service that the watcher thinks the tuple is describing. I 
> believe the 
> invoking of a service MUST work using an AoR. If an INVITE offering 
> voice ends up served by a chess application, I think the system is 
> utterly broken, and needs to be fixed. One fix could be using 
> GRUUs as 
> contacts, but that is not the only fix, and may not even be the best 
> one, IMHO.
> 

The only way to click the contact and guarantee to reach the intended service is to either have a distinct service-URI per service ( as suggested in the current model) or use caller/callee preferences, (with require parameter).

Do U agree ? and why can we not have both options.

Rgds/gf

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