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

[Jari Urpalainen <[e-mail]>]

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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip