Subject: RE: [Simple] 200 vs. 202

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 9 Nov 2001 15:28:12 -0500

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Thursday, November 08, 2001 11:48 AM
To: 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 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.

You seem to have answered your own question - you ensure the tuple IDs are
unique by requiring it in the specification.

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

Each tuple is unique; you should not be in the case where you get the same
tuple, with the same ID, from different sources (say, one an aggregator, and
the other the source of the state itself) but with different data (i.e.,
different online/offline values).

The issue that makes this complicated is that the right view of the presence
state of the presentity may NOT be the aggregation of the state of each of
its elements. Policy is usuallly injected to filter information, for
example, to change the contact ID from a host specific one, if one was used
(sip:[email-masked]) to a domain level one (sip:[email-masked]). That policy is
ideally placed in the domain of the presentity. That is why I believe that
you want to put aggregation there whenever possible. However, the mechanism
I have proposed allows things to at least sensibly work if there is no
centralized presence server in a domain, where the subscribers perform the
aggregation.

-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: [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]] 
> 
> 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