Subject: AW: [Simple] 200 vs. 202

From: Brazier Lachlan <[email-masked]>
Date: Sat, 10 Nov 2001 00:58:39 +0100

Hello,
thanks, I think I got the point about the tuples. Just two questions:

1) Why should I ever accept a NOTIFY from a client I have never heard off?
This will be the case for every client which 2xx response didn't reach me.
The difference in the NOTIFY will be in the Tag of the To header and the
Contact header.
As the draft would say, I SHOULD accept several NOTIFY's, this might not be
a big problem. YES/NO????
But it leads to my second question

2) Where do I send my re-Subscribe. To the first address, or to all the
Clients I collected through the Contact headers in the NOTIFY's.

If I send it to the first address, I ignore the Contact header(s). Is this
how it should be? I don't think so.

If I send it to the addresses collected through the Contact headers, will my
Subscription still be the same as the first one? I'm not sure, but maybe.
Thoughts?
One thought I got: 

UserA subscribes for userB. A proxy forks the SUBSCRIBE request to userC and
userD. Both send a 2xx response. Both send a NOTIFY with their Contact
headers. When userA re-subscribes, does he end up subscribed to userC and
userD instead of userB? Probably not when Authentication includes the To
header. But then I wont be subscribed to userB anymore as well, which leads
me to the case before - I need to ignore the Contact headers to stay
subscribed to userB.

And what happens if userC will accepts my Subscription? Am I subscribed to
userC instead of userB?

Any thoughts to this?

Cu 
Lachlan

-----Originalnachricht-----
Von: Jonathan Rosenberg
An: 'Brian Stucker'; Brazier Lachlan; adam.roach; Brazier Lachlan; Jonathan
Rosenberg; ''James Undery' '; Robert Sparks; ''Moran Tim (NET/Dallas)' ';
''Ngo, Dai (c)' '; ''ext Paul Kyzivat' '
Cc: ''simple' '
Gesendet: 09.11.01 21:43
Betreff: RE: [Simple] 200 vs. 202

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Friday, November 09, 2001 11:03 AM
To: Brazier Lachlan; adam.roach; Brazier Lachlan; 'Jonathan Rosenberg ';
''James Undery' '; 'Robert Sparks '; ''Moran Tim (NET/Dallas)' '; ''Ngo,
Dai
(c)' '; ''ext Paul Kyzivat' '
Cc: ''simple' '
Subject: RE: [Simple] 200 vs. 202

>If the user has a PA in each of their clients, and we fork the
subscribe,
you're going to 
>get the presence view from each client. Given, they're *supposed* to
know
the picture for 
>the entire user if they're a PA, but there's no way of really
guaranteeing
this unless you 
>have a presence server (and thus, don't fork).

Right. That has been the issue. Each device will only know its own
state.

>If you take a quick look at the cpim-pidf format of the presence
document,
you'll see that 
>you get a tuple for each client device that the user has, so you'll
wind up
with a 
>different presence state for each client the user has. This presents
some
interesting 
>problems trying to come up with a single view of what the user's
presence
status is as a 
>result. Which client device presence tuple represents the user at any
given
time? What 
>rules do you use to come to an overall conclusion as to the user's
presence
state?

There is nothing in the model of the presence system that says you are
supposed to generate a single online/offline state that represents the
presentity. In fact, the model in rfc2778 specifies that the state of a
presentity is a collection of tuples, each of which is a communications
means, contact address, and status. However, nothing in the model
prohibits
an aggregator from modeling a presentity with a single (or even no)
contact
addresses and a single piece of state.

-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

-----Original Message----- 
From: Brazier Lachlan [mailto:[email-masked]] 
Sent: Friday, November 09, 2001 5:10 AM 
To: Stucker, Brian [NGB:B635:EXCH]; adam.roach; Brazier Lachlan; 
'Jonathan Rosenberg '; ''James Undery' '; 'Robert Sparks '; ''Moran Tim 
(NET/Dallas)' '; ''Ngo, Dai (c)' '; ''ext Paul Kyzivat' ' 
Cc: ''simple' ' 
Subject: AW: [Simple] 200 vs. 202 

Hello! 
  
Wait a moment. What are we talking about? I always thought we are
talking 
about _USER_ presence, and NOT about the presence status of the clients
of 
the user. 
  
If you subscribe to the clients, as the xml scripts below indicate, you
tell

everybody who can be authenticated, where the user is available. I
always 
thought one intention of SIP was, to hide the exact position of the user

behind the user's url, meaning, not needing to know where exactly to
send 
the requests.  
  
!!!! Please correct me if I'm wrong !!!! 

Regarding the two xml scripts below: 
  
For the first one, I would need to tell a GUI that there are several 
"entities" (= clients) for the user, and I have the states of the
_clients_.

For the second one, I would just change the state of the _user_ in the 
sequence, as the xml script is processed. I do realise, that I ignore
the 
priority flag. 
  
Cu 
Lachlan 
-----Ursprüngliche Nachricht----- 
Von: Brian Stucker [mailto:[email-masked]] 
Gesendet am: Donnerstag, 08. November 2001 17:48 
An: adam.roach; 'Brazier Lachlan'; 'Jonathan Rosenberg '; ''James
Undery' ';

'Robert Sparks '; ''Moran Tim (NET/Dallas)' '; ''Ngo, Dai (c)' '; ''ext
Paul

Kyzivat' ' 
Cc: ''simple' ' 
Betreff: RE: [Simple] 200 vs. 202 

If your presentity is split across multiple PA's (which to me is a
dangerous

game), how do you ensure that the tuple ID is unique for each presence 
tuple? This is a requirement of the cpim-pidf-01 draft. 
If the tuple ID is kept unique across the presentity, I can't argue with
the

fact that it's pretty straightforward to aggregate as you're suggesting 
below. However, in your example, each PA has a disjoint subset of the 
presence information. What if one of them was a presence server that had
an 
aggregation of presence information? Then what? 
Regards, 
Brian Stucker 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked] 
<mailto:[email-masked]> ] 
Sent: Thursday, November 08, 2001 10:10 AM 
To: 'Brazier Lachlan'; 'Jonathan Rosenberg '; Stucker, Brian 
[NGB:B635:EXCH]; ''James Undery' '; 'Robert Sparks '; ''Moran Tim 
(NET/Dallas)' '; ''Ngo, Dai (c)' '; ''adam.roach' '; ''ext Paul Kyzivat'

' 
Cc: ''simple' ' 
Subject: RE: [Simple] 200 vs. 202 

> From: Brazier Lachlan [ mailto:[email-masked] 
<mailto:[email-masked]> ] 
> 
> Concerning accepting multiple NOTIFY's. I don't like the idea that the

> subscriber must determine the state of the presentity. I 
> think it's the 
> responsibility of the presentity, to tell the state it is in. 
> Otherwise I 
> really don't believe, that the presentity status can be 
> handled correctly... 
For the multiple-NOTIFY case, the subscriber only needs to 
do what it would normally do for a single NOTIFY. The way 
that the presence documents are structured, there are multiple 
tuples presented that must be sorted out and rendered in 
some fashion. 
If the body of presence NOTIFY messages contained, for 
example, a single value of "TRUE" or "FALSE," then your 
arguments might bear weight. However, as it stands, a single 
presence document can (and, in my experience using our own 
presence systems around our department, usually will) contain 
multiple tuples of presence information, each of which 
has its own state and a unique ID. 
When this information arrives from different sources, figuring 
out what to do with the tuples from multiple NOTIFY messages is 
precisely the same problem as figuring out what to do 
with mutiple tuples from the same NOTIFY message. 
Consider the following document: 
<presence xmlns="urn:ietf:params:cpim-presence"> 
  <presentity id="sip:[email-masked]"/> 
  <tuple id="0x12345678"> 
    <status>\n" 
      <value>OPEN</value>\n" 
    </status>\n" 
    <contact priority="1">sip:[email-masked]</contact> 
  </tuple> 
  <tuple id="0xaaaabbbb"> 
    <status>\n" 
      <value>OPEN</value>\n" 
    </status>\n" 
    <contact priority="2">sip:[email-masked]</contact> 
  </tuple> 
  <tuple id="0x11111111"> 
    <status>\n" 
      <value>CLOSED</value>\n" 
    </status>\n" 
    <contact priority="1">sip:[email-masked]</contact> 
  </tuple> 
</presence> 
How would your processing for this document differ from receiving the 
following three documents from three different sources? 
<presence xmlns="urn:ietf:params:cpim-presence"> 
  <presentity id="sip:[email-masked]"/> 
  <tuple id="0x12345678"> 
    <status>\n" 
      <value>OPEN</value>\n" 
    </status>\n" 
    <contact priority="1">sip:[email-masked]</contact> 
  </tuple> 
</presence> 

<presence xmlns="urn:ietf:params:cpim-presence"> 
  <presentity id="sip:[email-masked]"/> 
  <tuple id="0xaaaabbbb"> 
    <status>\n" 
      <value>OPEN</value>\n" 
    </status>\n" 
    <contact priority="2">sip:[email-masked]</contact> 
  </tuple> 
</presence> 

<presence xmlns="urn:ietf:params:cpim-presence"> 
  <presentity id="sip:[email-masked]"/> 
  <tuple id="0x11111111"> 
    <status>\n" 
      <value>CLOSED</value>\n" 
    </status>\n" 
    <contact priority="1">sip:[email-masked]</contact> 
  </tuple> 
</presence> 
If your answer is "not at all," you've defeated your own argument. 
If your implementation *would* have a problem with the three 
separate messages, but be able to handle the first, large message 
just fine, I'd be extremely curious for you to explain why. 
/a 
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple