Subject: AW: [Simple] 200 vs. 202

From: Brazier Lachlan <[email-masked]>
Date: Fri, 9 Nov 2001 12:10:24 +0100

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