Subject: AW: [Simple] 200 vs. 202

From: Brazier Lachlan <[email-masked]>
Date: Thu, 8 Nov 2001 05:30:08 +0100

Hello,

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 reasons mentioned below.

Cu
Lachlan

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

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

>Seems dangerous to allow the watcher to take NOTIFY messages that it
didn't
get the 2xx 
>response for. What is the watcher going to do if the notifications that
it
receives don't 
>mesh, ie.:
>- one PA says a contact is online, the other says it's offline? 

You shouldn't be receiving presence data for the same contact from two
different PUA. In fact, each PUA would generate a presence document with
tuples with distinct id's. Since the id's are chosen randomly, you'd
have to
actively be trying to cause an overlap to occur.

>- a PA says the subscription is pending, and is an aggregator of the
PUA's,
but another PA 
>says the subscription is active, and is not an aggregator?

There would be multiple active subscriptions, one for each PA which
generated a NOTIFY.

>I think you need to have some sort of order of precedence for the
watcher
to be able to 
>process the notifications correctly. Before your order of precedence
rules
were pretty 
>simple: if the tags match, take it, otherwise don't. Now, you've opened
yourself up to all 
>sorts of new complexities.

All of this is covered under sip-events. I don't see any precedence
issues.

>
>Hmmm... There's got to be a better way... 

The better way is to have aggregating presence agents. But, since we
can't
guarantee that, I think this kind of treatment may be needed.

-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

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

---

From: [email-masked]
Date: Thu, 8 Nov 2001 10:09:55 -0600

> From: Brazier Lachlan [mailto:[email-masked]]
>
> 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