Subject: [Sip] New Liaison Statement, "OMA LS 178 on XCAP diff-event"

From: Dean Willis (OMA) <[email-masked]>
Date: Thu, 01 Mar 2007 14:54:06 -0500

Title: OMA LS 178  on XCAP diff-event
Submission Date: 2007-03-01
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=303 
Please reply by 2007-03-23

From: Dean Willis(OMA) <[email-masked]>
To: IETF SIP WG([email-masked])
Cc: [email-masked]
[email-masked]
[email-masked]
Reponse Contact: Pavel Dostal <[email-masked]>
Antti Laurila <[email-masked]>
Technical Contact: Pavel Dostal <[email-masked]>
Antti Laurila <[email-masked]>
Purpose: For comment 
Body: 1	Overview

This liaison seeks IETF SIP WG for the opinion on the XCAP Diff 
Event Package as drafted in draft-urpalainen-sip-xcap-diff-event-00.

2	Proposal

OMA PAG WG deals with a requirement to enable subscription for
notification of changes in XCAP resource not only to single 
document but also to single XCAP component (XML element or attribute). 
This can not be achieved using draft-ietf-sip-xcap-config because the 
subscription in this case is allowed only to single document or 
folder.

A new SIP event package “xcap-diff” is defined in
draft-urpalainen-sip-xcap-diff-event-00. 
This event package allows subscription to a set of XCAP 
resources where resources can be either folder or document 
or component identified by node selector. 

As this functionality fits to current requirements, OMA PAG WG 
is considering adopting draft-urpalainen-sip-xcap-diff-event-00 
as the solution for XCAP clients to receive partial changes of 
the XCAP resources.

3	Requested Action(s)

OMA PAG WG kindly requests IETF SIP WG on the opinion on the 
XCAP Diff Event Package as drafted in 
draft-urpalainen-sip-xcap-diff-event-00 and its expected 
progress.

4	Conclusion

OMA PAG WG would like to thank IETF SIP WG for their kind 
consideration and response to this liaison request and look 
forward to future opportunities to work together.
Attachment(s):
     OMA LS 178 on XCAP Diff Event (https://datatracker.ietf.org/documents/LIAISON/file404.pdf)

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Mon, 5 Mar 2007 15:27:02 -0600

Antti and Thanos, either or both of you care to take a shot at this?

--
Dean

On Mar 5, 2007, at 3:20 PM, Jonathan Rosenberg wrote:

> My main question here is what are the use cases for subscribing to  
> an individual element, rather than the whole document? It would  
> need to be a case where a user cares about changes in one of their  
> documents, but not over certain parts of that document. For the  
> cases of resource-lists and rls-services, it was far from clear  
> when that would be desired. Wouldn't a user care about their entire  
> buddy list and not just some of it?
>
> If OMA could provide some specific example use cases and point out  
> problems with draft-ietf-sip-xcap-config for those cases, it would  
> be helpful in providing concrete feedback.
>
> Thanks,
> Jonathan R.
>
> Dean Willis (OMA) wrote:
>> URL of the IETF Web page: https://datatracker.ietf.org/public/ 
>> liaison_detail.cgi?detail_id=303 Please reply by 2007-03-23
>> Purpose: For comment Body: 1	Overview
>> document but also to single XCAP component (XML element or  
>> attribute). This can not be achieved using draft-ietf-sip-xcap- 
>> config because the subscription in this case is allowed only to  
>> single document or folder.
>> draft-urpalainen-sip-xcap-diff-event-00. This event package allows  
>> subscription to a set of XCAP resources where resources can be  
>> either folder or document or component identified by node  
>> selector. As this functionality fits to current requirements, OMA  
>> PAG WG is considering adopting draft-urpalainen-sip-xcap-diff- 
>> event-00 as the solution for XCAP clients to receive partial  
>> changes of the XCAP resources.
>> 3	Requested Action(s)
>> OMA PAG WG kindly requests IETF SIP WG on the opinion on the XCAP  
>> Diff Event Package as drafted in draft-urpalainen-sip-xcap-diff- 
>> event-00 and its expected progress.
>> 4	Conclusion
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ  
> 07054-2711
> Cisco Systems
> [email-masked]                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 05 Mar 2007 16:20:55 -0500

My main question here is what are the use cases for subscribing to an 
individual element, rather than the whole document? It would need to be 
a case where a user cares about changes in one of their documents, but 
not over certain parts of that document. For the cases of resource-lists 
and rls-services, it was far from clear when that would be desired. 
Wouldn't a user care about their entire buddy list and not just some of it?

If OMA could provide some specific example use cases and point out 
problems with draft-ietf-sip-xcap-config for those cases, it would be 
helpful in providing concrete feedback.

Thanks,
Jonathan R.

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

---

From: Jari Urpalainen <[email-masked]>
Date: Wed, 07 Mar 2007 10:02:17 +0200

ext Jonathan Rosenberg wrote:
> individual element, rather than the whole document? It would need to 
> be a case where a user cares about changes in one of their documents, 
> but not over certain parts of that document. For the cases of 
> resource-lists and rls-services, it was far from clear when that would 
> be desired. Wouldn't a user care about their entire buddy list and not 
> just some of it? 
Good point. I had a similar first impression as well.  What made me 
eventually change my mind was the fact that we indeed have a similar 
feature in XCAP, i.e. a partial GET of components (and this is a similar 
feature using sip). For sure, in my reference XCAP implementation 
(general server/client for resource-lists+services AU) I had zero use 
for the partial retrievals of XML nodes of a document. But this is not 
to say that someone may still find it useful. Adding this sort of 
feature afterwards is definitely imo much more awkward. And as I see it, 
OMA wants to avoid in some cases an additional http retrieval, so it is 
an optimization case and as well may make the client implementation 
simpler. And speaking about the actual implementation, adding this 
feature to the server is pretty much trivial if you manage to get the 
XCAP baseline done and all this patching stuff, i.e. it doesn't cause 
much PITA.

Another option would be that RFC3427 would be relaxed for sip event 
packages, i.e. FIFO model for event package names, so that e.g. OMA 
folks could do their own stuff based on their spec.
> helpful in providing concrete feedback.
there are some other differences: resource selection logic, "possible 
endless loop" issue, patch or not to patch, parameter stuff, initial 
subscription sync etc. And after glancing at the last config-framework I 
am still inclined to think that XCAP isn't the best fit there.
br, jari

---

From: "Dostal, Pavel" <[email-masked]>
Date: Thu, 8 Mar 2007 10:17:21 +0100

OMA defines a group document in a similar way as the RLS services
document is defined in draft-ietf-simple-xcap-list-usage. The group is
identified by URI that must be unique along all groups inside an XCAP
root and there is a global document representing all groups stored in
the users tree.
As the enabler server may need to get access to the group based on its
URI, the enabler must access the global document. In case the enabler
needs to know about the changes in the group document, for example to
remove a participant from a conference when the participant is removed
from the group document, there is a need to subscribe for changes of
such global document. And as such document may be really huge and only
few groups have the service (conference) active in some time,
subscription to only part of the global document is needed.

Best regards,

Pavel Dostal 

-----Original Message-----
From: Jari Urpalainen [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 9:02 AM
To: ext Jonathan Rosenberg
Cc: [email-masked]; [email-masked]; [email-masked];
Drage,Keith (Keith); [email-masked];
[email-masked]; Antti Laurila
Subject: Re: [Sip] New Liaison Statement, "OMA LS 178 on XCAP
diff-event"

---

From: Dean Willis <[email-masked]>
Date: Thu, 8 Mar 2007 14:48:18 -0600

> subscription to only part of the global document is needed.

This strikes me as a design issue. If the "global document" were a  
collection and each "group" a document, we wouldn't have this  
problem. Of course, I seem to recall saying this in OMA meetings and  
getting lots of funny looks from the room.

--
Dean

---

From: "Dostal, Pavel" <[email-masked]>
Date: Fri, 9 Mar 2007 08:22:20 +0100

>getting lots of funny looks from the room.

I'm sorry but I'm not sure if I understand your comment. 
In my understanding of usage of RLS (as defined in
draft-ietf-xcap-list-usage-05), a SIP request sent to the service URI
initiates a download of the list to the SIP service from the global
document, because the XUI is not known for the download from users tree.
If the SIP service needs from any reason to be informed about the
changes of the list, it needs to subscribe to the changes of the global
document, but only changes in a small part may be useful for the SIP
service. In this case subscription only to the part of the document
sounds like useful optimization.

Pavel