Subject: RE: [Simple] 200 vs. 202

From: "Brian Stucker" <[email-masked]>
Date: Thu, 8 Nov 2001 10:48:06 -0600

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