Subject: [Sip] xcap-diff-event

From: Jari Urpalainen <[email-masked]>
Date: Mon, 11 Dec 2006 08:01:23 +0200

Hi all!

I've submitted an event package i-d 
<http://www.ietf.org/internet-drafts/draft-urpalainen-sip-xcap-diff-event-00.txt> 
about syncing xcap resources with xcap-diff format. The event package 
part is pretty much similar what Jonathan had in xcap-package before it 
was "moved" into the config-framework. The biggest difference is 
probably an OMA requirement to have subscriptions to XCAP components 
also. Any comments ?
thanks, Jari

_______________________________________________
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: "Dostal, Pavel" <[email-masked]>
Date: Wed, 13 Dec 2006 16:42:16 +0100

Jari,

In chapter 4.3.1 In my opinion the "path" parameter shall be stated as
mandatory.

In chapter 4.6.3 the same handling is defined for selector locating
non-existing element and multiple elements. I'd rather distinguish these
cases as subscription to non-existing element may have real usage (as
stated in chapter 4.1), but subscription to multiple elements (in the
sense of one selector for multiple elements) shall not be possible at
all.

Regards,

Pavel

-----Original Message-----
From: Jari Urpalainen [mailto:[email-masked]] 
Sent: Monday, December 11, 2006 1:01 AM
To: SIP IETF
Subject: [Sip] xcap-diff-event

Hi all!

<http://www.ietf.org/internet-drafts/draft-urpalainen-sip-xcap-diff-even
t-00.txt>

---

From: Jari Urpalainen <[email-masked]>
Date: Thu, 14 Dec 2006 09:10:22 +0200

Thanks Pavel,

> In chapter 4.3.1 In my opinion the "path" parameter shall be stated as
right, it should be clarified.
> sense of one selector for multiple elements) shall not be possible at
right, the intention is to allow subscription to an non-existing element 
(as it is stated). However,  do you propose  something along the lines: 
exists = "single", "none" or "multiple" ? So none and multiple would be 
an "error" in XCAP sense where a unique node is always mandatory for a 
successful operation. Having these two separate states might be better, 
i.e. the client would probably know to change the request. Also it would 
be better in-line with XCAP where 404 and 409 error responses separate 
these cases. However, the initial subscription must then signal this 
multiple case, I suppose. So it would make the handling a bit more 
complex, but more deterministic.

Comments ?
--Jari

---

From: "Dostal, Pavel" <[email-masked]>
Date: Tue, 19 Dec 2006 17:40:35 +0100

Hello Jari,

>complex, but more deterministic.

In my opinion "none" and "single" is ok and I would prefer that
subscription is rejected or terminated in case of "multiple".
Your opinion?

Pavel