RE: [Sip] draft-urpalainen-sip-xcap-diff-event-02

"Anders Lindgren C" <anders.c.lindgren@ericsson.com> Thu, 04 October 2007 17:05 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdU8P-0006jC-Jf; Thu, 04 Oct 2007 13:05:13 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IdU8O-0006hf-ID for sip-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 13:05:12 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdU8O-0006hX-78 for sip@ietf.org; Thu, 04 Oct 2007 13:05:12 -0400
Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdU8N-0006bl-Fc for sip@ietf.org; Thu, 04 Oct 2007 13:05:12 -0400
Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F00C42107F; Thu, 4 Oct 2007 19:05:10 +0200 (CEST)
X-AuditID: c1b4fb3e-b0835bb0000007e1-2d-47051d4655bc
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CE02920FAF; Thu, 4 Oct 2007 19:05:10 +0200 (CEST)
Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 19:05:10 +0200
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] draft-urpalainen-sip-xcap-diff-event-02
Date: Thu, 04 Oct 2007 19:05:09 +0200
Message-ID: <6D34F0B7D5BCB246A42380744457CA3601A0FDF5@esealmw107.eemea.ericsson.se>
In-Reply-To: <156FE001-F0E1-4C11-9B60-42E0912C83F8@softarmor.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] draft-urpalainen-sip-xcap-diff-event-02
Thread-Index: Acf/TSOzVjme1zdGSKWpQSGUJMWghAHVxyBA
References: <46C948F1.7000503@nokia.com> <156FE001-F0E1-4C11-9B60-42E0912C83F8@softarmor.com>
From: Anders Lindgren C <anders.c.lindgren@ericsson.com>
To: Dean Willis <dean.willis@softarmor.com>, IETF SIP List <sip@ietf.org>
X-OriginalArrivalTime: 04 Oct 2007 17:05:10.0423 (UTC) FILETIME=[B8C4B270:01C806A8]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: Ingemar Lindgren <ingemar.lindgren@ericsson.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi all,
This is my view given with an OMA touch.

As I see it the i-d forms a good base to solve the requirements that I
have seen in OMA so far. It is an important corner stone when
implementing XCAP in a SIP environment as it make it possible to use SIP
to solve e.g. the syncronisation issue between two XCAP client using
existing SIP methods.
I can not find that the content of the i-d needs to be changed in any
major parts or that a different solution is needed than proposed.

I'm also happy with initial sync issue as documented.

It exists some issues related to how mapping between the content within
the R-URI in the SIP Subscribe and the XCAP resources in the Subscribe
body is done but I think that they better are handled in the OMA
documents as they are related to the environment where the i-d is used
more than being of basic nature. If these issues are found to be of
general interest it is better to document it in it's one i-d later on
when we got some experience from the usage of this i-d.

The i-d has some similarity with
http://tools.ietf.org/html/draft-ietf-sip-uri-list-subscribe-01 in that
sense that both are using the resource-list format to transport the
resources that you want information about. This opens up some questions
if the i-d also shall define a exploder function for xcap document
changes in that sense that I can subscribe for changes in a number of
users XCAP documents in one Subscribe. Also here I my view is that this
can be handled outside this i-d as it is not part of a base function and
that we need some experience from this function before we start to make
it more complex. As exploders often are related to attempts to reduce
some resource usage it might be better to implement this type of
function using this i-d and plus some more i-d/RFC and document it as a
part of a document done by the organization that see a need for the
function. The important thing is that the corner stones to use exist
general available.

Regards
Anders

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com] 
Sent: den 25 september 2007 10:18
To: IETF SIP List
Cc: Jari Urpalainen; Anders Lindgren C; Ingemar Lindgren
Subject: Re: [Sip] draft-urpalainen-sip-xcap-diff-event-02


On Aug 20, 2007, at 2:55 AM, Jari Urpalainen wrote:

> Hi all!
>
> I've updated <http://www.ietf.org/internet-drafts/draft-urpalainen-
> sip-xcap-diff-event-02.txt>. Element & attribute subscriptions were 
> moved to i-d: <http://www.ietf.org/internet-drafts/draft-ietf-
> simple-xcap-diff-06.txt>. Resource selections are done by a flat URI 
> list with the XCAP resource list format instead of the "path"
> header parameter, and some text nits have been done. The somewhat 
> controversial initial sync problem still exists when patches are 
> aggregated. It is however, proposed that we live with that now as it 
> is a corner case which still can be handled with the proposed 
> approach, any comments ?
> br, Jari


C'mon kids, OMA is quite reasonably busting my chops because the lack of
an xcap-diff-event is mangling their schedule for XDM, and we're a bit
late on our July milestone for WGLC here. Let's pick up the pace, ok?

I'd like to ask the OMA to double-check that they are OK with the
current draft.

Anybody else got anything to say about this draft? Can we live with the
initial sync issue as documented? I think I'm okay with it, but I've
been reasonably happy for the last couple of revs, so it's other people
that we need to hear from.

If we're all happy, I'd like to get this renamed as a WG draft and on
the working-group last-call schedule ASAP.

--
Dean




_______________________________________________
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