Subject: [Simple] Presence Data Model: how pres and sip URIs mix & match ?

From: "CORVOYSIER David RD-MAPS-REN" <[email-masked]>
Date: Fri, 15 Oct 2004 10:24:18 +0200

Hi,

First of all, I would like to say that the Presence Data Model draft is
a very good document that will provide a solid ground for future
discussions. 

I am in particular very interested by the separation between person and
service, because it clearly states that presence is an information to be
shared by many services.

Now I am a bit puzzled by the way presence URIs and SIP URIs interact.

For instance, imagine a user who has a presence URI and two SIP URIs
corresponding to two services:
pres:[email-masked]
sip:[email-masked] (AOR for the ptt service)
sip:[email-masked] (AOR for the IM service) 

In an ideal world, each service would publish the following:

        <presence xmlns="urn:ietf:params:xml:ns:pidf"
            entity="pres:[email-masked]">
          <tuple id="sg89ae">
            <status>
              <basic>open</basic>
            </status>
            <contact>sip:[email-masked]</contact>
          </tuple>
        </presence>   

        <presence xmlns="urn:ietf:params:xml:ns:pidf"
            entity="pres:[email-masked]">
          <tuple id="sf77ah">
            <status>
              <basic>open</basic>
            </status>
            <contact>sip:[email-masked]</contact>
          </tuple>
        </presence>   

Both tuples would then be aggregazted by the PA and notified to the
watchers that have subscribed to the presence of
pres:[email-masked].

Now, existing IM and PTT clients don't allow to specify both an AOR and
a presence URI. They would then probably publish the following:

        <presence xmlns="urn:ietf:params:xml:ns:pidf"
            entity="sip:[email-masked]">
          <tuple id="sg89ae">
            <status>
              <basic>open</basic>
            </status>
            <contact>sip:[email-masked]</contact>
          </tuple>
        </presence>   

        <presence xmlns="urn:ietf:params:xml:ns:pidf"
            entity="sip:[email-masked]">
          <tuple id="sf77ah">
            <status>
              <basic>open</basic>
            </status>
            <contact>sip:[email-masked]</contact>
          </tuple>
        </presence>   

In the same way, watchers may subscribe to the presentity's presence
specifying the SIP URIs rather than the presence URI.

This leads to the following questions:
- is the presence agent allowed to aggregate the two tuples (assuming
that the PA is perfectly aware of the fact that the three URIs relate to
the same presentity) ?
- what URI will be inserted in the entity attribute in notifications ?
- are watchers allowed to subscribe to the SIP URIs instead of the
presence URI ?
- in that case, will the watcher receive all presence tuples or only
those associated with the corresponding service (I assume here that the
entity attribute would in both cases correspond to the SIP URI that was
requested in the subscribe). 

Thanks in advance for your kind answers (and my apologies if this has
been answered before ! I am sort of a newbie to this list, despite I
have been working on presence for some years now ...)

David Corvoysier
France Telecom Research & Development
Enabler For Integrated Services Laboratory
Communication & Presence Platforms Team

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Oct 2004 16:12:48 -0400

> sip:[email-masked] (AOR for the IM service) 

Do you imagine it this way as a pleasant dream, or as a nightmare?
Does the user *want* all these addresses, or is he just forced to have 
them?

I see this as like having a separate phone number for phone and fax. It 
is at best a necessary evil. Life would be simpler with one really 
public address, if call routing would take care of picking the device.

>             <contact>sip:[email-masked]</contact>

I take issue with this being "ideal". It seems largely useless.

Why would you use gruus for the contacts when you have a unique AOR for 
each service?

And without some capabilities or other distinguishing entities, a 
watcher has no basis on which to pick among these, nor does a composer 
have any useful data to make decisions with.

> a presence URI. They would then probably publish the following:

Well, they don't currently publish either. Maybe when they are changed 
to publish they will also be changed to specify where to publish.

>             <contact>sip:[email-masked]</contact>

Since they are both sip, it would be a lot simpler if they both shared 
the same AOR (two devices registering to the same AOR.) And then they 
could publish their presence to that same AOR, and use it as their 
entity id as well. I would probably have them publish something more 
like the following:

          <presence xmlns="urn:ietf:params:xml:ns:pidf"
              entity="sip:[email-masked]">
            <tuple id="sg89ae">
              <status>
                <basic>open</basic>
                <precaps>
                   <audio>true</audio>
                   <message>false</message>
                   <duplex>half</duplex>
                </prescaps>
              </status>
              <contact>sip:[email-masked]</contact>
            </tuple>
          </presence>

          <presence xmlns="urn:ietf:params:xml:ns:pidf"
              entity="sip:[email-masked]">
            <tuple id="sf77ah">
              <status>
                <basic>open</basic>
                <precaps>
                   <audio>false</audio>
                   <message>true</message>
                   <duplex>full</duplex>
                </prescaps>
              </status>
              <contact>sip:[email-masked]</contact>
            </tuple>
          </presence>

Here, both devices would have REGISTERed with sip:[email-masked], 
and would have received the gruus above in return.

> specifying the SIP URIs rather than the presence URI.

I don't know of anyone who has seriously considered using pres urls. 
AFAIK most people are planning on using a sip AOR as the presence 
entitiy id.

I'm not going to try to respond to the following questions because they 
are based on a different world view.

	Paul