Subject: [Simple] an incremental step forward for xcap-diff and patch-ops

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 08 Oct 2005 01:27:12 -0400

Since the last IETF meeting, we havent yet resolved this issue of how to 
represent the changes in an XML document that are included in the 
xcap-diff format. The current draft uses an xcap change log type of 
format. The previous version used Jari's patch-ops, which has been 
contentious. The current mechanism doesnt work, due to some issues with 
CDATA encapsulation.

Xcap itself has a dependency on xcap-diff. Not for conveying the changes 
in XML document, but rather, for conveying etags. That aspect of the 
spec has been stable and uncontentious.

In order to at least break the dependencies and allow base xcap to move 
forward (though we have some work to do per my previous note), I'd 
propose to split the current xcap-diff draft in two. One part, which 
remains a working group item, defines just the format for representing 
the etag changes. The schema would define a point of extensibility for 
conveying the actual changes in the xml document, but not define a 
solution. I would then issue an individual -00 document with an xcap 
change-log type of format that could be used for this.

This would allow us to conclude on xcap-diff, and separately debate just 
the piece of it that describes the changes themself.

Comments?

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

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

---

From: Jari Urpalainen <[email-masked]>
Date: Tue, 11 Oct 2005 14:27:12 +0300

ext Jonathan Rosenberg wrote:

> Since the last IETF meeting, we havent yet resolved this issue of how 
> to represent the changes in an XML document that are included in the 
> contentious. The current mechanism doesnt work, due to some issues 
> with CDATA encapsulation.
>
> Xcap itself has a dependency on xcap-diff. Not for conveying the 
> changes in XML document, but rather, for conveying etags. That aspect 
> of the spec has been stable and uncontentious.
>
> In order to at least break the dependencies and allow base xcap to 
> move forward (though we have some work to do per my previous note), 
> I'd propose to split the current xcap-diff draft in two. One part, 
> which remains a working group item, defines just the format for 
> representing the etag changes. The schema would define a point of 
> extensibility for conveying the actual changes in the xml document, 
> but not define a solution. I would then issue an individual -00 
> document with an xcap change-log type of format that could be used for 
> this.
>
> This would allow us to conclude on xcap-diff, and separately debate 
> just the piece of it that describes the changes themself.
>
> Comments?
>
> Thanks,
> Jonathan R.

The other option would be to define the ETag changes content type in the 
base xcap spec, which can be as simple as <etags xmlns="urn:foo" 
prev="xxx" new="yyy"/> and continue xcap-diff as usual.
br,
Jari

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 21 Oct 2005 01:42:32 -0400

True, though the idea was that, if the server has to return xcap-diff 
documents in NOTIFY to tell users what changed, this should be the same 
format you use to tell them what changed when given in the http response.

I'm also shooting for minimal changes here, rather than revisiting major 
design decisions.

-Jonathan R.