Subject: [Simple] Scope of XCAP PIDF manipulation wrt. Presence Data Model

From: [email-masked]
Date: Tue, 21 Sep 2004 15:58:57 +0300

Hi all,

The approach presented in Data Model for Presence (http://www.ietf.org/internet-drafts/draft-rosenberg-simple-presence-data-model-00.txt) has been in principle approved in SIMPLE WG, but there are still some open issues on details. One of them concerns the scope of XCAP application usage for PIDF manipulation (http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-pidf-manipulation-usage-01.txt). The Data Model draft has the following text in Chapter 10: 

      One of the source of confusion around the XCAP manipulation of
      PIDF [17] is that it was unclear as to why one would use it as
      opposed to PUBLISH.  The presence data model presented here sheds
      some light on that.  PUBLISH is appropriate for communicating
      information about services and devices.  PUBLISH is designed for
      the model where there can be more than one such source (as there
      is for devices and servcies), and where such state is soft-state
      (as it should be for devices and services).  However, presentity
      state is not clearly soft-state, and the model here clearly
      indicates that each presence document can have a single presentity
      element.  Thus, it might make sense to change the
      pidf-manipulation spec to only allow setting of presentity tuples.
      Now, that doesnt forbid a source from trying to PUBLISH presentity
      information, but there is clearly a need for a hard-state approach
      for setting presentity information.

The concrete issue here is whether XCAP PIDF manipulation should be restricted to setting only presentity tuple, i.e. not allow the setting of service tuples or device information.

My opinion is that we should not make this kind of restriction. 

There is at least one use case where "hard state" service tuples make a lot of sense, and that is service tuples for "persistent" services such as e-mail, SMS, MMS or voicemail. These communication means are available for the sender even if the recipient is not on-line wrt. that service, since there is a network-based "inbox" taking care of them. XCAP PIDF manipulation is a better way to describe this kind "off-line" state for such services rather than SIP PUBLISH. (BTW, I believe we should define some new status attribute to this kind of services to clearly indicate the difference between "MMS available but no device on-line" vs. "MMS available with a device on-line" etc. Or probably the standardization fora responsible for e.g. MMS can do that.)

What might be a useful specification is to say that in a typical scenario information derived from SIP PUBLISH takes presedence over the information derived from XCAP. But that is already in the territory of specifying the composer policy, which I think is a separate effort from the data model of XCAP PIDF manipulation drafts.

So my proposal is basically to keep the XCAP PIDF manipulation draft as it is at the moment, and not make any restricting statements about its use in the Data Model either. Are there other opinions on this topic?

Regards,
	Markus

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 29 Sep 2004 00:25:35 -0400

Markus,

You make a good point about another use case for the pidf manipulation.

Based on this, I think the pidf-manipulation draft needs to more 
carefully outline the use cases. I think it would be good to point out 
that it is ideal for:

(1) manipulating person information,
(2) manipulating services that operate in the absence of agents that 
actively run on behalf of the user (email, for example)

In essence, then, the distinction is that PUBLISH is used when there is 
a software agent of some sort representing a device or service, and the 
ability to use that service or that device is predicated on the 
existence and correct operation of that agent. For the above two cases, 
there need not be a software agent that runs in order for the data to be 
meaningful, and thus xcap-pidf.

Probably it needs to be expressed better, but hopefully the idea makes 
sense.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Sep 2004 10:58:34 -0400

Jonathan,

I agree with you and Markus on the validity of Markus's suggested usage. 
And I agree the kind of clarification you suggest would be helpful. But 
I don't think this is normative behavior, so lets make sure the language 
isn't too strong. (All of these attributes should be possible to 
manipulate *either* via XCAP or PUBLISH.

	Paul

Jonathan Rosenberg wrote:
>> The approach presented in Data Model for Presence 
>> (http://www.ietf.org/internet-drafts/draft-rosenberg-simple-presence-data-model-00.txt) 
>> has been in principle approved in SIMPLE WG, but there are still some 
>> open issues on details. One of them concerns the scope of XCAP 
>> application usage for PIDF manipulation 
>> (http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-pidf-manipulation-usage-01.txt). 
>> The Data Model draft has the following text in Chapter 10:
>> The concrete issue here is whether XCAP PIDF manipulation should be 
>> restricted to setting only presentity tuple, i.e. not allow the 
>> setting of service tuples or device information.
>>
>> There is at least one use case where "hard state" service tuples make 
>> a lot of sense, and that is service tuples for "persistent" services 
>> such as e-mail, SMS, MMS or voicemail. These communication means are 
>> available for the sender even if the recipient is not on-line wrt. 
>> that service, since there is a network-based "inbox" taking care of 
>> them. XCAP PIDF manipulation is a better way to describe this kind 
>> "off-line" state for such services rather than SIP PUBLISH. (BTW, I 
>> believe we should define some new status attribute to this kind of 
>> services to clearly indicate the difference between "MMS available but 
>> no device on-line" vs. "MMS available with a device on-line" etc. Or 
>> probably the standardization fora responsible for e.g. MMS can do that.)
>>
>> What might be a useful specification is to say that in a typical 
>> scenario information derived from SIP PUBLISH takes presedence over 
>> the information derived from XCAP. But that is already in the 
>> territory of specifying the composer policy, which I think is a 
>> separate effort from the data model of XCAP PIDF manipulation drafts.
>>
>> So my proposal is basically to keep the XCAP PIDF manipulation draft 
>> as it is at the moment, and not make any restricting statements about 
>> its use in the Data Model either. Are there other opinions on this topic?
>>
>> Regards,
>>     Markus
>>  
>>