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

From: "Dostal, Pavel" <[email-masked]>
Date: Fri, 20 Apr 2007 15:37:06 +0200

All,

As a technical contact from OMA PAG WG, I wonder whether any official
feedback to the "OMA LS 178 on XCAP diff-event" is planned to be
provided by IETF to the OMA PAG WG.
Regards,

Pavel Dostal 

-----Original Message-----
From: Dean Willis (OMA) [mailto:[email-masked]] 
Sent: Thursday, March 01, 2007 8:54 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; Dostal, Pavel; Antti Laurila; Dostal, Pavel;
Antti Laurila
Subject: New Liaison Statement, "OMA LS 178 on XCAP diff-event" 

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: Fri, 20 Apr 2007 12:16:07 -0500

> provided by IETF to the OMA PAG WG.

Good question. I posted the following on the SIPPING list on March  
21, and I haven't seen a conclusion in SIPPING yet. Thanks for waking  
us up.

> Several people from the IETF community met as a design team on  
> March 21, 2007 during IETF 68 in Prague to discuss OMA liaison  
> statement 178 on XCAP diff-event. This LS relates to OMA's  
> requirement for an event package for use in monitoring changes to  
> non-configuration XML documents. The document draft-urpalainen-sip- 
> xcap-diff-event-01.txt had been previously submitted with the  
> intent of meeting these requirements.
>
> Attendees at this discussion included:
>
> Jari Urpalainen
> Krisztian Kiss
> Robert Sparks
> Dan Petrie
> Cullen Jennings
> Rohan Mahy
> Sumanth Channabasappa	
> Jonathan Rosenburg
> Dean Willis
>
>
> The conclusion of the meeting was to recommend some changes in the  
> current sipping-config document and to recommend development of a  
> separate xcap-config document tailored to OMA's requirements (while  
> still meeting general IETF applicability goals).
>
> Changes to the sipping-config document include adding the  
> application identifier and error responses previously identified in  
> design team discussion.
>
> The new xcap-event package will need to support several  
> requirements referred to in draft-urpalainen-sip-xcap-diff- 
> event-01.txt, including subscribing to a xcap document or a sub- 
> element of an xcap element. It will also need to support deferred  
> or aggregated notification. The design team recommends starting  
> with the text in draft-urpalainen-sip-xcap-diff-event-01.txt, but  
> has not agreed to the current  re-synch mechanism therein which is  
> expected to require some further work. This package could be  
> developed either as a WG effort (probably within the SIPPING  
> working group) or as an area-director sponsored individual  
> contribution. The design team feels that the general applicability  
> of this specification is sufficiently broad that it should be  
> pursued as a standards track effort, even though RFC 3325 and 3427  
> allows informational documents to define event packages of this sort.
>
> If this recommendation is accepted or declined we will need to  
> respond with an appropriate LS to OMA informing them of our intent.  
> They would like an answer within the next week or so.

--
Dean Willis

---

From: Jari Urpalainen <[email-masked]>
Date: Tue, 24 Apr 2007 09:41:35 +0300

ext Dean Willis wrote:
> Good question. I posted the following on the SIPPING list on March 21, 
> and I haven't seen a conclusion in SIPPING yet. Thanks for waking us up.
>
>
>> Several people from the IETF community met as a design team on March 
>> 21, 2007 during IETF 68 in Prague to discuss OMA liaison statement 
>> 178 on XCAP diff-event. This LS relates to OMA's requirement for an 
>> event package for use in monitoring changes to non-configuration XML 
>> documents. The document draft-urpalainen-sip-xcap-diff-event-01.txt 
>> had been previously submitted with the intent of meeting these 
>> requirements.
>>
>> Changes to the sipping-config document include adding the application 
>> identifier and error responses previously identified in design team 
>> discussion.
>>
>> The new xcap-event package will need to support several requirements 
>> referred to in draft-urpalainen-sip-xcap-diff-event-01.txt, including 
>> subscribing to a xcap document or a sub-element of an xcap element. 
>> It will also need to support deferred or aggregated notification. The 
>> design team recommends starting with the text in 
>> draft-urpalainen-sip-xcap-diff-event-01.txt, but has not agreed to 
>> the current  re-synch mechanism therein which is expected to require 
>> some further work. This package could be developed either as a WG 
>> effort (probably within the SIPPING working group) or as an 
>> area-director sponsored individual contribution. The design team 
>> feels that the general applicability of this specification is 
>> sufficiently broad that it should be pursued as a standards track 
>> effort, even though RFC 3325 and 3427 allows informational documents 
>> to define event packages of this sort.
>>
A concern was raised about the initial sync stage, so what could be less 
sucking options ? Actually there's a need for versioned retrieval of 
documents based on their ETags which would cleanly solve this issue.

One option would be that servers would make temporary copies of 
subscribed documents during the initial subscription, and these 
temporary URIs along  with the real URIs would be carried within the 
body of xcap-diff document. The client would need to fetch then these 
versioned resources based on temporary URIs. For the server 
implementation this is ugly and somewhat error prone, i.e. e.g. when to 
remove these temporary stuff.

A better option would be to have "real" versioning on the xcap server. 
So one could retrieve documents e.g. by requesting GET 
/resource-lists/joe/index?etag=sfsdf343ds. So client would really 
request the ETag based versioned  resource.  What's nice here that you 
could add rfc3229 semantics here quite easily also, i.e. the client 
could say: "I have this xyz version, give me the patch to the latest 
version". Of course, for the server this would be yet another additional 
requirement for the already pretty complex xcap picture.

So what am I missing here ? This issue is sad in a sense that it is once 
again those cases which rarely exist in practice, a real corner case 
that is.

br, Jari

---

From: Dean Willis <[email-masked]>
Date: Tue, 24 Apr 2007 16:49:47 -0500

On Apr 24, 2007, at 1:41 AM, Jari Urpalainen wrote:
> A concern was raised about the initial sync stage, so what could be  
> less sucking options ? Actually there's a need for versioned  
> retrieval of documents based on their ETags which would cleanly  
> solve this issue.
>
> temporary URIs along  with the real URIs would be carried within  
> the body of xcap-diff document. The client would need to fetch then  
> these versioned resources based on temporary URIs. For the server  
> implementation this is ugly and somewhat error prone, i.e. e.g.  
> when to remove these temporary stuff.
>
> A better option would be to have "real" versioning on the xcap  
> server. So one could retrieve documents e.g. by requesting GET / 
> resource-lists/joe/index?etag=sfsdf343ds. So client would really  
> request the ETag based versioned  resource.  What's nice here that  
> you could add rfc3229 semantics here quite easily also, i.e. the  
> client could say: "I have this xyz version, give me the patch to  
> the latest version". Of course, for the server this would be yet  
> another additional requirement for the already pretty complex xcap  
> picture.
>
> So what am I missing here ? This issue is sad in a sense that it is  
> once again those cases which rarely exist in practice, a real  
> corner case that is.

dude, I am SO not wanting to go back to OMA with an LS that says  
"Sorry, we need to revise XCAP to do full-blown versioning to meet  
your needs".

What ARE we going to tell them?

My understanding was we were going to do a fairly straightforward  
event package that met their needs, based on your old draft. As I  
remember, this simply made it necessary to do a full get of the most- 
current if you lost synch. Is this not acceptable?

--
Dean

---

From: Jari Urpalainen <[email-masked]>
Date: Wed, 25 Apr 2007 10:23:04 +0300

ext Dean Willis wrote:
>> retrieval of documents based on their ETags which would cleanly solve 
>> this issue.
>>
>> implementation this is ugly and somewhat error prone, i.e. e.g. when 
>> to remove these temporary stuff.
>>
>> server. So one could retrieve documents e.g. by requesting GET 
>> client could say: "I have this xyz version, give me the patch to the 
>> latest version". Of course, for the server this would be yet another 
>> additional requirement for the already pretty complex xcap picture.
>>
>> once again those cases which rarely exist in practice, a real corner 
>> case that is.
>
right, well I just gave some alternatives (there are others as well...). 
So I'm not really proposing this, just trying to move forward.
> What ARE we going to tell them?
Let's do what the minutes say, move this to sip(ping) wg item or do the 
informational thing, i.e. act ;-). And continue solving this issue.
> remember, this simply made it necessary to do a full get of the 
> most-current if you lost synch. Is this not acceptable?
>
> -- 
> Dean
I think what is written in the spec is the simplest solution, during the 
initial sync stage the client just skips those possible already applied 
patches, just some simple buffering (if even needed) on the client side. 
Also during the subscription time it may happen that you have to 
retrieve full docs. And then this ugly thing happens that you need two 
round trips for this aggregation mode, but the alternatives aren't 
better unless I'm missing here something. And once again this case 
rarely exist in practice but implementers (especially clients) must be 
aware of this. So it is anticipated that you can usually start with the 
aggregation mode straight away, but it may fail. If it does, then retry 
with this ugly mode. As I said versioning is imo the proper way to make 
this cleanly work, but it does have other consequences...
br,
Jari