ext Dean Willis wrote:
On Apr 20, 2007, at 8:37 AM, Dostal, Pavel wrote:
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,
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
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
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
