From simple-bounces@ietf.org Mon May 01 17:57:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagO7-0003AP-FX; Mon, 01 May 2006 17:57:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagO5-00032X-NH for simple@ietf.org; Mon, 01 May 2006 17:57:01 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FagO3-0007Ox-0q for simple@ietf.org; Mon, 01 May 2006 17:57:01 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 01 May 2006 17:56:59 -0400 X-IronPort-AV: i="4.05,77,1146456000"; d="scan'208"; a="87646541:sNHT32550788" 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 k41LuwTL024387; Mon, 1 May 2006 17:56:58 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 May 2006 17:56:58 -0400 Received: from [161.44.55.76] ([161.44.55.76]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 May 2006 17:56:58 -0400 Message-ID: <445664D1.6060906@cisco.com> Date: Mon, 01 May 2006 15:43:13 -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: Josh Littlefield Subject: Re: Reminder: [Simple] WGLC : draft-ietf-simple-xcap-09.txt References: <4436A828.7020206@cisco.com> <005901c65a8a$78b4f670$31713b51@BEMBUSTER> <4436E653.9050900@cisco.com> In-Reply-To: <4436E653.9050900@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2006 21:56:58.0211 (UTC) FILETIME=[2B016330:01C66D6A] X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 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 think its unlikely that someone would really want to extract the auid from the reverse domain name. Primarily the whole thing is just used for equality. However, I think its a good idea for the grammar, in any case, to be unambiguous, so that it can be parsed into its component forms. Since we are specifying that the AUID can have either form, and we are specifying a grammar for it, it should be unambigous. Thanks, Jonathan R. Josh Littlefield wrote: > Jeroen van Bemmel wrote: > >> Josh, >> >> The concern was about dots in global AUIDs. When dots are allowed, >> there is no syntactical distinction between "global" AUIDs and >> "vendor-specific" AUIDs, since e.g. "com.example.foo" would also be a >> valid global AUID > > > OK, sorry. I was thinking of the part of a vendor AUID to the right of > the reverse domain name, not of the global AUID. > >> >> If the distinction is not important, then the ABNF should be changed >> into: >> AUID = 1*pchar >> >> If on the other hand you want to be able to extract the reverse domain >> part from a vendor-specific AUID, then the syntax should also be >> changed to be able to detect where the reverse domain part ends and >> the AUID begins > > > I didn't see the need to extract the reverse domain part from a > vendor-specific AUID, since it sFrom simple-bounces@ietf.org Mon May 01 17:57:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagO7-0003AP-FX; Mon, 01 May 2006 17:57:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagO5-00032X-NH for simple@ietf.org; Mon, 01 May 2006 17:57:01 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FagO3-0007Ox-0q for simple@ietf.org; Mon, 01 May 2006 17:57:01 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 01 May 2006 17:56:59 -0400 X-IronPort-AV: i="4.05,77,1146456000"; d="scan'208"; a="87646541:sNHT32550788" 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 k41LuwTL024387; Mon, 1 May 2006 17:56:58 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 May 2006 17:56:58 -0400 Received: from [161.44.55.76] ([161.44.55.76]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 May 2006 17:56:58 -0400 Message-ID: <445664D1.6060906@cisco.com> Date: Mon, 01 May 2006 15:43:13 -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: Josh Littlefield Subject: Re: Reminder: [Simple] WGLC : draft-ietf-simple-xcap-09.txt References: <4436A828.7020206@cisco.com> <005901c65a8a$78b4f670$31713b51@BEMBUSTER> <4436E653.9050900@cisco.com> In-Reply-To: <4436E653.9050900@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2006 21:56:58.0211 (UTC) FILETIME=[2B016330:01C66D6A] X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 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 think its unlikely that someone would really want to extract the auid from the reverse domain name. Primarily the whole thing is just used for equality. However, I think its a good idea for the grammar, in any case, to be unambiguous, so that it can be parsed into its component forms. Since we are specifying that the AUID can have either form, and we are specifying a grammar for it, it should be unambigous. Thanks, Jonathan R. Josh Littlefield wrote: > Jeroen van Bemmel wrote: > >> Josh, >> >> The concern was about dots in global AUIDs. When dots are allowed, >> there is no syntactical distinction between "global" AUIDs and >> "vendor-specific" AUIDs, since e.g. "com.example.foo" would also be a >> valid global AUID > > > OK, sorry. I was thinking of the part of a vendor AUID to the right of > the reverse domain name, not of the global AUID. > >> >> If the distinction is not important, then the ABNF should be changed >> into: >> AUID = 1*pchar >> >> If on the other hand you want to be able to extract the reverse domain >> part from a vendor-specific AUID, then the syntax should also be >> changed to be able to detect where the reverse domain part ends and >> the AUID begins > > > I didn't see the need to extract the reverse domain part from a > vendor-specific AUID, since it seemed to me the point was AUID > uniqueness, not AUID parsing. > > Still, if you think it possible that someone will assign a global AUID > that would potentially conflict with some vendor's local AUID space, > then having dots in global AUIDs is a potential problem. > > Regards, > -josh > >> Regards, >> >> jeroen >> >> ----- Original Message ----- From: "Josh Littlefield" >> To: "Robert Sparks" >> Cc: >> Sent: Friday, April 07, 2006 7:58 PM >> Subject: Re: Reminder: [Simple] WGLC : draft-ietf-simple-xcap-09.txt >> >> >>> I have read the draft and think it's fine, with the following note: >>> I agree with the previously noted concerns except for the concern >>> about dots in the custom AUID names, which I really don't see as a >>> problem. >>> >>> -josh >>> >>> Robert Sparks wrote: >>> >>>> If you haven't sent comments, please do so now. >>>> >>>> RjS >>>> >>>> On Mar 27, 2006, at 1:32 PM, Robert Sparks wrote: >>>> >>>>> This is a SIMPLE working group Last Call for Comments on >>>>> draft-ietf-simple-xcap-09. >>>>> >>>>> This last call ends in two weeks - April 10, 2006 >>>>> >>>>> The previous version of this draft was approved for publication, >>>>> but was removed >>>>> from the RFC editor's queue to address a technical issue with >>>>> conditional inserts. >>>>> The group also agreed to incorporate several clarifying text >>>>> changes while the document >>>>> was open. >>>>> >>>>> Please review the changes carefully and send feedback to the SIMPLE >>>>> list, copying >>>>> Jonathan. >>>>> >>>>> RjS >>>>> >>>>> On Mar 23, 2006, at 5:50 PM, Internet-Drafts@ietf.org wrote: >>>>> >>>>>> 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 : The Extensible Markup Language (XML) >>>>>> Configuration Access Protocol (XCAP) >>>>>> Author(s) : J. Rosenberg >>>>>> Filename : draft-ietf-simple-xcap-09.txt >>>>>> Pages : 68 >>>>>> Date : 2006-3-23 >>>>>> This specification defines the Extensible Markup Language (XML) >>>>>> Configuration Access Protocol (XCAP). XCAP allows a client to read, >>>>>> write and modify application configuration data, stored in XML format >>>>>> on a server. XCAP maps XML document sub-trees and element attributes >>>>>> to HTTP URIs, so that these components can be directly accessed by >>>>>> HTTP. >>>>>> >>>>>> A URL for this Internet-Draft is: >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-09.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-09.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-09.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, especialeemed to me the point was AUID > uniqueness, not AUID parsing. > > Still, if you think it possible that someone will assign a global AUID > that would potentially conflict with some vendor's local AUID space, > then having dots in global AUIDs is a potential problem. > > Regards, > -josh > >> Regards, >> >> jeroen >> >> ----- Original Message ----- From: "Josh Littlefield" >> To: "Robert Sparks" >> Cc: >> Sent: Friday, April 07, 2006 7:58 PM >> Subject: Re: Reminder: [Simple] WGLC : draft-ietf-simple-xcap-09.txt >> >> >>> I have read the draft and think it's fine, with the following note: >>> I agree with the previously noted concerns except for the concern >>> about dots in the custom AUID names, which I really don't see as a >>> problem. >>> >>> -josh >>> >>> Robert Sparks wrote: >>> >>>> If you haven't sent comments, please do so now. >>>> >>>> RjS >>>> >>>> On Mar 27, 2006, at 1:32 PM, Robert Sparks wrote: >>>> >>>>> This is a SIMPLE working group Last Call for Comments on >>>>> draft-ietf-simple-xcap-09. >>>>> >>>>> This last call ends in two weeks - April 10, 2006 >>>>> >>>>> The previous version of this draft was approved for publication, >>>>> but was removed >>>>> from the RFC editor's queue to address a technical issue with >>>>> conditional inserts. >>>>> The group also agreed to incorporate several clarifying text >>>>> changes while the document >>>>> was open. >>>>> >>>>> Please review the changes carefully and send feedback to the SIMPLE >>>>> list, copying >>>>> Jonathan. >>>>> >>>>> RjS >>>>> >>>>> On Mar 23, 2006, at 5:50 PM, Internet-Drafts@ietf.org wrote: >>>>> >>>>>> 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 : The Extensible Markup Language (XML) >>>>>> Configuration Access Protocol (XCAP) >>>>>> Author(s) : J. Rosenberg >>>>>> Filename : draft-ietf-simple-xcap-09.txt >>>>>> Pages : 68 >>>>>> Date : 2006-3-23 >>>>>> This specification defines the Extensible Markup Language (XML) >>>>>> Configuration Access Protocol (XCAP). XCAP allows a client to read, >>>>>> write and modify application configuration data, stored in XML format >>>>>> on a server. XCAP maps XML document sub-trees and element attributes >>>>>> to HTTP URIs, so that these components can be directly accessed by >>>>>> HTTP. >>>>>> >>>>>> A URL for this Internet-Draft is: >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-09.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-09.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-09.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. >>>>>> Content-Type: text/plain >>>>>> Content-ID: <2006-3-23150339.I-D@ietf.org> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>> -- >>> ===================================================================== >>> Josh Littlefield Cisco Systems, Inc. >>> joshl@cisco.com 1414 Massachusetts Avenue >>> tel: 978-936-1379 fax: 978-936-2226 Boxborough, MA 01719-2205 >>> >>> _______________________________________________ >>> 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 Mon May 01 17:57:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagO3-0002xx-01; Mon, 01 May 2006 17:56:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagO2-0002us-4B for simple@ietf.org; Mon, 01 May 2006 17:56:58 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FagO0-0007Oq-Qk for simple@ietf.org; Mon, 01 May 2006 17:56:58 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 01 May 2006 14:56:56 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,77,1146466800"; d="scan'208"; a="27106783:sNHT23842936" 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 k41LurTT024347; Mon, 1 May 2006 17:56:56 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 May 2006 17:56:55 -0400 Received: from [161.44.55.76] ([161.44.55.76]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 May 2006 17:56:55 -0400 Message-ID: <445660E0.6010705@cisco.com> Date: Mon, 01 May 2006 15:26:24 -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: "Drage, Keith (Keith)" Subject: Re: [Simple] Merging PIDF documents from multiple sources References: <475FF955A05DD411980D00508B6D5FB00C29086D@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C29086D@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2006 21:56:55.0117 (UTC) FILETIME=[292947D0:01C66D6A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 Right. It was agreed also to revive this draft as a new SIMPLE item; I'll be updating and resubmitting before the next meeting. To answer your specific questions, see inline: Drage, Keith (Keith) wrote: > I believe this was intended to be covered by: > > draft-rosenberg-simple-presence-processing-model-01.txt > > which expired in February and is therefore no longer on the i-d area. > > It can however be found here: > > http://www.softarmor.com/wgdb/docs/draft-rosenberg-simple-presence-processing-model-01.txt > > regards > > Keith > > -----Original Message----- > *From:* Noga Tor [mailto:noga.tor@gmail.com] > *Sent:* 27 April 2006 12:52 > *To:* simple@ietf.org > *Subject:* [Simple] Merging PIDF documents from multiple sources > > Hi > > Im trying to understand what should be the strategy when merging > doucments that were published from different sources. > > Should all published person\tuple\device elements be sent to the > Watcher as received? You are free to do whatever you like. You can merge them, or you can send each piece of information without modifying it at all. The presence data model allows for multiple tuple, person or device elements to refer to the same thing, in which case they are differentiated with the instance ID. The primary application of that is presence servers which do not perform composition. > > Or should a merge strategy be implemented? Generally I think thats a better idea, but its an implementation choice. > > How should the Notify message look like? (assuming the watcher did > not add any filters to the subscription) Depends on your composition policy. > > Should it contain all the published elements? (multiple > person/device elements) Again see above. If you do decide not to merge, you MUST ensure that all tuples, person and devices referring to the same thing have different instance ID. > > Or should it contain merged publish elements? (one person/device > element) > > Or should it contain just the last published elements? (one > person/device element) Again, local choice. The data model draft talks about the fact that, when multiple elements are preent which refer to the same thing, a common and reasonable strategy at the watcher is to take the most recently published one (based on timestamp). Thanks, 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 ly 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. >>>>>> Content-Type: text/plain >>>>>> Content-ID: <2006-3-23150339.I-D@ietf.org> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>> -- >>> ===================================================================== >>> Josh Littlefield Cisco Systems, Inc. >>> joshl@cisco.com 1414 Massachusetts Avenue >>> tel: 978-936-1379 fax: 978-936-2226 Boxborough, MA 01719-2205 >>> >>> _______________________________________________ >>> 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 Mon May 01 17:57:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagO3-0002xx-01; Mon, 01 May 2006 17:56:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagO2-0002us-4B for simple@ietf.org; Mon, 01 May 2006 17:56:58 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FagO0-0007Oq-Qk for simple@ietf.org; Mon, 01 May 2006 17:56:58 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 01 May 2006 14:56:56 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,77,1146466800"; d="scan'208"; a="27106783:sNHT23842936" 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 k41LurTT024347; Mon, 1 May 2006 17:56:56 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 May 2006 17:56:55 -0400 Received: from [161.44.55.76] ([161.44.55.76]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 May 2006 17:56:55 -0400 Message-ID: <445660E0.6010705@cisco.com> Date: Mon, 01 May 2006 15:26:24 -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: "Drage, Keith (Keith)" Subject: Re: [Simple] Merging PIDF documents from multiple sources References: <475FF955A05DD411980D00508B6D5FB00C29086D@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C29086D@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2006 21:56:55.0117 (UTC) FILETIME=[292947D0:01C66D6A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 Right. It was agreed also to revive this draft as a new SIMPLE item; I'll be updating and resubmitting before the next meeting. To answer your specific questions, see inline: Drage, Keith (Keith) wrote: > I believe this was intended to be covered by: > > draft-rosenberg-simple-presence-processing-model-01.txt > > which expired in February and is therefore no longer on the i-d area. > > It can however be found here: > > http://www.softarmor.com/wgdb/docs/draft-rosenberg-simple-presence-processing-model-01.txt > > regards > > Keith > > -----Original Message----- > *From:* Noga Tor [mailto:noga.tor@gmail.com] > *Sent:* 27 April 2006 12:52 > *To:* simple@ietf.org > *Subject:* [Simple] Merging PIDF documents from multiple sources > > Hi > > Im trying to understand what should be the strategy when merging > doucments that were published from different sources. > > Should all published person\tuple\device elements be sent to the > Watcher as received? You are free to do whatever you like. You can merge them, or you can send each piece of information without modifying it at all. The presence data model allows for multiple tuple, person or device elements to refer to the same thing, in which case they are differentiated with the instance ID. The primary application of that is presence servers which do not perform composition. > > Or should a merge strategy be implemented? Generally I think thats a better idea, but its an implementation choice. > > How should the Notify message look like? (assuming the watcher did > not add any filters to the subscription) Depends on your composition policy. > > Should it contain all the published elements? (multiple > person/device elements) Again see above. If you do decide not to merge, you MUST ensure that all tuples, person and devices referring to the same thing have different instance ID. > > Or should it contain merged publish elements? (one person/device > element) > > Or should it contain just the last published elements? (one > person/device element) Again, local choice. The data model draft talks about the fact that, when multiple elements are preent which refer to the same thing, a common and reasonable strategy at the watcher is to take the most recently published one (based on timestamp). Thanks, 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 Mon May 01 17:57:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagO6-00037g-Qf; Mon, 01 May 2006 17:57:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagO5-00032I-Jf for simple@ietf.org; Mon, 01 May 2006 17:57:01 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FagO4-0007Oq-AR for simple@ietf.org; Mon, 01 May 2006 17:57:01 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 01 May 2006 14:57:00 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,77,1146466800"; d="scan'208"; a="27106796:sNHT22272068" 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 k41LuxvF024894; Mon, 1 May 2006 17:57:00 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 May 2006 17:56:59 -0400 Received: from [161.44.55.76] ([161.44.55.76]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 May 2006 17:56:59 -0400 Message-ID: <44566733.5000606@cisco.com> Date: Mon, 01 May 2006 15:53:23 -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: "Anders Lindgren C (HF/EAB)" Subject: Re: [Simple] WGLC : draft-ietf-simple-xcap-09.txt References: <2DC267ED40568D4F9AA4F5DF955AF16A024660FC@esealmw107.eemea.ericsson.se> In-Reply-To: <2DC267ED40568D4F9AA4F5DF955AF16A024660FC@esealmw107.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2006 21:56:59.0634 (UTC) FILETIME=[2BDA8520:01C66D6A] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Anders Lindgren C (HF/EAB) wrote: > Hi all, > I have some minor editorial comments to the draft > 1)In chapter 6.1 the example of an XCAP root URI is > "http://xcap.example.com. > In chapter 6.2 the example has as xcap root > "http://xcap.example.com/services and a statement that the example from > chapter 6.1 continues. > In chapter 7 the example is back to use a XCAP root URI that looks like > "http://xcap.example.com. > In chapter 13 the examples are using http://xcap.example.com/services as > example of the XCAP root URI > My propsal is to use the same XCAP root URI example > (http://xcap.example.com) everywhere. Agreed. Fixed everywhere. I also changed the buddy list document from fr.xml to index, again following the recommendations in the document. Thanks, 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 Mon May 01 17:57:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagO6-00035n-DK; Mon, 01 May 2006 17:57:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagO4-0002yM-LK for simple@ietf.org; Mon, 01 May 2006 17:57:00 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FagO0-0007Op-Af for simple@ietf.org; Mon, 01 May 2006 17:57:00 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 01 May 2006 17:56:56 -0400 X-IronPort-AV: i="4.05,77,1146456000"; d="scan'208"; a="87646527:sNHT31265172" 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 k41LurTR024347; Mon, 1 May 2006 17:56:56 -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.211); Mon, 1 May 2006 17:56:54 -0400 Received: from [161.44.55.76] ([161.44.55.76]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 May 2006 17:56:53 -0400 Message-ID: <44565FA4.8010303@cisco.com> Date: Mon, 01 May 2006 15:21:08 -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: Silvestr.Peknik@tietoenator.com Subject: Re: [Simple] publishing presence state - sip and pres uris References: <3ACC9A25264A684F82C71840111F979801740E6F@carrera.eu.tieto.com> In-Reply-To: <3ACC9A25264A684F82C71840111F979801740E6F@carrera.eu.tieto.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2006 21:56:54.0149 (UTC) FILETIME=[28959350:01C66D6A] 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 This can happen, yes. The presence data model draft (out shortly as an RFC) does say you shouldn't do this - that the URI in the SUBSCRIBE or PUBLISH should match that in the document. That said, the presence server should know that the pres and sip URI are equivalent, and thus even though the R-uri identifies the SIP URI, the document should be applied to the presentity URI sip:alan@example.com as well. Consequently, a SUBSCRIBE request for sip:alan@example.com would return a presence document whose entity attribute is sip:alan@example.com. Thanks, Jonathan R. Silvestr.Peknik@tietoenator.com wrote: > Hello, > > I am not sure how presence server should handle PUBLISH requests, if they have sip uri in To: header and pres uri in entity attribute in the presence document: > > PUBLISH ... > To: sip:alan@example.com > ... > > > ... > > > It seems that client should not create such requests (why use pres uri, if it knows sip uri?) but I think that it can happen thanks to RFC3863 (pidf) which mentions only pres uri to be inserted to the entity parameter. > Could someone explain what is the correct behavior here? Is it possible to have different uri's in To header and in the entity attribute? > > Thank you, > > Silvestr Peknik > Software Specialist > > TietoEnator > Czech Software Center > Phone +420 599 096 027 > Fax +420 599 096 110 > E-mail silvestr.peknik@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 > -- 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 Mon May 01 17:57:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagO6-00037g-Qf; Mon, 01 May 2006 17:57:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagO5-00032I-Jf for simple@ietf.org; Mon, 01 May 2006 17:57:01 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FagO4-0007Oq-AR for simple@ietf.org; Mon, 01 May 2006 17:57:01 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 01 May 2006 14:57:00 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,77,1146466800"; d="scan'208"; a="27106796:sNHT22272068" 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 k41LuxvF024894; Mon, 1 May 2006 17:57:00 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 May 2006 17:56:59 -0400 Received: from [161.44.55.76] ([161.44.55.76]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 May 2006 17:56:59 -0400 Message-ID: <44566733.5000606@cisco.com> Date: Mon, 01 May 2006 15:53:23 -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: "Anders Lindgren C (HF/EAB)" Subject: Re: [Simple] WGLC : draft-ietf-simple-xcap-09.txt References: <2DC267ED40568D4F9AA4F5DF955AF16A024660FC@esealmw107.eemea.ericsson.se> In-Reply-To: <2DC267ED40568D4F9AA4F5DF955AF16A024660FC@esealmw107.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2006 21:56:59.0634 (UTC) FILETIME=[2BDA8520:01C66D6A] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Anders Lindgren C (HF/EAB) wrote: > Hi all, > I have some minor editorial comments to the draft > 1)In chapter 6.1 the example of an XCAP root URI is > "http://xcap.example.com. > In chapter 6.2 the example has as xcap root > "http://xcap.example.com/services and a statement that the example from > chapter 6.1 continues. > In chapter 7 the example is back to use a XCAP root URI that looks like > "http://xcap.example.com. > In chapter 13 the examples are using http://xcap.example.com/services as > example of the XCAP root URI > My propsal is to use the same XCAP root URI example > (http://xcap.example.com) everywhere. Agreed. Fixed everywhere. I also changed the buddy list document from fr.xml to index, again following the recommendations in the document. Thanks, 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 Mon May 01 17:57:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagO6-00035n-DK; Mon, 01 May 2006 17:57:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagO4-0002yM-LK for simple@ietf.org; Mon, 01 May 2006 17:57:00 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FagO0-0007Op-Af for simple@ietf.org; Mon, 01 May 2006 17:57:00 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 01 May 2006 17:56:56 -0400 X-IronPort-AV: i="4.05,77,1146456000"; d="scan'208"; a="87646527:sNHT31265172" 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 k41LurTR024347; Mon, 1 May 2006 17:56:56 -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.211); Mon, 1 May 2006 17:56:54 -0400 Received: from [161.44.55.76] ([161.44.55.76]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 May 2006 17:56:53 -0400 Message-ID: <44565FA4.8010303@cisco.com> Date: Mon, 01 May 2006 15:21:08 -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: Silvestr.Peknik@tietoenator.com Subject: Re: [Simple] publishing presence state - sip and pres uris References: <3ACC9A25264A684F82C71840111F979801740E6F@carrera.eu.tieto.com> In-Reply-To: <3ACC9A25264A684F82C71840111F979801740E6F@carrera.eu.tieto.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2006 21:56:54.0149 (UTC) FILETIME=[28959350:01C66D6A] 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 This can happen, yes. The presence data model draft (out shortly as an RFC) does say you shouldn't do this - that the URI in the SUBSCRIBE or PUBLISH should match that in the document. That said, the presence server should know that the pres and sip URI are equivalent, and thus even though the R-uri identifies the SIP URI, the document should be applied to the presentity URI sip:alan@example.com as well. Consequently, a SUBSCRIBE request for sip:alan@example.com would return a presence document whose entity attribute is sip:alan@example.com. Thanks, Jonathan R. Silvestr.Peknik@tietoenator.com wrote: > Hello, > > I am not sure how presence server should handle PUBLISH requests, if they have sip uri in To: header and pres uri in entity attribute in the presence document: > > PUBLISH ... > To: sip:alan@example.com > ... > > > ... > > > It seems that client should not create such requests (why use pres uri, if it knows sip uri?) but I think that it can happen thanks to RFC3863 (pidf) which mentions only pres uri to be inserted to the entity parameter. > Could someone explain what is the correct behavior here? Is it possible to have different uri's in To header and in the entity attribute? > > Thank you, > > Silvestr Peknik > Software Specialist > > TietoEnator > Czech Software Center > Phone +420 599 096 027 > Fax +420 599 096 110 > E-mail silvestr.peknik@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 > -- 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 May 02 05:25:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Far8C-0001fP-40; Tue, 02 May 2006 05:25:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Far8A-0001fK-7F for simple@ietf.org; Tue, 02 May 2006 05:25:18 -0400 Received: from nproxy.gmail.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Far86-0000jH-MB for simple@ietf.org; Tue, 02 May 2006 05:25:18 -0400 Received: by nproxy.gmail.com with SMTP id l36so1961245nfa for ; Tue, 02 May 2006 02:25:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=nLWUTJkS7UoFTIJD3vewBHEUsrJFjjf6wqym9y3m2SI/JW9CS3BHMvU2SR6Mar4VHHjKPPQ5pN4gRCJYiDCiLFo4h0PabqQVoP2z3qBhUk70obWYAdsm0PVMnFUO/uOoP/vK6RjTgNX7b0oFY7w9x83qRjV1SKcE/eju36Yripg= Received: by 10.48.218.19 with SMTP id q19mr334715nfg; Tue, 02 May 2006 02:25:13 -0700 (PDT) Received: by 10.48.225.18 with HTTP; Tue, 2 May 2006 02:25:13 -0700 (PDT) Message-ID: <44781c350605020225te497307k2a9a0cb1b958e42a@mail.gmail.com> Date: Tue, 2 May 2006 12:25:13 +0300 From: "Noga Tor" To: simple@ietf.org Subject: Re: [Simple] Merging PIDF documents from multiple sources In-Reply-To: <445660E0.6010705@cisco.com> MIME-Version: 1.0 References: <475FF955A05DD411980D00508B6D5FB00C29086D@en0033exch001u.uk.lucent.com> <445660E0.6010705@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 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="===============2050923278==" Errors-To: simple-bounces@ietf.org --===============2050923278== Content-Type: multipart/alternative; boundary="----=_Part_7385_1329276.1146561913704" ------=_Part_7385_1329276.1146561913704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Thanks for the answers. Although the draft document does not contain the answers to my question (what should be the server's default policy) since in the specific chapter that interested me it said: "TODO: place default policy here" I did undertand though from Jonathan's reply that there is no answer and that it is open to various types of implementation. On 5/1/06, Jonathan Rosenberg wrote: > > Right. It was agreed also to revive this draft as a new SIMPLE item; > I'll be updating and resubmitting before the next meeting. > > To answer your specific questions, see inline: > > > Drage, Keith (Keith) wrote: > > > I believe this was intended to be covered by: > > > > draft-rosenberg-simple-presence-processing-model-01.txt > > > > which expired in February and is therefore no longer on the i-d area. > > > > It can however be found here: > > > > > http://www.softarmor.com/wgdb/docs/draft-rosenberg-simple-presence-proces= sing-model-01.txt > > > > regards > > > > Keith > > > > -----Original Message----- > > *From:* Noga Tor [mailto:noga.tor@gmail.com] > > *Sent:* 27 April 2006 12:52 > > *To:* simple@ietf.org > > *Subject:* [Simple] Merging PIDF documents from multiple sources > > > > Hi > > > > Im trying to understand what should be the strategy when merging > > doucments that were published from different sources. > > > > Should all published person\tuple\device elements be sent to the > > Watcher as received? > > You are free to do whatever you like. You can merge them, or you can > send each piece of information without modifying it at all. The presence > data model allows for multiple tuple, person or device elements to refer > to the same thing, in which case they are differentiated with the > instance ID. The primary application of that is presence servers which > do not perform composition. > > > > > Or should a merge strategy be implemented? > > Generally I think thats a better idea, but its an implementation choice. > > > > > How should the Notify message look like? (assuming the watcher did > > not add any filters to the subscription) > > Depends on your composition policy. > > > > > Should it contain all the published elements? (multiple > > person/device elements) > > Again see above. If you do decide not to merge, you MUST ensure that all > tuples, person and devices referring to the same thing have different > instance ID. > > > > > Or should it contain merged publish elements? (one person/device > > element) > > > > Or should it contain just the last published elements? (one > > person/device element) > > Again, local choice. The data model draft talks about the fact that, > when multiple elements are preent which refer to the same thing, a > common and reasonable strategy at the watcher is to take the most > recently published one (based on timestamp). > > Thanks, > 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 > ------=_Part_7385_1329276.1146561913704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Thanks for the answers.
 
Although the draft document does not contain the answers to my questio= n (what should be the server's default policy) since in the specific chapte= r that interested me it said: "TODO: place default policy here"
 
I did undertand though from Jonathan's reply that there is no answer a= nd that it is open to various types of implementation.
 
 
On 5/1/06, J= onathan Rosenberg <jdrosen@cisc= o.com> wrote:
Right. It was agreed also to rev= ive this draft as a new SIMPLE item;
I'll be updating and resubmitting b= efore the next meeting.

To answer your specific questions, see inline:


Drage, Ke= ith (Keith) wrote:

> I believe this was intended to be covered by= :
>
> draft-rosenberg-simple-presence-processing-model-01.txt
>
> which expired in February and is therefore no longer on th= e i-d area.
>
> It can however be found here:
>
> <= a href=3D"http://www.softarmor.com/wgdb/docs/draft-rosenberg-simple-presenc= e-processing-model-01.txt"> http://www.softarmor.com/wgdb/docs/draft-rosenberg-simple-presence-processi= ng-model-01.txt
>
> regards
>
> Keith
>>     -----Original Message-----
> &nbs= p;   *From:* Noga Tor [mailto: noga.tor@gmail.com]
> =     *Sent:* 27 April 2006 12:52
>   &nb= sp; *To:* simple@ietf.org
>&nb= sp;    *Subject:* [Simple] Merging PIDF documents from multi= ple sources
>
>     Hi
>
>  &nbs= p;  Im trying to understand what should be the strategy when merging>     doucments that were published from different= sources.
>
>     Should all published pers= on\tuple\device elements be sent to the
>     Watcher as received?

You are free t= o do whatever you like. You can merge them, or you can
send each piece o= f information without modifying it at all. The presence
data model allow= s for multiple tuple, person or device elements to refer
to the same thing, in which case they are differentiated with the
in= stance ID. The primary application of that is presence servers which
do = not perform composition.

>
>     Or sho= uld a merge strategy be implemented?

Generally I think thats a better idea, but its an implementation ch= oice.

>
>     How should the Notify mes= sage look like? (assuming the watcher did
>     n= ot add any filters to the subscription)

Depends on your composition policy.

>
>  =    Should it contain all the published elements? (multiple
>= ;     person/device elements)

Again see above. I= f you do decide not to merge, you MUST ensure that all
tuples, person and devices referring to the same thing have differentinstance ID.

>
>     Or should it con= tain merged publish elements? (one person/device
>   &= nbsp; element)
>
>     Or should it contain= just the last published elements? (one
>     person/device element)

Again, local= choice. The data model draft talks about the fact that,
when multiple e= lements are preent which refer to the same thing, a
common and reasonabl= e strategy at the watcher is to take the most
recently published one (based on timestamp).

Thanks,
Jonathan= R.


--
Jonathan D. Rosenberg, Ph.D.    &n= bsp;            = ;  600 Lanidex Plaza
Cisco Fellow     &nbs= p;            &= nbsp;           &nbs= p;    Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com=             = ;            &n= bsp;     FAX:   (973) 952-5050
http://www.jdrosen.net   &n= bsp;            = ;         PHONE: (973) 952-5000
http://www.cisco.com

------=_Part_7385_1329276.1146561913704-- --===============2050923278== 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 --===============2050923278==-- From simple-bounces@ietf.org Tue May 02 05:26:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Far9f-0002A6-57; Tue, 02 May 2006 05:26:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Far9c-0002A1-UF for simple@ietf.org; Tue, 02 May 2006 05:26:48 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Far9a-0000o0-AJ for simple@ietf.org; Tue, 02 May 2006 05:26:48 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id C1E04194473 for ; Tue, 2 May 2006 11:26:44 +0200 (CEST) Received: from [192.168.1.23] ([192.168.1.23]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 11:24:40 +0200 Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: 'simple@ietf.org' WG From: Hisham Khartabil Date: Tue, 2 May 2006 11:26:30 +0200 X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 02 May 2006 09:24:40.0520 (UTC) FILETIME=[3D421480:01C66DCA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Simple] WGLC: Presence Authorization 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: , Errors-To: simple-bounces@ietf.org The WG chairs would like to start a Working Group Last Call on the following draft: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules -05.txt This WGLC will end on April 15th. Please send your comments to this mailing list and to the authors. Thanks, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 02 05:48:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FarUb-0000rJ-BA; Tue, 02 May 2006 05:48:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FarUZ-0000rE-Py for simple@ietf.org; Tue, 02 May 2006 05:48:27 -0400 Received: from nproxy.gmail.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FarUY-00028S-A7 for simple@ietf.org; Tue, 02 May 2006 05:48:27 -0400 Received: by nproxy.gmail.com with SMTP id l36so1964310nfa for ; Tue, 02 May 2006 02:48:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=bQnhfs3caB1W1VEuIkVR0KFNq/mOwcnxaEKDJ4QislBh5c0tOpbuZ+6QGdzvYM1a/PXIQQpCRsxCA6Ki7BeWxPvw3rjkPJP8GbwM229eucBFKewQQ4WKWxeh1+FNG1Aa2oHRS+bb7uGi1owOdTJTGxkReemFGT0px/Fv13Ws1AU= Received: by 10.49.17.13 with SMTP id u13mr357717nfi; Tue, 02 May 2006 02:48:25 -0700 (PDT) Received: by 10.48.225.18 with HTTP; Tue, 2 May 2006 02:48:25 -0700 (PDT) Message-ID: <44781c350605020248v511e8708i639f600ac6dceb3f@mail.gmail.com> Date: Tue, 2 May 2006 12:48:25 +0300 From: "Noga Tor" To: simple@ietf.org MIME-Version: 1.0 X-Spam-Score: 1.9 (+) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Subject: [Simple] URI in of PUBLISH vs. 'To:' header in SUBSCRIBE 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="===============1736910926==" Errors-To: simple-bounces@ietf.org --===============1736910926== Content-Type: multipart/alternative; boundary="----=_Part_7569_3366927.1146563305284" ------=_Part_7569_3366927.1146563305284 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi I wanted to know if the alias used in the "To:" part of the SUBSCRIBE Request Header should be used in order to filter the different tuples of th= e PUBLISH. In this case, only the tuples whose contact URI matches the URI supplied in the "To:" of the subscribe will be sent in the notification. For example: Presentity *'pres:*someone@example.com' has published a document, and watcher 'im:watcher@im.com' subscribes to the im alias of the presentity. what should the NOTIFY contain? see example: PUBLISH =3D=3D=3D=3D=3D=3D=3D PUBLISH sip:presentity@example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com;branch=3Dz9hG4bK652hsge To: From: ;tag=3D1234wxyz Call-ID: 81818181@pua.example.com CSeq: 1 PUBLISH Max-Forwards: 70 Expires: 3600 Event: presence Content-Type: application/pidf+xml Content-Length: ... open im:someone@im.com open tel:+444444444@tele.com SUBSCRIBE =3D=3D=3D=3D=3D=3D=3D=3D=3D SUBSCRIBE sip:someone@example.com SIP/2.0 Via: SIP/2.0/UDP host.example.com;branch=3Dz9hG4bKnashds7 To: From: ;tag=3D12341234 Call-ID: 12345678@host.example.com CSeq: 1 SUBSCRIBE Max-Forwards: 70 Expires: 3600 Event: presence Contact: sip:user@host.example.com Content-Length: 0 HOW SHOULD THE NOTIFY BODY LOOK LIKE? (Assuming policy allows all the presence datato be shown) OPTION 1 =3D=3D=3D=3D=3D=3D=3D=3D open im:someone@im.com open tel:+444444444@tele.com OPTION 2 =3D=3D=3D=3D=3D=3D=3D=3D open im:someone@im.com Thanks Noga ------=_Part_7569_3366927.1146563305284 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi
 
I wanted to know if the alias used in the "To:" part of the = SUBSCRIBE Request Header should be used in order to filter the different tu= ples of the PUBLISH. In this case, only the tuples whose contact URI matche= s the URI supplied in the "To:" of the subscribe will be sent in = the notification.=20
 
For example: Presentity 'pres:someone@example.com' has published a document, and watcher 'im:watcher@im.com' subscribes to the im= alias of the presentity. what should the NOTIFY contain? see example:
 
PUBLISH
=3D=3D=3D=3D=3D=3D=3D
PUBLISH sip:presentity@examp= le.com SIP/2.0
      Via: SIP/2.0/UDP pua.example.com;branch=3Dz9hG4bK652hsge      To: <sip: presentity@example.com>
      From: <= sip:presentity@example.com>= ;;tag=3D1234wxyz
      Call-ID: 81818181@pua.example.com
      CSeq: 1 PUBLISH
   = ;   Max-Forwards: 70
      Expires: 3= 600
      Event: presence
   =    Content-Type: application/pidf+xml
    =   Content-Length: ...
<presence ... entity=3D" pres:someone@example.com&= gt;
  <tuple id=3D"ert4773">
  &nbs= p;<status>
    <basic>open</basic>=
   </status>
   <contact><= font color=3D"#ff0000">im:someone@im.c= om </contact>
  </tuple>
  <tuple id=3D"fhsdf8">
   = ;<status>
    <basic>open</basic><= br>   </status>
   <contact>tel:+44444= 4444@tele.com </contact>
  </tuple>
</presenc= e>
 
SUBSCRIBE
=3D=3D=3D=3D=3D=3D=3D=3D=3D
 SUBSCRIBE sip:someone@exa= mple.com SIP/2.0
      Via: SIP/2.0/UDP host.example.com;branch=3Dz9hG4bKnashd= s7
      To: < im:someone@im.com>
      From: <im:watcher@im.com>;tag=3D12341234      Call-ID: 12345678@host.example.com
      = CSeq: 1 SUBSCRIBE
      Max-Forwards: 70
   &n= bsp;  Expires: 3600
      Event: presence<= br>      Contact: sip:user@host.example.com
      Co= ntent-Length: 0
 
 
HOW SHOULD THE NOTIFY BODY LOOK LIKE?  (Assuming policy allo= ws all the presence datato be shown)
 
OPTION 1
=3D=3D=3D=3D=3D=3D=3D=3D
<presence ... entity=3D"pres:someone@example.com>
  <tuple id=3D"ert4773">
  &nbs= p;<status>
    <basic>open</basic>=
   </status>
   <contact><= font color=3D"#ff0000">im:someone@im.c= om </contact>
  </tuple>
  <tuple id=3D"fhsdf8">
   = ;<status>
    <basic>open</basic><= br>   </status>
   <contact>tel:+44444= 4444@tele.com </contact>
  </tuple>
</presenc= e>

 
OPTION 2
=3D=3D=3D=3D=3D=3D=3D=3D
 
<presence ... entity=3D"pres:someone@example.com>=20
  <tuple id=3D"ert4773">
  &nbs= p;<status>
    <basic>open</basic>=
   </status>
   <contact><= font style=3D"BACKGROUND-COLOR: #ffffff" color=3D"#ff0000"> im:someone@im.com</contact>
  </tuple><= /div></presence>
 
Thanks
Noga
------=_Part_7569_3366927.1146563305284-- --===============1736910926== 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 --===============1736910926==-- From simple-bounces@ietf.org Tue May 02 05:57:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Farda-0007J9-AD; Tue, 02 May 2006 05:57:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FardZ-0007H9-9C for simple@ietf.org; Tue, 02 May 2006 05:57:45 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FardY-0002TX-Ow for simple@ietf.org; Tue, 02 May 2006 05:57:45 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 1820B194460 for ; Tue, 2 May 2006 11:57:44 +0200 (CEST) Received: from [192.168.1.23] ([192.168.1.23]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 11:55:39 +0200 Mime-Version: 1.0 (Apple Message framework v623) In-Reply-To: <76B881F6-AABF-4585-809F-2EE144EFD8DF@nostrum.com> References: <6A6473FC-C145-43FC-BC3C-B7B9DD251748@nostrum.com> <76B881F6-AABF-4585-809F-2EE144EFD8DF@nostrum.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: WGLC: xml-patch, partial-* (was Re: [Simple] updated last-call schedule) Date: Tue, 2 May 2006 11:57:29 +0200 To: simple@ietf.org list X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 02 May 2006 09:55:39.0868 (UTC) FILETIME=[918411C0:01C66DCE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: 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 There has been no comments on these drafts during the WGLC period. This was confirmed with the editors. I am therefore extending this WGLC until May 15th. Please send your comments. If you believe the I-Ds are ready, please say so. Thanks, Hisham On Apr 12, 2006, at 10:36 PM, Robert Sparks wrote: > As per the plan below (except for an unintended two day late start): > > This is a SIMPLE Working Group Last Call for comments on the following > drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-simple-xml-patch-ops > -02.txt > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf- > format-06.txt > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-publish > -04.txt > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify > -06.txt > > This last call will end Monday May 1st. > > Please send your comments to the list and the respective draft editors. > > This is a relatively big bite - please give this priority over other > list discussions. > > Thanks, > > RjS > > > On Mar 27, 2006, at 1:35 PM, Robert Sparks wrote: > >> Based on the feedback during last week's meeting, we're adjusting the >> last call schedule as follows: >> >> 3/27-4/10 : xcap >> 4/10-5/1 : xml-patch, partial-* (3 weeks - several drafts, overlaps >> SIPit) >> 5/1-5/15: presence-rules >> >> RjS >> >> >> _______________________________________________ >> 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 May 02 05:59:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Farf1-000839-7T; Tue, 02 May 2006 05:59:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Farf0-000834-8R for simple@ietf.org; Tue, 02 May 2006 05:59:14 -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 1Farf0-0002db-6z for simple@ietf.org; Tue, 02 May 2006 05:59:14 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Farey-00083U-Gz for simple@ietf.org; Tue, 02 May 2006 05:59:14 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id B26EB19446C for ; Tue, 2 May 2006 11:59:10 +0200 (CEST) Received: from [192.168.1.23] ([192.168.1.23]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 11:57:06 +0200 Mime-Version: 1.0 (Apple Message framework v623) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3076ead17284fbacde9fa8103b9b8201@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] WGLC: Presence Authorization Rules Date: Tue, 2 May 2006 11:58:56 +0200 To: 'simple@ietf.org' WG X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 02 May 2006 09:57:06.0536 (UTC) FILETIME=[C52C8E80:01C66DCE] X-Spam-Score: -2.6 (--) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: 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 On May 2, 2006, at 11:26 AM, Hisham Khartabil wrote: > The WG chairs would like to start a Working Group Last Call on the > following draft: > > http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules > -05.txt > > This WGLC will end on April 15th. Of course I meant May 15th. Apologies. Hisham > > Please send your comments to this mailing list and to the authors. > > Thanks, > Hisham > > > _______________________________________________ > 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 May 03 09:47:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbHhX-0002y1-2t; Wed, 03 May 2006 09:47:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbHhV-0002xw-4M for simple@ietf.org; Wed, 03 May 2006 09:47:33 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbHhU-000156-Rh for simple@ietf.org; Wed, 03 May 2006 09:47:33 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FbHhU-0003LV-3Y; Wed, 03 May 2006 09:47:32 -0400 Received: from [127.0.0.1] (col-lab-dhcp33-245-066.bbn.com [128.33.245.66]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id k43DlVw08361; Wed, 3 May 2006 09:47:31 -0400 (EDT) Message-ID: <4458B472.2060305@bbn.com> Date: Wed, 03 May 2006 09:47:30 -0400 From: Richard Barnes User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Simple] WGLC: Presence Authorization Rules References: <3076ead17284fbacde9fa8103b9b8201@telio.no> In-Reply-To: <3076ead17284fbacde9fa8103b9b8201@telio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: "'simple@ietf.org' 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 Couple of minor corrections, mostly typographical: 1. In section 3 (page 4), it says "As described in [12], this document is composed of three parts - conditions, actions, and transformations. Each action or transformation ... has the property of being a positive grant of information to the watcher." This is technically incorrect, since the conditions, actions, and transformations are contained in rules, which make up the document. Propose changing to "As described in [12], this document contains rules composed of three parts - conditions, actions, and transformations. Each rule containing either the 'allow' action or the 'confirm' action, which is also called a permission, has the property of being a positive grant of information to the watcher." 2. In section 5 (page 18), the element "" is indented too far. 3. In section 8.7 (page 22), it seemse like there is an extra space in the provided URI template: Instead of "http://[xcap root]/ pres-rules/users/foo", should be "http://[xcap root]/pres-rules/users/foo" --Richard Barnes Hisham Khartabil wrote: > > On May 2, 2006, at 11:26 AM, Hisham Khartabil wrote: > >> The WG chairs would like to start a Working Group Last Call on the >> following draft: >> >> http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules-05.txt >> >> >> This WGLC will end on April 15th. > > Of course I meant May 15th. Apologies. > > Hisham > >> >> Please send your comments to this mailing list and to the authors. >> >> Thanks, >> Hisham >> >> >> _______________________________________________ >> 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 > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 03 20:48:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbS0o-0005Mj-Hd; Wed, 03 May 2006 20:48:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbS0n-0005Lr-M3 for simple@ietf.org; Wed, 03 May 2006 20:48:09 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbS0m-00052q-EI for simple@ietf.org; Wed, 03 May 2006 20:48:09 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 May 2006 19:48:11 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 03 May 2006 19:48:10 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 May 2006 19:48:09 -0500 Message-ID: From: "Thomson, Martin" To: , "ext Jonathan Rosenberg" Date: Wed, 3 May 2006 19:47:01 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 04 May 2006 00:48:09.0639 (UTC) FILETIME=[6A146B70:01C66F14] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: Presence rules and polite-block Thread-Index: AcZvFEE34P+LFvqKSAqPDJ6BGl6+mw== X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Simple] Presence rules and polite-block 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="===============1768726801==" Errors-To: simple-bounces@ietf.org --===============1768726801== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message UmVhZGluZyB0aHJvdWdoIHRoZSBzaW1wbGUtcHJlc2VuY2UtcnVsZXMgZHJhZnQgWzFdLCBJIG5v dGUgdGhhdCB0aGUgInBvbGl0ZS1ibG9jayIgdmFsdWUgZm9yIHRoZSA8c3ViLWhhbmRsaW5nPiBl bGVtZW50IHNlZW1zIGEgbGl0dGxlIG91dCBvZiBwbGFjZS4gIEkgdW5kZXJzdGFuZCB0aGF0IHRo aXMgbWF5IGJlIGluIGxpbmUgd2l0aCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMsIGJ1dCBJIHRo aW5rIHRoYXQsIHNlbWFudGljYWxseSwgdGhlICJwb2xpdGUtYmxvY2siIGlzIGEgYmV0dGVyIGxv Z2ljYWwgZml0IGZvciB0aGUgPHRyYW5zZm9ybWF0aW9ucz4gc2VjdGlvbi4NCg0KVGhlIGRpZmZl cmVuY2UgYmV0d2VlbiB0aGUgInBvbGl0ZS1ibG9jayIgYW5kICJhbGxvdyIgdmFsdWVzIGFyZSBv bmx5IGluIHRoZSB3YXkgdGhhdCB0aGUgZmluYWwgZG9jdW1lbnQgaXMgY29uc3RydWN0ZWQuICBU aGV5IGJvdGggYWZmZWN0IHRoZSBzdGF0ZSBtYWNoaW5lIGluIHRoZSBzYW1lIHdheSAtIGluIHRo ZSBkZXNjcmlwdGlvbiB5b3UgdXNlICJwb2xpdGUtYmxvY2siIG9yICJhbGxvdyIgaW4gdGhlIHNh bWUgd2F5Lg0KDQpSZWNvbW1lbmRhdGlvbiBieSBwc2V1ZG8tZXhhbXBsZToNCg0KPHJ1bGUgaWQ9 ImVybzYyOGhpOGoxcyI+DQogIDxjb25kaXRpb25zPjwvY29uZGl0aW9ucz4NCiAgPGFjdGlvbnM+ PHByOnN1Yi1oYW5kbGluZz5ibG9ja3xjb25maXJtfGFsbG93PC9wcjpzdWItaGFuZGxpbmc+PC9h Y3Rpb25zPg0KICA8dHJhbnNmb3JtYXRpb25zPjxwcjpwb2xpdGUtYmxvY2svPjwvdHJhbnNmb3Jt YXRpb25zPg0KPC9ydWxlPg0KDQpUaGUgPHBvbGl0ZS1ibG9jaz4gZWxlbWVudCB3b3VsZCBoYXZl IHRvIG92ZXJyaWRlIGFsbCBvdGhlciB0cmFuc2Zvcm1hdGlvbnMuICBTaW5jZSB0aGUgZWZmZWN0 aXZlIGRpZmZlcmVuY2UgYmV0d2VlbiAicG9saXRlLWJsb2NrIiBhbmQgImFsbG93IiBpcyBzZWVu IGxhdGVyIGluIHRoZSBwcm9jZXNzaW5nIHN0YWdlLCB0aGlzIHdpbGwgcHJvYmFibHkgY2xlYW4g Y29kZS4NCg0KDQpBbiB1bnJlbGF0ZWQgc3VnZ2VzdGlvbjogSW4gc2VjdGlvbiA0LCBJIGhhZCB0 byByZWFkIGl0IHR3aWNlIHRvIGdldCB0aGUgaW1wbGljYXRpb24gdGhhdCBGKEQpIHdhcyBhIG5v b3AuICBQZXJoYXBzIHlvdSBjb3VsZCBjbGFyaWZ5IHRoaXMgYnkgdXNpbmcgc29tZXRoaW5nIG1v cmUgZXhwbGljaXQ6IERuID0gRihEbyksIERuID0gRihGKERvKSksIERuID0gRihEbikge3doZXJl IERuID0gbm90aWZpY2F0aW9uIGRvY3VtZW50LCBEbyA9IG9yaWdpbmFsIGRvY3VtZW50fQ0KDQpO aXQ6IFBhZ2UgMTEsIGZpcnN0IGxpbmU6IHMvZm91ci90aHJlZS8NCg0KUmVnYXJkcywNCk1hcnRp biANCg0KWzFdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2ltcGxlLXBy ZXNlbmNlLXJ1bGVzLTA1LnR4dA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkg YW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHBy aXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdp bmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0= --===============1768726801== 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 --===============1768726801==-- From simple-bounces@ietf.org Thu May 04 12:02:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbgHj-0000WG-Fr; Thu, 04 May 2006 12:02:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbgHi-0000W6-3e for simple@ietf.org; Thu, 04 May 2006 12:02:34 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbgHf-0001hN-OK for simple@ietf.org; Thu, 04 May 2006 12:02:34 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 04 May 2006 09:02:29 -0700 X-IronPort-AV: i="4.05,89,1146466800"; d="scan'208"; a="272724876:sNHT3917575306" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k44G2TYg003908; Thu, 4 May 2006 09:02:29 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 12:02:28 -0400 Received: from [161.44.52.148] ([161.44.52.148]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 12:02:28 -0400 Message-ID: <445A2594.3030809@cisco.com> Date: Thu, 04 May 2006 12:02:28 -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: Jeroen van Bemmel Subject: Re: [Simple] WGLC : draft-ietf-simple-xcap-09.txt References: <008301c655aa$43902800$31713b51@BEMBUSTER> In-Reply-To: <008301c655aa$43902800$31713b51@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2006 16:02:28.0463 (UTC) FILETIME=[247CA7F0:01C66F94] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Thanks for your comments, and apologies for the very long delay in responding. Responses inline: Jeroen van Bemmel wrote: > Two comments: > > 1 - ambiguity in ABNF > > AUID = global-auid / vendor-auid > global-auid = auid > auid = 1*pchar > vendor-auid = rev-hostname "." auid > rev-hostname = toplabel *( "." domainlabel ) > domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum > toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum > > From RFC3986: > pchar = unreserved / pct-encoded / sub-delims / ":" / "@" > unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" > sub-delims = "!" / "$" / "&" / "'" / "(" / ")" > / "*" / "+" / "," / ";" / "=" > > The characters allowed in an AUID should be considered more carefully. > Currently, '.' is allowed which is ambiguous (i.e. which part belongs to > 'rev-hostname' and which part to the auid). Good point. I've redefined auid to omit it, and commented that the grammar for auid is equal to pchar minus the '.' > > 2 - normative reference [2] refers to an older version of XML schema, > latest is http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/ Fixed. Thanks for your comments, 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 May 04 13:40:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbhoA-0001Um-B8; Thu, 04 May 2006 13:40:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbho9-0001Ue-4D for simple@ietf.org; Thu, 04 May 2006 13:40:09 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbho7-0005ym-9O for simple@ietf.org; Thu, 04 May 2006 13:40:09 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 04 May 2006 10:40:07 -0700 X-IronPort-AV: i="4.05,89,1146466800"; d="scan'208"; a="272745864:sNHT37613004" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k44He6Yg017465; Thu, 4 May 2006 10:40:06 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 13:40:01 -0400 Received: from [161.44.52.148] ([161.44.52.148]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 13:40:00 -0400 Message-ID: <445A3C6F.8020405@cisco.com> Date: Thu, 04 May 2006 13:39:59 -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: "Schmidt, Christian" References: <72963DDDF17D7949ABD18DC5DA58E770EE22AE@MCHP7R5A.ww002.siemens.net> In-Reply-To: <72963DDDF17D7949ABD18DC5DA58E770EE22AE@MCHP7R5A.ww002.siemens.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2006 17:40:00.0494 (UTC) FILETIME=[C491B8E0:01C66FA1] X-Spam-Score: 0.0 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 Cc: simple@ietf.org Subject: [Simple] Re: WGLC : draft-ietf-simple-xcap-09.txt, some comments 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 Thanks for the detailed comments. Responses inline. Schmidt, Christian wrote: > > 6.2 Document Selector: > > Comment: The example > "http://xcap.example.com/services/resource-lists" is in violation > with the recommendation specified in section 6.1, stating that the > XCAP Root is recommended to be "http://xcap.". Hence the > example should be "http://xcap.example.com/resource-lists". Right, this was pointed out by a few people. Fixed. > > 6.3 Node Selector: > > Text in Verion 09: "Unfortunately, the characters permitted by these > productions include some that are not allowed for pchar, which is the > production for the allowed set of characters in path segments in the > URI. The AttValue production allows many such characters within the > US-ASCII set, including the space. Those characters MUST be percent- > encoded when placed in the URI. Furthermore, QName and AttValue > allow many Unicode characters, outside of US-ASCII. When these > characters need to be represented in the HTTP URI, they are percent- > encoded. To do this, the data should be encoded first as octets > according to the UTF-8 character encoding [18] and then only those > octets that do not correspond to characters in the unreserved set > should be percent-encoded. For example, the character A would be > represented as "A", the character LATIN CAPITAL LETTER A WITH GRAVE > would be represented as "%C3%80", and the character KATAKANA LETTER A > would be represented as "%E3%82%A2"." > > Comment: As first stated, a path segments allows all characters that > are part of the pchar set. Other characters need to be > percent-encoded. Hence, the actual description of how to transform > data into a valid path segment should state: Textproposal: "To do > this, the data should be encoded first as octets according to the > UTF-8 character encoding [18] and then only those octets that do not > correspond to the pchar set should be percent-encoded." Slight mod to this; it should be "..and only those octets that do not correspond to characters in the pchar set.." but otherwise, OK. > > Editorial Comment: Page 21: Last Paragraph: Selection 8.2.3) > > Selection 8.2.3 fixed. > > 7.4. Create or Replace an Element, page 27, first paragraph > > Text in Verion 09: "The "*" indicates that all element children of > are to be considered when computing the position for > insertion. If, instead of a wildcard *, an element name (QName) was > present, the expression above would insert the new element as the > position-th element amongst those with the same expanded name." > > Comment: A reference to Section 8.2.3 should be added here with > respect to how insertions are done. Added. > > Text in Verion 09: "To be certain that element insertions have the > GET(PUT(x))==x property, the client can check that the attribute > predicates in the final path segment of the URI match the attributes > of the element in the body of the request. As an example of an > request that would not have this property and therefore not be > idempotent, consider the following PUT request (URIs are line-folded > for readability): > > PUT /rls-services/users/bill/index/~~/rls-services/ > service%5b@uri=%22sip:good-friends@example.com%5d HTTP/1.1 > Content-Type:application/xcap-el+xml Host: xcap.example.com > > > http://xcap.example.com/resource-lists/users/joe > /index/~~/resource-lists/list%5b@name=%22l1%22%5d > presence > > This request will fail with a 409. The Request URI contains a final > path segment with a predicate based on attributes - > @uri="sip:good-friends@example.com". However, this will not match > the value of the "uri" attribute in the element in the body." > > Comment: A note should be added to make the implications of the > idempotent restriction clear. I.e. it will not be possible to replace > an element with one that has a new value for an attribute that is the > sole unique element identifier using a request URI that contains a > node selector that holds the current attribute value to identify the > element (as presented in the example). The only way around it would > be to specify the position instead of the attribute value in the node > selector (i.e. for the example the following request URI would work > taking that the element is the 2nd element: > /rls-services/users/bill/index/~~/rls-services/service%5b2%5d ). I added text to explain this. Another option that I listed, besides positional, is to replace the whole parent. > > > 7.7 Create or Replace an Attribute > > Text in Verion 09: "To be certain that attribute insertions have the > GET(PUT(x))==x property, the client can check that any attribute > predicate in the path segment that selects the element into which the > attribute is inserted, matches a different attribute than the one > being inserted by the request. As an example of a request that would > not have this property and therefore not be idempotent, consider the > following PUT request (URIs are line folded for readability): > > PUT /rls-services/users/bill/index/~~/ > rls-services/service%5b@uri=%22sip:good-friends@example.com%5d/@uri > HTTP/1.1 Content-Type:application/xcap-att+xml Host: xcap.example.com > "sip:bad-friends@example.com" > > This request will fail with a 409." > > Comment: A note should be added to make the implications of the > idempotent restriction clear. I.e. is will not be possible to replace > the attribute value of an attribute that is the sole unique element > identifier using a request URI that contains a node selector that > holds the current attribute value to identify the parent element (as > presented in the example). The only way around it would be to specify > the position instead of the attribute value in the node selector > (i.e. for the example the following request URI would work taking > that the parent element is the 2nd element: > /rls-services/users/bill/index/~~/rls-services/service%5b2%5d/@uri ). OK, included text here too. > > > > 8.2.1 Locating the Parent > > "If the parent URI has no node selector separator, it is referring to > the directory into which the document should be inserted. If this > directory does not exist, the server MUST return a 409 response, and > SHOULD include a detailed conflict report including the > element. Detailed conflict reports are discussed in Section 11. If > the directory does exist, the server checks to see if there is a > document with the same filename as the target node. If there is, the > operation is the replacement operation discussed in Section 8.2.4. > If it does not exist, it is the creation operation, discussed in > Section 8.2.4." > > Comment: As the XCAP protocol does not provide the means to create a > directory, it is not possible to have a directory structure in the > document selector and thus all documents are present in either to > global directory or the home directory (and never in a subdirectory > of the global or home directory). The only way to have one or more > subdirectories in the document selector is when the application usage > requires the existence of such subdirectories, which is in my view > very unlikely. This should be noted. Text now reads: If the parent URI has no node selector separator, it is referring to the directory into which the document should be inserted. In normal XCAP operations, this will be either the users home directory or the global directory, which will always exist on the server. However, if an application usage is making use of subdirectories (despite the fact that this is not recommended), it is possible that the directory into which the document should be inserted does not exist. In this case, the server MUST return a 409 response, and SHOULD include a detailed conflict report including the <no-parent> element. Detailed conflict reports are discussed in . If the directory does exist, the server checks to see if there is a document with the same filename as the target node. If there is, the operation is the replacement operation discussed in . If it does not exist, it is the creation operation, discussed in . > > Comment: The last reference should be replaced by 8.2.3. The same, at > first line in page 35. Good catch - fixed. > > > 8.2.7 Resource Interdependencies > > Text in Verion 09: "If the creation or replacement was successful, > and the resource interdependencies are resolved, the server returns a > 201 Created or or 200 OK, respectively. Note that a 201 Created is > generated for creation of new documents, elements, or attributes. A > 200 OK response to PUT MUST not contain any content." > > Comment: And what about the 201 Created? What should the content be > of the 201 Created? Should it e.g. contain the XCAP URI identifying > the just created document, element or attribute (in line with RFC > 2616]? We're not changing the guidelines here, so I just referenced 2616 for this. I don't think such information will be useful to the client though. > > > 8.4 DELETE Handling > > Text in Verion 09: "GET operations can be conditional, and follow the > procedures defined in [6]." > > Comment: Replace GET by DELETE fixed. > > 8.5 Managing Etags > > Text in Verion 09: "In the case of a DELETE, the entity tag refers to > the value of the entity tag for all other resources after the > deletion of the specified resource has occurred. One way to think > about this is that the server is, logically speaking, > re-instantiating the resource for a brief instant, so that it can > have an entity tag that can be reasonably returned in the response to > DELETE." > > Comment: This would be correct when deleting elements or attributes. > But there is no sense in creating and returning an ETag when the > whole document is deleted! I added a caveat that this discussion all assumes the document still exists after the operation in question. > > > 11.1 Document Structure > > Proposal for a modified definition: : This indicates that > an attempt to insert a document, element, or attribute failed because > the directory, document or element into which the insertion was > supposed to occur does not exist. This error element can contain an > optional element, which provides an HTTP URI of the xcap > resource that identifies the closest ancestor that does exist. This > HTTP URI MAY be a relative URI, relative to the document itself. > Because this is a valid HTTP URI, its node selector component MUST be > percent-encoded. > > Comment: Note that if the element must contain a HTTP URI > identifying an xcap resource, then it can never indicate a directory > (for e.g. the case in which the create of a document failed because > the parent directory does not exist). Good points. Taking your comment into account, I changed your text to: This indicates that an attempt to insert a document, element, or attribute failed because the directory, document or element into which the insertion was supposed to occur does not exist. This error element can contain an optional element, which provides an HTTP URI that represents the closest parent that would be a valid point of insertion. This HTTP URI MAY be a relative URI, relative to the document itself. Because this is a valid HTTP URI, its node selector component MUST be percent-encoded. > > > 12. XCAP Server Capabilities > > Proposal for enhanced text: The structure of the document is simple. > The root element is . Its children are , > , and . Each of these contain a list of > AUIDs, extensions and namespaces supported by the server. Extensions > are named by tokens defined by the extension, and typically define > new selectors. Namespaces are identified by their namespace URI. > Since all XCAP servers support the "xcap-caps" AUID, it MUST be > listed in the element and the > "urn:ietf:params:xml:ns:xcap-caps" namespace MUST be listed in the > element. Added your suggestoin on nsamespaces. > > Comment: It doesn't seem to be a good idea to list the supported > namespaces unrelated to the AUIDs. When an XCAP server supports > multiple application usages. All namespaces of all supported > application usages are returned as just one list. From this one list, > the XCAP client can not determine which namespaces are supported for > which application usages. "Supported" here really implies that the server can obtain the schema for elements from that namespace. Consequently, I don't think it really matters what application usage they are from. > > > 13. Examples > > Comment: The '/services' is to be removed in line with the > recommendation of section 6.1. Fixed. Thanks for your comments! -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 May 04 13:42:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbhqb-0003eA-9D; Thu, 04 May 2006 13:42:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbhqa-0003dz-CU for simple@ietf.org; Thu, 04 May 2006 13:42:40 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbhqZ-00069B-1p for simple@ietf.org; Thu, 04 May 2006 13:42:40 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 04 May 2006 10:42:39 -0700 X-IronPort-AV: i="4.05,89,1146466800"; d="scan'208"; a="272746217:sNHT30602232" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k44HgGVk001489; Thu, 4 May 2006 10:42:33 -0700 (PDT) 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.211); Thu, 4 May 2006 13:42:32 -0400 Received: from [161.44.52.148] ([161.44.52.148]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 13:42:32 -0400 Message-ID: <445A3D08.5060405@cisco.com> Date: Thu, 04 May 2006 13:42: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: Martin.Hynar@tietoenator.com Subject: Re: [Simple] WGLC : draft-ietf-simple-xcap-09.txt References: <3ACC9A25264A684F82C71840111F9798015FB163@carrera.eu.tieto.com> In-Reply-To: <3ACC9A25264A684F82C71840111F9798015FB163@carrera.eu.tieto.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2006 17:42:32.0666 (UTC) FILETIME=[1F4553A0:01C66FA2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: anders.c.lindgren@ericsson.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 Martin.Hynar@tietoenator.com wrote: > Hi, > > in my understanding the correct XCAP ROOT is the URI of the form > "http://xcap.example.com/services". In the examples, yes. However, as was pointed out in other mails, this form is not consistent with the guidelines in the specification. > > In the begining of section 6 there is written exatly this: > > "The URI is constructed by concatenating the > XCAP root with the document selector with the node selector separator > with a percent-encoded form of the node selector. ..." > > Then the description of document selector from section 6.2 states: > > "The first path segment MUST be the XCAP AUID." > > >>From these two fragments it concludes that if xcap root does not contain > "services" then this fragment cannot be in the xcap uri at all. However, > I must agree that the xcap specification should mention the example of > xcap root in uniform way. Right - it now uniformly follows the recommendations on construction of these things - no subdirectories (and thus, no "/services") and filenames called index. -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 May 04 13:47:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbhuv-0000X6-Qf; Thu, 04 May 2006 13:47:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbhuu-0000Sk-Ff for simple@ietf.org; Thu, 04 May 2006 13:47:08 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbhuu-0006Cy-3y for simple@ietf.org; Thu, 04 May 2006 13:47:08 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 04 May 2006 10:47:08 -0700 X-IronPort-AV: i="4.05,89,1146466800"; d="scan'208"; a="272748371:sNHT28242470" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k44HkoVu002960; Thu, 4 May 2006 10:47:07 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 13:46:45 -0400 Received: from [161.44.52.148] ([161.44.52.148]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 13:46:45 -0400 Message-ID: <445A3E05.5010701@cisco.com> Date: Thu, 04 May 2006 13:46:45 -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: Jeroen van Bemmel Subject: Re: [Simple] WGLC : draft-ietf-simple-xcap-09.txt References: <00a501c655b1$8e5a6920$31713b51@BEMBUSTER> In-Reply-To: <00a501c655b1$8e5a6920$31713b51@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2006 17:46:45.0643 (UTC) FILETIME=[B60E8DB0:01C66FA2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 Sure, but we have this problem in SIP too. The grammar for SIP extension headers is itself a match for every header defined in the spec. Its the job of the extensions themselves to define formats that are unambiguous. Consequently, I don't think we should add this 'x-' prefix to every future extension - its not needed. Thanks, Jonathan R. Jeroen van Bemmel wrote: > Another ABNF related comment: the "extension-selector" production in > section 6.3 is ambiguous, it is a superset of both "attribute-selector" > and "namespace-selector": > > node-selector = element-selector ["/" terminal-selector] > terminal-selector = attribute-selector / namespace-selector / > extension-selector > element-selector = step *( "/" step) > step = by-name / by-pos / by-attr / by-pos-attr / > extension-selector > by-name = NameorAny > by-pos = NameorAny "[" position "]" > position = 1*DIGIT > attr-test = ( "@" att-name "=" <"> att-value <"> ) / > ( "@" att-name "=" <'> att-value <'> ) > by-attr = NameorAny "[" attr-test "]" > by-pos-attr = NameorAny "[" position "]" "[" attr-test "]" > NameorAny = QName / "*" ; QName from XML Namespaces > att-name = QName > att-value = AttValue ; from XML specification > attribute-selector = "@" att-name > namespace-selector = "namespace::*" > extension-selector = 1*( %x00-2e / %x30-ff ) ; anything but "/" > One solution would be to change it into: > > extension-selector = "x-" 1*( %x00-2e / %x30-ff ) ; anything but "/" > Regards, > > Jeroen > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Thu May 04 14:30:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbiao-0007S6-6t; Thu, 04 May 2006 14:30:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbiam-0007EB-Ep for simple@ietf.org; Thu, 04 May 2006 14:30:24 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbiam-000881-3v for simple@ietf.org; Thu, 04 May 2006 14:30:24 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 04 May 2006 11:30:07 -0700 X-IronPort-AV: i="4.05,89,1146466800"; d="scan'208"; a="426309635:sNHT39863188950" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k44ITnVa003601 for ; Thu, 4 May 2006 11:30:07 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 14:29:35 -0400 Received: from [161.44.52.148] ([161.44.52.148]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 14:29:35 -0400 Message-ID: <445A480F.9070108@cisco.com> Date: Thu, 04 May 2006 14:29:35 -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: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2006 18:29:35.0690 (UTC) FILETIME=[B1EC9AA0:01C66FA8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Simple] Updated xcap draft 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've just submitted an update to the XCAP specification based on the last call comments I've received. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-simple-xcap-10.txt The changes are: * changed example URIs to conform to recommendations; namely, no subdirectories and naming of files as 'index'. Also updated example XUI from 'bill' and 'joe' to AOR per recommendations (sip:user@example.com) * noted that, since XUI = SIP AOR, you may need to percent encode SIP URI characters that are not permitted in the HTTP path segment, such as ? and / * updated auid grammar so that the '.' is not allowed * updated XML schema reference to most recent version * in discussion on percent-encoding of unicode characters, mention that escape coding is needed when utf-8 octets are outside of pchar. Previously, it said outside of reserved. * noted some of the limitations of get(put(x))=x in terms of operations that you can't do, and suggest alternatives * mentioned that Location header field and descriptive content can appear in a 201 per RFC 2616 guidelines * Re-defined the error to include the case where the insertion failed because a parent sub-directory doesn't exist. * note that canonicalization includes comments * clarified cases in which DELETE is permitted positionally without a unique attribute selector * removed extraneous reference to CPP (RFC3859) * ran idnits and verified -- 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 May 04 15:50:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbjpt-0005pP-0k; Thu, 04 May 2006 15:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbjpp-0005ob-Qf; Thu, 04 May 2006 15:50:01 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbjpp-00031G-G2; Thu, 04 May 2006 15:50:01 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k44Jo19W015352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fbjpp-00024o-9o; Thu, 04 May 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, 04 May 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-10.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 : The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-10.txt Pages : 69 Date : 2006-5-4 This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-10.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-10.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-10.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-5-4145357.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-4145357.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 Fri May 05 12:32:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc3EM-0005gD-8Q; Fri, 05 May 2006 12:32:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc3EK-0005dE-P7 for simple@ietf.org; Fri, 05 May 2006 12:32:36 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc3EJ-0002uZ-HZ for simple@ietf.org; Fri, 05 May 2006 12:32:36 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 05 May 2006 09:32:36 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,93,1146466800"; d="scan'208"; a="27434490:sNHT20846212" 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 k45GWZTL026324 for ; Fri, 5 May 2006 12:32:35 -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.211); Fri, 5 May 2006 12:32:34 -0400 Received: from [161.44.52.152] ([161.44.52.152]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 May 2006 12:32:34 -0400 Message-ID: <445B7E22.2050806@cisco.com> Date: Fri, 05 May 2006 12:32:34 -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: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 May 2006 16:32:34.0734 (UTC) FILETIME=[83857CE0:01C67061] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Simple] Updated XCAP draft -11 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 XML schema for the xcap-caps was omitted from the -10 by mistake. I submitted a -11 with the schema included. No other changes. Until it appears: http://www.jdrosen.net/papers/draft-ietf-simple-xcap-11.txt Thanks, 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 May 05 15:50:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc6JP-0006TI-Ad; Fri, 05 May 2006 15:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc6JO-0006TA-4Q; Fri, 05 May 2006 15:50:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc6JN-0002ej-PZ; Fri, 05 May 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k45Jo10e026714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fc6JN-0008Nh-9s; Fri, 05 May 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: Fri, 05 May 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-11.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 : The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-11.txt Pages : 71 Date : 2006-5-5 This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-11.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-11.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-11.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-5-5124308.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-5124308.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 Tue May 09 02:27:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdLfV-00083H-Qb; Tue, 09 May 2006 02:26:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdLfU-00083C-NM for simple@ietf.org; Tue, 09 May 2006 02:26:00 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdLfR-00055c-Bs for simple@ietf.org; Tue, 09 May 2006 02:26:00 -0400 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k496QngX029261 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 9 May 2006 01:26:51 -0500 In-Reply-To: <330A23D8336C0346B5C1A5BB19666647029AF7CC@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB19666647029AF7CC@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Simple] RE: IM delivery reports for conferencing Date: Tue, 9 May 2006 01:25:43 -0500 To: "Burger, Eric" X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 On Apr 7, 2006, at 8:14 AM, Burger, Eric wrote: > Client cannot do aggregation, as it has no clue why it is getting > bombarded with dozens of IMDN's for the single message it sent. > > That said, I agree, we should not do aggregations in the initial > release > of IMDN, but leave it as an exercise for the reader (and future > standardization work) for how a B2BUA could do aggregation. For the record, so I can say "I told you so" a couple of years from now (and so I'll have something to complain about besides forking, retargeting, PRACK, gratuitous use of B2BUAs, and broken identity models), IMDN is evil. Kill it now before it breeds. You've been warned. Ahead lies nothing but tears. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 09 05:38:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdOfZ-0004Yo-3d; Tue, 09 May 2006 05:38:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdOfX-0004Se-6o for simple@ietf.org; Tue, 09 May 2006 05:38:15 -0400 Received: from smtp12.clb.oleane.net ([213.56.31.47]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdOfV-0005ql-Mv for simple@ietf.org; Tue, 09 May 2006 05:38:15 -0400 Received: from Pavillonquatre ([194.3.133.88]) by smtp12.clb.oleane.net with ESMTP id k499c2rm003284 for ; Tue, 9 May 2006 11:38:03 +0200 Message-Id: <200605090938.k499c2rm003284@smtp12.clb.oleane.net> From: "Chantal Ladouce" To: Date: Tue, 9 May 2006 11:36:45 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZzTBZOSoZIjfRZSeiJRx25UELBOw== X-Spam-Score: 0.2 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Subject: [Simple] Wireless/WiFi Convergence Conference 2006 - Paris - France 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="===============0126754448==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0126754448== Content-Type: multipart/alternative; boundary="----=_NextPart_000_026E_01C6735C.DC297DD0" This is a multi-part message in MIME format. ------=_NextPart_000_026E_01C6735C.DC297DD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit UMA how? IMS when? Don't miss the 2006 Wireless/WiFi Convergence Conference to be held next week in Paris (on May 16 to May 19). Distinguished experts and key players in the convergence field will address technical issues. Registration is still open. Get all details at: http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006intro.htm ------=_NextPart_000_026E_01C6735C.DC297DD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

UMA how? = IMS when?

=

Don't miss the 2006 Wireless/WiFi Convergence Conference = to be held next week in Paris (on May 16 to May 19).

Distinguished experts and key players in the convergence field will address technical issues. =

Registration is still = open.

Get all details = at:

 

http://www.upperside.fr/wirelessconvergence2006/wwconvergenc= e2006intro.htm

=

 

 

------=_NextPart_000_026E_01C6735C.DC297DD0-- --===============0126754448== 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 --===============0126754448==-- From simple-bounces@ietf.org Wed May 10 04:26:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdjzv-0005Gq-G8; Wed, 10 May 2006 04:24:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdjzt-0005Gl-Lj for simple@ietf.org; Wed, 10 May 2006 04:24:41 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdjzr-0001CP-Bz for simple@ietf.org; Wed, 10 May 2006 04:24:41 -0400 Received: by ug-out-1314.google.com with SMTP id m2so27087uge for ; Wed, 10 May 2006 01:24:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=jWFJQWLhbfZrJxkdAEDefwNGsB3CHerKn0VJ5LEAaQ21wqt2C8cdhryLSZzYa+SrOyYqpI1QszVz+Y5Op3dZ7lFLJPmWBKSADF3NwIGOsqo0avM/i23tz+ez6SKWuqje70qKV/d1ui2OEp9xznmqOod9AdF416N3BUPI5myXaL0= Received: by 10.78.52.17 with SMTP id z17mr78029huz; Wed, 10 May 2006 01:24:36 -0700 (PDT) Received: by 10.78.75.7 with HTTP; Wed, 10 May 2006 01:24:36 -0700 (PDT) Message-ID: <6405cd720605100124k74436964k679aedf9223ff2ed@mail.gmail.com> Date: Wed, 10 May 2006 10:24:36 +0200 From: jos4711@googlemail.com To: simple@ietf.org MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Simple] Presencestate 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="===============1620652044==" Errors-To: simple-bounces@ietf.org --===============1620652044== Content-Type: multipart/alternative; boundary="----=_Part_17317_3111605.1147249476361" ------=_Part_17317_3111605.1147249476361 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi! I have a question about, how to adress a Presence Server/Presence Agent wit= h PUBLISH, SUBSCRIBE. If I have understand it correctly from the RFC 3903 Page 4 and 24, the Request-URI in a PUBLISH and a SUBSCRIBE is the URI of the PUA and not the Presence Server/Presence Agent. Correct? Example: My public SIP-URI is: client@sip.com Now, I want to Publish my Presencestate. So I have to adress the PUBLISH to client@sip.com. The SIP-Proxy who receives the Request will automatically forward it to the Presence Server/Presence Agent, which is responsible for my Presencestate. If someone wants to subscribe to my Presencestate, he SUBSCRIBEs to client@sip.com. The SIP-Proxy who receives the Request will automatically forward it to the Presence Server/Presence Agent, which is responsbile for my Presencestate. Greets, Harold. ------=_Part_17317_3111605.1147249476361 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Hi!
I have a question about, how to adress a Presence Server/Presence= Agent with PUBLISH, SUBSCRIBE.

If I have understand it correctly from the RFC 3903 Page 4 and 24, the R= equest-URI in a PUBLISH and a SUBSCRIBE is the URI of the PUA and not the P= resence Server/Presence Agent. Correct?

Example:
My public SIP-URI is: clie= nt@sip.com

Now, I want to Publish my Presencestate. So I have to adress the PUBLISH= to client@sip.com. The SIP-Proxy
= who receives the Request will automatically forward it to the Presence Serv= er/Presence Agent, which is responsible for my Presencestate.

If someone wants to subscribe to my Presencestate, he SUBSCRIBEs to client@sip.com. The SIP-Proxy who recei= ves the Request will automatically forward it to the Presence Server/Presen= ce Agent, which is responsbile for my Presencestate.

Greets,
Harold.

------=_Part_17317_3111605.1147249476361-- --===============1620652044== 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 --===============1620652044==-- From simple-bounces@ietf.org Wed May 10 04:58:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdkVl-0000t1-KM; Wed, 10 May 2006 04:57:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdkVk-0000rI-5h for simple@ietf.org; Wed, 10 May 2006 04:57:36 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdkVh-0002VR-TD for simple@ietf.org; Wed, 10 May 2006 04:57:36 -0400 Received: by nf-out-0910.google.com with SMTP id g2so1329490nfe for ; Wed, 10 May 2006 01:57:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=sMh/c8C2KXG8tenFewvOnbZ5qPYRNeiiuvmFr+wqL5kmXbq95WSpozvFnJYTerVgaVHbRBDPZozDrH25KMjx/AQ66ngK5jIHpoKXjySW5Uami4HQ6xGd8Tiv8BC/DMAhbmUe54oWdxTUcpTN1bL4POIItxvEPmwkD9O/F1Ruzy8= Received: by 10.48.218.20 with SMTP id q20mr372200nfg; Wed, 10 May 2006 01:57:33 -0700 (PDT) Received: by 10.48.225.18 with HTTP; Wed, 10 May 2006 01:57:33 -0700 (PDT) Message-ID: <44781c350605100157k307837dfm4b3874154dee0218@mail.gmail.com> Date: Wed, 10 May 2006 11:57:33 +0300 From: "Noga Tor" To: simple@ietf.org MIME-Version: 1.0 X-Spam-Score: 1.9 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Simple] The difference between RLS and Presence subscriptions 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="===============1503045055==" Errors-To: simple-bounces@ietf.org --===============1503045055== Content-Type: multipart/alternative; boundary="----=_Part_3395_6575990.1147251453009" ------=_Part_3395_6575990.1147251453009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi I was wondering in what way you can tell if a certain subscription is a Presence Subcription or an RLS Subscription. is there any indicator? is it done by the uri in the "TO: " header? and if so, in what way? Thanks Noga ------=_Part_3395_6575990.1147251453009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi
 
I was wondering in what way you can tell if a certain subscription is = a Presence Subcription or an RLS Subscription.
is there any indicator? is it done by the uri in the "TO: " = header? and if so, in what way?
 
Thanks
Noga
------=_Part_3395_6575990.1147251453009-- --===============1503045055== 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 --===============1503045055==-- From simple-bounces@ietf.org Wed May 10 05:17:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdkoA-0006tj-5L; Wed, 10 May 2006 05:16:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdko8-0006t9-Jq for simple@ietf.org; Wed, 10 May 2006 05:16:36 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdko7-0002y8-AW for simple@ietf.org; Wed, 10 May 2006 05:16:36 -0400 Received: by nf-out-0910.google.com with SMTP id g2so1332496nfe for ; Wed, 10 May 2006 02:16:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=ctdlvCHEB3ap0ZcreS+AWyD83riUZG2Ka93O2IR0LLbXXP274sxwsHTBAh5rAAz+W8gXUrM/yiK0kETAuFV61aemZFqjHqmctPHuhgnrjq/9LLhdu29IT2VWAuznxgjCUrnlUdVDkf1OcV9NXXCkjbKcHoM60PfNg79MXWeQzFE= Received: by 10.48.47.7 with SMTP id u7mr384675nfu; Wed, 10 May 2006 02:16:34 -0700 (PDT) Received: by 10.48.225.18 with HTTP; Wed, 10 May 2006 02:16:34 -0700 (PDT) Message-ID: <44781c350605100216l8112f0dmb34cf08aff3d1934@mail.gmail.com> Date: Wed, 10 May 2006 12:16:34 +0300 From: "Noga Tor" To: simple@ietf.org MIME-Version: 1.0 X-Spam-Score: 1.9 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [Simple] PARTIAL PUBLISH - draft-ietf-simple-partial-publish-04.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: , Content-Type: multipart/mixed; boundary="===============1246018981==" Errors-To: simple-bounces@ietf.org --===============1246018981== Content-Type: multipart/alternative; boundary="----=_Part_3463_19214490.1147252594743" ------=_Part_3463_19214490.1147252594743 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline When performing partial PUBLISH the root element is the . However, in the regular PUBLISH the root element is . Then when we perform the subsequent partial PUBLISHes, we want to refer the the original PUBLISH, using xpaths, for example : "presence/note" However, this XPATH will not match the note element in the previous publish= , beacuse its xpath is: "pidf-full/note" (this exact example appears in the draft-ietf-simple-partial-publish-04.txt) how can this difference be settled? should the Presence Server convert the "pidf-full" root tag to "presence"? or should the xpaths always be in the wildcard format: "*/note" etc..? thanks Noga ------=_Part_3463_19214490.1147252594743 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
When performing partial PUBLISH the root element is the <pidf-full&= gt;.
However, in the regular PUBLISH the root element is <presence>. =
 
Then when we perform the subsequent partial PUBLISHes, we want to refe= r the the original PUBLISH, using xpaths, for example :
"presence/note"
However, this XPATH will not match the note element in the previous pu= blish, beacuse its xpath is: "pidf-full/note" (this exact example= appears in the draft-ietf-simple-partial-publish-04.txt)
 
 
how can this difference be settled?
 
should the Presence Server convert the "pidf-full" root tag = to "presence"? or should the xpaths always be in the wildcard for= mat: "*/note" etc..?
 
 
thanks
Noga
 
 
------=_Part_3463_19214490.1147252594743-- --===============1246018981== 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 --===============1246018981==-- From simple-bounces@ietf.org Wed May 10 08:06:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdnRB-0006Bp-6f; Wed, 10 May 2006 08:05:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdnR9-0006Bh-Fd for simple@ietf.org; Wed, 10 May 2006 08:05:03 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdnR5-00024y-Vr for simple@ietf.org; Wed, 10 May 2006 08:05:03 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4AC4wl5012722; Wed, 10 May 2006 15:04:58 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 May 2006 15:04:06 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 May 2006 15:04:04 +0300 Received: from 172.21.34.145 ([172.21.34.145]) by esebe105.NOE.Nokia.com ([172.21.143.53]) with Microsoft Exchange Server HTTP-DAV ; Wed, 10 May 2006 12:04:04 +0000 Received: from hed034-145.research.nokia.com by esebe105.noe.nokia.com; 10 May 2006 15:04:04 +0300 Subject: Re: [Simple] PARTIAL PUBLISH - draft-ietf-simple-partial-publish-04.txt From: Jari Urpalainen To: ext Noga Tor In-Reply-To: <44781c350605100216l8112f0dmb34cf08aff3d1934@mail.gmail.com> References: <44781c350605100216l8112f0dmb34cf08aff3d1934@mail.gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 10 May 2006 15:04:03 +0300 Message-Id: <1147262643.7479.2.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) X-OriginalArrivalTime: 10 May 2006 12:04:04.0757 (UTC) FILETIME=[D54AD450:01C67429] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 On Wed, 2006-05-10 at 12:16 +0300, ext Noga Tor wrote: > When performing partial PUBLISH the root element is the . > However, in the regular PUBLISH the root element is . > > Then when we perform the subsequent partial PUBLISHes, we want to > refer the the original PUBLISH, using xpaths, for example : > "presence/note" > However, this XPATH will not match the note element in the previous > publish, beacuse its xpath is: "pidf-full/note" (this exact example > appears in the draft-ietf-simple-partial-publish-04.txt) > > > how can this difference be settled? > > should the Presence Server convert the "pidf-full" root tag to > "presence"? or should the xpaths always be in the wildcard format: > "*/note" etc..? > > > thanks > Noga > All partial updates, i.e. patches update not so the selectors always start either with "presence" or wildcard "*". So the presence server will store content as if were received. The publish request will be rejected with this mime type if the server doesn't support partial updates. With notifies will carry version number information (in addition to PIDF) to enable reasonable sync for the client. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 10 10:14:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdpQZ-0002Ch-DX; Wed, 10 May 2006 10:12:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdpQW-0002Az-Fb for simple@ietf.org; Wed, 10 May 2006 10:12: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 1FdpQW-0007R1-EA for simple@ietf.org; Wed, 10 May 2006 10:12:32 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FdpPX-0004dA-8I for simple@ietf.org; Wed, 10 May 2006 10:11:35 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 10 May 2006 10:11:31 -0400 X-IronPort-AV: i="4.05,109,1146456000"; d="scan'208"; a="88269593:sNHT28954000" 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 k4AEBUTL020755; Wed, 10 May 2006 10:11:30 -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.211); Wed, 10 May 2006 10:11:30 -0400 Received: from [192.168.1.100] ([10.86.243.0]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 May 2006 10:11:30 -0400 Message-ID: <4461F491.2080805@cisco.com> Date: Wed, 10 May 2006 10:11:29 -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: jos4711@googlemail.com Subject: Re: [Simple] Presencestate References: <6405cd720605100124k74436964k679aedf9223ff2ed@mail.gmail.com> In-Reply-To: <6405cd720605100124k74436964k679aedf9223ff2ed@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 May 2006 14:11:30.0403 (UTC) FILETIME=[A273D330:01C6743B] X-Spam-Score: -2.6 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 jos4711@googlemail.com wrote: > Hi! > I have a question about, how to adress a Presence Server/Presence Agent > with PUBLISH, SUBSCRIBE. > > If I have understand it correctly from the RFC 3903 Page 4 and 24, the > Request-URI in a PUBLISH and a SUBSCRIBE is the URI of the PUA and not > the Presence Server/Presence Agent. Correct? The R-URI in both cases is the identity of the presentity in question. > > Example: > My public SIP-URI is: client@sip.com > > Now, I want to Publish my Presencestate. So I have to adress the PUBLISH > to client@sip.com . The SIP-Proxy > who receives the Request will automatically forward it to the Presence > Server/Presence Agent, which is responsible for my Presencestate. > > If someone wants to subscribe to my Presencestate, he SUBSCRIBEs to > client@sip.com . The SIP-Proxy who receives the > Request will automatically forward it to the Presence Server/Presence > Agent, which is responsbile for my Presencestate. Correct. -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 May 10 11:08:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdqIm-0006fh-M1; Wed, 10 May 2006 11:08:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdqIl-0006fU-J4; Wed, 10 May 2006 11:08:35 -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 1Fdomo-0005Zr-Ry; Wed, 10 May 2006 09:31:30 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FdoYO-000405-HI; Wed, 10 May 2006 09:16:37 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4ADGXFQ020392; Wed, 10 May 2006 16:16:35 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 May 2006 16:16:28 +0300 Received: from [172.21.35.101] ([172.21.35.101]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 May 2006 16:16:27 +0300 Message-ID: <4461E7AA.6090207@nokia.com> Date: Wed, 10 May 2006 16:16:26 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: "ext simple-bounces@ietf.org" CC: simple@ietf.org Subject: Re: [Simple] Presencestate References: <6405cd720605100124k74436964k679aedf9223ff2ed@mail.gmail.com> In-Reply-To: <6405cd720605100124k74436964k679aedf9223ff2ed@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 May 2006 13:16:27.0145 (UTC) FILETIME=[F18EA790:01C67433] X-Spam-Score: -2.6 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 simple-bounces@ietf.org wrote: > Hi! > I have a question about, how to adress a Presence Server/Presence Agent > with PUBLISH, SUBSCRIBE. > > If I have understand it correctly from the RFC 3903 Page 4 and 24, the > Request-URI in a PUBLISH and a SUBSCRIBE is the URI of the PUA and not > the Presence Server/Presence Agent. Correct? Correct. > Example: > My public SIP-URI is: client@sip.com You probably mean ? ;) > Now, I want to Publish my Presencestate. So I have to adress the PUBLISH > to client@sip.com . The SIP-Proxy > who receives the Request will automatically forward it to the Presence > Server/Presence Agent, which is responsible for my Presencestate. Correct. > If someone wants to subscribe to my Presencestate, he SUBSCRIBEs to > client@sip.com . The SIP-Proxy who receives the > Request will automatically forward it to the Presence Server/Presence > Agent, which is responsbile for my Presencestate. Right. Of course another equally valid configuration is for the PUBLISH/SUBSCRIBE to end up in any of the UAs for that AOR that have a registered contact. This would mean in practice that presence is published and delivered directly between the end nodes. Unfortunately, there is really no way to know, a priori, which configuration a given domain has, e.g., for supporting the PUBLISH method. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu May 11 01:24:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe3dc-0004AR-9g; Thu, 11 May 2006 01:23:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe3da-00046g-Jq for simple@ietf.org; Thu, 11 May 2006 01:22:58 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe3dW-0004pH-Bk for simple@ietf.org; Thu, 11 May 2006 01:22:55 -0400 Received: by nf-out-0910.google.com with SMTP id h2so37533nfe for ; Wed, 10 May 2006 22:22:53 -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:references; b=j98z8/HSFbn6Ekf+bKHRN4eSk8IVRjvbdQaJgMfM7H+MbddIfF8j8aBXNgBdUc8n56pppdrDJUOHZOG/v8Hp97th4RRK9bCrt2DnMm30PScmfJx8xQZaQ0Z+M3sQENxwehhRPvgkvO82ukvQq7XT5GoL21Q86ZwIh0vXDMXd330= Received: by 10.48.208.8 with SMTP id f8mr219793nfg; Wed, 10 May 2006 22:22:53 -0700 (PDT) Received: by 10.48.12.8 with HTTP; Wed, 10 May 2006 22:22:53 -0700 (PDT) Message-ID: <60b4a2350605102222o74130744jc00f095b234653d6@mail.gmail.com> Date: Thu, 11 May 2006 10:52:53 +0530 From: "Gadigeppa Malagund" To: "Noga Tor" Subject: Re: [Simple] The difference between RLS and Presence subscriptions In-Reply-To: <44781c350605100157k307837dfm4b3874154dee0218@mail.gmail.com> MIME-Version: 1.0 References: <44781c350605100157k307837dfm4b3874154dee0218@mail.gmail.com> X-Spam-Score: 2.0 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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: , Content-Type: multipart/mixed; boundary="===============0383206554==" Errors-To: simple-bounces@ietf.org --===============0383206554== Content-Type: multipart/alternative; boundary="----=_Part_2459_25558755.1147324973357" ------=_Part_2459_25558755.1147324973357 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SGksCgpSTFMgc3Vic2NyaXB0aW9uIHJlcXVlc3QgaGFzICJTdXBwb3J0ZWQ6IGV2ZW50bGlzdCIg d2hlcmUgYXMgcHJlc2VuY2UKZG9lc24ndC4KClJlZ2FyZHMsCkdhZGkKT24gNS8xMC8wNiwgTm9n YSBUb3IgPG5vZ2EudG9yQGdtYWlsLmNvbT4gd3JvdGU6Cj4KPiBIaQo+Cj4gSSB3YXMgd29uZGVy aW5nIGluIHdoYXQgd2F5IHlvdSBjYW4gdGVsbCBpZiBhIGNlcnRhaW4gc3Vic2NyaXB0aW9uIGlz IGEKPiBQcmVzZW5jZSBTdWJjcmlwdGlvbiBvciBhbiBSTFMgU3Vic2NyaXB0aW9uLgo+IGlzIHRo ZXJlIGFueSBpbmRpY2F0b3I/IGlzIGl0IGRvbmUgYnkgdGhlIHVyaSBpbiB0aGUgIlRPOiAiIGhl YWRlcj8gYW5kIGlmCj4gc28sIGluIHdoYXQgd2F5Pwo+Cj4gVGhhbmtzCj4gTm9nYQo+Cj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBTaW1wbGUgbWFp bGluZyBsaXN0Cj4gU2ltcGxlQGlldGYub3JnCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ltcGxlCj4KPgo+Cg== ------=_Part_2459_25558755.1147324973357 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksPGJyPgo8YnI+ClJMUyBzdWJzY3JpcHRpb24gcmVxdWVzdCBoYXMgJnF1b3Q7U3VwcG9ydGVk OiBldmVudGxpc3QmcXVvdDsgd2hlcmUgYXMgcHJlc2VuY2UgZG9lc24ndC48YnI+PGJyPgpSZWdh cmRzLDxicj4KR2FkaTxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gNS8xMC8w NiwgPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPk5vZ2EgVG9yPC9iPiAmbHQ7PGEgaHJlZj0i bWFpbHRvOm5vZ2EudG9yQGdtYWlsLmNvbSI+bm9nYS50b3JAZ21haWwuY29tPC9hPiZndDsgd3Jv dGU6PC9zcGFuPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1s ZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAu OGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgo8ZGl2PjxkaXY+SGkgPC9kaXY+CjxkaXY+Jm5ic3A7 PC9kaXY+CjxkaXY+SSB3YXMgd29uZGVyaW5nIGluIHdoYXQgd2F5IHlvdSBjYW4gdGVsbCBpZiBh IGNlcnRhaW4gc3Vic2NyaXB0aW9uIGlzIGEgUHJlc2VuY2UgU3ViY3JpcHRpb24gb3IgYW4gUkxT IFN1YnNjcmlwdGlvbi48L2Rpdj4KPGRpdj5pcyB0aGVyZSBhbnkgaW5kaWNhdG9yPyBpcyBpdCBk b25lIGJ5IHRoZSB1cmkgaW4gdGhlICZxdW90O1RPOiAmcXVvdDsgaGVhZGVyPyBhbmQgaWYgc28s IGluIHdoYXQgd2F5PyA8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5UaGFua3M8L2Rpdj48 L2Rpdj48ZGl2PjxzcGFuIGNsYXNzPSJzZyI+CjxkaXY+Tm9nYTwvZGl2PgoKPC9zcGFuPjwvZGl2 Pjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5T aW1wbGUgbWFpbGluZyBsaXN0PGJyPjxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExp bmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86U2ltcGxlQGlldGYub3JnIj5TaW1w bGVAaWV0Zi5vcmc8L2E+PGJyPjxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmso d2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zaW1wbGUiIHRhcmdldD0iX2JsYW5rIj4KaHR0cHM6Ly93d3cxLmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ltcGxlPC9hPjxicj48YnI+PGJyPjwvYmxvY2txdW90ZT48L2Rpdj48 YnI+Cgo= ------=_Part_2459_25558755.1147324973357-- --===============0383206554== 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 --===============0383206554==-- From simple-bounces@ietf.org Thu May 11 01:57:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe4Ab-0000tQ-TR; Thu, 11 May 2006 01:57:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe4Aa-0000pf-Dd for simple@ietf.org; Thu, 11 May 2006 01:57:04 -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 1Fe4Aa-0006Nq-C2 for simple@ietf.org; Thu, 11 May 2006 01:57:04 -0400 Received: from nf-out-0910.google.com ([64.233.182.188]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fe40n-0004pA-Tf for simple@ietf.org; Thu, 11 May 2006 01:47:05 -0400 Received: by nf-out-0910.google.com with SMTP id p48so42603nfa for ; Wed, 10 May 2006 22:46:56 -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:references; b=hGlk6dpC26Ybwh4JDJNvQ6sbcCRjTEjSvC694MJ6TxIM9Md2C+Jn6BTI4up/pp8PySn8GTrA1B5JcnZ2PCDme+EWkWVfwNsk8dYpp45bfA5C27WkIQ1UU8YX4NTN+WzFvLDeiI3/3XIkU8SovwRrhUmNcSjxtiLFXqGkNBXPU2o= Received: by 10.48.254.12 with SMTP id b12mr123919nfi; Wed, 10 May 2006 22:46:56 -0700 (PDT) Received: by 10.48.12.8 with HTTP; Wed, 10 May 2006 22:46:56 -0700 (PDT) Message-ID: <60b4a2350605102246m5209c960t5181cde0561c78c8@mail.gmail.com> Date: Thu, 11 May 2006 11:16:56 +0530 From: "Gadigeppa Malagund" To: "Jari Urpalainen" Subject: Re: [Simple] PARTIAL PUBLISH - draft-ietf-simple-partial-publish-04.txt In-Reply-To: <1147262643.7479.2.camel@hed034-145.research.nokia.com> MIME-Version: 1.0 References: <44781c350605100216l8112f0dmb34cf08aff3d1934@mail.gmail.com> <1147262643.7479.2.camel@hed034-145.research.nokia.com> X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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: , Content-Type: multipart/mixed; boundary="===============1219551570==" Errors-To: simple-bounces@ietf.org --===============1219551570== Content-Type: multipart/alternative; boundary="----=_Part_2651_11757047.1147326416491" ------=_Part_2651_11757047.1147326416491 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SGksCgpXaGVuIHByZXNlbmNlIHNlcnZlciBzdXBwb3J0cyBNSU1FIGFwcGxpY2F0aW9uL3BpZGYt ZGlmZit4bWwgZnVsbCBQVUJMSVNICmNhbiBiZSBkb25lIGVpdGhlciB3aXRoIDxwcmVzZW5jZT4g b3IgPHBpZGYtZnVsbD4gYXMgcm9vdCB0YWcuCldoeSBzaG91bGQgd2UgdXNlIDxwcmVzZW5jZT4g d2hlbiBzZXJ2ZXIgc3VwcG9ydHMgcGlkZi1kaWZmK3htbCB3aGljaCBpcwpzdXBlcnNldCBvZiBw aWRmK3htbD8KSW5zdGVhZCB3ZSBjYW4gb25seSB1c2UgPHBpZGYtZnVsbD4gYW5kIDxwaWRmLWRp ZmY+LgoKUmVnYXJkcywKR2FkaQoKT24gNS8xMC8wNiwgSmFyaSBVcnBhbGFpbmVuIDxqYXJpLnVy cGFsYWluZW5Abm9raWEuY29tPiB3cm90ZToKPgo+IE9uIFdlZCwgMjAwNi0wNS0xMCBhdCAxMjox NiArMDMwMCwgZXh0IE5vZ2EgVG9yIHdyb3RlOgo+ID4gV2hlbiBwZXJmb3JtaW5nIHBhcnRpYWwg UFVCTElTSCB0aGUgcm9vdCBlbGVtZW50IGlzIHRoZSA8cGlkZi1mdWxsPi4KPiA+IEhvd2V2ZXIs IGluIHRoZSByZWd1bGFyIFBVQkxJU0ggdGhlIHJvb3QgZWxlbWVudCBpcyA8cHJlc2VuY2U+Lgo+ ID4KPiA+IFRoZW4gd2hlbiB3ZSBwZXJmb3JtIHRoZSBzdWJzZXF1ZW50IHBhcnRpYWwgUFVCTElT SGVzLCB3ZSB3YW50IHRvCj4gPiByZWZlciB0aGUgdGhlIG9yaWdpbmFsIFBVQkxJU0gsIHVzaW5n IHhwYXRocywgZm9yIGV4YW1wbGUgOgo+ID4gInByZXNlbmNlL25vdGUiCj4gPiBIb3dldmVyLCB0 aGlzIFhQQVRIIHdpbGwgbm90IG1hdGNoIHRoZSBub3RlIGVsZW1lbnQgaW4gdGhlIHByZXZpb3Vz Cj4gPiBwdWJsaXNoLCBiZWFjdXNlIGl0cyB4cGF0aCBpczogInBpZGYtZnVsbC9ub3RlIiAodGhp cyBleGFjdCBleGFtcGxlCj4gPiBhcHBlYXJzIGluIHRoZSBkcmFmdC1pZXRmLXNpbXBsZS1wYXJ0 aWFsLXB1Ymxpc2gtMDQudHh0KQo+ID4KPiA+Cj4gPiBob3cgY2FuIHRoaXMgZGlmZmVyZW5jZSBi ZSBzZXR0bGVkPwo+ID4KPiA+IHNob3VsZCB0aGUgUHJlc2VuY2UgU2VydmVyIGNvbnZlcnQgdGhl ICJwaWRmLWZ1bGwiIHJvb3QgdGFnIHRvCj4gPiAicHJlc2VuY2UiPyBvciBzaG91bGQgdGhlIHhw YXRocyBhbHdheXMgYmUgaW4gdGhlIHdpbGRjYXJkIGZvcm1hdDoKPiA+ICIqL25vdGUiIGV0Yy4u Pwo+ID4KPiA+Cj4gPiB0aGFua3MKPiA+IE5vZ2EKPiA+Cj4gQWxsIHBhcnRpYWwgdXBkYXRlcywg aS5lLiBwYXRjaGVzIHVwZGF0ZSA8cHJlc2VuY2U+IG5vdCA8cGlkZi1mdWxsPiBzbwo+IHRoZSBz ZWxlY3RvcnMgYWx3YXlzIHN0YXJ0IGVpdGhlciB3aXRoICJwcmVzZW5jZSIgb3Igd2lsZGNhcmQg IioiLiBTbwo+IHRoZSBwcmVzZW5jZSBzZXJ2ZXIgd2lsbCBzdG9yZSA8cGlkZi1mdWxsPiBjb250 ZW50IGFzIGlmIDxwcmVzZW5jZT4gd2VyZQo+IHJlY2VpdmVkLiBUaGUgcHVibGlzaCByZXF1ZXN0 IHdpbGwgYmUgcmVqZWN0ZWQgd2l0aCB0aGlzIG1pbWUgdHlwZSBpZgo+IHRoZSBzZXJ2ZXIgZG9l c24ndCBzdXBwb3J0IHBhcnRpYWwgdXBkYXRlcy4gV2l0aCBub3RpZmllcyA8cGlkZi1mdWxsPgo+ IHdpbGwgY2FycnkgdmVyc2lvbiBudW1iZXIgaW5mb3JtYXRpb24gKGluIGFkZGl0aW9uIHRvIFBJ REYpIHRvIGVuYWJsZQo+IHJlYXNvbmFibGUgc3luYyBmb3IgdGhlIGNsaWVudC4KPiBiciwKPiBK YXJpCj4KPgo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KPiBTaW1wbGUgbWFpbGluZyBsaXN0Cj4gU2ltcGxlQGlldGYub3JnCj4gaHR0cHM6Ly93d3cx LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ltcGxlCj4K ------=_Part_2651_11757047.1147326416491 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksPGJyPgoKPGJyPgoKV2hlbiBwcmVzZW5jZSBzZXJ2ZXIgc3VwcG9ydHMgTUlNRSBhcHBsaWNh dGlvbi9waWRmLWRpZmYreG1sIGZ1bGwKUFVCTElTSCBjYW4gYmUgZG9uZSBlaXRoZXIgd2l0aCAm bHQ7cHJlc2VuY2UmZ3Q7IG9yICZsdDtwaWRmLWZ1bGwmZ3Q7CmFzIHJvb3QgdGFnLjxicj4KCldo eSBzaG91bGQgd2UgdXNlICZsdDtwcmVzZW5jZSZndDsgd2hlbiBzZXJ2ZXIgc3VwcG9ydHMgcGlk Zi1kaWZmK3htbCB3aGljaCBpcyBzdXBlcnNldCBvZiBwaWRmK3htbD88YnI+CgpJbnN0ZWFkIHdl IGNhbiBvbmx5IHVzZSAmbHQ7cGlkZi1mdWxsJmd0OyBhbmQgJmx0O3BpZGYtZGlmZiZndDsuPGJy PgoKPGJyPgoKUmVnYXJkcyw8YnI+CgpHYWRpPGJyPjxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFp bF9xdW90ZSI+T24gNS8xMC8wNiwgPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPkphcmkgVXJw YWxhaW5lbjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpqYXJpLnVycGFsYWluZW5Abm9raWEuY29t Ij5qYXJpLnVycGFsYWluZW5Abm9raWEuY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxibG9ja3F1 b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdi KDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6 IDFleDsiPgpPbiBXZWQsIDIwMDYtMDUtMTAgYXQgMTI6MTYgKzAzMDAsIGV4dCBOb2dhIFRvciB3 cm90ZTo8YnI+Jmd0OyBXaGVuIHBlcmZvcm1pbmcgcGFydGlhbCBQVUJMSVNIIHRoZSByb290IGVs ZW1lbnQgaXMgdGhlICZsdDtwaWRmLWZ1bGwmZ3Q7Ljxicj4mZ3Q7IEhvd2V2ZXIsIGluIHRoZSBy ZWd1bGFyIFBVQkxJU0ggdGhlIHJvb3QgZWxlbWVudCBpcyAmbHQ7cHJlc2VuY2UmZ3Q7Ljxicj4m Z3Q7Cjxicj4mZ3Q7IFRoZW4gd2hlbiB3ZSBwZXJmb3JtIHRoZSBzdWJzZXF1ZW50IHBhcnRpYWwg UFVCTElTSGVzLCB3ZSB3YW50IHRvPGJyPiZndDsgcmVmZXIgdGhlIHRoZSBvcmlnaW5hbCBQVUJM SVNILCB1c2luZyB4cGF0aHMsIGZvciBleGFtcGxlIDo8YnI+Jmd0OyAmcXVvdDtwcmVzZW5jZS9u b3RlJnF1b3Q7PGJyPiZndDsgSG93ZXZlciwgdGhpcyBYUEFUSCB3aWxsIG5vdCBtYXRjaCB0aGUg bm90ZSBlbGVtZW50IGluIHRoZSBwcmV2aW91cwo8YnI+Jmd0OyBwdWJsaXNoLCBiZWFjdXNlIGl0 cyB4cGF0aCBpczogJnF1b3Q7cGlkZi1mdWxsL25vdGUmcXVvdDsgKHRoaXMgZXhhY3QgZXhhbXBs ZTxicj4mZ3Q7IGFwcGVhcnMgaW4gdGhlIGRyYWZ0LWlldGYtc2ltcGxlLXBhcnRpYWwtcHVibGlz aC0wNC50eHQpPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IGhvdyBjYW4gdGhpcyBkaWZmZXJlbmNl IGJlIHNldHRsZWQ/PGJyPiZndDs8YnI+CiZndDsgc2hvdWxkIHRoZSBQcmVzZW5jZSBTZXJ2ZXIg Y29udmVydCB0aGUgJnF1b3Q7cGlkZi1mdWxsJnF1b3Q7IHJvb3QgdGFnIHRvPGJyPiZndDsgJnF1 b3Q7cHJlc2VuY2UmcXVvdDs/IG9yIHNob3VsZCB0aGUgeHBhdGhzIGFsd2F5cyBiZSBpbiB0aGUg d2lsZGNhcmQgZm9ybWF0Ojxicj4mZ3Q7ICZxdW90Oyovbm90ZSZxdW90OyBldGMuLj88YnI+Jmd0 Ozxicj4mZ3Q7PGJyPiZndDsgdGhhbmtzCjxicj4mZ3Q7IE5vZ2E8YnI+Jmd0Ozxicj5BbGwgcGFy dGlhbCB1cGRhdGVzLCBpLmUuIHBhdGNoZXMgdXBkYXRlICZsdDtwcmVzZW5jZSZndDsgbm90ICZs dDtwaWRmLWZ1bGwmZ3Q7IHNvPGJyPnRoZSBzZWxlY3RvcnMgYWx3YXlzIHN0YXJ0IGVpdGhlciB3 aXRoICZxdW90O3ByZXNlbmNlJnF1b3Q7IG9yIHdpbGRjYXJkICZxdW90OyomcXVvdDsuIFNvPGJy PnRoZSBwcmVzZW5jZSBzZXJ2ZXIgd2lsbCBzdG9yZSAmbHQ7cGlkZi1mdWxsJmd0OyBjb250ZW50 IGFzIGlmICZsdDtwcmVzZW5jZSZndDsgd2VyZQo8YnI+cmVjZWl2ZWQuIFRoZSBwdWJsaXNoIHJl cXVlc3Qgd2lsbCBiZSByZWplY3RlZCB3aXRoIHRoaXMgbWltZSB0eXBlIGlmPGJyPnRoZSBzZXJ2 ZXIgZG9lc24ndCBzdXBwb3J0IHBhcnRpYWwgdXBkYXRlcy4gV2l0aCBub3RpZmllcyAmbHQ7cGlk Zi1mdWxsJmd0Ozxicj53aWxsIGNhcnJ5IHZlcnNpb24gbnVtYmVyIGluZm9ybWF0aW9uIChpbiBh ZGRpdGlvbiB0byBQSURGKSB0byBlbmFibGUKPGJyPnJlYXNvbmFibGUgc3luYyBmb3IgdGhlIGNs aWVudC48YnI+YnIsPGJyPkphcmk8YnI+PGJyPjxicj48YnI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+U2ltcGxlIG1haWxpbmcgbGlzdDxicj48YSBo cmVmPSJtYWlsdG86U2ltcGxlQGlldGYub3JnIj5TaW1wbGVAaWV0Zi5vcmc8L2E+PGJyPjxhIGhy ZWY9Imh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpbXBsZSI+Cmh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpbXBsZTwvYT48YnI+PC9ibG9ja3F1 b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+Cg== ------=_Part_2651_11757047.1147326416491-- --===============1219551570== 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 --===============1219551570==-- From simple-bounces@ietf.org Thu May 11 02:51:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe506-0003fo-1z; Thu, 11 May 2006 02:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe4zP-0003Zl-F6 for simple@ietf.org; Thu, 11 May 2006 02:49:35 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe4k7-0007Z8-0b for simple@ietf.org; Thu, 11 May 2006 02:33:48 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4B6XeE0029882; Thu, 11 May 2006 09:33:45 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 May 2006 09:33:44 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 May 2006 09:33:44 +0300 Received: from 172.21.34.145 ([172.21.34.145]) by esebe105.NOE.Nokia.com ([172.21.143.53]) with Microsoft Exchange Server HTTP-DAV ; Thu, 11 May 2006 06:33:44 +0000 Received: from hed034-145.research.nokia.com by esebe105.noe.nokia.com; 11 May 2006 09:33:44 +0300 Subject: Re: [Simple] PARTIAL PUBLISH - draft-ietf-simple-partial-publish-04.txt From: Jari Urpalainen To: ext Gadigeppa Malagund In-Reply-To: <60b4a2350605102246m5209c960t5181cde0561c78c8@mail.gmail.com> References: <44781c350605100216l8112f0dmb34cf08aff3d1934@mail.gmail.com> <1147262643.7479.2.camel@hed034-145.research.nokia.com> <60b4a2350605102246m5209c960t5181cde0561c78c8@mail.gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 11 May 2006 09:33:44 +0300 Message-Id: <1147329224.13413.22.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) X-OriginalArrivalTime: 11 May 2006 06:33:44.0493 (UTC) FILETIME=[D9E84DD0:01C674C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 On Thu, 2006-05-11 at 11:16 +0530, ext Gadigeppa Malagund wrote: > Hi, > > When presence server supports MIME application/pidf-diff+xml full > PUBLISH can be done either with or as root tag. right, but they are using different mime types. With application/pidf-diff+xml is disallowed. > Why should we use when server supports pidf-diff+xml which > is superset of pidf+xml? > Instead we can only use and . > > Regards, > Gadi > right, but not all servers will support partials. In principle would not have been needed at all if PIDF had been designed to be used with partial updates. Support for partials is thus easily negotiated with these different mime types. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu May 11 03:20:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe5Sz-0001hP-NA; Thu, 11 May 2006 03:20:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe5Sz-0001hH-7c for simple@ietf.org; Thu, 11 May 2006 03:20:09 -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 1Fe4Xt-00079S-OW for simple@ietf.org; Thu, 11 May 2006 02:21:09 -0400 Received: from ebb01.tietoenator.com ([193.12.180.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fe4Q2-0004zu-91 for simple@ietf.org; Thu, 11 May 2006 02:13:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] The difference between RLS and Presence subscriptions Date: Thu, 11 May 2006 08:12:30 +0200 Message-ID: <31721CD4D0090B4BA32CBA5E2C40AE90023676ED@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] The difference between RLS and Presence subscriptions Thread-Index: AcZ0u/lJD3B5xIgcTbuq6Lh524jS4QABL4tw From: To: , X-OriginalArrivalTime: 11 May 2006 06:13:00.0330 (UTC) FILETIME=[F45418A0:01C674C1] X-Spam-Score: -2.6 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: 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 ________________________________________ >From: Gadigeppa Malagund [mailto:gadigeppa@gmail.com]=20 >Sent: Thursday, May 11, 2006 7:23 AM >To: Noga Tor >Cc: simple@ietf.org >Subject: Re: [Simple] The difference between RLS and Presence subscriptions > >Hi, > >RLS subscription request has "Supported: eventlist" where as presence doesn't. > >Regards, >Gadi >On 5/10/06, Noga Tor wrote: >Hi=20 >=20 >I was wondering in what way you can tell if a certain subscription is a Presence Subcription or an RLS Subscription. >is there any indicator? is it done by the uri in the "TO: " header? and if so, in what way?=20 >=20 >Thanks >Noga Adam Roach has written here in simple@ietf.org something about it few weeks ago: -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Monday, April 24, 2006 7:16 PM To: Peknik Silvestr Cc: simple@ietf.org Subject: Re: [Simple] draft-ietf-simple-event-list: identifyinglist subscriptions Silvestr.Peknik@tietoenator.com wrote: > As mentioned in the draft, SIP URI does not indicate whether it belongs > to list of resources or to single resource. Can I assume that Supported: > eventlist header means that the subscription is a list subscription, or > can it happen that also subscription to single resource contains > Supported: eventlist? The "Supported: eventlist" header field in the request simply means that the client *understands* list subscriptions. It has no implication regarding whether the client expects the indicated resource to be a list or not. So, the statement is even stronger than you put it: it's not just that a subscription to a single resource *CAN* contain "Supported: eventlist" -- it's that it *MUST* contain "Supported: eventlist" if the subscriber understands the event list format. (I'm using this "must" as a "this is the only way, in my opinion, a reasonable implementation can behave," not as a standards statement. The specification would technically allow the client to pick and choose which subscriptions to indicate event list support -- but not indicating support for event lists would always make things work worse, and never better). > This differentiation is needed if the server > handles both subscriptions to list and subscriptions to single resources No, it's not. It *is* true that the server needs to know whether a subscription is to be treated as a list subscription or as a subscription to a single resource. This is exactly the same statement that a terminating MTA needs to know whether an email message is intended for a single account or for a mailing list. In both cases, the server knows this *independent* of what the client sends. The server knows whether it's a single resource or whether it's a list because it's *provisioned* to know which URIs (or email addresses) correspond to single resources and which URIs (or email addresses) correspond to lists. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu May 11 05:28:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe7Ru-0003Ys-5e; Thu, 11 May 2006 05:27:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZY15-00089Y-Pa for simple@ietf.org; Fri, 28 Apr 2006 14:48:35 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZY11-0003sX-Cr for simple@ietf.org; Fri, 28 Apr 2006 14:48:35 -0400 Received: from [127.0.0.1] (mail.songbird.com [208.184.79.10]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k3SImFLT030443; Fri, 28 Apr 2006 11:48:16 -0700 Message-ID: <44525AD4.1000700@ninebynine.org> Date: Fri, 28 Apr 2006 19:11:32 +0100 From: Graham Klyne User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Xiang Ting Subject: Re: [Simple]Can Message/CPIM be without MIME message-body References: <9d77d7060604280724j8ba0b60w42b18e30f9529c89@mail.gmail.com> In-Reply-To: <9d77d7060604280724j8ba0b60w42b18e30f9529c89@mail.gmail.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: gk@ninebynine.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-Mailman-Approved-At: Thu, 11 May 2006 05:27:08 -0400 Cc: Graham Klyne , Derek Atkins , simple@ietf.org, Derek Atkins 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 Xiang Ting wrote: > RFC 3862 describes CPIM message format as following: > [snip1] > A complete message looks something like this: > > m: Content-type: Message/CPIM > s: > h: (message-metadata-headers) > s: > e: (encapsulated MIME message-body) > [/snip1] > > [snip2] > 2.4. Message Content > > The final section of a Message/CPIM is the MIME-encapsulated message > content, which follows standard MIME formatting rules [1][2]. > > The MIME content headers MUST include at least a Content-Type header. > The content may be any MIME type. > [/snip2] > > In practice, I encountered a CPIM message without body. My parser > judged it as an invalid message format, but the opposers said that > there aren't specifications pointing out that CPIM MUST have a body. > I want to know whether the standard CPIM must have a encapsulated MIME > message body? > > Thanks in advance. This is not something I recall we considered explicitly. I would say the conformant way of generating a message would be to include the content-type header but leave the body empty. What is less clear to me is whether, in the spirit of "be liberal in what you accept", it would be good for a receiver to handle the case that no MIME body is present. Consider this question: can there ever be a significant difference between having an empty message body, and having no message body? In the former case, the content-type is specified; in the latter case, it is not. What message body content type would you when replying to a message? Same as the received message? I raise these points so you can see the situation is not without possible subtleties. If it came down to me to arbitrate on the basis of the current specification, I'd say that the MIME body must be present, but may be empty. (I don't think there's any statement that the MIME body part is optional.) However, I was just one of the editors - the design was a working group consensus activity, and I'd prefer this matter to be resolved by a similar consensus debate, if possible. #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu May 11 05:28:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe7Ru-0003Yy-Gs; Thu, 11 May 2006 05:27:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZZVd-0001Ph-37 for simple@ietf.org; Fri, 28 Apr 2006 16:24:13 -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 1FZZVd-0001b4-0z for simple@ietf.org; Fri, 28 Apr 2006 16:24:13 -0400 Received: from mail.ihtfp.org ([204.107.200.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FZZVW-0005yg-Rv for simple@ietf.org; Fri, 28 Apr 2006 16:24:12 -0400 Received: from cliodev.pgp.com (CLIODEV.IHTFP.ORG [204.107.200.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id 260C7BD8387; Fri, 28 Apr 2006 16:24:06 -0400 (EDT) Received: (from warlord@localhost) by cliodev.pgp.com (8.13.1/8.13.1/Submit) id k3SKO5vU001460; Fri, 28 Apr 2006 16:24:05 -0400 From: Derek Atkins To: Graham Klyne Subject: Re: [Simple]Can Message/CPIM be without MIME message-body References: <9d77d7060604280724j8ba0b60w42b18e30f9529c89@mail.gmail.com> <44525AD4.1000700@ninebynine.org> Date: Fri, 28 Apr 2006 16:24:05 -0400 In-Reply-To: <44525AD4.1000700@ninebynine.org> (Graham Klyne's message of "Fri, 28 Apr 2006 19:11:32 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.6 (--) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-Mailman-Approved-At: Thu, 11 May 2006 05:27:08 -0400 Cc: Graham Klyne , Derek Atkins , 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 Hi, Graham Klyne writes: > Xiang Ting wrote: >> RFC 3862 describes CPIM message format as following: >> [snip1] >> A complete message looks something like this: >> >> m: Content-type: Message/CPIM >> s: >> h: (message-metadata-headers) >> s: >> e: (encapsulated MIME message-body) >> [/snip1] >> >> [snip2] >> 2.4. Message Content >> >> The final section of a Message/CPIM is the MIME-encapsulated message >> content, which follows standard MIME formatting rules [1][2]. >> >> The MIME content headers MUST include at least a Content-Type header. >> The content may be any MIME type. >> [/snip2] >> >> In practice, I encountered a CPIM message without body. My parser >> judged it as an invalid message format, but the opposers said that >> there aren't specifications pointing out that CPIM MUST have a body. >> I want to know whether the standard CPIM must have a encapsulated MIME >> message body? >> >> Thanks in advance. > > This is not something I recall we considered explicitly. I would say the > conformant way of generating a message would be to include the content-type > header but leave the body empty. > > What is less clear to me is whether, in the spirit of "be liberal in what you > accept", it would be good for a receiver to handle the case that no MIME body is > present. Consider this question: can there ever be a significant difference > between having an empty message body, and having no message body? In the former > case, the content-type is specified; in the latter case, it is not. What > message body content type would you when replying to a message? Same as the > received message? I raise these points so you can see the situation is not > without possible subtleties. > > If it came down to me to arbitrate on the basis of the current specification, > I'd say that the MIME body must be present, but may be empty. (I don't think > there's any statement that the MIME body part is optional.) However, I was just > one of the editors - the design was a working group consensus activity, and I'd > prefer this matter to be resolved by a similar consensus debate, if possible. > > #g I'm not sure why you'd ever want a CPIM message without a body. I agree with Graham here. My personal feeling is that it makes no sense to have CPIM without a body (but an empty body is okay). But if we really need a clarification we're probably going to need to ask the ADs because the IMPP working group shut down. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri May 12 03:45:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeSKt-0000iN-IH; Fri, 12 May 2006 03:45:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeSKt-0000iI-1c for simple@ietf.org; Fri, 12 May 2006 03:45:19 -0400 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeSKr-0002Pm-OL for simple@ietf.org; Fri, 12 May 2006 03:45:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 May 2006 09:43:25 +0200 Message-ID: <3ACC9A25264A684F82C71840111F9798018D681F@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New element in simple-presence-rules-05 draft Thread-Index: AcZ1l8B76LsoWG3fRLi0BWo1gCpisQ== From: To: X-OriginalArrivalTime: 12 May 2006 07:45:06.0081 (UTC) FILETIME=[FC588910:01C67597] X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Simple] New element in simple-presence-rules-05 draft 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 found new element in the presence rules draft, but there is no description for it. What is the actual purpose of that? BR, Martin Martin Hynar Software Specialist TietoEnator Czech Software Center Phone: +420 599 096 022 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 From simple-bounces@ietf.org Fri May 12 07:01:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeVNe-0001dE-Pt; Fri, 12 May 2006 07:00:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeVNc-0001WT-TU for simple@ietf.org; Fri, 12 May 2006 07:00:20 -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 1FeVNc-0003gE-S2 for simple@ietf.org; Fri, 12 May 2006 07:00:20 -0400 Received: from ebb01.tietoenator.com ([193.12.180.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FeV9W-00048m-RG for simple@ietf.org; Fri, 12 May 2006 06:45:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 May 2006 12:44:53 +0200 Message-ID: <3ACC9A25264A684F82C71840111F9798018D69BE@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bug in draft-ietf-simple-partial-publish-04 Thread-Index: AcZ1sRo9Xwu7onIBSvGVWXwLF93ZaA== From: To: X-OriginalArrivalTime: 12 May 2006 10:44:56.0043 (UTC) FILETIME=[1BAA13B0:01C675B1] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: simple@ietf.org Subject: [Simple] Bug in draft-ietf-simple-partial-publish-04 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 Hi, there is typist error in new draft-ietf-simple-partial-publish-04 draft. In chapter 4.3.2 there is in the first bullet mentioned If-Match header. While in example in chapter 6 in flow M3 from PUA to Compositor there is used SIP-If-Match. The later alternative should be the correct one, as it is SIP traffic. br, Martin Hynar Martin Hynar Software Specialist TietoEnator Czech Software Center Phone: +420 599 096 022 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 From simple-bounces@ietf.org Fri May 12 09:10:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeXP0-0003au-1s; Fri, 12 May 2006 09:09:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeXOz-0003ap-8P for simple@ietf.org; Fri, 12 May 2006 09:09:53 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeXOx-0002bR-25 for simple@ietf.org; Fri, 12 May 2006 09:09:53 -0400 Received: by py-out-1112.google.com with SMTP id e30so539277pya for ; Fri, 12 May 2006 06:09:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Kvs0Px/yBR529NKIU1kOXqZbe29n7+eIkqubl7kxOHZ27SwjtHuINf/9YH+LwsNIjf8g3wkahWSoWvTgMYIdY0bsNpw9ip/4Jxe2GFJKuvtvX7R3B7raAsZl2o/6k5QAcMOKr9mtXu/qH8qOMDjUVhCtnu3pyRgH44v6sQp6C8k= Received: by 10.35.91.10 with SMTP id t10mr2321180pyl; Fri, 12 May 2006 06:09:50 -0700 (PDT) Received: by 10.35.83.12 with HTTP; Fri, 12 May 2006 06:09:50 -0700 (PDT) Message-ID: <7759a74d0605120609y4390fc53kfd717b7321e233e8@mail.gmail.com> Date: Fri, 12 May 2006 18:39:50 +0530 From: "Aniruddha Vaidya" To: simple@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Simple] How to publish authorization policies on XCAP server 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="===============0106230556==" Errors-To: simple-bounces@ietf.org --===============0106230556== Content-Type: multipart/alternative; boundary="----=_Part_10081_19005722.1147439390753" ------=_Part_10081_19005722.1147439390753 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, I'm not clear about how to store the authorization rules on XCAP server. Who will store the rules on the server ? Is it the user agent ? Thanks in advance Aniruddha ------=_Part_10081_19005722.1147439390753 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello,

I'm not clear about how to store the authorization rules on X= CAP server.
Who will store the rules on the server ?
Is it the user a= gent ?

Thanks in advance
Aniruddha


------=_Part_10081_19005722.1147439390753-- --===============0106230556== 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 --===============0106230556==-- From simple-bounces@ietf.org Fri May 12 12:49:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Feaou-0001Bl-N3; Fri, 12 May 2006 12:48:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Feaot-0001Bg-QI for Simple@ietf.org; Fri, 12 May 2006 12:48:51 -0400 Received: from nz-out-0102.google.com ([64.233.162.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Feaoq-000642-Ju for Simple@ietf.org; Fri, 12 May 2006 12:48:51 -0400 Received: by nz-out-0102.google.com with SMTP id i11so213254nzi for ; Fri, 12 May 2006 09:48:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=MWd4qT2rlydqqU5cFOZ+qycHI743F0rG2zj0uuEXHmsNALb3r1vRcQ/EhzJmb2hvWkewKXs980LH0nqphTKro08/Jb0FFhDSjZbYQeZpH5X9neUbjnpUmh7LJzz8G6w5tDLY4fkwvNLpChKkk2iLPt/wRSWZU4cTWnDyKJeESuc= Received: by 10.64.151.20 with SMTP id y20mr1766599qbd; Fri, 12 May 2006 09:48:44 -0700 (PDT) Received: by 10.65.132.9 with HTTP; Fri, 12 May 2006 09:48:44 -0700 (PDT) Message-ID: Date: Fri, 12 May 2006 17:48:44 +0100 From: "Eduardo Martins" To: Simple@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Subject: [Simple] SIMPLE reference client 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 Hi, I'm having trouble to find SIMPLE clients, can someone recommend one that is compliant with the standards and drafts ? Thanks Eduardo Martins _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon May 15 06:08:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfZyF-0003lk-24; Mon, 15 May 2006 06:06:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfZyE-0003kc-Fe for simple@ietf.org; Mon, 15 May 2006 06:06:34 -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 1FfYIq-0005FC-8O for simple@ietf.org; Mon, 15 May 2006 04:19:44 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FfXqx-0003ux-5O for simple@ietf.org; Mon, 15 May 2006 03:51:02 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4F7ols2004986; Mon, 15 May 2006 10:50:49 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 May 2006 10:50:48 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 May 2006 10:50:48 +0300 Received: from 172.21.34.145 ([172.21.34.145]) by esebe105.NOE.Nokia.com ([172.21.143.53]) with Microsoft Exchange Server HTTP-DAV ; Mon, 15 May 2006 07:50:47 +0000 Received: from hed034-145.research.nokia.com by esebe105.noe.nokia.com; 15 May 2006 10:50:47 +0300 From: Jari Urpalainen To: ext Jonathan Rosenberg Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 15 May 2006 10:50:47 +0300 Message-Id: <1147679447.28012.15.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) X-OriginalArrivalTime: 15 May 2006 07:50:48.0381 (UTC) FILETIME=[479C9ED0:01C677F4] X-Spam-Score: -0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: "'simple@ietf.org' WG" Subject: [Simple] Presence rules 05 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 Hi Jonathan! Some xml nits: Example in 5: -leftover from previous common policy, i.e. identity should probably be: -remove xmlns:xsi and xsi:schemaLocation declarations -id of is of type , so the value cannot start with a number Schema in 6: - extension is probably more reasonable with processContents="lax" definition as strict is the default. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon May 15 06:27:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfaIT-0000fw-QU; Mon, 15 May 2006 06:27:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfaIT-0000fp-1Y for simple@ietf.org; Mon, 15 May 2006 06:27:29 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfaIS-0002r3-JE for simple@ietf.org; Mon, 15 May 2006 06:27:29 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4FAR9EG029623; Mon, 15 May 2006 13:27:11 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 May 2006 13:27:10 +0300 Received: from [127.0.0.1] ([172.21.35.76]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 15 May 2006 13:27:09 +0300 Message-ID: <4468577C.109@nokia.com> Date: Mon, 15 May 2006 13:27:08 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "'simple@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 May 2006 10:27:09.0824 (UTC) FILETIME=[1F633800:01C6780A] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Cullen Jennings , "Amitkumar.Goel@infineon.com" , Rohan Mahy Subject: [Simple] MSRP: direction attributes 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 Hi: I think this issue was discussed, but never concluded, perhaps because we didn't copy the MSRP authors in the e-mail discussion. Amit has been arguing that the MSRP I-D does not discuss the interaction of the SDP direction attributes with MSRP. To be more specific of the problem description, assume I have an SDP offer for an MSRP unidirectional session, so I would include the a=sendonly (if I want to send) attribute. Now, I believe the direction attribute affects MSRP SEND request. Specifically, it shouldn't affect the generation of REPORT requests from the other party, as REPORT requests are kind-of control protocol. Further more... the direction attribute shouldn't affect IMDN responses, which will be generated also with SEND requests. As a counter party, I reproduce here what SDP-new says about this direction attributes and their relation to RTP and RTCP. I think we need to extrapolate the same ideas to MSRP: Note that recvonly applies to the media only, not to any associated control protocol (e.g. an RTP based system in recvonly mode SHOULD still send RTCP packets). and later: Note that sendonly applies only to the media, and any associated control protocol (e.g. RTCP) SHOULD still be received and processed as normal. So, since the MSRP draft is silent about this relation of the SDP direction attributes, I think there should be an explicit mention of how to deal with. I can proposed to add the following text to the draft: ------ 8.9 SDP direction attribute and MSRP SDP defines a number of attributes that modify the direction of media flows. These are the "sendonly", "recvonly", "inactive", and "sendrecv" attributes. If a "sendonly" or "recvonly" attribute modifies an MSRP media description line, the attribute indicates the direction of MSRP SEND requests that contain regular payload. Unless otherwise specified, these attributes do not affect the direction of other requests, such as REPORT, or SEND requests that contain some kind of control protocol (e.g., IMDN reports), which should be generated according to the protocol rules as if no direction attribute were present. --- Is this acceptable? If so, please include this text in the draft and proceed with it as soon as possible. BR, Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 16 02:04:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfseU-0005E1-Bw; Tue, 16 May 2006 02:03:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfseS-0005Dg-7n for simple@ietf.org; Tue, 16 May 2006 02:03:24 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfseQ-00013Q-VX for simple@ietf.org; Tue, 16 May 2006 02:03:24 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 16 May 2006 02:03:23 -0400 X-IronPort-AV: i="4.05,132,1146456000"; d="scan'208"; a="88641265:sNHT30069232" 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 k4G63MTL010800; Tue, 16 May 2006 02:03:22 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 02:03:22 -0400 Received: from [192.168.128.160] ([10.82.225.105]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 02:03:21 -0400 Message-ID: <446923FE.6040106@cisco.com> Date: Mon, 15 May 2006 20:59:42 -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: Aniruddha Vaidya Subject: Re: [Simple] How to publish authorization policies on XCAP server References: <7759a74d0605120609y4390fc53kfd717b7321e233e8@mail.gmail.com> In-Reply-To: <7759a74d0605120609y4390fc53kfd717b7321e233e8@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 06:03:22.0049 (UTC) FILETIME=[6FB62B10:01C678AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Typically, yes. The client would create a rules document and place it on the server. -Jonathan R. Aniruddha Vaidya wrote: > Hello, > > I'm not clear about how to store the authorization rules on XCAP server. > Who will store the rules on the server ? > Is it the user agent ? > > Thanks in advance > Aniruddha > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 May 16 02:04:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfseO-00058s-NG; Tue, 16 May 2006 02:03:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfseN-00058i-49 for simple@ietf.org; Tue, 16 May 2006 02:03:19 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org wiFrom simple-bounces@ietf.org Tue May 16 02:04:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfseU-0005E1-Bw; Tue, 16 May 2006 02:03:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfseS-0005Dg-7n for simple@ietf.org; Tue, 16 May 2006 02:03:24 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfseQ-00013Q-VX for simple@ietf.org; Tue, 16 May 2006 02:03:24 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 16 May 2006 02:03:23 -0400 X-IronPort-AV: i="4.05,132,1146456000"; d="scan'208"; a="88641265:sNHT30069232" 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 k4G63MTL010800; Tue, 16 May 2006 02:03:22 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 02:03:22 -0400 Received: from [192.168.128.160] ([10.82.225.105]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 02:03:21 -0400 Message-ID: <446923FE.6040106@cisco.com> Date: Mon, 15 May 2006 20:59:42 -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: Aniruddha Vaidya Subject: Re: [Simple] How to publish authorization policies on XCAP server References: <7759a74d0605120609y4390fc53kfd717b7321e233e8@mail.gmail.com> In-Reply-To: <7759a74d0605120609y4390fc53kfd717b7321e233e8@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 06:03:22.0049 (UTC) FILETIME=[6FB62B10:01C678AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Typically, yes. The client would create a rules document and place it on the server. -Jonathan R. Aniruddha Vaidya wrote: > Hello, > > I'm not clear about how to store the authorization rules on XCAP server. > Who will store the rules on the server ? > Is it the user agent ? > > Thanks in advance > Aniruddha > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 May 16 02:04:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfseO-00058s-NG; Tue, 16 May 2006 02:03:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfseN-00058i-49 for simple@ietf.org; Tue, 16 May 2006 02:03:19 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfseJ-00013E-Q4 for simple@ietf.org; Tue, 16 May 2006 02:03:19 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 May 2006 23:03:15 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,132,1146466800"; d="scan'208"; a="28102429:sNHT23528320" 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 k4G63DTL010784; Tue, 16 May 2006 02:03: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.211); Tue, 16 May 2006 02:03:12 -0400 Received: from [192.168.128.160] ([10.82.225.105]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 02:03:12 -0400 Message-ID: <446922BC.7080900@cisco.com> Date: Mon, 15 May 2006 20:54:20 -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: "Thomson, Martin" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 06:03:12.0487 (UTC) FILETIME=[6A031F70:01C678AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: simple@ietf.org Subject: [Simple] Re: Presence rules and polite-block 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 Thomson, Martin wrote: > Reading through the simple-presence-rules draft [1], I note that the > "polite-block" value for the element seems a little > out of place. I understand that this may be in line with existing > implementations, but I think that, semantically, the "polite-block" > is a better logical fit for the section. We have discussed this, in fact. The complication is that 'polite-block' isn't the same as any of the other transformations at all. The problem is that the model in presence-rules is that you have some 'raw' presence document with all of the data in it. The transformations that get applied to the document all determine which information in the document can be revealed to watchers. Polite block isn't removing information at all. Instead, its suggesting that the presence server make up some kind of fake presence document and then send that to the watcher. We found it difficult to represent this as a transformation in the same way the others are represented. As a consequence of this different, the other transformations defined in presence-rules don't make sense in conjunction with polite-block. This dependence required us to move polite-block to an action. > > The difference between the "polite-block" and "allow" values are only > in the way that the final document is constructed. They both affect > the state machine in the same way - in the description you use > "polite-block" or "allow" in the same way. They affect the watcher state machine in the same way, but not the other aspects of presence server behavior. > > Recommendation by pseudo-example: > > > block|confirm|allow > > > The Date: Mon, 15 May 2006 20:54:20 -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: "Thomson, Martin" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 06:03:12.0487 (UTC) FILETIME=[6A031F70:01C678AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: simple@ietf.org Subject: [Simple] Re: Presence rules and polite-block 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 Thomson, Martin wrote: > Reading through the simple-presence-rules draft [1], I note that the > "polite-block" value for the element seems a little > out of place. I understand that this may be in line with existing > implementations, but I think that, semantically, the "polite-block" > is a better logical fit for the section. We have discussed this, in fact. The complication is that 'polite-block' isn't the same as any of the other transformations at all. The problem is that the model in presence-rules is that you have some 'raw' presence document with all of the data in it. The transformations that get applied to the document all determine which information in the document can be revealed to watchers. Polite block isn't removing information at all. Instead, its suggesting that the presence server make up some kind of fake presence document and then send that to the watcher. We found it difficult to represent this as a transformation in the same way the others are represented. As a consequence of this different, the other transformations defined in presence-rules don't make sense in conjunction with polite-block. This dependence required us to move polite-block to an action. > > The difference between the "polite-block" and "allow" values are only > in the way that the final document is constructed. They both affect > the state machine in the same way - in the description you use > "polite-block" or "allow" in the same way. They affect the watcher state machine in the same way, but not the other aspects of presence server behavior. > > Recommendation by pseudo-example: > > > block|confirm|allow > > > The element would have to override all other > transformations. Since the effective difference between > "polite-block" and "allow" is seen later in the processing stage, > this will probably clean code. The fact that it 'overrides' everything else is a sure sign that this doesn't work. A criteria for something being its own permission (as discussed in common-policy) is that it is orthogonal to other things. > > > An unrelated suggestion: In section 4, I had to read it twice to get > the implication that F(D) was a noop. Perhaps you could clarify this > by using something more explicit: Dn = F(Do), Dn = F(F(Do)), Dn = > F(Dn) {where Dn = notification document, Do = original document} I'm not sure further mathematical notation would clarify this. Instead I just added some text that states explicitly that its a no-op: In other words, further applications of the privacy filtering operation would not result in any further changes of the document, making further application of the filtering operation a no-op. > > Nit: Page 11, first line: s/four/three/ fixed. Thanks for your comments, 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 k> element would have to override all other > transformations. Since the effective difference between > "polite-block" and "allow" is seen later in the processing stage, > this will probably clean code. The fact that it 'overrides' everything else is a sure sign that this doesn't work. A criteria for something being its own permission (as discussed in common-policy) is that it is orthogonal to other things. > > > An unrelated suggestion: In section 4, I had to read it twice to get > the implication that F(D) was a noop. Perhaps you could clarify this > by using something more explicit: Dn = F(Do), Dn = F(F(Do)), Dn = > F(Dn) {where Dn = notification document, Do = original document} I'm not sure further mathematical notation would clarify this. Instead I just added some text that states explicitly that its a no-op: In other words, further applications of the privacy filtering operation would not result in any further changes of the document, making further application of the filtering operation a no-op. > > Nit: Page 11, first line: s/four/three/ fixed. Thanks for your comments, 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 May 16 02:04:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffseb-0005FU-N8; Tue, 16 May 2006 02:03:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffsea-0005F0-3V for simple@ietf.org; Tue, 16 May 2006 02:03:32 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfseZ-00013Q-Qj for simple@ietf.org; Tue, 16 May 2006 02:03:32 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 16 May 2006 02:03:32 -0400 X-IronPort-AV: i="4.05,132,1146456000"; d="scan'208"; a="88641274:sNHT30371428" 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 k4G63VvF003885; Tue, 16 May 2006 02:03:31 -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.211); Tue, 16 May 2006 02:03:31 -0400 Received: from [192.168.128.160] ([10.82.225.105]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 02:03:31 -0400 Message-ID: <4469371E.2020301@cisco.com> Date: Mon, 15 May 2006 22:21:18 -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: Arjun Roychowdhury Subject: Re: [Simple] updated presence-rules draft References: <440FBC93.5050700@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 06:03:31.0221 (UTC) FILETIME=[752DB450:01C678AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 I started to type this response a month back but never finished it. Apologies for the delay in responding. inline. Arjun Roychowdhury wrote: > The part of this authorization I-D is very useful for > authorization of 'any state sharing' - not just presence. > > My question, therefore, is that should the common-policy draft include, > at the least, some of the clauses in its schema > definition instead of leaving it open for others to extend ? Or, the > presence-authorization draft makes its scope more general by saying the > draft applies to a wide variety of state sharing, not limited to > presence authorization. This is a good question. The specification was meant to address presence specifically, and not be a generic package-independent authorization document. Sub-handling is pretty much the only thing that might be shared across packages; almost everything else in the spec is specific to presence. As such, an authorization policy spec for another package will need more than sub-handling. I'll also note that subscription handling authorization for other packages varies; in some packages, they aren't authorized by the subscriber at all; rather, authorization is almost an algorithmic function of the subscriber. For example, with the watcherinfo event package, its usually just the subscriber themselves. Consequently, I think the document should stay focused on its current scope - providing authorization for presence. Thanks, 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 May 16 02:04:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfseW-0005ES-PY; Tue, 16 May 2006 02:03:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfseV-0005EN-Ms for simple@ietf.org; Tue, 16 May 2006 02:03:27 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfseU-00013Q-CH for simple@ietf.org; Tue, 16 May 2006 02:03:27 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 16 May 2006 02:03:26 -0400 X-IronPort-AV: i="4.05,132,1146456000"; d="scan'208"; a="88641268:sNHT30398248" 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 k4G63PTL010807; Tue, 16 May 2006 02:03:26 -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.211); Tue, 16 May 2006 02:03:25 -0400 Received: from [192.168.128.160] ([10.82.225.105]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 02:03:24 -0400 Message-ID: <44693483.7000002@cisco.com> Date: Mon, 15 May 2006 22:10: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: Martin.Hynar@tietoenator.com Subject: Re: [Simple] New element in simple-presence-rules-05 draft References: <3ACC9A25264A684F82C71840111F9798018D681F@carrera.eu.tieto.com> In-Reply-To: <3ACC9A25264A684F82C71840111F9798018D681F@carrera.eu.tieto.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 06:03:25.0257 (UTC) FILETIME=[719FAB90:01C678AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 Wow. I must say, this is scary. It took me a bunch of digging to figure out what this was, since I didn't recognize it either. This was a feature in the -02 draft that allowed you to specify whether the contact and device-id elements should be obfuscated. However, the feature was removed in -03, but somehow the schema definition was never updated to remove it. Thus, its not a new element at all, but rather an old one that somehow never got garbage collected. I'm mystified because I could have SWORN that, for -05, I went over the schema with a fine tooth comb to make sure it matched up with the text descriptions and RPID. Don't know how I missed it. Anyway, it is now most assuredly removed from the schema definition. Thanks, Jonathan R. Martin.Hynar@tietoenator.com wrote: > Hello, > > I found new element in the presence rules draft, but > there is no description for it. What is the actual purpose of that? > > > BR, Martin > > > Martin Hynar > Software Specialist > > TietoEnator > Czech Software Center > Phone: +420 599 096 022 > 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 > -- 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 May 16 02:04:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffseb-0005F8-9M; Tue, 16 May 2006 02:03:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfseZ-0005Ev-KF for simple@ietf.org; Tue, 16 May 2006 02:03:31 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfseX-00013Q-BH for simple@ietf.org; Tue, 16 May 2006 02:03:31 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 16 May 2006 02:03:29 -0400 X-IronPort-AV: i="4.05,132,1146456000"; d="scan'208"; a="88641272:sNHT31312428" 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 k4G63STL010813; Tue, 16 May 2006 02:03:29 -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.211); Tue, 16 May 2006 02:03:28 -0400 Received: from [192.168.128.160] ([10.82.225.105]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 02:03:28 -0400 Message-ID: <446935EE.8030301@cisco.com> Date: Mon, 15 May 2006 22:16:14 -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: Richard Barnes Subject: Re: [Simple] WGLC: Presence Authorization Rules References: <3076ead17284fbacde9fa8103b9b8201@telio.no> <4458B472.2060305@bbn.com> In-Reply-To: <4458B472.2060305@bbn.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 06:03:28.0268 (UTC) FILETIME=[736B1CC0:01C678AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: "'simple@ietf.org' 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 Thanks for the comments. Replies inline. Richard Barnes wrote: > Couple of minor corrections, mostly typographical: > > 1. In section 3 (page 4), it says "As described in [12], this document > is composed of three parts - conditions, actions, and transformations. > Each action or transformation ... has the property of being a positive > grant of information to the watcher." This is technically incorrect, > since the conditions, actions, and transformations are contained in > rules, which make up the document. Propose changing to "As described in > [12], this document contains rules composed of three parts - conditions, > actions, and transformations. Each rule containing either the 'allow' > action or the 'confirm' action, which is also called a permission, has > the property of being a positive grant of information to the watcher." You are correct on the first count that the document is actually composed of rules, each of which has conditions, actions and transformations. I've made your suggested change there. However, the second part of your suggestion seems to imply that only allow or confirm are positive grants of information to the watcher. This is not true. Each permission - where a permission is an action or transformation - is a positive grant of information. > > 2. In section 5 (page 18), the element "" is > indented too far. fixed. > > 3. In section 8.7 (page 22), it seemse like there is an extra space in > the provided URI template: Instead of "http://[xcap root]/ > pres-rules/users/foo", should be "http://[xcap root]/pres-rules/users/foo" good catch - fixed. Thanks, 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 May 16 10:38:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0gl-00086H-KV; Tue, 16 May 2006 10:38:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0gk-000867-4X for Simple@ietf.org; Tue, 16 May 2006 10:38:18 -0400 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg0gi-0001G6-Un for Simple@ietf.org; Tue, 16 May 2006 10:38:18 -0400 Received: by py-out-1112.google.com with SMTP id e30so1390672pya for ; Tue, 16 May 2006 07:38:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=jUf3XCnqTz2H81fFv+LVz6/y8oa0aRlzGFUPvgkFx1/kw0T6Ov5JmXNQLwa9DgN+ndZRl5kLdleASGtafPQIs0XMDPcaXnel0HL28VvZO2xuahBNj35gzddu0t25R7BbGrnisML23bKrNO2WF0UYcsRbF6gdwx74L/8IeDqkFzw= Received: by 10.35.77.18 with SMTP id e18mr3538049pyl; Tue, 16 May 2006 07:38:13 -0700 (PDT) Received: by 10.35.54.16 with HTTP; Tue, 16 May 2006 07:38:13 -0700 (PDT) Message-ID: <52db68bc0605160738u41c703f8l20529f7ca3a8ec7d@mail.gmail.com> Date: Tue, 16 May 2006 20:08:13 +0530 From: Sudhir To: Simple@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [Simple] Query in Publish 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: , Content-Type: multipart/mixed; boundary="===============0668424461==" Errors-To: simple-bounces@ietf.org --===============0668424461== Content-Type: multipart/alternative; boundary="----=_Part_76622_28329003.1147790293422" ------=_Part_76622_28329003.1147790293422 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi All, what is the importance of having SIP-If-match header and entiy tags in PUBLISH request and response. Any response is appericated thanks in advance Sudhir ------=_Part_76622_28329003.1147790293422 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi All,
 
what is the importance of having SIP-If-match header and entiy tags in= PUBLISH request and response.
 
Any response is appericated
 
thanks in advance
Sudhir
 
 
------=_Part_76622_28329003.1147790293422-- --===============0668424461== 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 --===============0668424461==-- From simple-bounces@ietf.org Tue May 16 10:55:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0xT-0004iJ-8o; Tue, 16 May 2006 10:55:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0xR-0004iE-9v for simple@ietf.org; Tue, 16 May 2006 10:55:33 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg0xO-0002QN-UL for simple@ietf.org; Tue, 16 May 2006 10:55:33 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 16 May 2006 07:55:30 -0700 X-IronPort-AV: i="4.05,134,1146466800"; d="scan'208"; a="1807107905:sNHT32890840" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k4GEtUrW011357; Tue, 16 May 2006 07:55:30 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4GEtTsJ008918; Tue, 16 May 2006 07:55:30 -0700 (PDT) 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.211); Tue, 16 May 2006 10:55:29 -0400 Received: from [192.168.128.160] ([10.82.225.105]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 10:55:28 -0400 Message-ID: <4469E7E0.1030201@cisco.com> Date: Tue, 16 May 2006 10:55:28 -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 References: <1147679447.28012.15.camel@hed034-145.research.nokia.com> In-Reply-To: <1147679447.28012.15.camel@hed034-145.research.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 14:55:29.0079 (UTC) FILETIME=[C5B45470:01C678F8] DKIM-Signature: a=rsa-sha1; q=dns; l=1005; t=1147791330; x=1148655330; c=relaxed/simple; s=sjdkim8001; 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=20Presence=20rules=2005; X=v=3Dcisco.com=3B=20h=3DOp6BLkwPVSQq3WGS/QiGibfIeYQ=3D; b=HYIYcqqcDSxfk6tDwmxEjllDSoz6Wi4BU9IB7xtTdfh5yxbmwO2oCGY2hyXf5xIyWfC8pGMj GwLS/YtOlf6KvAOcKw20nrVpguTH42kavJw0mzr5Frprp+PBnfaBN/1E; Authentication-Results: sj-dkim-8.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "'simple@ietf.org' WG" Subject: [Simple] Re: Presence rules 05 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 Jari Urpalainen wrote: > Hi Jonathan! > > Some xml nits: > > Example in 5: > -leftover from previous common policy, i.e. identity should probably > be: > good catch. Fixed. For some reason XML spy still said this example was valid even with the updated schema. > -remove xmlns:xsi and xsi:schemaLocation declarations ok. > -id of is of type , so the value cannot start with a > number fixed. > > Schema in 6: > - extension is probably more reasonable with > processContents="lax" definition as strict is the default. fixed. Thanks for the comments as always, 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 May 16 11:07:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg18w-0007va-Do; Tue, 16 May 2006 11:07:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg18u-0007vV-Mp for simple@ietf.org; Tue, 16 May 2006 11:07:24 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg18s-00033L-Au for simple@ietf.org; Tue, 16 May 2006 11:07:24 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 16 May 2006 08:07:21 -0700 X-IronPort-AV: i="4.05,134,1146466800"; d="scan'208"; a="277590013:sNHT155818324" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k4GF7LAk002829 for ; Tue, 16 May 2006 08:07:21 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4GF7IsP014516 for ; Tue, 16 May 2006 08:07:21 -0700 (PDT) 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.211); Tue, 16 May 2006 11:07:15 -0400 Received: from [192.168.128.160] ([10.82.225.105]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 11:07:14 -0400 Message-ID: <4469EAA2.4040907@cisco.com> Date: Tue, 16 May 2006 11:07:14 -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: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 15:07:15.0157 (UTC) FILETIME=[6A8F4850:01C678FA] DKIM-Signature: a=rsa-sha1; q=dns; l=588; t=1147792041; x=1148656041; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:updated=20presence-rules=20draft; X=v=3Dcisco.com=3B=20h=3DUFZ3pWIATlzjxmLtVBRxD0X7PUs=3D; b=a+V7buddbZWGCz83j6BPjI6wx72RJvpfAz0zYIfascFfuNRKk9pSx0JUp/8q0/uAyNogXOtj mQWLU7A7p644CC8SztGeu5NYBTTqfJrDIkviyR6DeOks7AanF5Ma/UC4; Authentication-Results: sj-dkim-5.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Simple] updated presence-rules draft 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 Folks, I've submitted an update to the presence-rules draft based on comments received during WGLC. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-simple-presence-rules-06.txt Thanks, 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 May 16 16:28:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg68X-0004I3-Gn; Tue, 16 May 2006 16:27:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg68W-0004Ht-AF for simple@ietf.org; Tue, 16 May 2006 16:27:20 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg68V-0004t0-Hb for simple@ietf.org; Tue, 16 May 2006 16:27:20 -0400 Received: from [10.10.108.88] ([65.119.52.228]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k4GKQnr5001645 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 16 May 2006 15:26:57 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <4468577C.109@nokia.com> References: <4468577C.109@nokia.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Date: Tue, 16 May 2006 15:26:42 -0500 To: Miguel Garcia X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Cullen Jennings , Rohan Mahy , "'simple@ietf.org'" , "Amitkumar.Goel@infineon.com" Subject: [Simple] Re: MSRP: direction attributes 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 agree in general with your opinion about how a=sendonly should work in MSRP. My only concern about putting the language in the MSRP draft is that draft has already been submitted to the IESG. Assuming they don't ask for a rewrite, that leaves the option of adding it in the auth 48 period, or creating a separate draft. I think this change is borderline for being appropriate for an auth 48 change. (Certainly, we've seen much more substantive auth48 changes before :-) ) Perhaps the chairs will comment? Comment on the proposed language inline: On May 15, 2006, at 5:27 AM, Miguel Garcia wrote: > Hi: > > I think this issue was discussed, but never concluded, perhaps > because we didn't copy the MSRP authors in the e-mail discussion. > > Amit has been arguing that the MSRP I-D does not discuss the > interaction of the SDP direction attributes with MSRP. To be more > specific of the problem description, assume I have an SDP offer for > an MSRP unidirectional session, so I would include the a=sendonly > (if I want to send) attribute. > > Now, I believe the direction attribute affects MSRP SEND request. > Specifically, it shouldn't affect the generation of REPORT requests > from the other party, as REPORT requests are kind-of control protocol. > > Further more... the direction attribute shouldn't affect IMDN > responses, which will be generated also with SEND requests. > > As a counter party, I reproduce here what SDP-new says about this > direction attributes and their relation to RTP and RTCP. I think we > need to extrapolate the same ideas to MSRP: > > Note that recvonly > applies to the media only, not to any associated control > protocol (e.g. an RTP based system in recvonly mode SHOULD > still send RTCP packets). > > and later: > > Note that sendonly > applies only to the media, and any associated control > protocol > (e.g. RTCP) SHOULD still be received and processed as > normal. > > > So, since the MSRP draft is silent about this relation of the SDP > direction attributes, I think there should be an explicit mention > of how to deal with. I can proposed to add the following text to > the draft: > > > ------ > 8.9 SDP direction attribute and MSRP > > SDP defines a number of attributes that modify the direction of > media flows. These are the "sendonly", "recvonly", "inactive", and > "sendrecv" attributes. > > If a "sendonly" or "recvonly" attribute modifies an MSRP media > description line, the attribute indicates the direction of MSRP > SEND requests that contain regular payload. Unless otherwise > specified, these attributes do not affect the direction of other > requests, such as REPORT, or SEND requests that contain some kind > of control protocol (e.g., IMDN reports), which should be generated > according to the protocol rules as if no direction attribute were > present. > --- > I agree with everything except the "or Send requests that contain some kind of control protocol..." part. I'm not sure we can generalize that all such content should ignore a sendonly attribute. It would be better to leave that up to the specification for the particular control protocol. It might make sense for IMDN, but if someone were to define the "mind control protocol for MSRP", for example, I'm not sure that overriding "sendonly" would make sense. > > Is this acceptable? If so, please include this text in the draft > and proceed with it as soon as possible. > > BR, > > Miguel > > -- > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.an.garcia@openlaboratory.net > Nokia Research Center Helsinki, Finland > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 16 16:43:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg6Nh-0003qc-Gb; Tue, 16 May 2006 16:43:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg6Ng-0003o6-Cb; Tue, 16 May 2006 16:43:00 -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 1Fg5im-0003UQ-C4; Tue, 16 May 2006 16:00:44 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fg5YQ-0001aV-49; Tue, 16 May 2006 15:50:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k4GJo167010836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fg5YP-0007lE-Ol; Tue, 16 May 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: Tue, 16 May 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-rules-06.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 : Presence Authorization Rules Author(s) : J. Rosenberg Filename : draft-ietf-simple-presence-rules-06.txt Pages : 28 Date : 2006-5-16 Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules-06.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-presence-rules-06.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-presence-rules-06.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-5-16132706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presence-rules-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presence-rules-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-16132706.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 Tue May 16 17:09:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg6ma-0005eS-W6; Tue, 16 May 2006 17:08:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg6mZ-0005eF-KL for simple@ietf.org; Tue, 16 May 2006 17:08:43 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg6mY-0007QB-57 for simple@ietf.org; Tue, 16 May 2006 17:08:43 -0400 Received: (qmail 18275 invoked by uid 0); 16 May 2006 21:08:38 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 16 May 2006 21:08:38 -0000 Message-ID: <009901c6792c$e8386610$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: References: Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-presence-rules-06.txt Date: Tue, 16 May 2006 23:08:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: 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 Jonathan, The way in which namespaces are bound to 'provide-unknown-attribute' could be problematic when multiple XML documents are combined. XML tools will not be aware of the binding, and could e.g. rename conflicting namespace prefixes which would cause the rule to become invalid. Suggestion: true this keeps the namespace binding more local to the rule, and works when multiple rule documents are merged. Also, it avoids confusion, since the namespace prefix used in target documents (to which the rules are applied) might well be different from "new". Regards, jeroen PS Minor nit: for the example in 5 could consider to use 'urn:ietf:params:xml:ns:common-policy' as default namespace ----- Original Message ----- From: To: Cc: Sent: Tuesday, May 16, 2006 9:50 PM Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-rules-06.txt >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 : Presence Authorization Rules > Author(s) : J. Rosenberg > Filename : draft-ietf-simple-presence-rules-06.txt > Pages : 28 > Date : 2006-5-16 > > Authorization is a key function in presence systems. Authorization > policies, also known as authorization rules, specify what presence > information can be given to which watchers, and when. This > specification defines an Extensible Markup Language (XML) document > format for expressing presence authorization rules. Such a document > can be manipulated by clients using the XML Configuration Access > Protocol (XCAP), although other techniques are permitted. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules-06.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-presence-rules-06.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-presence-rules-06.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. > -------------------------------------------------------------------------------- > _______________________________________________ > 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 May 16 17:33:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg7A0-0006Sn-5E; Tue, 16 May 2006 17:32:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg79z-0006Se-4w for simple@ietf.org; Tue, 16 May 2006 17:32:55 -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 1Fg6WM-0006Vn-BS for simple@ietf.org; Tue, 16 May 2006 16:51:58 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fg6HC-0003CW-Lf for simple@ietf.org; Tue, 16 May 2006 16:36:28 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id C9647194556 for ; Tue, 16 May 2006 22:36:14 +0200 (CEST) Received: from [10.247.252.192] ([212.169.96.218]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 22:35:55 +0200 In-Reply-To: References: <4468577C.109@nokia.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <46ba08e7a158402df66a47c84372ed21@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Re: MSRP: direction attributes Date: Tue, 16 May 2006 22:35:57 +0200 To: Ben Campbell X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 16 May 2006 20:35:57.0164 (UTC) FILETIME=[55CABAC0:01C67928] X-Spam-Score: -2.6 (--) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Miguel Garcia , Rohan Mahy , Cullen Jennings , "'simple@ietf.org'" , "Amitkumar.Goel@infineon.com" 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 On May 16, 2006, at 10:26 PM, Ben Campbell wrote: > I agree in general with your opinion about how a=sendonly should work > in MSRP. > > My only concern about putting the language in the MSRP draft is that > draft has already been submitted to the IESG. Assuming they don't ask > for a rewrite That's a big assumption :) I think we ca add this clarifying text for a rev after the IETF last call. Hisham > , that leaves the option of adding it in the auth 48 period, or > creating a separate draft. I think this change is borderline for being > appropriate for an auth 48 change. (Certainly, we've seen much more > substantive auth48 changes before :-) ) > > Perhaps the chairs will comment? > > Comment on the proposed language inline: > > On May 15, 2006, at 5:27 AM, Miguel Garcia wrote: > >> Hi: >> >> I think this issue was discussed, but never concluded, perhaps >> because we didn't copy the MSRP authors in the e-mail discussion. >> >> Amit has been arguing that the MSRP I-D does not discuss the >> interaction of the SDP direction attributes with MSRP. To be more >> specific of the problem description, assume I have an SDP offer for >> an MSRP unidirectional session, so I would include the a=sendonly (if >> I want to send) attribute. >> >> Now, I believe the direction attribute affects MSRP SEND request. >> Specifically, it shouldn't affect the generation of REPORT requests >> from the other party, as REPORT requests are kind-of control >> protocol. >> >> Further more... the direction attribute shouldn't affect IMDN >> responses, which will be generated also with SEND requests. >> >> As a counter party, I reproduce here what SDP-new says about this >> direction attributes and their relation to RTP and RTCP. I think we >> need to extrapolate the same ideas to MSRP: >> >> Note that recvonly >> applies to the media only, not to any associated control >> protocol (e.g. an RTP based system in recvonly mode SHOULD >> still send RTCP packets). >> >> and later: >> >> Note that sendonly >> applies only to the media, and any associated control >> protocol >> (e.g. RTCP) SHOULD still be received and processed as >> normal. >> >> >> So, since the MSRP draft is silent about this relation of the SDP >> direction attributes, I think there should be an explicit mention of >> how to deal with. I can proposed to add the following text to the >> draft: >> >> >> ------ >> 8.9 SDP direction attribute and MSRP >> >> SDP defines a number of attributes that modify the direction of media >> flows. These are the "sendonly", "recvonly", "inactive", and >> "sendrecv" attributes. >> >> If a "sendonly" or "recvonly" attribute modifies an MSRP media >> description line, the attribute indicates the direction of MSRP SEND >> requests that contain regular payload. Unless otherwise specified, >> these attributes do not affect the direction of other requests, such >> as REPORT, or SEND requests that contain some kind of control >> protocol (e.g., IMDN reports), which should be generated according to >> the protocol rules as if no direction attribute were present. >> --- >> > > I agree with everything except the "or Send requests that contain some > kind of control protocol..." part. I'm not sure we can generalize that > all such content should ignore a sendonly attribute. It would be > better to leave that up to the specification for the particular > control protocol. It might make sense for IMDN, but if someone were to > define the "mind control protocol for MSRP", for example, I'm not sure > that overriding "sendonly" would make sense. > >> >> Is this acceptable? If so, please include this text in the draft and >> proceed with it as soon as possible. >> >> BR, >> >> Miguel >> >> -- >> Miguel A. Garcia tel:+358-50-4804586 >> sip:miguel.an.garcia@openlaboratory.net >> Nokia Research Center Helsinki, Finland >> > > > _______________________________________________ > 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 May 17 01:44:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgEoj-0001gP-Oy; Wed, 17 May 2006 01:43:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgEoi-0001ek-B1 for Simple@ietf.org; Wed, 17 May 2006 01:43:28 -0400 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgEoX-0001VP-8l for Simple@ietf.org; Wed, 17 May 2006 01:43:28 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 6E2C4205E5 for ; Wed, 17 May 2006 11:11:33 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 58258205DD for ; Wed, 17 May 2006 11:11:33 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.163]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 11:12:56 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Simple] Query in Publish request Date: Wed, 17 May 2006 11:12:49 +0530 Message-ID: <25BCA7DFCBA19D46B8C519C146430A94025149C7@BLR-EC-MBX02.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Query in Publish request Thread-Index: AcZ49sWJZz917MArTz+8JLoIHLbowgAey2ag From: To: , X-OriginalArrivalTime: 17 May 2006 05:42:56.0627 (UTC) FILETIME=[BFB75C30:01C67974] X-Spam-Score: 0.2 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: 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="===============0951638102==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0951638102== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67974.BF8CFFAE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67974.BF8CFFAE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable an entity-tag is returned by ESC in the response to a successful PUBLISH. =20 To update a previously published event state, PUBLISH requests MUST contain a=20 SIP-If-Match header field with the value of Etag that was returned in the last successful=20 response to PUBLISH.=20 an initial PUBLISH request MUST NOT contain a SIP-If-Match header field. =20 >From section4.1 of RFC 3903... =20 When updating previously published event state, PUBLISH requests MUST contain a single SIP-If-Match header field identifying the specific event state that the request is refreshing, modifying or removing. This header field MUST contain a single entity-tag that was returned by the ESC in the SIP-ETag header field of the response to a previous publication. =20 you can also look at the examples (section 15) of the rfc. =20 =20 Rgds Meera ________________________________ From: Sudhir [mailto:t.sudhirkumar@gmail.com]=20 Sent: Tuesday, May 16, 2006 8:08 PM To: Simple@ietf.org Subject: [Simple] Query in Publish request Hi All, =20 what is the importance of having SIP-If-match header and entiy tags in PUBLISH request and response. =20 Any response is appericated =20 thanks in advance Sudhir =20 =20 ------_=_NextPart_001_01C67974.BF8CFFAE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
an=20 entity-tag is returned by ESC = in=20 the response to a successful PUBLISH.   =
To update a previously published event state, = PUBLISH=20 requests MUST contain a
SIP-If-Match header field with the value of = Etag that=20 was returned in the last successful
response to PUBLISH. =
an initial=20 PUBLISH request MUST NOT contain a SIP-If-Match header field.
=
 
From section4.1 of RFC = 3903...
 
When updating previously published event = state,=20 PUBLISH requests MUST
 contain a single SIP-If-Match header = field=20 identifying the specific
 event state that the request is = refreshing,=20 modifying or removing.
 This header field MUST contain a single entity-tag that was=20 returned
 by the ESC in the SIP-ETag header field of the = response to a=20 previous
 publication.
 
you=20 can also look at the examples (section 15) of the=20 rfc.  
 
Rgds
Meera


From: Sudhir = [mailto:t.sudhirkumar@gmail.com]=20
Sent: Tuesday, May 16, 2006 8:08 PM
To:=20 Simple@ietf.org
Subject: [Simple] Query in Publish=20 request

Hi All,
 
what is the importance of having SIP-If-match header and entiy tags = in=20 PUBLISH request and response.
 
Any response is appericated
 
thanks in advance
Sudhir
 
 
------_=_NextPart_001_01C67974.BF8CFFAE-- --===============0951638102== 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 --===============0951638102==-- From simple-bounces@ietf.org Wed May 17 02:26:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgFTX-0006ot-EH; Wed, 17 May 2006 02:25:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgFTV-0006ol-Mo for Simple@ietf.org; Wed, 17 May 2006 02:25:37 -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 1FgEdx-0000g4-64 for Simple@ietf.org; Wed, 17 May 2006 01:32:21 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FgET9-0008KB-5x for Simple@ietf.org; Wed, 17 May 2006 01:21:20 -0400 Received: by ug-out-1314.google.com with SMTP id m3so133561uge for ; Tue, 16 May 2006 22:21:09 -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:references; b=ilOf+yNLYLnyi/tap9hVRxa9ar8fc9b0lw6mhaoXrgO0Z4I85V6q+sXorOPlcaPNA5rjjG348oCLhU+FTBP6Ytcae/WN8V/lnf01JcD9LfRnGocxJa/IETvVAk7nLMT2W0ekd50ZzwsMOowfZrAaQxP2APUAy3WnstTjC7wsUgQ= Received: by 10.67.88.8 with SMTP id q8mr259311ugl; Tue, 16 May 2006 22:21:09 -0700 (PDT) Received: by 10.66.240.1 with HTTP; Tue, 16 May 2006 22:21:09 -0700 (PDT) Message-ID: <60b4a2350605162221v3e7d4f4bl503b8da02b657496@mail.gmail.com> Date: Wed, 17 May 2006 10:51:09 +0530 From: "Gadigeppa Malagund" To: Sudhir Subject: Re: [Simple] Query in Publish request In-Reply-To: <52db68bc0605160738u41c703f8l20529f7ca3a8ec7d@mail.gmail.com> MIME-Version: 1.0 References: <52db68bc0605160738u41c703f8l20529f7ca3a8ec7d@mail.gmail.com> X-Spam-Score: -1.2 (-) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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: , Content-Type: multipart/mixed; boundary="===============0965330943==" Errors-To: simple-bounces@ietf.org --===============0965330943== Content-Type: multipart/alternative; boundary="----=_Part_40811_9054082.1147843269550" ------=_Part_40811_9054082.1147843269550 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SGksCgpUbyByZWZyZXNoIFBVQkxJU0ggZG9uZSBwcmV2aW91c2x5LCBpdCBpcyBzdWZmaWNpZW50 IHRvIHB1dCBTSVAtSWYtTWF0Y2g6CjxldGFnPiBhbmQgbmVlZG4ndCBzZW5kIHRoZSBib2R5LiBT byB3ZSBzYXZlIG4vdyByZXNvdXJjZXMuCgpSZWdhcmRzLApHYWRpCgpPbiA1LzE2LzA2LCBTdWRo aXIgPHQuc3VkaGlya3VtYXJAZ21haWwuY29tPiB3cm90ZToKPgo+IEhpIEFsbCwKPgo+IHdoYXQg aXMgdGhlIGltcG9ydGFuY2Ugb2YgaGF2aW5nIFNJUC1JZi1tYXRjaCBoZWFkZXIgYW5kIGVudGl5 IHRhZ3MgaW4KPiBQVUJMSVNIIHJlcXVlc3QgYW5kIHJlc3BvbnNlLgo+Cj4gQW55IHJlc3BvbnNl IGlzIGFwcGVyaWNhdGVkCj4KPiB0aGFua3MgaW4gYWR2YW5jZQo+IFN1ZGhpcgo+Cj4KPgo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gU2ltcGxlIG1h aWxpbmcgbGlzdAo+IFNpbXBsZUBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpbXBsZQo+Cj4KPgoKCi0tIApHYWRpZ2VwcGEgTWFsYWd1bmQKKzkxIDk4 NDU4NTQ0MzIK ------=_Part_40811_9054082.1147843269550 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksPGJyPgo8YnI+ClRvIHJlZnJlc2ggUFVCTElTSCBkb25lIHByZXZpb3VzbHksIGl0IGlzIHN1 ZmZpY2llbnQgdG8gcHV0ClNJUC1JZi1NYXRjaDogJmx0O2V0YWcmZ3Q7IGFuZCBuZWVkbid0IHNl bmQgdGhlIGJvZHkuIFNvIHdlIHNhdmUgbi93CnJlc291cmNlcy48YnI+Cjxicj4KUmVnYXJkcyw8 YnI+CkdhZGk8YnI+PGJyPjxkaXY+PHNwYW4gY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiA1LzE2LzA2 LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+U3VkaGlyPC9iPiAmbHQ7PGEgaHJlZj0ibWFp bHRvOnQuc3VkaGlya3VtYXJAZ21haWwuY29tIj50LnN1ZGhpcmt1bWFyQGdtYWlsLmNvbTwvYT4m Z3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJi b3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0 IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4KPGRpdj48ZGl2PkhpIEFsbCw8L2Rpdj4K PGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj53aGF0IGlzIHRoZSBpbXBvcnRhbmNlIG9mIGhhdmluZyBT SVAtSWYtbWF0Y2ggaGVhZGVyIGFuZCBlbnRpeSB0YWdzIGluIFBVQkxJU0ggcmVxdWVzdCBhbmQg cmVzcG9uc2UuPC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+QW55IHJlc3BvbnNlIGlzIGFw cGVyaWNhdGVkPC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+dGhhbmtzIGluIGFkdmFuY2U8 L2Rpdj48L2Rpdj48ZGl2PjxzcGFuIGNsYXNzPSJzZyI+CjxkaXY+U3VkaGlyPC9kaXY+CjxkaXY+ Jm5ic3A7PC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+Cgo8L3NwYW4+PC9kaXY+PGJyPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPlNpbXBsZSBtYWlsaW5n IGxpc3Q8YnI+PGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZl bnQsdGhpcykiIGhyZWY9Im1haWx0bzpTaW1wbGVAaWV0Zi5vcmciPlNpbXBsZUBpZXRmLm9yZzwv YT48YnI+PGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQs dGhpcykiIGhyZWY9Imh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpbXBs ZSIgdGFyZ2V0PSJfYmxhbmsiPgpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaW1wbGU8L2E+PGJyPjxicj48YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9 ImFsbCI+PGJyPi0tIDxicj5HYWRpZ2VwcGEgTWFsYWd1bmQ8YnI+KzkxIDk4NDU4NTQ0MzIK ------=_Part_40811_9054082.1147843269550-- --===============0965330943== 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 --===============0965330943==-- From simple-bounces@ietf.org Wed May 17 02:31:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgFZE-0000Ve-Ds; Wed, 17 May 2006 02:31:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgFZC-0000Tn-Al for simple@ietf.org; Wed, 17 May 2006 02:31:30 -0400 Received: from [203.196.150.38] (helo=mail.uulogic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgFZB-0003YS-1O for simple@ietf.org; Wed, 17 May 2006 02:31:30 -0400 Received: from shankar ([192.168.1.91]) by mail.uulogic.com (8.11.0/8.11.0) with SMTP id k4H6VVA24437 for ; Wed, 17 May 2006 12:01:31 +0530 Message-ID: <00ab01c6797b$87bac360$5b01a8c0@shankar> From: "uday shankar" To: Date: Wed, 17 May 2006 12:01:28 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Logged: Logged by mail.uulogic.com as k4H6VVA24437 at Wed May 17 12:01:31 2006 X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Subject: [Simple] need suggestion. 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="===============1550308503==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1550308503== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A8_01C679A9.A15453D0" This is a multi-part message in MIME format. ------=_NextPart_000_00A8_01C679A9.A15453D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi, I am Uday.I am trying to implement Instant Messaging using SIP.I = have been searching for open source code in c or c++. At present we are = using sipXpbx server and sipXzphone for client.but sipXzphone is not = supporting Instant Messaging.I would be thankful if you suggest me the = client that supports Instant Messaging. =20 Regards, P.Uday = Shankar. =20 --=20 Uday Shankar Exaband (India) PVT. LTD. *************************************************************************= ******** This email and any files transmitted along with it are confidential and = intended=20 solely for the use of the individual or entity to whom they are = addressed. Mail recipients and senders are bound by the=20 EXABAND (INDIA) PRIVATE LIMITED Non-Disclosure Policy. If you have not signed the Non-Disclosure Policy or if you feel you have received this mail in error, please notify security@exaband.net *************************************************************************= ******** ------=_NextPart_000_00A8_01C679A9.A15453D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi,
     I am = Uday.I am trying=20 to implement  Instant Messaging using SIP.I have been searching for = open=20 source code in c or c++. At present we are using sipXpbx server and = sipXzphone=20 for client.but sipXzphone is not supporting Instant Messaging.I would be = thankful if you suggest me the client that supports Instant=20 Messaging.
          &nbs= p;            = ;           =20
          &nbs= p;            = ;            =             &= nbsp;           &n= bsp; =20 Regards,
          &nbs= p;            = ;            =             &= nbsp;           &n= bsp; =20 P.Uday Shankar.
  
--
Uday Shankar
Exaband (India) = PVT.=20 LTD.
 
****************************************************************= *****************
 
This email and any files transmitted = along with it=20 are confidential and intended
solely for the use of the individual = or entity=20 to whom they are addressed.
Mail recipients and senders are bound by = the=20
EXABAND (INDIA) PRIVATE LIMITED Non-Disclosure Policy.
If you = have not=20 signed the Non-Disclosure Policy or if you feel you have
received = this mail=20 in error, please notify security@exaband.net
********= *************************************************************************=
------=_NextPart_000_00A8_01C679A9.A15453D0-- --===============1550308503== 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 --===============1550308503==-- From simple-bounces@ietf.org Wed May 17 09:57:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgMWa-0003gc-SD; Wed, 17 May 2006 09:57:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgMWY-0003cv-Ur for simple@ietf.org; Wed, 17 May 2006 09:57:14 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgMWW-0002BP-Ln for simple@ietf.org; Wed, 17 May 2006 09:57:14 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 17 May 2006 06:57:12 -0700 X-IronPort-AV: i="4.05,138,1146466800"; d="scan'208"; a="1807823572:sNHT31623236" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k4HDvC1O005188; Wed, 17 May 2006 06:57:12 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k4HDvBJj014702; Wed, 17 May 2006 06:57:11 -0700 (PDT) Received: from [10.43.1.123] ([10.21.97.84]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 06:57:11 -0700 In-Reply-To: References: <4468577C.109@nokia.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1F98E7FE-0203-4B7B-8620-369DF931287B@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Wed, 17 May 2006 15:57:15 +0200 To: Ben Campbell X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 17 May 2006 13:57:11.0880 (UTC) FILETIME=[CB9FDC80:01C679B9] DKIM-Signature: a=rsa-sha1; q=dns; l=848; t=1147874232; x=1148738232; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20MSRP=3A=20direction=20attributes; X=v=3Dcisco.com=3B=20h=3DBBjtn+aPtxXg0IRATv/kiRvQSSc=3D; b=pTepbInqSezRYw7mCEaQZhKGKwpMK0TSHBezCGAHcDd34eyL9e1/h58mj9Mi0t4DibP0M3nK ntAjS6m+TYwtUWmgfPNFvYf/zFQPmoxa+fTh1rtsV6b0qxytGQ7lNAhJ; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Miguel Garcia , Rohan Mahy , "'simple@ietf.org'" , "Amitkumar.Goel@infineon.com" Subject: [Simple] Re: MSRP: direction attributes 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 On May 16, 2006, at 10:26 PM, Ben Campbell wrote: > I agree in general with your opinion about how a=sendonly should > work in MSRP. > > My only concern about putting the language in the MSRP draft is > that draft has already been submitted to the IESG. Assuming they > don't ask for a rewrite, that leaves the option of adding it in the > auth 48 period, or creating a separate draft. I think this change > is borderline for being appropriate for an auth 48 change. > (Certainly, we've seen much more substantive auth48 changes > before :-) ) > > Perhaps the chairs will comment? We will need Jon's opinion on this but I suggest, write the text, make a diff, check it in to SVN - send the diff to Jon and see if wants to a) have us submit new version b) add it as RFC editor note c) ignore (unlikely) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 17 10:02:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgMb5-0007UP-1v; Wed, 17 May 2006 10:01:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgMb3-0007UK-21 for simple@ietf.org; Wed, 17 May 2006 10:01:53 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgMb0-0002L2-MG for simple@ietf.org; Wed, 17 May 2006 10:01:53 -0400 Received: from [192.168.1.105] ([71.204.151.47]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k4HE1572090489 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 17 May 2006 09:01:43 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <1F98E7FE-0203-4B7B-8620-369DF931287B@cisco.com> References: <4468577C.109@nokia.com> <1F98E7FE-0203-4B7B-8620-369DF931287B@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Date: Wed, 17 May 2006 09:01:44 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Miguel Garcia , Rohan Mahy , "'simple@ietf.org'" , "Amitkumar.Goel@infineon.com" Subject: [Simple] Re: MSRP: direction attributes 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 Will do. On May 17, 2006, at 8:57 AM, Cullen Jennings wrote: > > On May 16, 2006, at 10:26 PM, Ben Campbell wrote: > >> I agree in general with your opinion about how a=sendonly should >> work in MSRP. >> >> My only concern about putting the language in the MSRP draft is >> that draft has already been submitted to the IESG. Assuming they >> don't ask for a rewrite, that leaves the option of adding it in >> the auth 48 period, or creating a separate draft. I think this >> change is borderline for being appropriate for an auth 48 change. >> (Certainly, we've seen much more substantive auth48 changes >> before :-) ) >> >> Perhaps the chairs will comment? > > We will need Jon's opinion on this but I suggest, write the text, > make a diff, check it in to SVN - send the diff to Jon and see if > wants to > > a) have us submit new version > b) add it as RFC editor note > c) ignore (unlikely) > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu May 18 05:46:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgf4J-00026L-JZ; Thu, 18 May 2006 05:45:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgf4J-00026G-1O for simple@ietf.org; Thu, 18 May 2006 05:45:19 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgf4F-0003Zw-C6 for simple@ietf.org; Thu, 18 May 2006 05:45:19 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B09C24F003F for ; Thu, 18 May 2006 11:45:12 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 11:45:12 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 11:45:12 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 197512714 for ; Thu, 18 May 2006 12:45:12 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D5DA04DB53 for ; Thu, 18 May 2006 12:45:11 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8B64D4DAB3 for ; Thu, 18 May 2006 12:45:11 +0300 (EEST) From: "Salvatore Loreto (JO/LMF)" To: simple@ietf.org In-Reply-To: References: Content-Type: text/plain Date: Thu, 18 May 2006 12:45:11 +0300 Message-Id: <1147945511.3503.10.camel@n121.nomadiclab.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 18 May 2006 09:45:12.0409 (UTC) FILETIME=[C2216C90:01C67A5F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Simple] partial-notify draft 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 Hi there, I remember in the last IETF meeting the idea was move on this draft and let it approach the WGLC. But I don't have noticed any WGLC, and now the draft is in expired status!!! Can you explain why ? regards Sal _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu May 18 07:05:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FggJN-00046k-Qm; Thu, 18 May 2006 07:04:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FggJM-00045X-3i for simple@ietf.org; Thu, 18 May 2006 07:04:56 -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 1FggJM-000054-2L for simple@ietf.org; Thu, 18 May 2006 07:04:56 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fgg3f-0001FB-BA for simple@ietf.org; Thu, 18 May 2006 06:48:44 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4IAmebp029399; Thu, 18 May 2006 13:48:41 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 13:48:02 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 13:48:02 +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] partial-notify draft Date: Thu, 18 May 2006 13:47:56 +0300 Message-ID: In-Reply-To: <1147945511.3503.10.camel@n121.nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] partial-notify draft Thread-Index: AcZ6YTutKTXMfNRyS86Jp/lzlj1PUgABdLIQ From: To: , X-OriginalArrivalTime: 18 May 2006 10:48:02.0258 (UTC) FILETIME=[8922BB20:01C67A68] X-Spam-Score: -2.6 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 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 Salvatore, You seem to have missed a couple of mails on the list. WGLC was issued by the chairs on April 12 according to this mail: http://www1.ietf.org/mail-archive/web/simple/current/msg06449.html Due to the lack of comments, the WGLC was extended: http://www1.ietf.org/mail-archive/web/simple/current/msg06487.html BTW, for the record, I think those drafts under the last call are ready. Markus >-----Original Message----- >From: ext Salvatore Loreto (JO/LMF)=20 >[mailto:salvatore.loreto@ericsson.com]=20 >Sent: 18 May, 2006 12:45 >To: simple@ietf.org >Subject: [Simple] partial-notify draft > >Hi there, > > >I remember in the last IETF meeting >the idea was move on this draft and let it approach the WGLC. > >But I don't have noticed any WGLC, and now the draft is in=20 >expired status!!! > >Can you explain why ? > >regards >Sal > > >_______________________________________________ >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 Thu May 18 23:52:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgw1i-0002tj-HK; Thu, 18 May 2006 23:51:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgw1h-0002tZ-Jv for simple@ietf.org; Thu, 18 May 2006 23:51:45 -0400 Received: from [130.94.222.106] (helo=citilindia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgw1e-00056N-Vj for simple@ietf.org; Thu, 18 May 2006 23:51:45 -0400 Received: (qmail 32504 invoked by uid 24170); 19 May 2006 03:51:36 -0000 Received: from unknown (HELO IN00201) ([61.14.7.242]) (envelope-sender ) by 130.94.222.106 (qmail-ldap-1.03) with SMTP for ; 19 May 2006 03:51:36 -0000 Message-ID: <003401c67af7$86e8eac0$6b0019ac@Trinity.local> From: "Abhijit A. Mahajani" To: "uday shankar" , References: <00ab01c6797b$87bac360$5b01a8c0@shankar> Subject: Re: [Simple] need suggestion. Date: Fri, 19 May 2006 09:21:34 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: 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="===============0379506186==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0379506186== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01C67B25.9F286970" This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C67B25.9F286970 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Uday! May be you can use windows messenger 5.0.0482 as IM client. Best Regards. Abhijit ----- Original Message -----=20 From: uday shankar=20 To: simple@ietf.org=20 Sent: Wednesday, May 17, 2006 12:01 PM Subject: [Simple] need suggestion. hi, I am Uday.I am trying to implement Instant Messaging using SIP.I = have been searching for open source code in c or c++. At present we are = using sipXpbx server and sipXzphone for client.but sipXzphone is not = supporting Instant Messaging.I would be thankful if you suggest me the = client that supports Instant Messaging. =20 Regards, P.Uday = Shankar. =20 --=20 Uday Shankar Exaband (India) PVT. LTD. = *************************************************************************= ******** This email and any files transmitted along with it are confidential = and intended=20 solely for the use of the individual or entity to whom they are = addressed. Mail recipients and senders are bound by the=20 EXABAND (INDIA) PRIVATE LIMITED Non-Disclosure Policy. If you have not signed the Non-Disclosure Policy or if you feel you = have received this mail in error, please notify security@exaband.net = *************************************************************************= ******** -------------------------------------------------------------------------= ----- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple ------=_NextPart_000_0031_01C67B25.9F286970 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Uday!
May be you can use windows messenger = 5.0.0482 as IM=20 client.
Best Regards.
Abhijit
----- Original Message -----
From:=20 uday=20 shankar
Sent: Wednesday, May 17, 2006 = 12:01=20 PM
Subject: [Simple] need = suggestion.

hi,
     I am = Uday.I am=20 trying to implement  Instant Messaging using SIP.I have been = searching=20 for open source code in c or c++. At present we are using sipXpbx = server and=20 sipXzphone for client.but sipXzphone is not supporting Instant = Messaging.I=20 would be thankful if you suggest me the client that supports Instant=20 Messaging.
          &nbs= p;            = ;           =20
          &nbs= p;            = ;            =             &= nbsp;           &n= bsp; =20 Regards,
          &nbs= p;            = ;            =             &= nbsp;           &n= bsp; =20 P.Uday Shankar.
   =
--
Uday Shankar
Exaband = (India) PVT.=20 LTD.
 
****************************************************************= *****************
 
This email and any files transmitted = along with=20 it are confidential and intended
solely for the use of the = individual or=20 entity to whom they are addressed.
Mail recipients and senders are = bound by=20 the
EXABAND (INDIA) PRIVATE LIMITED Non-Disclosure Policy.
If = you have=20 not signed the Non-Disclosure Policy or if you feel you = have
received this=20 mail in error, please notify security@exaband.net
********= *************************************************************************=

_______________________________________________
Simple = mailing=20 = list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple<= BR> ------=_NextPart_000_0031_01C67B25.9F286970-- --===============0379506186== 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 --===============0379506186==-- From simple-bounces@ietf.org Fri May 19 05:00:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh0pU-0007qW-U0; Fri, 19 May 2006 04:59:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh0pU-0007qR-0G for simple@ietf.org; Fri, 19 May 2006 04:59:28 -0400 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh0pR-00060R-Fg for simple@ietf.org; Fri, 19 May 2006 04:59:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 May 2006 10:58:49 +0200 Message-ID: <3ACC9A25264A684F82C71840111F979801961BB4@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Infinite loops in rls subscriptions Thread-Index: AcZ7InGrsSf7FsHCQvaOZqC1oYzPJQ== From: To: X-OriginalArrivalTime: 19 May 2006 08:59:13.0850 (UTC) FILETIME=[805079A0:01C67B22] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Simple] Infinite loops in rls subscriptions 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 Hi,=20 in draft-ietf-simple-event-list-07 is written: 7.4 Infinite Loops One risk introduced by the ability to nest resource lists is the possibility of creating lists which ultimately contain themselves as a sub-list. Detection and handling of such a case is trivial when the RLS services all of the virtual subscriptions internally. When back-end subscriptions are created to service virtual subscriptions, however, detection of such situations becomes a more difficult problem. Implementors of RLSes that create back-end subscriptions MUST implement safeguards to prevent such nestings from creating an infinite loop of subscriptions. Typically, such mechanisms will require support in the back-end subscription protocol. In particular, applying filters to the back-end subscriptions can be an effective way to preclude such problems. I have 2 questions: - if an user performs rls subscription and RLS detects loop in virtual subscriptions, should it break the cycle and keep the rls subscription active, or reject the rls subscription? - it seems to me that it is not possible to detect loops in back end subscriptions (subscriptions between different servers). If I have list in RLS1 which contains reference to list in RLS2, and the list in RLS2 contains reference back to the list in RLS1, there is no way (provided by standards) how to detect this loop, because the back-end subscription coming from RLS2 to RLS1 wont carry any hint that it is related to preceding back-end subscription from RLS1 to RLS2. Am I correct?=20 Thanks,=20 Silvestr Peknik Software Specialist TietoEnator _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri May 19 10:42:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh6BQ-0002JB-Mh; Fri, 19 May 2006 10:42:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh6BP-0002J4-DW for simple@ietf.org; Fri, 19 May 2006 10:42:27 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh6BO-0004Db-60 for simple@ietf.org; Fri, 19 May 2006 10:42:27 -0400 Received: from [172.17.2.252] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.4) with ESMTP id k4JEgNex036665 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 19 May 2006 09:42:25 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6D079B7C-C93C-4286-B732-97424E7FEA27@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Fri, 19 May 2006 09:42:22 -0500 To: simple@ietf.org X-Mailer: Apple Mail (2.749.3) Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Robert Sparks Subject: [Simple] New WG -00s 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 Folks - If you are anticipating issuing a SIMPLE WG -00 between now and the deadline for IETF66, please send a note to the chairs so we don't miss it on the pre-approval list. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon May 22 10:05:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiB1m-00077o-5h; Mon, 22 May 2006 10:04:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiB1l-00077j-C3 for simple@ietf.org; Mon, 22 May 2006 10:04:57 -0400 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiB1j-0001v0-RT for simple@ietf.org; Mon, 22 May 2006 10:04:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 May 2006 16:04:45 +0200 Message-ID: <3ACC9A25264A684F82C71840111F9798019A72D4@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Few more comments to presence-rules-06 Thread-Index: AcZ9qK4jgFfPtlq/RMWnaLp8ZOOklQ== From: To: X-OriginalArrivalTime: 22 May 2006 14:04:52.0622 (UTC) FILETIME=[B25042E0:01C67DA8] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: simple@ietf.org Subject: [Simple] Few more comments to presence-rules-06 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 Hi, I traversed the presence rules draft 06 once again and I found few issues there. - In section 3.1.1.2 there is last paragraph noticing usage of TEL URI and SIP URI for one user. There is bug in first combination of URIs starting "A WR identity .." SIP with phone to SIP but should be SIP with phone to TEL in the reverse direction I would prefer to mention SIP URI with the phone number instead of pure SIP URI - In section 3.3.2.14 third paragraph first sentence.=20 "Another consequence of this definition is that the interpretation of the element can change should the presence server be upgraded with a new schema that defines authorization rules for elements included in a ." This sentence makes me really confused and I can't catch the idea. Other issues are moreless cosmetic - First paragraph of 3.1.1.2 contains "can can" sequence - Last paragraph of 3.2.1 contains "is is" sequence - In section 3.3.2 there is used element - Permission definitions are in form: there is permission XXX realized by element . But provide unknown attribute permission violates this convention. Similar deviation is in 3.3.2.15. In addition, what was the reason to change to ? It somehow breaks the conventions of provide-xxx elements. BR, Martin Martin Hynar Software Specialist TietoEnator Czech Software Center Phone: +420 599 096 022 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 From simple-bounces@ietf.org Tue May 23 11:19:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiYeM-0000T9-UH; Tue, 23 May 2006 11:18:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiYeL-0000T4-5l for simple@ietf.org; Tue, 23 May 2006 11:18:21 -0400 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiYeK-0004FW-06 for simple@ietf.org; Tue, 23 May 2006 11:18:21 -0400 Received: by py-out-1112.google.com with SMTP id f28so1797458pyf for ; Tue, 23 May 2006 08:18:19 -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:mime-version:content-type:content-transfer-encoding:content-disposition; b=Io6KEwUprvJZwHoVMJNgHtL8ZSlf/xeK2TWuLfsMqurpaXXbFfTqNvWoH/SdRbC4AwrX+IQBISsrBddqc1g5DznIOsVfA+1VLcrRP23+BuORbID6pP1MM/GeV7Nf8UARxEhYx8YdYcH0wOOAaMIx8UTNy5gVgZX7W482yQVy7q0= Received: by 10.35.101.9 with SMTP id d9mr897912pym; Tue, 23 May 2006 08:18:19 -0700 (PDT) Received: by 10.64.220.8 with HTTP; Tue, 23 May 2006 08:18:19 -0700 (PDT) Message-ID: <9d77d7060605230818t50745ac4j6090da96ec4f6020@mail.gmail.com> Date: Tue, 23 May 2006 23:18:19 +0800 From: "Xiang Ting" To: simple Subject: [Simple]How does MSRP support NAT traversal? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Cullen Jennings , Paul Kyzivat , Rohan Mahy 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 In IPv4 based IMS core network, how does an UE communicate with another UE which behind a NAT? Does some MSRP relay need? Which one act as a active connection role? Thanks. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 23 11:41:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiZ0b-0003jj-2g; Tue, 23 May 2006 11:41:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiZ0a-0003je-9p for simple@ietf.org; Tue, 23 May 2006 11:41:20 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiZ0X-0005CP-Tp for simple@ietf.org; Tue, 23 May 2006 11:41:20 -0400 Received: from [131.161.248.91] (open-131-161-248-91.cliq.com [131.161.248.91]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k4NFexF00575; Tue, 23 May 2006 08:40:59 -0700 In-Reply-To: <9d77d7060605230818t50745ac4j6090da96ec4f6020@mail.gmail.com> References: <9d77d7060605230818t50745ac4j6090da96ec4f6020@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3293ae2bae06cbae4b1637ed3c353f17@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple]How does MSRP support NAT traversal? Date: Tue, 23 May 2006 08:41:25 -0700 To: "Xiang Ting" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Cullen Jennings , Rohan Mahy , Paul Kyzivat , simple 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 See draft-ietf-simple-msrp-relays-07.txt thanks, -rohan On May 23, 2006, at 8:18, Xiang Ting wrote: > In IPv4 based IMS core network, how does an UE communicate with > another UE which behind a NAT? > Does some MSRP relay need? > Which one act as a active connection role? > > > Thanks. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 24 10:54:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiujZ-0007NH-CL; Wed, 24 May 2006 10:53:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiujX-0007NC-HN for simple@ietf.org; Wed, 24 May 2006 10:53:11 -0400 Received: from [192.84.19.225] (helo=mail.8x8.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiujW-00031r-9g for simple@ietf.org; Wed, 24 May 2006 10:53:11 -0400 Received: from [10.0.2.15] (godzilla.8x8.com [192.168.84.42]) by mail.8x8.com (Postfix) with ESMTP id 7466333C191; Wed, 24 May 2006 07:53:01 -0700 (PDT) Message-ID: <4474734C.6050407@acm.org> Date: Wed, 24 May 2006 07:53:00 -0700 From: Marc Petit-Huguenin User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple]How does MSRP support NAT traversal? References: <9d77d7060605230818t50745ac4j6090da96ec4f6020@mail.gmail.com> <3293ae2bae06cbae4b1637ed3c353f17@ekabal.com> In-Reply-To: <3293ae2bae06cbae4b1637ed3c353f17@ekabal.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Cullen Jennings , Paul Kyzivat , simple 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 Rohan Mahy wrote: > See draft-ietf-simple-msrp-relays-07.txt Isn't possible to use draft-ietf-mmusic-ice-tcp-00 for this? > > thanks, > -rohan > > On May 23, 2006, at 8:18, Xiang Ting wrote: >> In IPv4 based IMS core network, how does an UE communicate with >> another UE which behind a NAT? >> Does some MSRP relay need? >> Which one act as a active connection role? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 24 12:00:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FivlG-0008Az-CO; Wed, 24 May 2006 11:59:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FivlE-000867-Ew for simple@ietf.org; Wed, 24 May 2006 11:59:00 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FivlB-0006P3-1k for simple@ietf.org; Wed, 24 May 2006 11:59:00 -0400 Received: from [131.161.248.91] (open-131-161-248-91.cliq.com [131.161.248.91]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id k4OFwYF26232; Wed, 24 May 2006 08:58:34 -0700 In-Reply-To: <44747301.9040804@petit-huguenin.org> References: <9d77d7060605230818t50745ac4j6090da96ec4f6020@mail.gmail.com> <3293ae2bae06cbae4b1637ed3c353f17@ekabal.com> <44747301.9040804@petit-huguenin.org> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple]How does MSRP support NAT traversal? Date: Wed, 24 May 2006 08:59:01 -0700 To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Cullen Jennings , Rohan Mahy , Paul Kyzivat , simple 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 Hi Marc, It was specifically a non-goal of MSRP to use a TURN server for MSRP traffic. thanks, -rohan On May 24, 2006, at 7:51, Marc Petit-Huguenin wrote: > Rohan Mahy wrote: >> See draft-ietf-simple-msrp-relays-07.txt > > Isn't possible to use draft-ietf-mmusic-ice-tcp-00 for this? > >> >> thanks, >> -rohan >> >> On May 23, 2006, at 8:18, Xiang Ting wrote: >>> In IPv4 based IMS core network, how does an UE communicate with >>> another UE which behind a NAT? >>> Does some MSRP relay need? >>> Which one act as a active connection role? >>> >>> >>> Thanks. >> >> >> _______________________________________________ >> 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 May 24 14:02:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FixgX-0002Kr-36; Wed, 24 May 2006 14:02:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FixgV-0002KW-CX for simple@ietf.org; Wed, 24 May 2006 14:02:15 -0400 Received: from [192.84.19.225] (helo=mail.8x8.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FixgU-0004zk-3m for simple@ietf.org; Wed, 24 May 2006 14:02:15 -0400 Received: from [10.0.2.15] (godzilla.8x8.com [192.168.84.42]) by mail.8x8.com (Postfix) with ESMTP id 2B4FA33C1F7; Wed, 24 May 2006 11:02:09 -0700 (PDT) Message-ID: <44749F9F.4080000@acm.org> Date: Wed, 24 May 2006 11:02:07 -0700 From: Marc Petit-Huguenin User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple]How does MSRP support NAT traversal? References: <9d77d7060605230818t50745ac4j6090da96ec4f6020@mail.gmail.com> <3293ae2bae06cbae4b1637ed3c353f17@ekabal.com> <44747301.9040804@petit-huguenin.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Cullen Jennings , Paul Kyzivat , simple 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 Rohan Mahy wrote: > Hi Marc, > > It was specifically a non-goal of MSRP to use a TURN server for MSRP > traffic. I understand, but what technically prevent doing NAT traversal for MSRP with a TCP TURN server? > > thanks, > -rohan > > > On May 24, 2006, at 7:51, Marc Petit-Huguenin wrote: >> Rohan Mahy wrote: >>> See draft-ietf-simple-msrp-relays-07.txt >> >> Isn't possible to use draft-ietf-mmusic-ice-tcp-00 for this? >> >>> >>> thanks, >>> -rohan >>> >>> On May 23, 2006, at 8:18, Xiang Ting wrote: >>>> In IPv4 based IMS core network, how does an UE communicate with >>>> another UE which behind a NAT? >>>> Does some MSRP relay need? >>>> Which one act as a active connection role? >>>> >>>> >>>> Thanks. >>> >>> >>> _______________________________________________ >>> 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 May 24 14:30:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiy7i-0005pM-VV; Wed, 24 May 2006 14:30:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiy7h-0005pH-M4 for simple@ietf.org; Wed, 24 May 2006 14:30:21 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiy7g-0006Km-8V for simple@ietf.org; Wed, 24 May 2006 14:30:21 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4OIU59N031227; Wed, 24 May 2006 21:30:06 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 May 2006 21:29:18 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 May 2006 21:29:18 +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]How does MSRP support NAT traversal? Date: Wed, 24 May 2006 21:29:17 +0300 Message-ID: In-Reply-To: <44749F9F.4080000@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple]How does MSRP support NAT traversal? Thread-Index: AcZ/XU+0Z3CLN6mIS9CGm/HjmQYYRwAAbhVw From: To: , X-OriginalArrivalTime: 24 May 2006 18:29:18.0718 (UTC) FILETIME=[F811E1E0:01C67F5F] X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: fluffy@cisco.com, pkyzivat@cisco.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 Hi,=20 >-----Original Message----- >From: ext Marc Petit-Huguenin [mailto:petithug@acm.org]=20 >Sent: 24 May, 2006 21:02 >To: Rohan Mahy >Cc: Cullen Jennings; Paul Kyzivat; simple >Subject: Re: [Simple]How does MSRP support NAT traversal? > >Rohan Mahy wrote: >> Hi Marc, >>=20 >> It was specifically a non-goal of MSRP to use a TURN server for MSRP=20 >> traffic. > >I understand, but what technically prevent doing NAT traversal=20 >for MSRP with a TCP TURN server? > Good question, I have been wondering the same. If TURN relays start to = be available (I hope they do, although I haven't heard about such a = thing), it would make sense to run MSRP through TURN instead of = introducing separate MSRP specific relays. There may be other reasons to = use MSRP relays, but the pure NAT traversal should be based on something = more generic. =20 Regards, Markus ---------------------------- Markus Isom=E4ki markus.isomaki@nokia.com ---------------------------- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed May 24 19:55:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj3Bp-0006LZ-PT; Wed, 24 May 2006 19:54:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj3Bo-0006GN-1t for simple@ietf.org; Wed, 24 May 2006 19:54:56 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj3Bm-0002mq-P1 for simple@ietf.org; Wed, 24 May 2006 19:54:56 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-2.cisco.com with ESMTP; 24 May 2006 16:54:54 -0700 X-IronPort-AV: i="4.05,169,1146466800"; d="scan'208"; a="323390463:sNHT33160680" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k4ONssLk003509; Wed, 24 May 2006 16:54:54 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k4ONssJj004759; Wed, 24 May 2006 16:54:54 -0700 (PDT) Received: from [192.168.1.2] ([10.21.145.154]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 May 2006 16:54:53 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Cullen Jennings Subject: Re: [Simple]How does MSRP support NAT traversal? Date: Wed, 24 May 2006 16:54:51 -0700 To: "" X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 24 May 2006 23:54:53.0986 (UTC) FILETIME=[73FF3820:01C67F8D] DKIM-Signature: a=rsa-sha1; q=dns; l=1364; t=1148514894; x=1149378894; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Simple]How=20does=20MSRP=20support=20NAT=20traversal?; X=v=3Dcisco.com=3B=20h=3DuZfpG1glNyzWlhVDpQ073Yhnres=3D; b=mt/Gm5jw14au2aPhtF5Cc7MRfx8npoRLola3lMS1tCTrrn7qUXkHinZNIliJfqCiZg5tmNMn ZHX/Fw5b5Jr4PrVNoRv83ttXOK54308des+uOQ4ZWELOfv2Yl6xTDQd6; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( 30 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: petithug@acm.org, pkyzivat@cisco.com, simple@ietf.org, rohan@ekabal.com 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 can imagine that it might be possible to set up a MSRP session over =20= TURN or over STUNT. I've not checked the details of this being =20 possible but seems like it might work. Keep in mind TLS won't work =20 very well with TURN. On May 24, 2006, at 11:29 AM, =20 wrote: > Hi, > >> -----Original Message----- >> From: ext Marc Petit-Huguenin [mailto:petithug@acm.org] >> Sent: 24 May, 2006 21:02 >> To: Rohan Mahy >> Cc: Cullen Jennings; Paul Kyzivat; simple >> Subject: Re: [Simple]How does MSRP support NAT traversal? >> >> Rohan Mahy wrote: >>> Hi Marc, >>> >>> It was specifically a non-goal of MSRP to use a TURN server for MSRP >>> traffic. >> >> I understand, but what technically prevent doing NAT traversal >> for MSRP with a TCP TURN server? >> > > Good question, I have been wondering the same. If TURN relays start =20= > to be available (I hope they do, although I haven't heard about =20 > such a thing), it would make sense to run MSRP through TURN instead =20= > of introducing separate MSRP specific relays. There may be other =20 > reasons to use MSRP relays, but the pure NAT traversal should be =20 > based on something more generic. > > Regards, > Markus > > ---------------------------- > Markus Isom=E4ki > markus.isomaki@nokia.com > ---------------------------- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu May 25 03:42:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjATT-0005Sa-9C; Thu, 25 May 2006 03:41:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjATR-0005SV-7e for simple@ietf.org; Thu, 25 May 2006 03:41:37 -0400 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjATP-0006yY-KG for simple@ietf.org; Thu, 25 May 2006 03:41:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] publishing presence state - sip and pres uris Date: Thu, 25 May 2006 09:41:17 +0200 Message-ID: <3ACC9A25264A684F82C71840111F9798019F9730@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] publishing presence state - sip and pres uris Thread-Index: AcZtaiy36vC9PkrmTDev2gU79UdE9wSY0X1Q From: To: X-OriginalArrivalTime: 25 May 2006 07:41:20.0539 (UTC) FILETIME=[9D484EB0:01C67FCE] X-Spam-Score: 0.2 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 >-----Original Message----- >From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >Sent: Monday, May 01, 2006 9:21 PM >To: Peknik Silvestr >Cc: simple@ietf.org >Subject: Re: [Simple] publishing presence state - sip and pres uris > >This can happen, yes. The presence data model draft (out shortly as an >RFC) does say you shouldn't do this - that the URI in the SUBSCRIBE or >PUBLISH should match that in the document. What is the relation between To header and r-URI? Currently it seems to me that the client should set both to the same value, but r-URI can be changed by proxies. If this is the case, why not to use To header instead of r-URI for identifying the target of the request? And if the r-URI can not be changed, what is the purpose of To header? > >That said, the presence server should know that the pres and sip URI are >equivalent, and thus even though the R-uri identifies the SIP URI, the >document should be applied to the presentity URI sip:alan@example.com as >well. Consequently, a SUBSCRIBE request for sip:alan@example.com would >return a presence document whose entity attribute is sip:alan@example.com. I guess there is typo - it should say: ...applied to the presentity URI pres:alan@example.com as well... Am I right? Thank you,=20 Silvestr Peknik > >Thanks, >Jonathan R. > >Silvestr.Peknik@tietoenator.com wrote: > >> Hello, >> >> I am not sure how presence server should handle PUBLISH requests, if they >have sip uri in To: header and pres uri in entity attribute in the presence >document: >> >> PUBLISH ... >> To: sip:alan@example.com >> ... >> >> >> ... >> >> >> It seems that client should not create such requests (why use pres uri, >if it knows sip uri?) but I think that it can happen thanks to RFC3863 >(pidf) which mentions only pres uri to be inserted to the entity parameter. >> Could someone explain what is the correct behavior here? Is it possible >to have different uri's in To header and in the entity attribute? >> >> Thank you, >> >> Silvestr Peknik >> Software Specialist >> >> TietoEnator >> Czech Software Center >> Phone +420 599 096 027 >> Fax +420 599 096 110 >> E-mail silvestr.peknik@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 >> > >-- >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 May 25 07:07:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjDfg-0002H3-Ug; Thu, 25 May 2006 07:06:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjDff-0002Cm-Kn for simple@ietf.org; Thu, 25 May 2006 07:06:27 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjDfd-00066x-Sk for simple@ietf.org; Thu, 25 May 2006 07:06:27 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZT00GJEJCMJO@szxga02-in.huawei.com> for simple@ietf.org; Thu, 25 May 2006 19:17:10 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZT008JBJCMSS@szxga02-in.huawei.com> for simple@ietf.org; Thu, 25 May 2006 19:17:10 +0800 (CST) Received: from z53160 ([10.164.5.15]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZT00C29J42GO@szxml04-in.huawei.com> for simple@ietf.org; Thu, 25 May 2006 19:12:04 +0800 (CST) Date: Thu, 25 May 2006 19:01:54 +0800 From: Harrison Zhou To: simple@ietf.org Message-id: <022401c67fea$a2c397c0$0f05a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: fluffy@cisco.com, jon.peterson@neustar.biz, RjS@estacado.net, pkyzivat@cisco.com Subject: [Simple] Presence: in inter-domains X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harrison Zhou 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="===============0353565737==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0353565737== Content-type: multipart/alternative; boundary="Boundary_(ID_eNE3YgbX/CqUM1UxYRvq4Q)" This is a multi-part message in MIME format. --Boundary_(ID_eNE3YgbX/CqUM1UxYRvq4Q) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi: I think presence function has been very important and useful in SIP. If someone wants to use the other SIP's functions (such as Instance Message, voice, video) he or she will firstly get the peer's presence information. In inter-domains scenario,I think it is inefficient between presence servers if we use the SIP process rules in existence . For instance, userA1 and user A2 in domain example1.com and userB1 in domain example2.com. userA1 and user A2 both subscribed the userB1's presence information. if userB1's state is changed,the Presence Server in domain example2.com must send two NOTIFY to Presence Server in domain example1.com. And the two NOTIFY messages carry the same information. So if many UAs in domain example1.com all subscribed userB1's state, it will .... --Boundary_(ID_eNE3YgbX/CqUM1UxYRvq4Q) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi:
   I think presence function has been very important and useful in SIP.
   If someone wants to use the other SIP's functions (such as Instance
   Message, voice, video) he or she will firstly get the peer's presence
   information. 
   In inter-domains scenario,I think it is inefficient between presence
   servers if we use the SIP process rules in existence . For instance,
   userA1 and user A2 in domain example1.com and userB1 in domain
   example2.com. userA1 and user A2 both subscribed the userB1's presence
   information. if userB1's state is changed,the Presence Server in domain
   example2.com must send two NOTIFY to Presence Server in domain
   example1.com. And the two NOTIFY messages carry the same information.
   So if many UAs in domain example1.com all subscribed userB1's state,
   it will ....  
--Boundary_(ID_eNE3YgbX/CqUM1UxYRvq4Q)-- --===============0353565737== 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 --===============0353565737==-- From simple-bounces@ietf.org Sat May 27 19:53:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk8a3-0003cc-HU; Sat, 27 May 2006 19:52:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk8a2-0003cX-8I for simple@ietf.org; Sat, 27 May 2006 19:52:26 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fk8a1-0008Pm-1z for simple@ietf.org; Sat, 27 May 2006 19:52:26 -0400 Received: from bear.cs.columbia.edu (IDENT:hY29IIKxg0T0VkypYLlqE3v7ubHD+8lP@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k4RNqAX6010894 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 27 May 2006 19:52:22 -0400 (EDT) Received: from [128.59.23.96] (vs2140pc.cs.columbia.edu [128.59.23.96]) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k4RNqAfW030498; Sat, 27 May 2006 19:52:10 -0400 Message-ID: <4478E5A7.7050604@cs.columbia.edu> Date: Sat, 27 May 2006 19:49:59 -0400 From: Vishal Kumar Singh User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: simple@ietf.org, Jonathan Rosenberg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.5 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Simple] Question on Presence Data Model draft 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, In vehicle tracking for a user (applications), where should we put the information about the vehicle itself in the PIDF or in other words, how do we model the vehicle's information. Information about a vehicle is coming from a presence source in vehicle. This information may include vehicle's location and vehicle specific information like its ignition status, fuel status, movement status (parked, moving) etc. Regards, Vishal -- Not everything that can be counted counts, and not everything that counts can be counted. -By Albert Einstein _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon May 29 10:10:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkiQp-00019V-2b; Mon, 29 May 2006 10:09:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkiQn-00019P-Gq for simple@ietf.org; Mon, 29 May 2006 10:09:17 -0400 Received: from wr-out-0506.google.com ([64.233.184.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkiQl-0002N0-9g for simple@ietf.org; Mon, 29 May 2006 10:09:17 -0400 Received: by wr-out-0506.google.com with SMTP id i7so886864wra for ; Mon, 29 May 2006 07:09:12 -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:mime-version:content-type:content-transfer-encoding:content-disposition; b=eCDjAZnA0UXnzurPQfNiUoV2k8jUMygZRUOs0O/XkfT08v8/oUol9OBv0Hdmkcijzb1N5Prpqc+q0bvyAFrc8L3RI3kyp7KkvKSkU4e3FYUsfTSb7KaDwHA22VAsydDWcf4dAln0ujwykHA3LSmhK9sCfsbmgHDhKWspvHb5GfU= Received: by 10.64.131.14 with SMTP id e14mr992025qbd; Mon, 29 May 2006 07:09:12 -0700 (PDT) Received: by 10.64.220.8 with HTTP; Mon, 29 May 2006 07:09:12 -0700 (PDT) Message-ID: <9d77d7060605290709r16c71839xb3d6310868ea078e@mail.gmail.com> Date: Mon, 29 May 2006 22:09:12 +0800 From: "Xiang Ting" To: simple Subject: [Simple]Two questions about MSRP REPORT's byte range. MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Cullen Jennings , Paul Kyzivat , Rohan Mahy 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 In recent MSRP draft: draft-ietf-simple-message-sessions-14, page 25: If the Success-Report header field was set to "yes", then when a complete message has been received, the receiver MUST send a success REPORT with a byte range covering the whole message. If the Success- Report header field is set to "yes", then the receiver MAY generate incremental success REPORTs as the chunks are received. These can be sent periodically and cover all the bytes that have been received so far, or they can be sent after a chunk arrives and cover just the part from that chunk. Question 1: The statement force a REPORT need include a Byte-Range header, but the REPORT example (page 41) in this draft does not include such a header, as following: MSRP dkei38sd REPORT To-Path: msrp://alicepc.example.com:7777/iau39;tcp From-Path: msrp://bob.example.com:8888/9di4ea;tcp Message-ID: 12339sdqwer Status: 000 200 OK -------dkei38sd$ Is it conflict with protocol? Question 2: If a Byte-Range header is a must, how to send REPORT to an SEND requeste with empty body, such as: MSRP tid1234 SEND From-Path: msrp://alice.exampel.com:7777/dfafw3r34;tcp To-Path: msrp://bob.example.com:8888/e4w3rw34;tcp Message-ID: sfwe4rw3sdf Successful-Report: yes -------tid1234$ I think the REPORT maybe like following: MSRP dkei38sdw REPORT From-Path: msrp://alice.exampel.com:7777/dfafw3r34;tcp To-Path: msrp://bob.example.com:8888/e4w3rw34;tcp Message-ID: sfwe4rw3sdf Byte-Range: 0-0/0 Status: 000 200 OK -------dkei38sdw$ but the protocol say that the byte-range must start from 1, how to solve this conflict? Any reply is appreciated. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon May 29 11:07:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkjKv-0005fR-AZ; Mon, 29 May 2006 11:07:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkjKt-0005fL-JM for simple@ietf.org; Mon, 29 May 2006 11:07:15 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkjKs-0005O4-8t for simple@ietf.org; Mon, 29 May 2006 11:07:15 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 29 May 2006 08:07:14 -0700 X-IronPort-AV: i="4.05,184,1146466800"; d="scan'208"; a="1814737786:sNHT35609748" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k4TF7D6o029357; Mon, 29 May 2006 08:07:13 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4TF7CcL022632; Mon, 29 May 2006 08:07:13 -0700 (PDT) Received: from [192.168.1.2] ([10.21.113.88]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 08:07:12 -0700 In-Reply-To: <9d77d7060605290709r16c71839xb3d6310868ea078e@mail.gmail.com> References: <9d77d7060605290709r16c71839xb3d6310868ea078e@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6BC183A0-B09B-445E-B48B-5D9B725491AC@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Simple]Two questions about MSRP REPORT's byte range. Date: Mon, 29 May 2006 08:07:10 -0700 To: Xiang Ting , Adam Roach X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 29 May 2006 15:07:12.0774 (UTC) FILETIME=[90826A60:01C68331] DKIM-Signature: a=rsa-sha1; q=dns; l=2124; t=1148915233; x=1149779233; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Simple]Two=20questions=20about=20MSRP=20REPORT's=20byte=20range .; X=v=3Dcisco.com=3B=20h=3D2doCGGKEyrD9B2prMQy3BTkqiKA=3D; b=B8g2yrIzjJDA1uPf7tJnvRkzvg/+9XacA8gHpMI3GL3xUF3DmbYSaOXmyvrIjGknmqiNX+tv kJgyFGGZebzQb7301K69XecLEXYYKSaYDtZfHkE9HCQ7e8Xp/KFbnR1I; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Rohan Mahy , Paul Kyzivat , simple 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 Adam - question for you inline ... Xiang - good questions - thanks. On May 29, 2006, at 7:09 AM, Xiang Ting wrote: > In recent MSRP draft: draft-ietf-simple-message-sessions-14, page 25: > If the Success-Report header field was set to "yes", then when a > complete message has been received, the receiver MUST send a success > REPORT with a byte range covering the whole message. If the > Success- > Report header field is set to "yes", then the receiver MAY generate > incremental success REPORTs as the chunks are received. These > can be > sent periodically and cover all the bytes that have been received so > far, or they can be sent after a chunk arrives and cover just the > part from that chunk. > > Question 1: > The statement force a REPORT need include a Byte-Range header, but the > REPORT example (page 41) in this draft does not include such a header, > as following: > MSRP dkei38sd REPORT > To-Path: msrp://alicepc.example.com:7777/iau39;tcp > From-Path: msrp://bob.example.com:8888/9di4ea;tcp > Message-ID: 12339sdqwer > Status: 000 200 OK > -------dkei38sd$ > Is it conflict with protocol? This looks like a mistake - I think the example needs a Byte-Range header. Thanks for finding this. > > Question 2: > If a Byte-Range header is a must, how to send REPORT to an SEND > requeste with empty body, such as: > MSRP tid1234 SEND > From-Path: msrp://alice.exampel.com:7777/dfafw3r34;tcp > To-Path: msrp://bob.example.com:8888/e4w3rw34;tcp > Message-ID: sfwe4rw3sdf > Successful-Report: yes > -------tid1234$ > > I think the REPORT maybe like following: > MSRP dkei38sdw REPORT > From-Path: msrp://alice.exampel.com:7777/dfafw3r34;tcp > To-Path: msrp://bob.example.com:8888/e4w3rw34;tcp > Message-ID: sfwe4rw3sdf > Byte-Range: 0-0/0 > Status: 000 200 OK > -------dkei38sdw$ > but the protocol say that the byte-range must start from 1, how to > solve this conflict? I suspect this should be Byte-Range: 1-0/0 Adam, can you confirm this looks right to you? > > Any reply is appreciated. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 30 06:39:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl1bl-0008AW-Ga; Tue, 30 May 2006 06:37:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl1bj-0008AR-SJ for simple@ietf.org; Tue, 30 May 2006 06:37:51 -0400 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl1bi-0004ny-Dz for simple@ietf.org; Tue, 30 May 2006 06:37:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Simple] publishing presence state - sip and pres uris (again) Date: Tue, 30 May 2006 11:40:22 +0200 Message-ID: <3ACC9A25264A684F82C71840111F979801AC089D@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] publishing presence state - sip and pres uris (again) Thread-Index: AcaDzRJ/KAxCkTDTQk++ulgJNZasgg== From: To: X-OriginalArrivalTime: 30 May 2006 09:40:49.0436 (UTC) FILETIME=[2257EDC0:01C683CD] X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Hi, please could you check my questions? Thank you, Silvestr >-----Original Message----- >From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >Sent: Monday, May 01, 2006 9:21 PM >To: Peknik Silvestr >Cc: simple@ietf.org >Subject: Re: [Simple] publishing presence state - sip and pres uris > >This can happen, yes. The presence data model draft (out shortly as an >RFC) does say you shouldn't do this - that the URI in the SUBSCRIBE or=20 >PUBLISH should match that in the document. What is the relation between To header and r-URI? Currently it seems to me that the client should set both to the same value, but r-URI can be changed by proxies. If this is the case, why not to use To header instead of r-URI for identifying the target of the request? And if the r-URI can not be changed, what is the purpose of To header? > >That said, the presence server should know that the pres and sip URI are >equivalent, and thus even though the R-uri identifies the SIP URI, the=20 >document should be applied to the presentity URI sip:alan@example.com as >well. Consequently, a SUBSCRIBE request for sip:alan@example.com would=20 >return a presence document whose entity attribute is sip:alan@example.com. I guess there is typo - it should say: ...applied to the presentity URI pres:alan@example.com as well... Am I right? Thank you, Silvestr Peknik _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue May 30 18:51:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlD3J-0002tz-EN; Tue, 30 May 2006 18:51:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlD3H-0002tF-EK; Tue, 30 May 2006 18:51:03 -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 1FlD3H-0006Lq-A9; Tue, 30 May 2006 18:51:03 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlD3F-0003Qs-Qt; Tue, 30 May 2006 18:51:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k4UMo1mU007756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 May 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FlD2H-0000mh-A0; Tue, 30 May 2006 18: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: Tue, 30 May 2006 18:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-imdn-00.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 : Instant Message Disposition Notification Author(s) : E. Burger, H. Khartabil Filename : draft-ietf-simple-imdn-00.txt Pages : 27 Date : 2006-5-30 Instant Messaging (IM) refers to the transfer of messages between users in real-time. This document extends Message/CPIM message format to enable endpoints to request, create and send IM Disposition Notifications (IMDN), including delivery and read notifications, for page-mode as well as session mode instant messages. This document also describes how SIP and MSRP entities behave using this extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-00.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-imdn-00.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-imdn-00.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-5-30162236.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-imdn-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-imdn-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-30162236.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 Wed May 31 19:01:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlZh8-0001d0-Cp; Wed, 31 May 2006 19:01:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlZh6-0001co-Pc for simple@ietf.org; Wed, 31 May 2006 19:01:40 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlZh4-00071G-H3 for simple@ietf.org; Wed, 31 May 2006 19:01:40 -0400 Received: by py-out-1112.google.com with SMTP id i75so118739pye for ; Wed, 31 May 2006 16:01:38 -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=jHOe6kDX9QGIeCg0z5btoLcAWFRNiSvous1VJv4FqAORckuqUBQDWDPgQWuR7Y8skyA5Mnr/9p3pN0YVtxljJAoGKUan8Db4dOfz7P+Jj28yUnfQKKluqmOS5K/DsMTLDYX2ReXZtAoMuDOEDFQBBwGIaJQ+Dy6RZyyWNSdUNQ0= Received: by 10.35.29.6 with SMTP id g6mr837749pyj; Wed, 31 May 2006 16:01:37 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Wed, 31 May 2006 16:01:37 -0700 (PDT) Message-ID: <953beacc0605311601x17c4fdbav88e4e5b40b286da7@mail.gmail.com> Date: Wed, 31 May 2006 16:01:37 -0700 From: "Rohan Mahy" To: "Vishal Kumar Singh" Subject: Re: [Simple] Question on Presence Data Model draft In-Reply-To: <4478E5A7.7050604@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4478E5A7.7050604@cs.columbia.edu> 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 Hi Vishal, I'm assuming that the vehicle is a tuple for a human presentity--that the car doesn't have its own resource/presentity name. I don't think ignition is really orthogonal to movement status. I think you want a rich presence indicator of movement within the tuple representing the vehicle. The lock status might be relevant here as well. What you are probably trying to determine is 1) a state of occupancy, and 2) a state of distraction. Keep in mind that many hybrids don't require use of an ignition switch. I think these work for automobiles and trucks, but not for other types of vehicles: - parked locked (vehicle off) - parked unlocked (vehicle off) - standing (vehicle ready - idling/enabled) - stopped (vehicle not moving, but in a driving "gear") - under-way (vehicle in motion) You probably don't want fuel status. Projected range is probably more interesting. 1 liter of fuel in a Prius vs. 1 liter in a Hummer makes a big difference in range. The car stereo is often an interesting contributor to presence. Some cars even allow you to turn on the stereo with the ignition off. As a student I used to sit in my car while studying, because the stereo was better there. Be aware that many car stereos are easily heard (and listened to) outside the vehicle. Finally, if one or more of the seat belts are on this is probably a pretty reliable indicator of the presence of a human. Unfortunately, not having seat belts on is not a reliable indicator that there are *not* humans in the car. thanks, -rohan On 5/27/06, Vishal Kumar Singh wrote: > Hello, > > In vehicle tracking for a user (applications), where should we put the > information about the vehicle itself in the PIDF or in other words, how > do we model the vehicle's information. Information about a vehicle is > coming from a presence source in vehicle. This information may include > vehicle's location and vehicle specific information like its ignition > status, fuel status, movement status (parked, moving) etc. > > Regards, > Vishal > > -- > Not everything that can be counted counts, and not everything that > counts can be counted. > -By Albert Einstein > > _______________________________________________ > 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