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

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 30 Sep 2004 20:40:45 -0400

I'm not sure about that. I'm really worried that we'll have interop 
problems because folks will look at the pidf-manipulation draft, look at 
publish, and decide to just do one of them, whereas the provider chose 
the other. Generally, having more than one way to do the same thing is bad.

-Jonathan R.

Paul Kyzivat wrote:

> 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:
> 
>> 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.
>>
>> [email-masked] wrote:
>>
>>> 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
>>>
>>
> 

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

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