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

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:jari.urpalainen@nokia.com] 
Sent: Wednesday, March 07, 2007 9:02 AM
To: ext Jonathan Rosenberg
Cc: fluffy@cisco.com; sip@ietf.org; OMA-PAG@MAIL.OPENMOBILEALLIANCE.ORG;
Drage,Keith (Keith); OMA-LIAISON@MAIL.OPENMOBILEALLIANCE.ORG;
dean.willis@softarmor.com; Antti Laurila
Subject: Re: [Sip] New Liaison Statement, "OMA LS 178 on XCAP
diff-event"

ext 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? 
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.
>
> 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.
>
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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip