Subject: RE: [Simple] Reacting to multiple sources of presence data (was 2 00v202)

From: [email-masked]
Date: Tue, 13 Nov 2001 12:58:57 +0200

Maybe SUBSCRIBE should be treated as INVITE with three way handshake. It is
actually a session in a sense.
This way the subscriber will be able to choose from whom to accept the
notifications.

-------------------------
Avshalom Houri
Software Architect, Lotus Sametime
IBM Software Group

Office +972-8-9409761 X123

                    Jonathan Rosenberg                                                                                        
                    <[email-masked]>        To:     Robert Sparks <[email-masked]>,                         
                    Sent by:                          "[email-masked]'" <[email-masked]>     
                    [email-masked]       cc:                                                                      
                    icsoft.com                       Subject:     RE: [Simple] Reacting to multiple sources of presence data  
                                                      (was 2 00v202)                                                          
                                                                                                                              
                    13/11/2001 00:01                                                                                          

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: Monday, November 12, 2001 12:53 PM
> To: [email-masked]'
> Subject: [Simple] Reacting to multiple sources of presence data (was
> 200v202)
>
> Given that:
>
> * A SUBSCRIBE may fork
> * Multiple endpoints may accept the SUBSCRIBE
> * These notifying endpoints may not have identical
>   presence documents to provide
>
> The root problem is:
> * How do we reconcile the different documents?

Yes, that is the essence of the problem.

>
> There have been a handful of proposed solutions, each
> bringing their own set of additional problems. I think
> these two capture the main flavors of the proposals:
>
> 1) Accept only the notifier who's 2xx was chosen by
>    the proxy mesh to be forwarded to the subscriber.
>    Ignore input from all other notifiers.
>    Rely on configuration of all the elements to provide
>    the "right" presence document.
>    (I think this is the currently documented solution)
>    Problems:
>      * Doesn't allow state aggregation (but maybe that
>        should be a domain-specific application and not
>        something we try to do generically in protocol)

Another problem I pointed out is that the 2xx which was "chosen by the
proxy
mesh" may be a 202, and later be rejected, whereas one of the 2xx which was
not chosen, is later accepted. However, its NOTIFY is discarded.

>
> 2) Accept all notifiers by springing subscriptions into
>    being on receiving NOTIFYs with matching dialog identifiers
>    (but unknown to-tags). Each such subscription exists
>    independently of the others, with its own lifetime and
>    route-set. Rely on configuration of all the elements
>    to provide the "right" set of notifiers.
>    Problems:
>      * How do you resolve conflicts during state composition?
>      * Is the DoS opportunity this creates acceptable?

I'm not sure I understand the DoS opportunity. Can you elaborate?

>      * The configuration necessary to reach the "right" set
>        is very restrictive. (For instance, all the notifiers
>        must be behind the same number of challenging proxies).

I don't see that at all. What has the number of proxies got to do with it?

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "James Undery" <[email-masked]>
Date: Tue, 13 Nov 2001 11:08:10 -0000

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> [email-masked]

> This way the subscriber will be able to choose from whom to accept the

Please read the original thread "200 vs. 202" for why this is a REALLY bad
idea.

James