Subject: [Simple] Proposed changes to XCAP PIDF manipulation

From: [email-masked]
Date: Wed, 20 Oct 2004 17:34:44 +0300

Hi all,

Based on the recent publication of SIMPLE Presence Data model draft and some mailing list discussion, I propose to make the following changes on XCAP PIDF manipulation draft.

1. The introduction chapter needs to be aligned with the data model. Also, the use cases for XCAP PIDF manipulation need to be still more clearly spelled out. I propose to update the first two paragraphs in the introduction, which currently say:

   The Session Initiation Protocol (SIP) for Instant Messaging and
   Presence (SIMPLE) specifications allow a user, called a watcher, to
   subscribe to another user, called a presentity, in order to learn
   their presence information [8].

   A SIP based mechanism, SIP PUBLISH method, has been defined for
   publishing presence state [4].  However, SIP PUBLISH has a limited
   scope and does not address all the requirements for setting presence
   state.  First, it only allows a single Presence User Agent (PUA) to
   publish its view of the presence state, independently of and without
   the possibility to learn about the states set by other PUAs.  Since
   each PUA is typically tied to a single physical device, this means
   that it is hard to set device independent presence state using SIP
   PUBLISH.  Second, SIP PUBLISH creates a soft state which expires
   after the negotiated lifetime unless it is refreshed.  This makes it
   unsuitable for setting state that should prevail even without active
   refreshing.  There are several use cases where setting of permanent
   presence state that can be manipulated independent of any device is
   needed.  For instance presentity's e-mail (mailto: URI) and WWW
   homepage (http: URI) address are this kind of information.  Similarly
   a user might want to set information, such as a note, that should
   constitute his presence information in the absence of any active
   publications, i.e.  serve as a sort of default presence state.
   SIMPLE based presence systems thus require a mechanism to complement
   SIP PUBLISH in order to address these use cases.

To be:

   The Session Initiation Protocol (SIP) for Instant Messaging and
   Presence (SIMPLE) specifications allow a user, called a watcher, to
   subscribe to another user, called a presentity, in order to learn
   their presence information [8].  The presence data model has been
   specified in [ref-to-data-model].  The data model makes a clean
   separation between person, service and device related information.
   
   A SIP based mechanism, SIP PUBLISH method, has been defined for
   publishing presence state [4].  Using SIP PUBLISH a Presence User
   Agent (PUA) can publish its view of the presence state, independently 
   of and without the need to learn about the states set by other PUAs.  
   However, SIP PUBLISH has a limited scope and does not address all the 
   requirements for setting presence state.  The main issue is that SIP 
   PUBLISH creates a soft state which expires after the negotiated 
   lifetime unless it is refreshed.  This makes it unsuitable for cases
   where  state that should prevail without active devices capable of 
   refreshing the state.  

   There are three main use cases where setting of permanent presence state 
   that is independent of activeness of any particular device is useful.  
   The first case concerns setting person related state.  The presentity 
   would often like to set its presence state even for periods when it has 
   no active devices capable of publishing available.  Good examples are 
   traveling, vacations and so on.  The second case is about setting state
   for services that are open for communication even if the presentity
   does not have a device running that service on-line.  Examples of this 
   kind of services include e-mail, MMS and SMS.  In these services the 
   presentity is provisioned with a server that makes the service 
   persistently available, at least in certain form, and it would be good
   to be able to advertise this to the watchers. Since it is not realistic 
   to assume that all e-mail, MMS or SMS servers can publish presence state 
   on their own (and even if this were possible, such state would almost never 
   change), this has to be done by some other device - and since the 
   availability of the service is not dependent on that device, it would be 
   unpractical to require that device to be constantly active just to publish 
   such availability.  The third case concerns setting the default state
   of person, any service or any device in the absence of any device capable
   of actively publishing such state.  For instance the presentity might 
   want to advertise that his or her voice service is right now closed, just
   to let the watchers to know that such service might be open at some point. 
   Again, this type of default state is independent of any particular device,
   and can be considered to be rather persistent.    
   
   Even though SIP PUBLISH remains to be the main way of publishing presence
   state in SIMPLE based presence systems and is espcially well suited for
   publishing dynamic state (which presence mainly is), it needs to be 
   complemented by the mechanism described in this document to address the
   use cases presented above.      
   
2. Examples will be alinged with data model, e.g. person element will be used.

---

So this is just wordsmithing, nothing normative is really changed. Any opinions on whether the proposed introduction matches with the data model and whether the motivation of having XCAP PIDF manipulation in addition to SIP PUBLISH is clear enough?

Markus

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