IM rules

NOTICE: Please note that this eMail, and the = contents thereof,
is subject to the standard NMMU eMail disclaimer = which may be found at:
http://www.nmmu.ac.za/disclaimer/email.htm ------_=_NextPart_001_01C6E567.34F3DA88-- --===============2058818427== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============2058818427==-- From simple-bounces@ietf.org Sun Oct 01 22:36:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUDfB-0002nU-4P; Sun, 01 Oct 2006 22:36:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUDfA-0002nP-2P for simple@ietf.org; Sun, 01 Oct 2006 22:36:12 -0400 Received: from maillog.itri.org.tw ([61.61.254.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUDf7-0007VR-HY for simple@ietf.org; Sun, 01 Oct 2006 22:36:11 -0400 Received: from mail.itri.org.tw (mail [140.96.157.2]) by maillog.itri.org.tw (8.12.10/8.12.10) with ESMTP id k922RNQx014547 for ; Mon, 2 Oct 2006 10:27:24 +0800 (CST) Received: from mail.itri.org.tw (localhost [127.0.0.1]) by mail.itri.org.tw (8.13.4/8.13.4) with ESMTP id k922dLln016245 for ; Mon, 2 Oct 2006 10:39:21 +0800 (CST) Received: from ms4.itri.org.tw ([140.96.151.44]) by mail.itri.org.tw (8.13.4/8.13.4) with ESMTP id k922dLbx016235 for ; Mon, 2 Oct 2006 10:39:21 +0800 (CST) Received: from 52092035393 ([140.96.151.160]) by ms4.itri.org.tw (Lotus Domino Release 5.0.13a) with ESMTP id 2006100210284323:34216 ; Mon, 2 Oct 2006 10:28:43 +0800 From: "Jeffrey" To: "'Simple WG'" Subject: [Simple] About XCAP Authentication Date: Mon, 2 Oct 2006 10:34:46 +0800 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 thread-index: Acaj0Y1BtRQrThIHS8WS9DUMf2aBHhB+anSQ In-Reply-To: <44B18A4D.7050709@cisco.com> X-MIMETrack: Itemize by SMTP Server on MS4/ITRI(Release 5.0.13a |April 8, 2004) at 2006-10-02 10:28:43 AM, Serialize by Router on MS4/ITRI(Release 5.0.13a |April 8, 2004) at 2006-10-02 10:28:45 AM, Serialize complete at 2006-10-02 10:28:45 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="big5" X-Spam-Score: 1.8 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Dear there, I am implementing XCAP for presence authorization rule and contact list manipulation as specified by SIMPLE XCAP. I try to add authentication mechanism on XCAP via HTTP Digest. But I wonder if every manipulation (like GET, PUT, DELETE) between XCAP client and XCAP server has to go the process of HTTP Digest Authentication. If it is necessary, I am afraid the performance on XCAP operation will decrease. Any solution or suggestion for better implementation? Thanks in advance. BR, Jeffrey %;+H%s%i/`%]'t$u,c0|>w1K8j0T!A+D+|)w$'&,%s*L!A=P$E(O%N)N4&ES%;+H%s$:.e!A(C=P>P74&9+H%s!C This email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Oct 03 03:50:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUf2G-0004ve-Fr; Tue, 03 Oct 2006 03:49:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUf2F-0004vZ-At for simple@ietf.org; Tue, 03 Oct 2006 03:49:51 -0400 Received: from datnt07.tieto.com ([194.110.47.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUf28-00005z-SO for simple@ietf.org; Tue, 03 Oct 2006 03:49:51 -0400 Received: from viper.eu.tieto.com ([194.110.47.167]) by datnt07.tieto.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 Oct 2006 10:49:01 +0300 Received: from sagaris.eu.tieto.com ([131.207.197.143]) by viper.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 10:49:29 +0300 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 Date: Tue, 3 Oct 2006 10:49:28 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification on usage of xcap-diff Thread-Index: AcbmwHQCxDSnIW18SoaPK1px35u1rw== From: To: X-OriginalArrivalTime: 03 Oct 2006 07:49:29.0056 (UTC) FILETIME=[74935600:01C6E6C0] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [Simple] Clarification on usage of xcap-diff X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hello, I am currently working with the xcap-diff and I am not very sure about one issue. 1. I have document 2. I do PUT operation replacing whole document PUT http://server/path/document 3. In notification there will be xcap-diff document A:

new content of the document

B: In my opinion, as xml-patch-ops-01 says - sel attribute contains relative path to document root "/", the latter alternative is correct. What I am not sure, whether it is correct to omit the change-log part of the xcap-diff document and leave on the client to download the new document by itself. br, Martin +-------------------------------------+ Martin Hynar Software Specialist TietoEnator Czech Software Center Phone: +420 597 459 713 Mobile: +420 724 035 397 E-mail: Martin.Hynar@TietoEnator.com Vystavni 292/13 CZ-709 16 Ostrava www.tietoenator.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Oct 03 05:32:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUgcx-0006Pn-RE; Tue, 03 Oct 2006 05:31:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUgcw-0006PX-TL for simple@ietf.org; Tue, 03 Oct 2006 05:31:50 -0400 Received: from mail1.tieto.com ([194.110.47.24] helo=datnt07.tieto.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUgcu-0000Nh-HG for simple@ietf.org; Tue, 03 Oct 2006 05:31:50 -0400 Received: from veyron.eu.tieto.com ([194.110.47.230]) by datnt07.tieto.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 Oct 2006 12:31:20 +0300 Received: from sagaris.eu.tieto.com ([131.207.197.143]) by veyron.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 12:31:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Clarification on usage of xcap-diff Date: Tue, 3 Oct 2006 12:28:42 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Clarification on usage of xcap-diff Thread-Index: AcbmzAIf5joR6z1ERXGMtpPZi7YvPAAAk83R References: <4522288F.3090704@nokia.com> From: To: , X-OriginalArrivalTime: 03 Oct 2006 09:31:47.0189 (UTC) FILETIME=[BF301A50:01C6E6CE] X-Spam-Score: 0.2 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hello, so, if I understood it correctly, you think that if I replace sel=3D"/" = with sel=3D"*" then also option A is correct? Meaning of this is that * substitutes arbitrary element in the document = and the first matching occurence will be the root element of the = document. br, Martin -----Original Message----- From: Jari Urpalainen [mailto:jari.urpalainen@nokia.com] Sent: Tue 10/3/2006 11:08 AM To: ext Bulent Gecer (TN/EAB) Cc: Hynar Martin; simple@ietf.org Subject: Re: [Simple] Clarification on usage of xcap-diff =20 ext Bulent Gecer (TN/EAB) wrote: > Hello,=20 > > I guess a workaround would be to send back two notifications, the = first > stating that the document was deleted (no "new-etag" in the diff-doc) > and the second stating that the document was created (no "prev-etag" = in > the diff-doc). > > BR, > > /Bulent > > =20 you could do that but it is not desirable > -----Original Message----- > From: Martin.Hynar@tietoenator.com = [mailto:Martin.Hynar@tietoenator.com] > > Sent: den 3 oktober 2006 09:49 > To: simple@ietf.org > Subject: [Simple] Clarification on usage of xcap-diff > > > Hello, > > I am currently working with the xcap-diff and I am not very sure about > one issue. > > 1. I have document > 2. I do PUT operation replacing whole document > PUT http://server/path/document > 3. In notification there will be xcap-diff document > A: > > previous-etag=3D"1"> > > > new content of the document > > > > > B: > > previous-etag=3D"1"/> > > > In my opinion, as xml-patch-ops-01 says - sel attribute contains > relative path to document root "/", the latter alternative is correct. > What I am not sure, whether it is correct to omit the change-log part = of > the xcap-diff document and leave on the client to download the new > document by itself. > > br, Martin > > > =20 B. model is the only way currently when you can't describe the diff with = patch-ops-02, i.e. for example you'll have xml prolog changes which=20 cannot be located (and patched) with XPath semantics (ok, a corner case, = but possible). So B. describes a replace (=3D=3D PUT with 201 response) = and=20 the client needs to fetch the document with GET. Btw. a plain "/"=20 selector is disallowed for but the document root element can=20 be replaced with "*" or "[root_elem_name]". So given these conditions=20 can be met, also A is possible (which is quite typical, btw.) br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Oct 03 06:27:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUhTF-00011R-Q3; Tue, 03 Oct 2006 06:25:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUhTD-00010p-Kx for simple@ietf.org; Tue, 03 Oct 2006 06:25:51 -0400 Received: from mail.tieto.com ([194.110.47.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUhQM-00052q-QL for simple@ietf.org; Tue, 03 Oct 2006 06:22:56 -0400 Received: from veyron.eu.tieto.com ([194.110.47.230]) by mail.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 13:22:41 +0300 Received: from sagaris.eu.tieto.com ([131.207.197.143]) by veyron.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 13:22:41 +0300 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 Date: Tue, 3 Oct 2006 13:22:40 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request URI and To header in SUBSCRIBE request Thread-Index: Acbm1drPHbJCbGd4Ta25Gv/MhGt1bQ== From: To: X-OriginalArrivalTime: 03 Oct 2006 10:22:41.0154 (UTC) FILETIME=[DB7E2E20:01C6E6D5] X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: David.Pilar@tietoenator.com Subject: [Simple] Request URI and To header in SUBSCRIBE request X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hello,=20 I am not able to find out what should happen when a SUBSCRIBE request has different URIs in Request URI and in To header: SUBSCRIBE sip:user1@example.com SIP/2.0 ... To: sip:user2@example.com ... Which header should I take as the one to which the subscription is targeted? Is this defined somewhere? Thank you for your time, Silvestr Peknik Software Specialist TietoEnator=09 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Oct 03 06:32:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUhZB-0005qg-H1; Tue, 03 Oct 2006 06:32:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUhZA-0005lD-B8 for simple@ietf.org; Tue, 03 Oct 2006 06:32:00 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUhZ8-0005uv-Qi for simple@ietf.org; Tue, 03 Oct 2006 06:32:00 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k93AVuZD007689; Tue, 3 Oct 2006 13:31:57 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 13:31:56 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 3 Oct 2006 13:31:55 +0300 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int01.ntc.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k93AVsWN015184; Tue, 3 Oct 2006 13:31:54 +0300 Received: from [172.21.38.148] (esdhcp038148.research.nokia.com [172.21.38.148]) by kusti.research.nokia.com (Postfix) with ESMTP id 46E7793B78; Tue, 3 Oct 2006 13:31:54 +0300 (EEST) Message-ID: <45223C1A.1000000@nokia.com> Date: Tue, 03 Oct 2006 13:31:54 +0300 From: Jari Urpalainen User-Agent: Thunderbird 1.5.0.7 (X11/20060913) MIME-Version: 1.0 To: "ext Martin.Hynar@tietoenator.com" Subject: Re: [Simple] Clarification on usage of xcap-diff References: <4522288F.3090704@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Oct 2006 10:31:55.0115 (UTC) FILETIME=[25ADEBB0:01C6E6D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org ext Martin.Hynar@tietoenator.com wrote: > Hello, > > so, if I understood it correctly, you think that if I replace sel="/" with sel="*" then also option A is correct? > > exactly, given that all changes are within the document root element (which is the most typical case, others are really corner-cases, imo. But anyway the server/notifier knows ;-) how to act). > Meaning of this is that * substitutes arbitrary element in the document and the first matching occurence will be the root element of the document. > > br, Martin > > > right , wildcard "*" selects all element children (of the root node), i.e. a valid xml document must only have one document root element, so there's no ambiguity here. So you could even change to a different QName but it is certainly rare. But you could for example, have XML entities within the prologue which can't be described with XPath semantics. You don't generally use them, and then the client does a full re-fetch (and there this open issue of xcap-diff still exists, at least theoretically). > -----Original Message----- > From: Jari Urpalainen [mailto:jari.urpalainen@nokia.com] > Sent: Tue 10/3/2006 11:08 AM > To: ext Bulent Gecer (TN/EAB) > Cc: Hynar Martin; simple@ietf.org > Subject: Re: [Simple] Clarification on usage of xcap-diff > > ext Bulent Gecer (TN/EAB) wrote: > >> Hello, >> >> I guess a workaround would be to send back two notifications, the first >> stating that the document was deleted (no "new-etag" in the diff-doc) >> and the second stating that the document was created (no "prev-etag" in >> the diff-doc). >> >> BR, >> >> /Bulent >> >> >> > you could do that but it is not desirable > >> -----Original Message----- >> From: Martin.Hynar@tietoenator.com [mailto:Martin.Hynar@tietoenator.com] >> >> Sent: den 3 oktober 2006 09:49 >> To: simple@ietf.org >> Subject: [Simple] Clarification on usage of xcap-diff >> >> >> Hello, >> >> I am currently working with the xcap-diff and I am not very sure about >> one issue. >> >> 1. I have document >> 2. I do PUT operation replacing whole document >> PUT http://server/path/document >> 3. In notification there will be xcap-diff document >> A: >> >> > previous-etag="1"> >> >> >> new content of the document >> >> >> >> >> B: >> >> > previous-etag="1"/> >> >> >> In my opinion, as xml-patch-ops-01 says - sel attribute contains >> relative path to document root "/", the latter alternative is correct. >> What I am not sure, whether it is correct to omit the change-log part of >> the xcap-diff document and leave on the client to download the new >> document by itself. >> >> br, Martin >> >> >> >> > B. model is the only way currently when you can't describe the diff with > patch-ops-02, i.e. for example you'll have xml prolog changes which > cannot be located (and patched) with XPath semantics (ok, a corner case, > but possible). So B. describes a replace (== PUT with 201 response) and > the client needs to fetch the document with GET. Btw. a plain "/" > selector is disallowed for but the document root element can > be replaced with "*" or "[root_elem_name]". So given these conditions > can be met, also A is possible (which is quite typical, btw.) > br, > Jari > > btw. a typo 200 OK, not 201 Created, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Oct 03 07:59:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUium-0000GA-6G; Tue, 03 Oct 2006 07:58:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUiuk-0000Fo-DO for simple@ietf.org; Tue, 03 Oct 2006 07:58:22 -0400 Received: from wx-out-0506.google.com ([66.249.82.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUiuj-0007IJ-6R for simple@ietf.org; Tue, 03 Oct 2006 07:58:22 -0400 Received: by wx-out-0506.google.com with SMTP id t4so1883040wxc for ; Tue, 03 Oct 2006 04:58:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YfUycWMs63A/f8HPCCD9pMVe/M9eIVuWlxORGxsEagGkQXWffFXjaS2jVF6+oC1nBI+xiMeG1gtvG56Ue7ZmYPh1/cXpqlFeCwTqeVD7wIMg54EEwFJMpQA0R8bFPJ6rlLe8P/tsrdGzxnKYP3u5Eo8vkirpBolJecx6OHpKlk4= Received: by 10.90.94.2 with SMTP id r2mr3320988agb; Tue, 03 Oct 2006 04:58:20 -0700 (PDT) Received: by 10.90.66.1 with HTTP; Tue, 3 Oct 2006 04:58:20 -0700 (PDT) Message-ID: Date: Tue, 3 Oct 2006 13:58:20 +0200 From: samuel To: "Silvestr.Peknik@tietoenator.com" Subject: Re: [Simple] Request URI and To header in SUBSCRIBE request In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 1.0 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: David.Pilar@tietoenator.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Req-URI always identifies the target of the request. Samuel. 2006/10/3, Silvestr.Peknik@tietoenator.com : > Hello, > > I am not able to find out what should happen when a SUBSCRIBE request > has different URIs in Request URI and in To header: > > > SUBSCRIBE sip:user1@example.com SIP/2.0 > ... > To: sip:user2@example.com > ... > > Which header should I take as the one to which the subscription is > targeted? Is this defined somewhere? > > Thank you for your time, > > Silvestr Peknik > Software Specialist > TietoEnator > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Oct 03 22:21:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUwN4-0008Mz-JB; Tue, 03 Oct 2006 22:20:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUwN3-0008Mu-4r for simple@ietf.org; Tue, 03 Oct 2006 22:20:29 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUwN0-0005vM-Nm for simple@ietf.org; Tue, 03 Oct 2006 22:20:29 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 03 Oct 2006 19:20:26 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k942KQcJ016054; Tue, 3 Oct 2006 19:20:26 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k942JxJv026759; Tue, 3 Oct 2006 19:20:25 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 19:20:13 -0700 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 19:20:12 -0700 Message-ID: <45231A5B.8090802@cisco.com> Date: Tue, 03 Oct 2006 22:20:11 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Subject: Re: [Simple] About XCAP Authentication References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2006 02:20:12.0539 (UTC) FILETIME=[9F2FD4B0:01C6E75B] DKIM-Signature: a=rsa-sha1; q=dns; l=1475; t=1159928426; x=1160792426; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Simple]=20About=20XCAP=20Authentication; X=v=3Dcisco.com=3B=20h=3Dcham2h4d8+KUa5GwrzQpmxh/6Pg=3D; b=dMAM3JrddpqOJHWbt7NHjvz3iIPD1K8Y0e07T1NVXtFNmrofYLWA4Vcvt9/h1p3hW18a8ywj wAWC1jF0NwkjDkdavlVQ/vUaDtoIciCVPulgfV8GNKby3YCzsAg91Dn2; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 'Simple WG' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org The typical solution with HTTP is to run it over TLS, and authenticate just once using HTTP digest. After that, additional authentication operations are not needed. -Jonathan R. Jeffrey wrote: > Dear there, > > I am implementing XCAP for presence authorization rule and contact list > manipulation as specified by SIMPLE XCAP. I try to add authentication > mechanism on XCAP via HTTP Digest. But I wonder if every manipulation (like > GET, PUT, DELETE) between XCAP client and XCAP server has to go the process > of HTTP Digest Authentication. If it is necessary, I am afraid the > performance on XCAP operation will decrease. Any solution or suggestion for > better implementation? > > Thanks in advance. > > BR, > Jeffrey > > > %;+H%s%i/`%]'t$u,c0|>w1K8j0T!A+D+|)w$'&,%s*L!A=P$E(O%N)N4&ES%;+H%s$:.e!A(C=P>P74&9+H%s!C > This email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient. > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Oct 03 22:27:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUwTS-0005te-PS; Tue, 03 Oct 2006 22:27:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUwTR-0005tZ-If for simple@ietf.org; Tue, 03 Oct 2006 22:27:05 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUwTP-0006ym-7r for simple@ietf.org; Tue, 03 Oct 2006 22:27:05 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 03 Oct 2006 19:27:02 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k942R2xN021612; Tue, 3 Oct 2006 19:27:02 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k942R2ql013282; Tue, 3 Oct 2006 19:27:02 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 19:27:02 -0700 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 19:27:01 -0700 Message-ID: <45231BF4.7010308@cisco.com> Date: Tue, 03 Oct 2006 22:27:00 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Urpalainen Subject: Re: [Simple] Clarification on usage of xcap-diff References: <4522288F.3090704@nokia.com> <45223C1A.1000000@nokia.com> In-Reply-To: <45223C1A.1000000@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2006 02:27:01.0624 (UTC) FILETIME=[93053F80:01C6E75C] DKIM-Signature: a=rsa-sha1; q=dns; l=1369; t=1159928822; x=1160792822; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Simple]=20Clarification=20on=20usage=20of=20xcap-diff; X=v=3Dcisco.com=3B=20h=3Dg19aLrvt28oHmCT3X47KVYN4SPc=3D; b=U+I63f647Ms6JxMMao7Fd3TwWFUaXUmd5be7AJCFXQ4f86x2gDdI89kPI5OkQj9RuuUF+woV HP/PpYYGd4bydz6cmF483BX87akcQevEoYx5ZPFYncyUnvK4I8u1QY9Q; Authentication-Results: sj-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org inline. Jari Urpalainen wrote: >> Meaning of this is that * substitutes arbitrary element in the >> document and the first matching occurence will be the root element of >> the document. >> >> br, Martin >> >> >> > > right , wildcard "*" selects all element children (of the root node), > i.e. a valid xml document must only have one document root element, so > there's no ambiguity here. So you could even change to a different QName > but it is certainly rare. But you could for example, have XML entities > within the prologue which can't be described with XPath semantics. Also I suspect the server would find it easier to report the change without the change-log since it never got an XCAP operation than transformed the document from one version to the next (i.e., element additions or removals). You > don't generally use them, and then the client does a full re-fetch (and > there this open issue of xcap-diff still exists, at least theoretically). What open issue? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Oct 03 22:29:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUwVy-0007Fv-1S; Tue, 03 Oct 2006 22:29:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUwVw-0007Fc-7z for simple@ietf.org; Tue, 03 Oct 2006 22:29:40 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUwVr-000790-Oz for simple@ietf.org; Tue, 03 Oct 2006 22:29:40 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 03 Oct 2006 19:29:35 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k942TZks013312; Tue, 3 Oct 2006 19:29:35 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k942TYJn002237; Tue, 3 Oct 2006 19:29:35 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 Oct 2006 19:29:34 -0700 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 19:29:34 -0700 Message-ID: <45231C8C.6040007@cisco.com> Date: Tue, 03 Oct 2006 22:29:32 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: Re: [Simple] RE: question about Presence XDMS AUID References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 Oct 2006 02:29:34.0140 (UTC) FILETIME=[EDED57C0:01C6E75C] DKIM-Signature: a=rsa-sha1; q=dns; l=4138; t=1159928975; x=1160792975; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Simple]=20RE=3A=20question=20about=20Presence=20XDMS=20AUID; X=v=3Dcisco.com=3B=20h=3DGCwwIlHCj6mosEht8T2lpqN7yAw=3D; b=bAZrrcETdaa7a9pruyALgky1F06Dm7NTc+R+n8i3glb+KWV0q17HsK2It/JD4lT5RdPVCqSi L6HcACdc3KKJ/Na+o879WCDkspiyLJ0S7XaBXFhQj+V+TR0gre4eY7oQ; Authentication-Results: sj-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I don't think that external references are in any way antithetical to the design of common policy. Common policy readily specifies how rules are combined, and due to the additive nature of the grants, you end up with a privacy safe system if the references cannot be fetched. -Jonathan R. Markus.Isomaki@nokia.com wrote: > Hi, > > I think David is on the right track here. As Jonathan says, it would be possible just do extensions and keep the AUID. However, extensions such as and were quite contrary to the design of common policy, so at least I thought it safer to go with a separate AUID. I think common policy has some expectation on what should happen when rules from different sources are combined, and it becomes quite difficult if an extension breaks that logic. > > Markus > > > ________________________________ > > From: ext David Viamonte [mailto:david.viamonte@genaker.net] > Sent: 15 September, 2006 19:16 > To: Jonathan Rosenberg > Cc: simple@ietf.org > Subject: Re: [Simple] RE: question about Presence XDMS AUID > > > As I said, I do not judge OMA's decision. I just explained the differences. In general I agree it would have been possible to keep the AUID and define a new namespace with OMA extensions. This is similar -although not in the XCAP area- to what OMA has done to define new Presence elements. Perhaps there is space in OMA v2 to go that way. > > Just one minor comment: usage of external references is explicitly discouraged in section 5 of IETF Common Policies. Although it mentions that this feature could be added as an extension in a future version, perhaps the "strong" statement made someone think it made sense to define a new AUID? > > Cheers, > > David > > > > Jonathan Rosenberg escribi�: > > I'll note that it is possible to define extensions WITHOUT having to define a new AUID. > > By defining a new AUID, the OMA presence-rules is not backwards compatible or interoperable with the generic IETF version. Servers would need to support both, and clients at least one. > > Instead, had these just beed defined as extensions within a different namespace, you would have a single AUID, a single mechanism, and backwards compatibility based on the defined extensibility rules in common policy. > > -Jonathan R. > > David Viamonte wrote: > > > > Hi, > > Observe that the element is not the only difference. > > Actually, if you have a look at the reference I provided earlier (section 6.6.2 in the XDM core spec) the differences between Common Policy and OMA Presence Rules are supposed to be the following ones: > > - > - > - > > Thus, even if the element could potentially cover the identity> functionality, there are still OMA elements which are not addressed (anonymous requests and external URI lists). You can refer to my previous post about why an element may be useful from the OMA point of view. The is self-explanatory. > > I do not judge pros (IETF spec compliancy) and cons (standardization delay) of not having raised these elements as generic requirements into IETF. > > I agree with your considerations about IOP. > > Hope this helps. > > Cheers, > > David > > ------------------------------------------------- > This mail sent through IMP: http://horde.org/imp/ > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Oct 04 02:51:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV0aT-0003me-Pc; Wed, 04 Oct 2006 02:50:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV0aS-0003mJ-D8 for simple@ietf.org; Wed, 04 Oct 2006 02:50:36 -0400 Received: from datnt07.tieto.com ([194.110.47.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV0aI-0000JU-Jw for simple@ietf.org; Wed, 04 Oct 2006 02:50:36 -0400 Received: from veyron.eu.tieto.com ([194.110.47.230]) by datnt07.tieto.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Oct 2006 09:49:47 +0300 Received: from sagaris.eu.tieto.com ([131.207.197.143]) by veyron.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 09:50:14 +0300 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: [Simple] Request URI and To header in SUBSCRIBE request Date: Wed, 4 Oct 2006 09:50:18 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Request URI and To header in SUBSCRIBE request Thread-Index: Acbm4zweaeWZ8pDRQzyACmxddgXQRAAngIiQ From: To: X-OriginalArrivalTime: 04 Oct 2006 06:50:14.0601 (UTC) FILETIME=[585E4B90:01C6E781] X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: David.Pilar@tietoenator.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org So, does To header have any purpose apart from dialog identification? Silvestr >-----Original Message----- >From: samuel [mailto:samu60@gmail.com] >Sent: Tuesday, October 03, 2006 1:58 PM >To: Peknik Silvestr >Cc: simple@ietf.org; Pilar David >Subject: Re: [Simple] Request URI and To header in SUBSCRIBE request > >Req-URI always identifies the target of the request. > >Samuel. >2006/10/3, Silvestr.Peknik@tietoenator.com >: >> Hello, >> >> I am not able to find out what should happen when a SUBSCRIBE request >> has different URIs in Request URI and in To header: >> >> >> SUBSCRIBE sip:user1@example.com SIP/2.0 >> ... >> To: sip:user2@example.com >> ... >> >> Which header should I take as the one to which the subscription is >> targeted? Is this defined somewhere? >> >> Thank you for your time, >> >> Silvestr Peknik >> Software Specialist >> TietoEnator >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Oct 04 04:57:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV2Xt-0005i6-70; Wed, 04 Oct 2006 04:56:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV2Xs-0005i1-B5 for simple@ietf.org; Wed, 04 Oct 2006 04:56:04 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV2Xq-0006Qr-Sh for simple@ietf.org; Wed, 04 Oct 2006 04:56:04 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k948tsQl011271; Wed, 4 Oct 2006 11:55:59 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 11:55:51 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 4 Oct 2006 11:55:51 +0300 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int02.ntc.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k948tnPK017291; Wed, 4 Oct 2006 11:55:49 +0300 Received: from [172.21.38.148] (esdhcp038148.research.nokia.com [172.21.38.148]) by kusti.research.nokia.com (Postfix) with ESMTP id E868D93B78; Wed, 4 Oct 2006 11:55:48 +0300 (EEST) Message-ID: <45237714.6030306@nokia.com> Date: Wed, 04 Oct 2006 11:55:48 +0300 From: Jari Urpalainen User-Agent: Thunderbird 1.5.0.7 (X11/20060913) MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Simple] Clarification on usage of xcap-diff References: <4522288F.3090704@nokia.com> <45223C1A.1000000@nokia.com> <45231BF4.7010308@cisco.com> In-Reply-To: <45231BF4.7010308@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2006 08:55:51.0531 (UTC) FILETIME=[E4BA8BB0:01C6E792] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org ext Jonathan Rosenberg wrote: > inline. > > Jari Urpalainen wrote: > > >>> Meaning of this is that * substitutes arbitrary element in the >>> document and the first matching occurence will be the root element >>> of the document. >>> >>> br, Martin >>> >>> >>> >> >> right , wildcard "*" selects all element children (of the root node), >> i.e. a valid xml document must only have one document root element, >> so there's no ambiguity here. So you could even change to a different >> QName but it is certainly rare. But you could for example, have XML >> entities within the prologue which can't be described with XPath >> semantics. > > Also I suspect the server would find it easier to report the change > without the change-log since it never got an XCAP operation than > transformed the document from one version to the next (i.e., element > additions or removals). > right. However, I've implemented also "xmldiff" based on patch-ops and while it is in general much more complex (with many possible algorithms) than patching (be it xcap, patch-ops etc.) you can still implement one with "basic" simple rules without enormous amount of complex code. So the end result may not be the most efficient one but it is certainly doable and imo yes, even worth implementing e.g. for xcap clients. > > You >> don't generally use them, and then the client does a full re-fetch >> (and there this open issue of xcap-diff still exists, at least >> theoretically). > > What open issue? > > -Jonathan R. > I was just referring to the "old" documented issue, i.e. the initial sync of http resources/sip notify. It may however, be that this belongs to config-paper, but all the proposed solutions seem to have some inadequacy and/or complexity, or is there a (new) reasonable resolution here that I'm unaware of ? thanks, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Oct 04 11:07:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV8KY-00029Q-O4; Wed, 04 Oct 2006 11:06:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV8KX-00029L-NQ for simple@ietf.org; Wed, 04 Oct 2006 11:06:41 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV8KW-0001LL-9h for simple@ietf.org; Wed, 04 Oct 2006 11:06:41 -0400 Received: from S4DE9JSAAHV.ost.t-com.de (S4DE9JSAAHV.ost.t-com.de [10.125.177.138]) by tcmail21.dmz.telekom.de with ESMTP for simple@ietf.org; Wed, 4 Oct 2006 17:06:35 +0200 Received: from S4DE9JSAAMW.ost.t-com.de ([10.125.177.114]) by S4DE9JSAAHV.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 17:06:34 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Oct 2006 17:06:35 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IM rules Thread-Index: Acbnxq4H/VC58+SIRHaZ7vN62uQkUQ== From: "Alexeitsev, D" To: X-OriginalArrivalTime: 04 Oct 2006 15:06:34.0797 (UTC) FILETIME=[AEBF95D0:01C6E7C6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Simple] IM rules X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1771655504==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1771655504== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E7C6.AF1C0186" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E7C6.AF1C0186 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello altogether Are there any I-Ds discussing the Instant Message authorisation rules, basically black/white lists. The OMA does some extensions to the common policy framework for the IM policing, but are there any IETF documents on this? Thanks, Denis Alexeitsev=20 ------_=_NextPart_001_01C6E7C6.AF1C0186 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IM rules

Hello altogether

Are there any I-Ds discussing the = Instant Message authorisation rules, basically black/white lists.

The OMA does some extensions to the = common policy framework for the IM policing, but are there any IETF = documents on this?

Thanks,
Denis Alexeitsev

------_=_NextPart_001_01C6E7C6.AF1C0186-- --===============1771655504== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1771655504==-- From simple-bounces@ietf.org Wed Oct 04 15:59:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVCto-0002ED-38; Wed, 04 Oct 2006 15:59:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVCtn-0002E5-2D for simple@ietf.org; Wed, 04 Oct 2006 15:59:23 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVCtd-0002Mw-Qa for simple@ietf.org; Wed, 04 Oct 2006 15:59:23 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 04 Oct 2006 15:59:13 -0400 X-IronPort-AV: i="4.09,256,1157342400"; d="scan'208"; a="105736836:sNHT50979452" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k94JxD2k013375; Wed, 4 Oct 2006 15:59:13 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k94JxAuO000231; Wed, 4 Oct 2006 15:59:13 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 15:59:12 -0400 Received: from [161.44.55.134] ([161.44.55.134]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 15:59:11 -0400 Message-ID: <4524128F.80804@cisco.com> Date: Wed, 04 Oct 2006 15:59:11 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alexeitsev, D" Subject: Re: [Simple] IM rules References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2006 19:59:11.0760 (UTC) FILETIME=[8F838900:01C6E7EF] DKIM-Signature: a=rsa-sha1; q=dns; l=901; t=1159991953; x=1160855953; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Simple]=20IM=20rules |To:=22Alexeitsev,=20D=22=20; X=v=3Dcisco.com=3B=20h=3DGaquJRympnB43MlTCVhWlBrRnTo=3D; b=e+kO9EqPMOuPz/I20ARk5+YPkJ1Vs/vvWGccEpFE2PAjPk5tljBfR4NLHFbmqkkwqFhnYpjg fBH4JhSJAufOCUhZdA1mKoeYtYdIw2ObTjg074l+wDMPzkK4d1UCihjg; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org No. -Jonathan R. Alexeitsev, D wrote: > Hello altogether > > Are there any I-Ds discussing the Instant Message authorisation rules, > basically black/white lists. > > The OMA does some extensions to the common policy framework for the IM > policing, but are there any IETF documents on this? > > Thanks, > Denis Alexeitsev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Oct 04 15:59:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVCtS-0001zz-Dc; Wed, 04 Oct 2006 15:59:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVCtR-0001zU-8C for simple@ietf.org; Wed, 04 Oct 2006 15:59:01 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVCtB-0002Eh-1j for simple@ietf.org; Wed, 04 Oct 2006 15:59:01 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 04 Oct 2006 12:58:45 -0700 X-IronPort-AV: i="4.09,256,1157353200"; d="scan'208"; a="44855359:sNHT58127144" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k94Jwi8w008998; Wed, 4 Oct 2006 15:58:44 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k94JwiuI029989; Wed, 4 Oct 2006 15:58:44 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 15:58:44 -0400 Received: from [161.44.55.134] ([161.44.55.134]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 15:58:43 -0400 Message-ID: <45241273.3030801@cisco.com> Date: Wed, 04 Oct 2006 15:58:43 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Urpalainen Subject: Re: [Simple] Clarification on usage of xcap-diff References: <4522288F.3090704@nokia.com> <45223C1A.1000000@nokia.com> <45231BF4.7010308@cisco.com> <45237714.6030306@nokia.com> In-Reply-To: <45237714.6030306@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2006 19:58:43.0511 (UTC) FILETIME=[7EAD1470:01C6E7EF] DKIM-Signature: a=rsa-sha1; q=dns; l=1919; t=1159991924; x=1160855924; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Simple]=20Clarification=20on=20usage=20of=20xcap-diff |To:Jari=20Urpalainen=20; X=v=3Dcisco.com=3B=20h=3Dg19aLrvt28oHmCT3X47KVYN4SPc=3D; b=COll/LZBta3DZ+S8ouv3W4LektFSTaFCpKu74Tg4vzQ/RatjzhUo9gbMjRj4pXvL+SyBGtWF aIxoxVjjMfmv6WHjao5r8XzKyr9Iq3vlb2Es/AQbw/icXlceGKWrG6pV; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org inline. Jari Urpalainen wrote: >> >>> don't generally use them, and then the client does a full re-fetch >>> (and there this open issue of xcap-diff still exists, at least >>> theoretically). >> >> >> What open issue? >> >> -Jonathan R. >> > I was just referring to the "old" documented issue, i.e. the initial > sync of http resources/sip notify. It may however, be that this belongs > to config-paper, but all the proposed solutions seem to have some > inadequacy and/or complexity, or is there a (new) reasonable resolution > here that I'm unaware of ? I have been thinking about this lately. Firstly I think it makes sense to put this issue in the event package draft (http://www.ietf.org/internet-drafts/draft-ietf-sipping-xcap-config-00.txt), so that xcap-diff is pure format and can proceed easily. On the issue itself, I think there is a simpler solution than what is in the document. The idea is this. When you get a NOTIFY with an etag, you do a non-conditional GET. This will either produce a version with the same etag as you had in the NOTIFY, or not. If not, it has to be because the document has changed since the previous NOTIFY, and so another NOTIFY is coming. When that NOTIFY comes, you check its new-etag. If it matches the document, great. If not, discard and wait for the next NOTIFY. You'll eventually get a NOTIFY whose new etag matches the document received via HTTP. At this point you are synchronized. This will work as long as the server is sending NOTIFYs for each document change. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Oct 04 15:59:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVCto-0002ED-38; Wed, 04 Oct 2006 15:59:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVCtn-0002E5-2D for simple@ietf.org; Wed, 04 Oct 2006 15:59:23 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVCtd-0002Mw-Qa for simple@ietf.org; Wed, 04 Oct 2006 15:59:23 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 04 Oct 2006 15:59:13 -0400 X-IronPort-AV: i="4.09,256,1157342400"; d="scan'208"; a="105736836:sNHT50979452" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k94JxD2k013375; Wed, 4 Oct 2006 15:59:13 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k94JxAuO000231; Wed, 4 Oct 2006 15:59:13 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 15:59:12 -0400 Received: from [161.44.55.134] ([161.44.55.134]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 15:59:11 -0400 Message-ID: <4524128F.80804@cisco.com> Date: Wed, 04 Oct 2006 15:59:11 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alexeitsev, D" Subject: Re: [Simple] IM rules References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2006 19:59:11.0760 (UTC) FILETIME=[8F838900:01C6E7EF] DKIM-Signature: a=rsa-sha1; q=dns; l=901; t=1159991953; x=1160855953; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Simple]=20IM=20rules |To:=22Alexeitsev,=20D=22=20; X=v=3Dcisco.com=3B=20h=3DGaquJRympnB43MlTCVhWlBrRnTo=3D; b=e+kO9EqPMOuPz/I20ARk5+YPkJ1Vs/vvWGccEpFE2PAjPk5tljBfR4NLHFbmqkkwqFhnYpjg fBH4JhSJAufOCUhZdA1mKoeYtYdIw2ObTjg074l+wDMPzkK4d1UCihjg; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org No. -Jonathan R. Alexeitsev, D wrote: > Hello altogether > > Are there any I-Ds discussing the Instant Message authorisation rules, > basically black/white lists. > > The OMA does some extensions to the common policy framework for the IM > policing, but are there any IETF documents on this? > > Thanks, > Denis Alexeitsev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Oct 04 15:59:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVCtS-0001zz-Dc; Wed, 04 Oct 2006 15:59:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVCtR-0001zU-8C for simple@ietf.org; Wed, 04 Oct 2006 15:59:01 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVCtB-0002Eh-1j for simple@ietf.org; Wed, 04 Oct 2006 15:59:01 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 04 Oct 2006 12:58:45 -0700 X-IronPort-AV: i="4.09,256,1157353200"; d="scan'208"; a="44855359:sNHT58127144" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k94Jwi8w008998; Wed, 4 Oct 2006 15:58:44 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k94JwiuI029989; Wed, 4 Oct 2006 15:58:44 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 15:58:44 -0400 Received: from [161.44.55.134] ([161.44.55.134]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 15:58:43 -0400 Message-ID: <45241273.3030801@cisco.com> Date: Wed, 04 Oct 2006 15:58:43 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Urpalainen Subject: Re: [Simple] Clarification on usage of xcap-diff References: <4522288F.3090704@nokia.com> <45223C1A.1000000@nokia.com> <45231BF4.7010308@cisco.com> <45237714.6030306@nokia.com> In-Reply-To: <45237714.6030306@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2006 19:58:43.0511 (UTC) FILETIME=[7EAD1470:01C6E7EF] DKIM-Signature: a=rsa-sha1; q=dns; l=1919; t=1159991924; x=1160855924; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Simple]=20Clarification=20on=20usage=20of=20xcap-diff |To:Jari=20Urpalainen=20; X=v=3Dcisco.com=3B=20h=3Dg19aLrvt28oHmCT3X47KVYN4SPc=3D; b=COll/LZBta3DZ+S8ouv3W4LektFSTaFCpKu74Tg4vzQ/RatjzhUo9gbMjRj4pXvL+SyBGtWF aIxoxVjjMfmv6WHjao5r8XzKyr9Iq3vlb2Es/AQbw/icXlceGKWrG6pV; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org inline. Jari Urpalainen wrote: >> >>> don't generally use them, and then the client does a full re-fetch >>> (and there this open issue of xcap-diff still exists, at least >>> theoretically). >> >> >> What open issue? >> >> -Jonathan R. >> > I was just referring to the "old" documented issue, i.e. the initial > sync of http resources/sip notify. It may however, be that this belongs > to config-paper, but all the proposed solutions seem to have some > inadequacy and/or complexity, or is there a (new) reasonable resolution > here that I'm unaware of ? I have been thinking about this lately. Firstly I think it makes sense to put this issue in the event package draft (http://www.ietf.org/internet-drafts/draft-ietf-sipping-xcap-config-00.txt), so that xcap-diff is pure format and can proceed easily. On the issue itself, I think there is a simpler solution than what is in the document. The idea is this. When you get a NOTIFY with an etag, you do a non-conditional GET. This will either produce a version with the same etag as you had in the NOTIFY, or not. If not, it has to be because the document has changed since the previous NOTIFY, and so another NOTIFY is coming. When that NOTIFY comes, you check its new-etag. If it matches the document, great. If not, discard and wait for the next NOTIFY. You'll eventually get a NOTIFY whose new etag matches the document received via HTTP. At this point you are synchronized. This will work as long as the server is sending NOTIFYs for each document change. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Oct 05 03:04:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVNGR-0002wP-W6; Thu, 05 Oct 2006 03:03:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVNGQ-0002wK-Hi for simple@ietf.org; Thu, 05 Oct 2006 03:03:26 -0400 Received: from mail.tieto.com ([194.110.47.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVNGL-00070k-1H for simple@ietf.org; Thu, 05 Oct 2006 03:03:26 -0400 Received: from viper.eu.tieto.com ([194.110.47.167]) by mail.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 10:03:03 +0300 Received: from sagaris.eu.tieto.com ([131.207.197.143]) by viper.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 10:03:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Clarification on usage of xcap-diff Date: Thu, 5 Oct 2006 10:00:50 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Clarification on usage of xcap-diff Thread-Index: Acbn74D/m34QboWgT4OkE4JAKdXvlAAXHy7g References: <4522288F.3090704@nokia.com> <45223C1A.1000000@nokia.com> <45231BF4.7010308@cisco.com> <45237714.6030306@nokia.com> <45241273.3030801@cisco.com> From: To: , X-OriginalArrivalTime: 05 Oct 2006 07:03:05.0332 (UTC) FILETIME=[4E2C4340:01C6E84C] X-Spam-Score: 0.2 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hello, the usage with ietf-sipping-xcap-config is one of xcap-diff = applications. And this one is also used in OMA specifications. br, Martin -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: Wed 10/4/2006 9:58 PM To: Jari Urpalainen Cc: Hynar Martin; simple@ietf.org Subject: Re: [Simple] Clarification on usage of xcap-diff =20 inline. Jari Urpalainen wrote: >> >>> don't generally use them, and then the client does a full re-fetch=20 >>> (and there this open issue of xcap-diff still exists, at least=20 >>> theoretically). >> >> >> What open issue? >> >> -Jonathan R. >> > I was just referring to the "old" documented issue, i.e. the initial=20 > sync of http resources/sip notify. It may however, be that this = belongs=20 > to config-paper, but all the proposed solutions seem to have some=20 > inadequacy and/or complexity, or is there a (new) reasonable = resolution=20 > here that I'm unaware of ? I have been thinking about this lately. Firstly I think it makes sense to put this issue in the event package=20 draft=20 (http://www.ietf.org/internet-drafts/draft-ietf-sipping-xcap-config-00.tx= t),=20 so that xcap-diff is pure format and can proceed easily. On the issue itself, I think there is a simpler solution than what is in = the document. The idea is this. When you get a NOTIFY with an etag, you=20 do a non-conditional GET. This will either produce a version with the=20 same etag as you had in the NOTIFY, or not. If not, it has to be because = the document has changed since the previous NOTIFY, and so another=20 NOTIFY is coming. When that NOTIFY comes, you check its new-etag. If it=20 matches the document, great. If not, discard and wait for the next=20 NOTIFY. You'll eventually get a NOTIFY whose new etag matches the=20 document received via HTTP. At this point you are synchronized. This will work as long as the server is sending NOTIFYs for each=20 document change. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Oct 05 03:40:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVNq7-0008PK-TV; Thu, 05 Oct 2006 03:40:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVNq6-0008PF-EG for simple@ietf.org; Thu, 05 Oct 2006 03:40:18 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVNq1-0007f6-M9 for simple@ietf.org; Thu, 05 Oct 2006 03:40:18 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k957e1qU009042; Thu, 5 Oct 2006 10:40:04 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 10:40:03 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 5 Oct 2006 10:40:03 +0300 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int02.ntc.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k957e2d8031287; Thu, 5 Oct 2006 10:40:02 +0300 Received: from [172.21.38.148] (esdhcp038148.research.nokia.com [172.21.38.148]) by kusti.research.nokia.com (Postfix) with ESMTP id B2E8F93B78; Thu, 5 Oct 2006 10:40:02 +0300 (EEST) Message-ID: <4524B6D2.8050205@nokia.com> Date: Thu, 05 Oct 2006 10:40:02 +0300 From: Jari Urpalainen User-Agent: Thunderbird 1.5.0.7 (X11/20060913) MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Simple] Clarification on usage of xcap-diff References: <4522288F.3090704@nokia.com> <45223C1A.1000000@nokia.com> <45231BF4.7010308@cisco.com> <45237714.6030306@nokia.com> <45241273.3030801@cisco.com> In-Reply-To: <45241273.3030801@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2006 07:40:03.0235 (UTC) FILETIME=[78256730:01C6E851] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org ext Jonathan Rosenberg wrote: > inline. > > Jari Urpalainen wrote: > > >>> >>>> don't generally use them, and then the client does a full re-fetch >>>> (and there this open issue of xcap-diff still exists, at least >>>> theoretically). >>> >>> >>> What open issue? >>> >>> -Jonathan R. >>> >> I was just referring to the "old" documented issue, i.e. the initial >> sync of http resources/sip notify. It may however, be that this >> belongs to config-paper, but all the proposed solutions seem to have >> some inadequacy and/or complexity, or is there a (new) reasonable >> resolution here that I'm unaware of ? > > > I have been thinking about this lately. > > Firstly I think it makes sense to put this issue in the event package > draft > (http://www.ietf.org/internet-drafts/draft-ietf-sipping-xcap-config-00.txt), > so that xcap-diff is pure format and can proceed easily. > agreed, it is a better place. > On the issue itself, I think there is a simpler solution than what is > in the document. The idea is this. When you get a NOTIFY with an etag, > you do a non-conditional GET. This will either produce a version with > the same etag as you had in the NOTIFY, or not. If not, it has to be > because the document has changed since the previous NOTIFY, and so > another NOTIFY is coming. When that NOTIFY comes, you check its > new-etag. If it matches the document, great. If not, discard and wait > for the next NOTIFY. You'll eventually get a NOTIFY whose new etag > matches the document received via HTTP. At this point you are > synchronized. > > This will work as long as the server is sending NOTIFYs for each > document change. > > -Jonathan R. > right, this is the simplest approach which is probably good enough for XCAP resources. The disturbing fact is that servers could never do efficient aggregation of individual patches. Instead, you should provide several elements for the same resource, which isn't that nice. Btw. maxOccurs="unbounded" cardinality is missing from schema definition. How about adding some semantics to re-SUBSCRIBE to tell the server "aggregation allowed" meaning sync achieved on the client side ? thanks, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Oct 05 05:41:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVPi5-0002UR-Bl; Thu, 05 Oct 2006 05:40:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVPi3-0002UC-Ov for simple@ietf.org; Thu, 05 Oct 2006 05:40:07 -0400 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVPi2-00025i-8q for simple@ietf.org; Thu, 05 Oct 2006 05:40:07 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id k959e50E110906 for ; Thu, 5 Oct 2006 09:40:05 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k959gGao2732034 for ; Thu, 5 Oct 2006 11:42:16 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k959e5iK024160 for ; Thu, 5 Oct 2006 11:40:05 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k959e40L024155 for ; Thu, 5 Oct 2006 11:40:04 +0200 To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Thu, 5 Oct 2006 11:42:14 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.5HF607 | June 26, 2006) at 05/10/2006 11:42:15, Serialize complete at 05/10/2006 11:42:15 X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [Simple] sip, sips, pres schemas X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0141674260==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============0141674260== Content-Type: multipart/alternative; boundary="=_alternative 00351D96C22571FE_=" This is a multipart message in MIME format. --=_alternative 00351D96C22571FE_= Content-Type: text/plain; charset="US-ASCII" This question may have been raised before but I do not recall that it was completely answered. Assume that a user: * Subscribes to sips:X@Y.com * Subscribes to sip:X@Y.com * Subscribes to pres:X@Y.com This may happen especially when subscribing to groups. Should these be considered as three separate entities? Should each subscription get a notification only when the subscribed to schema is published? If the user should get the same PIDF document for all its subscriptions (no matter which scheme the user have used), what should be the leading entity sips, sip, pres? Should the leading entity be changed as the presence server learns more general schemas (pres: is more general then sip: for example)? I am not sure how clients will handle changing the leading entity on different notifies. --Avshalom --=_alternative 00351D96C22571FE_= Content-Type: text/html; charset="US-ASCII"
This question may have been raised before but I do not recall that it
was completely answered.

Assume that a user:
* Subscribes to sips:X@Y.com
* Subscribes to sip:X@Y.com
* Subscribes to pres:X@Y.com

This may happen especially when subscribing to groups.

Should these be considered as three separate entities?
Should each subscription get a notification only when the subscribed to
schema is published?

If the user should get the same PIDF document for all its subscriptions
(no matter which scheme the user have used), what should be the leading
entity sips, sip, pres? Should the leading entity be changed as the
presence server learns more general schemas (pres: is more general
then sip: for example)? I am not sure how clients will handle changing
the leading entity on different notifies.

--Avshalom

--=_alternative 00351D96C22571FE_=-- --===============0141674260== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0141674260==-- From simple-bounces@ietf.org Thu Oct 05 15:51:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVZEy-0000jh-6O; Thu, 05 Oct 2006 15:50:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVZEm-0000Qx-Cr; Thu, 05 Oct 2006 15:50:32 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVZEm-0007rX-AA; Thu, 05 Oct 2006 15:50:32 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GVZEm-0001XM-0c; Thu, 05 Oct 2006 15:50:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id B639817607; Thu, 5 Oct 2006 19:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GVZEH-0006gg-B2; Thu, 05 Oct 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 05 Oct 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-diff-03.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-diff-03.txt Pages : 14 Date : 2006-10-5 This specification defines a document format that can be used to indicate that a change has occurred in a document managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). This format indicates the document that has changed and its former and new entity tags. It also can indicate the specific change that was made in the document, using an XML patch format. XCAP diff documents can be delivered to clients using a number of means, including a Session Initiation Protocol (SIP) event package. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-diff-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-xcap-diff-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-xcap-diff-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-5100513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-diff-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-diff-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-5100513.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Thu Oct 05 16:57:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVaG9-0005AP-3o; Thu, 05 Oct 2006 16:56:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVaG8-0005AK-27 for simple@ietf.org; Thu, 05 Oct 2006 16:56:00 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVaG5-0004D2-LH for simple@ietf.org; Thu, 05 Oct 2006 16:56:00 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Oct 2006 16:55:57 -0400 X-IronPort-AV: i="4.09,266,1157342400"; d="scan'208"; a="105892384:sNHT55663754" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k95KtvlQ001211; Thu, 5 Oct 2006 16:55:57 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k95KtsYL018035; Thu, 5 Oct 2006 16:55:57 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 16:55:54 -0400 Received: from [160.39.252.102] ([10.86.240.209]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 16:55:54 -0400 Message-ID: <4525715A.3040304@cisco.com> Date: Thu, 05 Oct 2006 16:55:54 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Urpalainen Subject: Re: [Simple] Clarification on usage of xcap-diff References: <4522288F.3090704@nokia.com> <45223C1A.1000000@nokia.com> <45231BF4.7010308@cisco.com> <45237714.6030306@nokia.com> <45241273.3030801@cisco.com> <4524B6D2.8050205@nokia.com> In-Reply-To: <4524B6D2.8050205@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2006 20:55:54.0243 (UTC) FILETIME=[A5F6FD30:01C6E8C0] DKIM-Signature: a=rsa-sha1; q=dns; l=2589; t=1160081757; x=1160945757; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Simple]=20Clarification=20on=20usage=20of=20xcap-diff |To:Jari=20Urpalainen=20; X=v=3Dcisco.com=3B=20h=3Dg19aLrvt28oHmCT3X47KVYN4SPc=3D; b=HHb7BP7srdahJiPZAkwi2T7G1+Ku7l0oOKJVDlITwnt+JoqBqDb36hnmF4CQpvSaNWvMhUG9 vyha4OzLSQon7qbJ1Hz1wU1+9MxzSeUk0b5nQVL4KIv7sks6+224T8OJ; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org inline. Jari Urpalainen wrote: >> Firstly I think it makes sense to put this issue in the event package >> draft >> (http://www.ietf.org/internet-drafts/draft-ietf-sipping-xcap-config-00.txt), >> so that xcap-diff is pure format and can proceed easily. >> > agreed, it is a better place. Right. I will strike the section from the revision of the document. > >> On the issue itself, I think there is a simpler solution than what is >> in the document. The idea is this. When you get a NOTIFY with an etag, >> you do a non-conditional GET. This will either produce a version with >> the same etag as you had in the NOTIFY, or not. If not, it has to be >> because the document has changed since the previous NOTIFY, and so >> another NOTIFY is coming. When that NOTIFY comes, you check its >> new-etag. If it matches the document, great. If not, discard and wait >> for the next NOTIFY. You'll eventually get a NOTIFY whose new etag >> matches the document received via HTTP. At this point you are >> synchronized. >> >> This will work as long as the server is sending NOTIFYs for each >> document change. > right, this is the simplest approach which is probably good enough for > XCAP resources. The disturbing fact is that servers could never do > efficient aggregation of individual patches. I wouldn't say never; the server can do it once it knows that the client has the specific version whose etag is in the NOTIFY. The ultimate fix for this is something I think Aki proposed in sipping way back (which we need to revisit), which was that a SUBSCRIBE could contain the etag of the resource being subscibed to that the client already has. Instead, you should provide > several elements for the same resource, which isn't that > nice. Sorry - I don't follow this... > Btw. maxOccurs="unbounded" cardinality is missing from > schema definition. Yes, I know. This had been pointed out to me privately by others. > How about adding some semantics to re-SUBSCRIBE to > tell the server "aggregation allowed" meaning sync achieved on the > client side ? I think the etag-in-SUBSCRIBE approach would provide a clean way to do that. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Oct 05 17:06:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVaPq-0004Tq-D6; Thu, 05 Oct 2006 17:06:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVaPp-0004Tk-Ac for simple@ietf.org; Thu, 05 Oct 2006 17:06:01 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVaPo-0005Gv-1I for simple@ietf.org; Thu, 05 Oct 2006 17:06:01 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Oct 2006 17:05:58 -0400 X-IronPort-AV: i="4.09,266,1157342400"; d="scan'208"; a="105893689:sNHT4046125130" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k95L5wAX006793; Thu, 5 Oct 2006 17:05:58 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k95L5vYJ022221; Thu, 5 Oct 2006 17:05:58 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 17:05:57 -0400 Received: from [160.39.252.102] ([10.86.240.209]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 17:05:57 -0400 Message-ID: <452573B4.8030802@cisco.com> Date: Thu, 05 Oct 2006 17:05:56 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avshalom Houri Subject: Re: [Simple] sip, sips, pres schemas References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2006 21:05:57.0123 (UTC) FILETIME=[0D4F2D30:01C6E8C2] DKIM-Signature: a=rsa-sha1; q=dns; l=2204; t=1160082358; x=1160946358; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Simple]=20sip,=20sips,=20pres=20schemas |To:Avshalom=20Houri=20; X=v=3Dcisco.com=3B=20h=3Danwh4GMKVlP8ntxz2Q8fW6PaU08=3D; b=gvYkU7o7lAuu5V5l+QC1/l4ac1opMr04Qv5Pr9Ew7ufwnh9PEZz3rHfBvzDTxsvfCKv/gnb1 YYlPGHO4D8bZK4eCbOXiOn+76UKuqj5L57qi5iOjMzB/zAd5OTs9tX7V; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org inline. Avshalom Houri wrote: > > This question may have been raised before but I do not recall that it > was completely answered. > > Assume that a user: > * Subscribes to sips:X@Y.com > * Subscribes to sip:X@Y.com > * Subscribes to pres:X@Y.com > > This may happen especially when subscribing to groups. > > Should these be considered as three separate entities? The sip and sips would be the same entity. The pres ought to be. > Should each subscription get a notification only when the subscribed to > schema is published? Assuming each URI points to the same resource, there would be a notify on each subscription when it changes, whether its a consequence of a publish or something else. > > If the user should get the same PIDF document for all its subscriptions > (no matter which scheme the user have used), what should be the leading > entity sips, sip, pres? Well, this at least is answered in RFC 4479, which says this: When a document is constructed, the presentity URI is ideally set to the identifier used to request the document in the first place. For example, if a document was requested through a SIP SUBSCRIBE request, the presentity URI would match the Request URI of the SUBSCRIBE request. This follows the principle of least surprise, since the entity requesting the document may not be aware of the other identifiers for the presentity. >Should the leading entity be changed as the > presence server learns more general schemas (pres: is more general > then sip: for example)? I am not sure how clients will handle changing > the leading entity on different notifies. I don't follow here. What do you mean by 'learn'? The subscription is established to a particular URI, and the notifications would contain a presentity ID of that form. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Oct 06 01:04:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVhrh-0005RW-MW; Fri, 06 Oct 2006 01:03:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVhrg-0005RQ-8K for simple@ietf.org; Fri, 06 Oct 2006 01:03:16 -0400 Received: from [202.54.171.30] (helo=mmcmail.megasoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVhre-0006zD-9Z for simple@ietf.org; Fri, 06 Oct 2006 01:03:16 -0400 Received: from voip06 (voip06.megasoft.com [172.16.0.72] (may be forged)) by mmcmail.megasoft.com (8.12.10/8.12.10) with ESMTP id k9652iH8030559 for ; Fri, 6 Oct 2006 10:32:52 +0530 Message-Id: <200610060502.k9652iH8030559@mmcmail.megasoft.com> From: "HEM" To: Date: Fri, 6 Oct 2006 10:34:45 +0530 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcbpBPByo8jLNc2wTSybDda3rcESZA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Subject: [Simple] how to reduce no of subscribe between rls and presence.... X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1006677057==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1006677057== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C6E933.0C51D010" This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C6E933.0C51D010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear SIMPLE subscribers, My query : In my presence design there are 30 peoples who should subscribe all each other. This means every user has buddies of all other 29 peoples. Problem: Every user sends subscribe to list (RLS). RLS sends 29 subscribe to Presence server to get the status in the Notification. All the 30 users subscribes to rls then 30 X 29 = 870 subscribe is sent to the Presence server. Now almost same 30 notification goint to sent 29 times. Is there any possible to reduce this subscription rate. Eg. While sending first user subscribe we get all 30 persons notification. Is there any possibility to avoid other persons subscription to send it to presence.... Is there any document speaks about this??? Expecting your suggestions help me... By Hem ------=_NextPart_000_0010_01C6E933.0C51D010 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear SIMPLE = subscribers,

My query : In my presence design there are 30 peoples = who should subscribe all each other. This means every user has buddies of all other = 29 peoples.

Problem: Every user sends subscribe to list (RLS). = RLS sends 29 subscribe to Presence server to get the status in the = Notification.

All the 30 users subscribes to rls then 30 X 29 =3D = 870 subscribe is sent to the Presence server. Now almost same 30 = notification goint to sent 29 times. Is there any possible to reduce this subscription = rate.

Eg. While sending first user subscribe we get all 30 = persons notification. Is there any possibility to avoid other persons = subscription to send it to presence……….

Is there any document speaks about = this???

Expecting your suggestions help = me…..

Hem

------=_NextPart_000_0010_01C6E933.0C51D010-- --===============1006677057== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1006677057==-- From simple-bounces@ietf.org Fri Oct 06 02:23:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVj6Q-0004v1-7Y; Fri, 06 Oct 2006 02:22:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVj6P-0004uk-39 for simple@ietf.org; Fri, 06 Oct 2006 02:22:33 -0400 Received: from [202.54.171.30] (helo=mmcmail.megasoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVj6L-0001UQ-W5 for simple@ietf.org; Fri, 06 Oct 2006 02:22:32 -0400 Received: from voip06 (voip06.megasoft.com [172.16.0.72] (may be forged)) by mmcmail.megasoft.com (8.12.10/8.12.10) with ESMTP id k966MNH8002685 for ; Fri, 6 Oct 2006 11:52:26 +0530 Message-Id: <200610060622.k966MNH8002685@mmcmail.megasoft.com> From: "HEM" To: Date: Fri, 6 Oct 2006 11:54:19 +0530 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcbpEA4f2Qet1TQ1T5mjs77MJHdskA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Subject: [Simple] Simple question about user provisioning X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1201909198==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1201909198== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C6E93E.2B585050" This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C6E93E.2B585050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear simple experts, I am Hemkumar doing analysis about presence server, rls and glms. Very happy to subscribe with SIMPLE group to share queries with all you. This is my simple query but I am struggling. Client sends subscribe to RLS with the request uri (i.e. list name e.g. User1_list@home1.com) not rls uri. IFC execution finds out the subscribe is to RLS using uri present in the subscribe (user1_list@home1.com) and the supported header. Then forward to rls. Then in the rls corresponding resource list is assigned to the user and buddies are derived then processed. Question: I think request uri which represents listname(not rls uri) is a separate uri defined for presence service. Who will define this uri? How client knows this uri? Is this unique one? Is user can select his own uri name? Who will configure this uri in the fcl logic? Who will configure this uri , resource list mapping? Is any document says about this? Please tell me if you found answer for any one . Question may be silly. But my theoretical knowledge is not enough to find out answers for the above Please help me guys. Thanking You Hemkumar ------=_NextPart_000_0028_01C6E93E.2B585050 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear simple experts,

I am Hemkumar doing analysis about presence server, = rls and glms.

Very happy to subscribe with SIMPLE group to share = queries with all you.

This is my simple query but I am = struggling.

Client sends subscribe to RLS with the request uri = (i.e. list name e.g. User1_list@home1.com) not rls uri. IFC execution finds out the subscribe is to RLS using uri = present in the subscribe (user1_list@home1.com) and the supported header. Then forward to rls. Then in the rls corresponding resource list is assigned to the user and buddies are derived then = processed.

Question: I think request uri which represents = listname(not rls uri) is a separate uri defined for presence = service.

Who will define this = uri?

How client knows this = uri?

Is this unique one?

Is user can select his own uri = name?

Who will configure this uri in the fcl = logic?

Who will configure this uri , resource list = mapping?

Is any document says about this? Please tell me if = you found answer for any one .

Question may be silly. But my theoretical knowledge = is not enough to find out answers for the above

Please help me guys.

Thanking You

Hemkumar

------=_NextPart_000_0028_01C6E93E.2B585050-- --===============1201909198== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1201909198==-- From simple-bounces@ietf.org Fri Oct 06 07:14:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVndQ-0000vn-9g; Fri, 06 Oct 2006 07:12:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVndP-0000vi-3j for simple@ietf.org; Fri, 06 Oct 2006 07:12:55 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVndN-0005rv-JJ for simple@ietf.org; Fri, 06 Oct 2006 07:12:55 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k96BCpwe015461; Fri, 6 Oct 2006 14:12:51 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 14:12:51 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 6 Oct 2006 14:12:50 +0300 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int01.ntc.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k96BComF014981; Fri, 6 Oct 2006 14:12:50 +0300 Received: from [172.21.38.148] (esdhcp038148.research.nokia.com [172.21.38.148]) by kusti.research.nokia.com (Postfix) with ESMTP id 2BA9F93B78; Fri, 6 Oct 2006 14:12:50 +0300 (EEST) Message-ID: <45263A31.9070409@nokia.com> Date: Fri, 06 Oct 2006 14:12:49 +0300 From: Jari Urpalainen User-Agent: Thunderbird 1.5.0.7 (X11/20060913) MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Simple] Clarification on usage of xcap-diff References: <4522288F.3090704@nokia.com> <45223C1A.1000000@nokia.com> <45231BF4.7010308@cisco.com> <45237714.6030306@nokia.com> <45241273.3030801@cisco.com> <4524B6D2.8050205@nokia.com> <4525715A.3040304@cisco.com> In-Reply-To: <4525715A.3040304@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2006 11:12:50.0561 (UTC) FILETIME=[5C7A7F10:01C6E938] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org ext Jonathan Rosenberg wrote: >> On the issue itself, I think there is a simpler solution than what is >> in the document. The idea is this. When you get a NOTIFY with an >> etag, you do a non-conditional GET. This will either produce a >> version with the same etag as you had in the NOTIFY, or not. If not, >> it has to be because the document has changed since the previous >> NOTIFY, and so another NOTIFY is coming. When that NOTIFY comes, you >> check its new-etag. If it matches the document, great. If not, >> discard and wait for the next NOTIFY. You'll eventually get a NOTIFY >> whose new etag matches the document received via HTTP. At this point >> you are synchronized. >>> >>> This will work as long as the server is sending NOTIFYs for each >>> document change. > >> right, this is the simplest approach which is probably good enough >> for XCAP resources. The disturbing fact is that servers could never >> do efficient aggregation of individual patches. > > I wouldn't say never; the server can do it once it knows that the > client has the specific version whose etag is in the NOTIFY. The > ultimate fix for this is something I think Aki proposed in sipping way > back (which we need to revisit), which was that a SUBSCRIBE could > contain the etag of the resource being subscibed to that the client > already has. > ok, I was unclear what I meant, so the server doesn't know the time to start aggregating, so it may have an "educated guess" so theoretically it could be almost infinite waiting... Imo there's a difference here than with Aki's i-d (in sip), which tries to suppress notifies or bodies (although it is definitely a very good thing and yes should be combined here). What I am looking for is a directive from the client (who definitely knows when it is ready) to the server that aggregation is preferred. Also, it might be reasonable to allow sending only document updates, i.e. no patch info at all for the clients who don't need transmission optimization (or don't support patching). So they want to sync on document basis and want to have a deterministic knowledge of document removals. Usually this sort of thing is easily solved by mime-types and Accept-header which doesn't fit here. So this is imo semantically different than "Suppress-Notify-If-Match" but it is ok for me if this is combined with this "sync" issue (and of course documented). So whatever works and is fairly easily implementable is fine with me. > > Instead, you should provide >> several elements for the same resource, which isn't that >> nice. > > Sorry - I don't follow this... > I just meant when you aggregate patches for a document you just give all individual changes within separate elements (which all refer to the same http resource), so you can then aggregate and give also all ETag changes. So during sync this is ok, but not afterwards. > >> Btw. maxOccurs="unbounded" cardinality is missing from >> schema definition. > > Yes, I know. This had been pointed out to me privately by others. > > >> How about adding some semantics to re-SUBSCRIBE to tell the server >> "aggregation allowed" meaning sync achieved on the client side ? > > I think the etag-in-SUBSCRIBE approach would provide a clean way to do > that. > > -Jonathan R. > Maybe so, although binding this single subscription ETag to multiple ETags of http documents isn't imo that "clean" or clear. But whatever, the discussion can continue only on xcap-config, if there's an even simpler and/or better way... br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Oct 06 08:05:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVoRk-00054y-VU; Fri, 06 Oct 2006 08:04:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVoRf-000505-Le for simple@ietf.org; Fri, 06 Oct 2006 08:04:52 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVoE7-0006pL-4c for simple@ietf.org; Fri, 06 Oct 2006 07:50:52 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 359D81944CC for