From simple-admin@ietf.org Mon Mar 1 00:22:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05271 for ; Mon, 1 Mar 2004 00:22:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxftG-0001lv-00 for simple-archive@ietf.org; Mon, 01 Mar 2004 00:22:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxfsP-0001d2-00 for simple-archive@ietf.org; Mon, 01 Mar 2004 00:22:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxfrZ-0001Sy-00; Mon, 01 Mar 2004 00:21:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfrS-0004On-NE; Mon, 01 Mar 2004 00:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axfqv-0004GR-Rc for simple@optimus.ietf.org; Mon, 01 Mar 2004 00:20:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05065 for ; Mon, 1 Mar 2004 00:20:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axfqt-0001Ok-00 for simple@ietf.org; Mon, 01 Mar 2004 00:20:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axfq1-0001Ic-00 for simple@ietf.org; Mon, 01 Mar 2004 00:19:34 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1AxfpB-00017S-00 for simple@ietf.org; Mon, 01 Mar 2004 00:18:41 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 29 Feb 2004 21:18:01 -0800 Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 29 Feb 2004 21:18:12 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 29 Feb 2004 21:18:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.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] Inter-domain Requirements for SIMPLE Message-ID: Thread-Topic: [Simple] Inter-domain Requirements for SIMPLE Thread-Index: AcP/Rm47GX5c1y8eTKmCVssXW92aUwABB36w From: "Orit Levin" To: "Jonathan Rosenberg" Cc: "Robert Sparks" , "IETF SIMPLE WG" , "Avshalom Houri" X-OriginalArrivalTime: 01 Mar 2004 05:18:09.0991 (UTC) FILETIME=[96407570:01C3FF4C] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 29 Feb 2004 21:18:33 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Inline. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20 Sent: Sunday, February 29, 2004 8:33 PM To: Orit Levin Cc: Robert Sparks; IETF SIMPLE WG; Avshalom Houri Subject: Re: [Simple] Inter-domain Requirements for SIMPLE OK, now I understand. I think that this is not really the requirement; this is once again=20 really the main requirement here - optimizing message transfer between=20 domains.=20 OL: you are right that this specific new feature (7.1.2) is introduced in order to build a mechanism to meet requirement 7.3 . That being said, the draft identifies a number of orthogonal optimization approaches: 7.1.2, 7.2, and 7.3. What you are proposing is one mechanism for achieving that, but=20 not the only one. OL: Are you saying that other optimization approaches can be introduced (I would love to hear and explore each one of them) or are you saying that a different mechanism for achieving 7.3 can be introduced? (Again, let's hear/see it.) -Jonathan R. Orit Levin wrote: > The requirement is for the case where a subscription to a group exists > (i.e. the present information is available at the watchers' domain > already). Upon getting the permission, a new watcher is added to the > group and the presence information is delivered to it from its PS > locally. >=20 > Hope it clarifies the case, > Orit. >=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20 > Sent: Saturday, February 28, 2004 7:11 AM > To: Orit Levin > Cc: Robert Sparks; IETF SIMPLE WG; Avshalom Houri > Subject: Re: [Simple] Inter-domain Requirements for SIMPLE >=20 > Orit, >=20 > I am still confused on this requirement. >=20 > It sounds like what you want is for the watcher to find out if he has=20 > permission to subscribe or fetch presence from the presentity, without > actually subscribing or fetching? In other words, it would be a request=20 > from the watcher to the presentity to ask the presentity to set an=20 > authorization policy for the watcher, in absence of any specific=20 > subscription. Is that right? >=20 > If so, what is the motivating use case here? >=20 > THanks, > Jonathan R. >=20 > Orit Levin wrote: >=20 >=20 >>This requirement attempts to say: >> >>A potential watcher asks a presentity to grant access to presentity's >>presence information, but the watcher (or more precisely, its PS) is >=20 > not >=20 >>interested in the presence information being pushed on individual >=20 > basis >=20 >>from this point on. In other words, it can be implemented by just >=20 > adding >=20 >>the watcher to presentity's ACL. Or in case of groups, adding the >>requesting watcher to a specific group. >> >>Orit. >> >>-----Original Message----- >>From: Robert Sparks [mailto:rsparks@dynamicsoft.com]=20 >>Sent: Wednesday, February 25, 2004 8:48 AM >>To: Orit Levin >>Cc: IETF SIMPLE WG; Avshalom Houri >>Subject: Re: [Simple] Inter-domain Requirements for SIMPLE >> >>Orit, Avshalom - >> >>Thanks for submitting this draft. You've captured some >>important thoughts around deploying presence systems that >>deserve attention. I particularly look forward to the >>discussions we'll have around section 7.3 (Grouping of >>Watchers for SHARING of Presence Info). >> >>One quick question: I don't understand what you're looking >>for with the first requirement of 7.1: >> >> o Presence access: It MUST be possible to request continuous >> access to the status of a remote presentity without >> "subscribing" to it. >> >>Could you explain this a little more? >> >>RjS >> >>On Mon, 2004-02-23 at 17:33, Orit Levin wrote: >> >> >>>Guys! >>>We have submitted a requirements document for secure and efficient >>>transfer of presence information over inter-domain links. >>>Please, take a look at our thoughts and suggestions: >>> >>> >> >> > http://www.ietf.org/internet-drafts/draft-levin-simple-interdomain-reqs- >=20 >>00.txt >> >> >>>We look forward to your feedbacks on how we can enhance SIMPLE to >>>support these directions. >>> >>>Thanks, >>>Orit. >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> >=20 >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Mar 1 00:23:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05364 for ; Mon, 1 Mar 2004 00:23:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxftK-0004bV-AJ for simple-archive@odin.ietf.org; Mon, 01 Mar 2004 00:22:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i215Mwbe017691 for simple-archive@odin.ietf.org; Mon, 1 Mar 2004 00:22:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxftK-0004bG-69 for simple-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 00:22:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05289 for ; Mon, 1 Mar 2004 00:22:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxftH-0001m0-00 for simple-web-archive@ietf.org; Mon, 01 Mar 2004 00:22:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxfsQ-0001d9-00 for simple-web-archive@ietf.org; Mon, 01 Mar 2004 00:22:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxfrZ-0001Sy-00; Mon, 01 Mar 2004 00:21:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfrS-0004On-NE; Mon, 01 Mar 2004 00:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axfqv-0004GR-Rc for simple@optimus.ietf.org; Mon, 01 Mar 2004 00:20:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05065 for ; Mon, 1 Mar 2004 00:20:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axfqt-0001Ok-00 for simple@ietf.org; Mon, 01 Mar 2004 00:20:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axfq1-0001Ic-00 for simple@ietf.org; Mon, 01 Mar 2004 00:19:34 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1AxfpB-00017S-00 for simple@ietf.org; Mon, 01 Mar 2004 00:18:41 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 29 Feb 2004 21:18:01 -0800 Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 29 Feb 2004 21:18:12 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 29 Feb 2004 21:18:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.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] Inter-domain Requirements for SIMPLE Message-ID: Thread-Topic: [Simple] Inter-domain Requirements for SIMPLE Thread-Index: AcP/Rm47GX5c1y8eTKmCVssXW92aUwABB36w From: "Orit Levin" To: "Jonathan Rosenberg" Cc: "Robert Sparks" , "IETF SIMPLE WG" , "Avshalom Houri" X-OriginalArrivalTime: 01 Mar 2004 05:18:09.0991 (UTC) FILETIME=[96407570:01C3FF4C] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 29 Feb 2004 21:18:33 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Inline. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20 Sent: Sunday, February 29, 2004 8:33 PM To: Orit Levin Cc: Robert Sparks; IETF SIMPLE WG; Avshalom Houri Subject: Re: [Simple] Inter-domain Requirements for SIMPLE OK, now I understand. I think that this is not really the requirement; this is once again=20 really the main requirement here - optimizing message transfer between=20 domains.=20 OL: you are right that this specific new feature (7.1.2) is introduced in order to build a mechanism to meet requirement 7.3 . That being said, the draft identifies a number of orthogonal optimization approaches: 7.1.2, 7.2, and 7.3. What you are proposing is one mechanism for achieving that, but=20 not the only one. OL: Are you saying that other optimization approaches can be introduced (I would love to hear and explore each one of them) or are you saying that a different mechanism for achieving 7.3 can be introduced? (Again, let's hear/see it.) -Jonathan R. Orit Levin wrote: > The requirement is for the case where a subscription to a group exists > (i.e. the present information is available at the watchers' domain > already). Upon getting the permission, a new watcher is added to the > group and the presence information is delivered to it from its PS > locally. >=20 > Hope it clarifies the case, > Orit. >=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20 > Sent: Saturday, February 28, 2004 7:11 AM > To: Orit Levin > Cc: Robert Sparks; IETF SIMPLE WG; Avshalom Houri > Subject: Re: [Simple] Inter-domain Requirements for SIMPLE >=20 > Orit, >=20 > I am still confused on this requirement. >=20 > It sounds like what you want is for the watcher to find out if he has=20 > permission to subscribe or fetch presence from the presentity, without > actually subscribing or fetching? In other words, it would be a request=20 > from the watcher to the presentity to ask the presentity to set an=20 > authorization policy for the watcher, in absence of any specific=20 > subscription. Is that right? >=20 > If so, what is the motivating use case here? >=20 > THanks, > Jonathan R. >=20 > Orit Levin wrote: >=20 >=20 >>This requirement attempts to say: >> >>A potential watcher asks a presentity to grant access to presentity's >>presence information, but the watcher (or more precisely, its PS) is >=20 > not >=20 >>interested in the presence information being pushed on individual >=20 > basis >=20 >>from this point on. In other words, it can be implemented by just >=20 > adding >=20 >>the watcher to presentity's ACL. Or in case of groups, adding the >>requesting watcher to a specific group. >> >>Orit. >> >>-----Original Message----- >>From: Robert Sparks [mailto:rsparks@dynamicsoft.com]=20 >>Sent: Wednesday, February 25, 2004 8:48 AM >>To: Orit Levin >>Cc: IETF SIMPLE WG; Avshalom Houri >>Subject: Re: [Simple] Inter-domain Requirements for SIMPLE >> >>Orit, Avshalom - >> >>Thanks for submitting this draft. You've captured some >>important thoughts around deploying presence systems that >>deserve attention. I particularly look forward to the >>discussions we'll have around section 7.3 (Grouping of >>Watchers for SHARING of Presence Info). >> >>One quick question: I don't understand what you're looking >>for with the first requirement of 7.1: >> >> o Presence access: It MUST be possible to request continuous >> access to the status of a remote presentity without >> "subscribing" to it. >> >>Could you explain this a little more? >> >>RjS >> >>On Mon, 2004-02-23 at 17:33, Orit Levin wrote: >> >> >>>Guys! >>>We have submitted a requirements document for secure and efficient >>>transfer of presence information over inter-domain links. >>>Please, take a look at our thoughts and suggestions: >>> >>> >> >> > http://www.ietf.org/internet-drafts/draft-levin-simple-interdomain-reqs- >=20 >>00.txt >> >> >>>We look forward to your feedbacks on how we can enhance SIMPLE to >>>support these directions. >>> >>>Thanks, >>>Orit. >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> >=20 >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Mar 1 00:37:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06292 for ; Mon, 1 Mar 2004 00:37:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axg7T-0003Oc-00 for simple-archive@ietf.org; Mon, 01 Mar 2004 00:37:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axg6i-0003IV-00 for simple-archive@ietf.org; Mon, 01 Mar 2004 00:36:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axg63-0003Bw-00; Mon, 01 Mar 2004 00:36:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axg5x-00063l-J9; Mon, 01 Mar 2004 00:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axg5d-00060j-BI for simple@optimus.ietf.org; Mon, 01 Mar 2004 00:35:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06107 for ; Mon, 1 Mar 2004 00:35:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axg5a-00039m-00 for simple@ietf.org; Mon, 01 Mar 2004 00:35:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axg4g-00033N-00 for simple@ietf.org; Mon, 01 Mar 2004 00:34:42 -0500 Received: from pecan.cc.columbia.edu ([128.59.59.178] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 1Axg4D-0002wp-00 for simple@ietf.org; Mon, 01 Mar 2004 00:34:13 -0500 Received: from cs.columbia.edu (UBAHN.dhcp.ietf59.or.kr [218.37.227.100]) (user=hgs10 mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i215Y8K0010852 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 1 Mar 2004 00:34:10 -0500 (EST) Message-ID: <4042CB54.3080201@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: pidf namespace, was: Re: [Simple] comments on draft-ietf-simple-rpid (long) References: <4041F046.7050207@dynamicsoft.com> <40429762.4070101@cs.columbia.edu> <4042BB0A.20908@dynamicsoft.com> In-Reply-To: <4042BB0A.20908@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 00:34:12 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit According to the RFC editor: 2003/10/29 draft-ietf-impp-cpim-pidf-08.txt IANA H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. Peterson Presence Information Data Format (PIDF) Bytes: 55276 IANA seems to be taken its time, but it seems late to try to change a fairly basic part of PIDF at this time. The only limitation of using targetNamespace that there can't be another extension that also defines activity, relationship, etc., just in a different namespace. From a practical perspective, this seems like an advantage, not a drawback. Having two IETF extensions that use and seems to invite confusion to address non-problems (lack of coordination [these are IETF extensions, after all] and shortage of English words). Jonathan Rosenberg wrote: > I had forgotten about that bit. > > Actually, the text in PIDF seems wrong to me. Here is what it says: > > Although the existing PIDF definition allows arbitrary elements to > appear in the element, it may be sometimes desirable to > standardize extension status elements and their semantics (the > meanings of particular statuses, how they should be interpreted). The > URN 'urn:ietf:params:xml:ns:pidf:status' has been defined as a > namespace URI for extensions standardized by the IETF, and new values > in this namespace must be defined by a standards-track RFC. > > The following example XML Schema defines an extension for > presence information, which can have the values of 'home', 'office', > or 'car'. If the element were standardized, this document > would be made available in an RFC along with information about the > use of the extension. These extensions should use the namespace > 'urn:ietf:params:xml:ns:pidf:status', and each RFC defining an > extension should register an extension name within that namespace > with IANA. > > This seems to suggest that all extensions actually have the namespace > urn:ietf:params:xml:ns:pidf:status, as opposed to being WITHIN that > namespace. That interpretation is supported by the example which follows: > > > xmlns:tns="urn:ietf:params:xml:ns:pidf:status" > xmlns:xs="http://www.w3.org/2001/XMLSchema" > elementFormDefault="qualified" > attributeFormDefault="unqualified"> > > > note the target namespace. > > I don't think this is right; each extensions should have its own namespace. > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Mar 1 00:38:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06321 for ; Mon, 1 Mar 2004 00:38:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axg7W-0006Vg-P9 for simple-archive@odin.ietf.org; Mon, 01 Mar 2004 00:37:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i215bcTX025019 for simple-archive@odin.ietf.org; Mon, 1 Mar 2004 00:37:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axg7W-0006VN-Ft for simple-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 00:37:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06309 for ; Mon, 1 Mar 2004 00:37:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axg7T-0003Oi-00 for simple-web-archive@ietf.org; Mon, 01 Mar 2004 00:37:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axg6j-0003Id-00 for simple-web-archive@ietf.org; Mon, 01 Mar 2004 00:36:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axg63-0003Bw-00; Mon, 01 Mar 2004 00:36:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axg5x-00063l-J9; Mon, 01 Mar 2004 00:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axg5d-00060j-BI for simple@optimus.ietf.org; Mon, 01 Mar 2004 00:35:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06107 for ; Mon, 1 Mar 2004 00:35:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axg5a-00039m-00 for simple@ietf.org; Mon, 01 Mar 2004 00:35:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axg4g-00033N-00 for simple@ietf.org; Mon, 01 Mar 2004 00:34:42 -0500 Received: from pecan.cc.columbia.edu ([128.59.59.178] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 1Axg4D-0002wp-00 for simple@ietf.org; Mon, 01 Mar 2004 00:34:13 -0500 Received: from cs.columbia.edu (UBAHN.dhcp.ietf59.or.kr [218.37.227.100]) (user=hgs10 mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i215Y8K0010852 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 1 Mar 2004 00:34:10 -0500 (EST) Message-ID: <4042CB54.3080201@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: pidf namespace, was: Re: [Simple] comments on draft-ietf-simple-rpid (long) References: <4041F046.7050207@dynamicsoft.com> <40429762.4070101@cs.columbia.edu> <4042BB0A.20908@dynamicsoft.com> In-Reply-To: <4042BB0A.20908@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 00:34:12 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit According to the RFC editor: 2003/10/29 draft-ietf-impp-cpim-pidf-08.txt IANA H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. Peterson Presence Information Data Format (PIDF) Bytes: 55276 IANA seems to be taken its time, but it seems late to try to change a fairly basic part of PIDF at this time. The only limitation of using targetNamespace that there can't be another extension that also defines activity, relationship, etc., just in a different namespace. From a practical perspective, this seems like an advantage, not a drawback. Having two IETF extensions that use and seems to invite confusion to address non-problems (lack of coordination [these are IETF extensions, after all] and shortage of English words). Jonathan Rosenberg wrote: > I had forgotten about that bit. > > Actually, the text in PIDF seems wrong to me. Here is what it says: > > Although the existing PIDF definition allows arbitrary elements to > appear in the element, it may be sometimes desirable to > standardize extension status elements and their semantics (the > meanings of particular statuses, how they should be interpreted). The > URN 'urn:ietf:params:xml:ns:pidf:status' has been defined as a > namespace URI for extensions standardized by the IETF, and new values > in this namespace must be defined by a standards-track RFC. > > The following example XML Schema defines an extension for > presence information, which can have the values of 'home', 'office', > or 'car'. If the element were standardized, this document > would be made available in an RFC along with information about the > use of the extension. These extensions should use the namespace > 'urn:ietf:params:xml:ns:pidf:status', and each RFC defining an > extension should register an extension name within that namespace > with IANA. > > This seems to suggest that all extensions actually have the namespace > urn:ietf:params:xml:ns:pidf:status, as opposed to being WITHIN that > namespace. That interpretation is supported by the example which follows: > > > xmlns:tns="urn:ietf:params:xml:ns:pidf:status" > xmlns:xs="http://www.w3.org/2001/XMLSchema" > elementFormDefault="qualified" > attributeFormDefault="unqualified"> > > > note the target namespace. > > I don't think this is right; each extensions should have its own namespace. > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Mar 1 00:51:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07222 for ; Mon, 1 Mar 2004 00:51:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxgKy-000552-00 for simple-archive@ietf.org; Mon, 01 Mar 2004 00:51:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxgK2-0004zt-00 for simple-archive@ietf.org; Mon, 01 Mar 2004 00:50:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxgJX-0004uj-00; Mon, 01 Mar 2004 00:50:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgJW-00086t-CW; Mon, 01 Mar 2004 00:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgIz-000850-AL for simple@optimus.ietf.org; Mon, 01 Mar 2004 00:49:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07101 for ; Mon, 1 Mar 2004 00:49:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxgIw-0004sP-00 for simple@ietf.org; Mon, 01 Mar 2004 00:49:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxgI4-0004lR-00 for simple@ietf.org; Mon, 01 Mar 2004 00:48:33 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AxgHA-0004X7-00 for simple@ietf.org; Mon, 01 Mar 2004 00:47:36 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i215krUG005742; Mon, 1 Mar 2004 00:46:54 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA10215; Mon, 1 Mar 2004 00:46:53 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Mar 2004 00:46:53 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6479@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Niemi Aki (Nokia-M/Espoo)'" , ext Jonathan Rosenberg Cc: Markus.Isomaki@nokia.com, pkyzivat@cisco.com, hisham.khartabil@nokia.com, Miguel.An.Garcia@nokia.com, simple@ietf.org Subject: RE: [Simple] Chat sessions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 00:46:52 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Aki When we were discussing sidebars, I made arguments like this against making a sidebar a separate session. Sidebars, I argued, are just media (mixing) changes, they have nothing to do with session management. I lost this argument, and I will be very unhappy if IM works differently. One of the reasons I lost it was the observation that a sidebar could include participants who are not main conference participants. I think you have the same issue here. Brian > -----Original Message----- > From: Niemi Aki (Nokia-M/Espoo) [mailto:aki.niemi@nokia.com] > Sent: Sunday, February 29, 2004 12:40 PM > To: ext Jonathan Rosenberg > Cc: Markus.Isomaki@nokia.com; Brian.Rosen@marconi.com; > pkyzivat@cisco.com; hisham.khartabil@nokia.com; > Miguel.An.Garcia@nokia.com; simple@ietf.org > Subject: Re: [Simple] Chat sessions > > > > > ext Jonathan Rosenberg wrote: > > > >> 3. As Aki explained, sidebars and private IMs within a conference > >> are two different things. Sidebars are subconferences, that include > >> a certain subset of the participants in the main conference. They > >> need to be explicitly created and deleted. Private IMs within a > >> conference are also targeted to a subset of the conference > >> participants. But there is no need to setup a sidebar or any other > >> additional context to send them. The recipients can simply be > >> signaled within each message (as proposed by using CPIM To header). > >> This seems to be a specific property of IM, as this sort of > >> addressing would be impossible e.g. in RTP. In theory priate > >> messaging facility could be supported by sidebars, but in this case > >> the focus would need to have as many sidebars constantly setup, as > >> there are different possible participant subset combinations. Way > >> too complex and not needed. > > > > > > I dont think that, functionally, what you are describing is > different > > from a sidebar. What differs is that the specifics of this media > > type allow for a more efficient implementation of the sidebar than > > would be possible for another media type, such as audio. > Indeed, the > > same is true for IM in general - why set up a session (ala > msrp) when > > you can just send a pager mode? > > The ultimate proof of difference in functionality is that private > messages are usable and useful in a sidebar - in fact it makes no > difference whether they're sent within the context of a conference, a > conference sidebar, or a sidebar of a conference sidebar. > > Let me provide a concrete example of an already existing service (IRC) > that has what I think is a close approximation of both sidebar and > private message functionality. (BTW, I feel strongly that if MSRP > conferences aren't as feature rich as IRC is, and provide the > same user > experience, we've failed miserably.) > > Channels in IRC have identities, e.g., #helsinki, and > participant lists > that are delivered in a very similar manner that the conference-info > events would be delivered. Users join these channels using JOIN, at > which time they get the participant list, and after that, > updates e.g., > whenever anyone leaves or joins the channel. > > Users can send private messages to the other participants in > the channel: > > PRIVMSG foobar :Some nick you got there foobar! > > Usually, these messages are displayed in the same pane as the rest of > the channel's messages, including information about the sender but > marked accordingly as private. > > A user can also invite others to a sidebar of sorts, that is, a new > channel, whose properties can be set such that it can be joined by > invitation only. > > INVITE FunnyNick #my_channel > INVITE BeerLover #my_channel > INVITE ROOLZ #my_channel > > Joining this new channel as a result of an invitation (with JOIN) > usually results in a new window, moving the focus of conversation away > from the original channel, but still maintaining the original channel' > and its messages active in the background. > > The users may again send messages either to the entire > channel (MSG), or > to only one participant (PRIVMSG). A recipient of an INVITE will > generally make a choice just like in a SIP invitation whether > or not to > join the sidebar or not. Receiving a PRIVMSG requires no actions from > the recipient. Indeed, it might even go unnoticed. > > Taking this into account, I fail to see how sidebars alone can be made > to work in providing similar functionality in MSRP conferences. Either > sidears or private messages alone won't result in the same level of > functionality. > > Wrapping all private conversation inside a sidebar is incredibly > inefficient and results in bad user experience, since there > is no way to > distinguish a REFER that is to a sidebar whose sole purpose > is to send a > single private message to the user or have a real ad-hoc conversation > posibly consisting of a real exchange of messages. In fact, this would > require 4 rounds of singalling (not including sidebar creation and > tear-down), plus user interaction in between: > > REFER (to sidebar) > 200 OK > > -Query/inform user whether wants to join- > > INVITE (to sidebar) > 200 OK > ACK > > (Note: would probably also require subscription to conference-info, > because one would be interested to whom they are sending the private > messages...) > > MSRP SEND > MSRP OK > > BYE > 200 OK > > ...as opposed to a single round of messages: > > MSRP SEND (private) > 200 OK > > (Note that enabling auto-answering wrt the REFER would in the > worst case > result in a sidebar bombardment, or having a user be moved over to a > sidebar in the middle of, say, message composition.) > > The same level of functionality would also not be met with only using > private messages. AFAIK, the purpose of a sidebar is to move the focus > of the conversation temporarily outside the original conference. This > requires being able to wrap a discussion into a separate > context. A very > important aspect of this is to let the user decide whether to > joing such > a sidebar, and when to join it. Determining to which context a > particular received private message belongs to can in this > case only be > done in the recipients head - there are no protocol elements to help. > > As a conclusion, I don't see how sidebars alone can provide > the required > functionality. > > > > > So, the question is, do we see the perceived efficiency > improvements > > of a pager-mode sidebar as being sufficiently good to allow for > > defining a separate sidebar mechanism for it? > > It is also about user interaction. When a user receives an > INVITE for an > MSRP session, it can make a choice just like in a voice call between > accepting the call or rejecting it. Page mode doesn't provide that > functionality. > > Cheers, > Aki > > > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Mar 1 00:52:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07250 for ; Mon, 1 Mar 2004 00:52:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgL2-0008Hg-3E for simple-archive@odin.ietf.org; Mon, 01 Mar 2004 00:51:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i215paJ2031838 for simple-archive@odin.ietf.org; Mon, 1 Mar 2004 00:51:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgL1-0008HO-Us for simple-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 00:51:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07236 for ; Mon, 1 Mar 2004 00:51:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxgKz-000557-00 for simple-web-archive@ietf.org; Mon, 01 Mar 2004 00:51:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxgK3-000501-00 for simple-web-archive@ietf.org; Mon, 01 Mar 2004 00:50:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxgJX-0004uj-00; Mon, 01 Mar 2004 00:50:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgJW-00086t-CW; Mon, 01 Mar 2004 00:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgIz-000850-AL for simple@optimus.ietf.org; Mon, 01 Mar 2004 00:49:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07101 for ; Mon, 1 Mar 2004 00:49:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxgIw-0004sP-00 for simple@ietf.org; Mon, 01 Mar 2004 00:49:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxgI4-0004lR-00 for simple@ietf.org; Mon, 01 Mar 2004 00:48:33 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AxgHA-0004X7-00 for simple@ietf.org; Mon, 01 Mar 2004 00:47:36 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i215krUG005742; Mon, 1 Mar 2004 00:46:54 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id AAA10215; Mon, 1 Mar 2004 00:46:53 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Mar 2004 00:46:53 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6479@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Niemi Aki (Nokia-M/Espoo)'" , ext Jonathan Rosenberg Cc: Markus.Isomaki@nokia.com, pkyzivat@cisco.com, hisham.khartabil@nokia.com, Miguel.An.Garcia@nokia.com, simple@ietf.org Subject: RE: [Simple] Chat sessions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 00:46:52 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Aki When we were discussing sidebars, I made arguments like this against making a sidebar a separate session. Sidebars, I argued, are just media (mixing) changes, they have nothing to do with session management. I lost this argument, and I will be very unhappy if IM works differently. One of the reasons I lost it was the observation that a sidebar could include participants who are not main conference participants. I think you have the same issue here. Brian > -----Original Message----- > From: Niemi Aki (Nokia-M/Espoo) [mailto:aki.niemi@nokia.com] > Sent: Sunday, February 29, 2004 12:40 PM > To: ext Jonathan Rosenberg > Cc: Markus.Isomaki@nokia.com; Brian.Rosen@marconi.com; > pkyzivat@cisco.com; hisham.khartabil@nokia.com; > Miguel.An.Garcia@nokia.com; simple@ietf.org > Subject: Re: [Simple] Chat sessions > > > > > ext Jonathan Rosenberg wrote: > > > >> 3. As Aki explained, sidebars and private IMs within a conference > >> are two different things. Sidebars are subconferences, that include > >> a certain subset of the participants in the main conference. They > >> need to be explicitly created and deleted. Private IMs within a > >> conference are also targeted to a subset of the conference > >> participants. But there is no need to setup a sidebar or any other > >> additional context to send them. The recipients can simply be > >> signaled within each message (as proposed by using CPIM To header). > >> This seems to be a specific property of IM, as this sort of > >> addressing would be impossible e.g. in RTP. In theory priate > >> messaging facility could be supported by sidebars, but in this case > >> the focus would need to have as many sidebars constantly setup, as > >> there are different possible participant subset combinations. Way > >> too complex and not needed. > > > > > > I dont think that, functionally, what you are describing is > different > > from a sidebar. What differs is that the specifics of this media > > type allow for a more efficient implementation of the sidebar than > > would be possible for another media type, such as audio. > Indeed, the > > same is true for IM in general - why set up a session (ala > msrp) when > > you can just send a pager mode? > > The ultimate proof of difference in functionality is that private > messages are usable and useful in a sidebar - in fact it makes no > difference whether they're sent within the context of a conference, a > conference sidebar, or a sidebar of a conference sidebar. > > Let me provide a concrete example of an already existing service (IRC) > that has what I think is a close approximation of both sidebar and > private message functionality. (BTW, I feel strongly that if MSRP > conferences aren't as feature rich as IRC is, and provide the > same user > experience, we've failed miserably.) > > Channels in IRC have identities, e.g., #helsinki, and > participant lists > that are delivered in a very similar manner that the conference-info > events would be delivered. Users join these channels using JOIN, at > which time they get the participant list, and after that, > updates e.g., > whenever anyone leaves or joins the channel. > > Users can send private messages to the other participants in > the channel: > > PRIVMSG foobar :Some nick you got there foobar! > > Usually, these messages are displayed in the same pane as the rest of > the channel's messages, including information about the sender but > marked accordingly as private. > > A user can also invite others to a sidebar of sorts, that is, a new > channel, whose properties can be set such that it can be joined by > invitation only. > > INVITE FunnyNick #my_channel > INVITE BeerLover #my_channel > INVITE ROOLZ #my_channel > > Joining this new channel as a result of an invitation (with JOIN) > usually results in a new window, moving the focus of conversation away > from the original channel, but still maintaining the original channel' > and its messages active in the background. > > The users may again send messages either to the entire > channel (MSG), or > to only one participant (PRIVMSG). A recipient of an INVITE will > generally make a choice just like in a SIP invitation whether > or not to > join the sidebar or not. Receiving a PRIVMSG requires no actions from > the recipient. Indeed, it might even go unnoticed. > > Taking this into account, I fail to see how sidebars alone can be made > to work in providing similar functionality in MSRP conferences. Either > sidears or private messages alone won't result in the same level of > functionality. > > Wrapping all private conversation inside a sidebar is incredibly > inefficient and results in bad user experience, since there > is no way to > distinguish a REFER that is to a sidebar whose sole purpose > is to send a > single private message to the user or have a real ad-hoc conversation > posibly consisting of a real exchange of messages. In fact, this would > require 4 rounds of singalling (not including sidebar creation and > tear-down), plus user interaction in between: > > REFER (to sidebar) > 200 OK > > -Query/inform user whether wants to join- > > INVITE (to sidebar) > 200 OK > ACK > > (Note: would probably also require subscription to conference-info, > because one would be interested to whom they are sending the private > messages...) > > MSRP SEND > MSRP OK > > BYE > 200 OK > > ...as opposed to a single round of messages: > > MSRP SEND (private) > 200 OK > > (Note that enabling auto-answering wrt the REFER would in the > worst case > result in a sidebar bombardment, or having a user be moved over to a > sidebar in the middle of, say, message composition.) > > The same level of functionality would also not be met with only using > private messages. AFAIK, the purpose of a sidebar is to move the focus > of the conversation temporarily outside the original conference. This > requires being able to wrap a discussion into a separate > context. A very > important aspect of this is to let the user decide whether to > joing such > a sidebar, and when to join it. Determining to which context a > particular received private message belongs to can in this > case only be > done in the recipients head - there are no protocol elements to help. > > As a conclusion, I don't see how sidebars alone can provide > the required > functionality. > > > > > So, the question is, do we see the perceived efficiency > improvements > > of a pager-mode sidebar as being sufficiently good to allow for > > defining a separate sidebar mechanism for it? > > It is also about user interaction. When a user receives an > INVITE for an > MSRP session, it can make a choice just like in a voice call between > accepting the call or rejecting it. Page mode doesn't provide that > functionality. > > Cheers, > Aki > > > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Mar 1 00:55:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07468 for ; Mon, 1 Mar 2004 00:55:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxgOo-0005Ue-00 for simple-archive@ietf.org; Mon, 01 Mar 2004 00:55:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxgNv-0005Ou-00 for simple-archive@ietf.org; Mon, 01 Mar 2004 00:54:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxgNP-0005J7-00; Mon, 01 Mar 2004 00:54:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgNO-00005c-TX; Mon, 01 Mar 2004 00:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgMr-0008Ok-Qz for simple@optimus.ietf.org; Mon, 01 Mar 2004 00:53:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07324 for ; Mon, 1 Mar 2004 00:53:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxgMp-0005HA-00 for simple@ietf.org; Mon, 01 Mar 2004 00:53:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxgLs-0005BD-00 for simple@ietf.org; Mon, 01 Mar 2004 00:52:29 -0500 Received: from brazilnut.cc.columbia.edu ([128.59.59.203] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 1AxgL1-00055U-00 for simple@ietf.org; Mon, 01 Mar 2004 00:51:35 -0500 Received: from cs.columbia.edu (UBAHN.dhcp.ietf59.or.kr [218.37.227.100]) (user=hgs10 mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i215pQiA012662 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 1 Mar 2004 00:51:28 -0500 (EST) Message-ID: <4042CF62.7030907@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , Simple WG Subject: Re: [Simple] comments on draft-ietf-simple-rpid (long) References: <4041F046.7050207@dynamicsoft.com> <4042B316.4050104@cisco.com> In-Reply-To: <4042B316.4050104@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 00:51:30 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: >> How does busy differ from closed? Also, I dont see a reason why it >> couldnt automatically be generated. For example, if I'm in a meeting. > > > It differs because it means that you (probably) don't want to > communicate, not that you can't. A call will possibly result in alerting > the presentity. It may then result in no answer, or an answer from > someone who will be annoyed with you. > > While it could be generated automatically, I think maybe the assumption > was that automated generation could be more precise. OTOH, it may be > that filtering will turn the more precise specifications into this one > in order to be less specific. So maybe the 2nd sentence should be removed. Reworded to User is busy, without further details. While this activity would typically be associated with a status of CLOSED, a presentity may declare itself busy to discourage communication, but indicate that it still can be reached if needed. > Maybe that the phone would ring without answer? Or that it would be > answered by whoever the phone number was reassigned to? (Aren't phone > numbers wonderful?) Added sentence along those lines. This interpretation implies that OPEN implies nothing about the usefulness of communication that is possible. > I have a related issue that I thought I already raised, but maybe not. > > I agree with your characterization of idle on commercial IM systems, and > that is probably what we want for those built with SIMPLE as well. But > when we extend the notion of presence to phones we typically get a > different semantic. It is common to be in close proximity to a phone and > yet not use it for long periods of time. So if idle is based on how long > since the phone was used, then a long idle time says nothing about the > likelihood that a call would be answered. And conversely, a lack of an > status likely increases the probability that a call won't be > answered. > > So we end up with a status attribute whose significance is dependent on > the type of device publishing it. That seems like a bad thing. I'm not > sure what the solution is. Perhaps replacing idle with an attribute that > expressed a probability that the device is attended? I can't see how a PC or phone could compute these probabilities. This would require knowing that 10 minutes of absence (the only observable value), for a particular user, implies that there's a 20% chance that the user has stepped out. Unless your PC or phone has a user proximity detector, this seems hard to do. We do have the contact-type to allow the receiver to guess what this may mean. I think we discussed this before: in almost all cases, the value of a long idle time is not all that high (unless you know that the presentity is either a telemarketer who doesn't exist without a phone or a compulsive PC user that doesn't take his hands off the keyboard while in the office), but a short idle time is a good indication that somebody is likely home, be it a phone or PC. Thus, my suggestion is to leave this as is and not try to over-interpret the value. > > > _______________________________________________ > 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-admin@ietf.org Mon Mar 1 01:00:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07766 for ; Mon, 1 Mar 2004 01:00:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxgTj-00062J-00 for simple-archive@ietf.org; Mon, 01 Mar 2004 01:00:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxgSu-0005vh-00 for simple-archive@ietf.org; Mon, 01 Mar 2004 00:59:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxgSH-0005pc-00; Mon, 01 Mar 2004 00:59:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgSC-0000xJ-WE; Mon, 01 Mar 2004 00:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgRg-0000w8-9u for simple@optimus.ietf.org; Mon, 01 Mar 2004 00:58:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07602 for ; Mon, 1 Mar 2004 00:58:24 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxgRd-0005mQ-00 for simple@ietf.org; Mon, 01 Mar 2004 00:58:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxgQb-0005fi-00 for simple@ietf.org; Mon, 01 Mar 2004 00:57:22 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AxgPd-0005YJ-00 for simple@ietf.org; Mon, 01 Mar 2004 00:56:21 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i215uJ017528; Mon, 1 Mar 2004 07:56:19 +0200 (EET) X-Scanned: Mon, 1 Mar 2004 07:56:15 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i215uFve012164; Mon, 1 Mar 2004 07:56:15 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00aGxb8i; Mon, 01 Mar 2004 07:56:14 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i215uE724891; Mon, 1 Mar 2004 07:56:14 +0200 (EET) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 07:56:13 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Simple] comments on draft-ietf-simple-xcap-list-usage-00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797802@esebe019.ntc.nokia.com> Thread-Topic: [Simple] comments on draft-ietf-simple-xcap-list-usage-00 Thread-Index: AcP/RaynMtr7pZQIRxGNnDL5cX01wwAC+mgQ To: Cc: X-OriginalArrivalTime: 01 Mar 2004 05:56:13.0676 (UTC) FILETIME=[E76F22C0:01C3FF51] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 07:56:13 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > Sent: 01.March.2004 06:28 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: 'simple@ietf.org' > Subject: RE: [Simple] comments on draft-ietf-simple-xcap-list-usage-00 >=20 >=20 >=20 >=20 > One problem with this approach is that "name" is an > optional attribute in the latest draft. If you remove > URI to be an element, then it becomes difficult (if > not impossible; I'm not an XPATH expert) to identify > an entry. That's not a problem. You can still identify an entry by its position, = which xcap allows, btw. >=20 > There is strong motivation to have a very small notation > for minimal list, along the lines of: >=20 > > > Yes, I was thinking the same. If the uri in unique, why do we need name? /Hisham >=20 > /a >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Sunday, February 29, 2004 20:34 > > To: adam@dynamicsoft.com > > Subject: RE: [Simple] comments on=20 > draft-ietf-simple-xcap-list-usage-00 > >=20 > >=20 > > Yes. > >=20 > > Instead of=20 > >=20 > > > > Hisham Khartabil > > > >=20 > > I'm proposing: > >=20 > > > > sip:hisham@nokia.com > > Hisham Khartabil > > > >=20 > > /Hisham > >=20 > > > -----Original Message----- > > > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > > > Sent: 01.March.2004 03:48 > > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org > > > Cc: Jonathan Rosenberg > > > Subject: RE: [Simple] comments on=20 > > draft-ietf-simple-xcap-list-usage-00 > > >=20 > > >=20 > > >=20 > > > hisham.khartabil@nokia.com=20 > > [mailto:hisham.khartabil@nokia.com] writes: > > >=20 > > > > - Section 3: and element has 2 attributes, name and=20 > > > > uri. For xcap specific reasons, I understand why name needs=20 > > > > to be an attribute > > >=20 > > > Yes, I agree that it does, and that the reasons are rather > > > specific to XCAP. > > >=20 > > > > but I think it is much cleaner to have=20 > > > > the uri as an element. It fits in better with the=20 > > > > display-name element and other extensions that will go there. > > >=20 > > > So... are you proposing a change or not? > > >=20 > > > /a > > >=20 > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Mar 1 01:01:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07813 for ; Mon, 1 Mar 2004 01:01:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgTn-00016B-3W for simple-archive@odin.ietf.org; Mon, 01 Mar 2004 01:00:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2160dYk004217 for simple-archive@odin.ietf.org; Mon, 1 Mar 2004 01:00:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgTn-00015w-01 for simple-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 01:00:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07784 for ; Mon, 1 Mar 2004 01:00:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxgTk-00062O-00 for simple-web-archive@ietf.org; Mon, 01 Mar 2004 01:00:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxgSu-0005vo-00 for simple-web-archive@ietf.org; Mon, 01 Mar 2004 00:59:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxgSH-0005pc-00; Mon, 01 Mar 2004 00:59:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgSC-0000xJ-WE; Mon, 01 Mar 2004 00:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgRg-0000w8-9u for simple@optimus.ietf.org; Mon, 01 Mar 2004 00:58:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07602 for ; Mon, 1 Mar 2004 00:58:24 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxgRd-0005mQ-00 for simple@ietf.org; Mon, 01 Mar 2004 00:58:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxgQb-0005fi-00 for simple@ietf.org; Mon, 01 Mar 2004 00:57:22 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AxgPd-0005YJ-00 for simple@ietf.org; Mon, 01 Mar 2004 00:56:21 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i215uJ017528; Mon, 1 Mar 2004 07:56:19 +0200 (EET) X-Scanned: Mon, 1 Mar 2004 07:56:15 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i215uFve012164; Mon, 1 Mar 2004 07:56:15 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00aGxb8i; Mon, 01 Mar 2004 07:56:14 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i215uE724891; Mon, 1 Mar 2004 07:56:14 +0200 (EET) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 07:56:13 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Simple] comments on draft-ietf-simple-xcap-list-usage-00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797802@esebe019.ntc.nokia.com> Thread-Topic: [Simple] comments on draft-ietf-simple-xcap-list-usage-00 Thread-Index: AcP/RaynMtr7pZQIRxGNnDL5cX01wwAC+mgQ To: Cc: X-OriginalArrivalTime: 01 Mar 2004 05:56:13.0676 (UTC) FILETIME=[E76F22C0:01C3FF51] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 07:56:13 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > Sent: 01.March.2004 06:28 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: 'simple@ietf.org' > Subject: RE: [Simple] comments on draft-ietf-simple-xcap-list-usage-00 >=20 >=20 >=20 >=20 > One problem with this approach is that "name" is an > optional attribute in the latest draft. If you remove > URI to be an element, then it becomes difficult (if > not impossible; I'm not an XPATH expert) to identify > an entry. That's not a problem. You can still identify an entry by its position, = which xcap allows, btw. >=20 > There is strong motivation to have a very small notation > for minimal list, along the lines of: >=20 > > > Yes, I was thinking the same. If the uri in unique, why do we need name? /Hisham >=20 > /a >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Sunday, February 29, 2004 20:34 > > To: adam@dynamicsoft.com > > Subject: RE: [Simple] comments on=20 > draft-ietf-simple-xcap-list-usage-00 > >=20 > >=20 > > Yes. > >=20 > > Instead of=20 > >=20 > > > > Hisham Khartabil > > > >=20 > > I'm proposing: > >=20 > > > > sip:hisham@nokia.com > > Hisham Khartabil > > > >=20 > > /Hisham > >=20 > > > -----Original Message----- > > > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > > > Sent: 01.March.2004 03:48 > > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); simple@ietf.org > > > Cc: Jonathan Rosenberg > > > Subject: RE: [Simple] comments on=20 > > draft-ietf-simple-xcap-list-usage-00 > > >=20 > > >=20 > > >=20 > > > hisham.khartabil@nokia.com=20 > > [mailto:hisham.khartabil@nokia.com] writes: > > >=20 > > > > - Section 3: and element has 2 attributes, name and=20 > > > > uri. For xcap specific reasons, I understand why name needs=20 > > > > to be an attribute > > >=20 > > > Yes, I agree that it does, and that the reasons are rather > > > specific to XCAP. > > >=20 > > > > but I think it is much cleaner to have=20 > > > > the uri as an element. It fits in better with the=20 > > > > display-name element and other extensions that will go there. > > >=20 > > > So... are you proposing a change or not? > > >=20 > > > /a > > >=20 > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Mar 1 01:49:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09305 for ; Mon, 1 Mar 2004 01:49:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxhEy-0002Fp-00 for simple-archive@ietf.org; Mon, 01 Mar 2004 01:49:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxhDz-0002B5-00 for simple-archive@ietf.org; Mon, 01 Mar 2004 01:48:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxhDo-00027e-00; Mon, 01 Mar 2004 01:48:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhDd-0005cx-BZ; Mon, 01 Mar 2004 01:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhD4-0005cX-4M for simple@optimus.ietf.org; Mon, 01 Mar 2004 01:47:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09275 for ; Mon, 1 Mar 2004 01:47:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxhD0-00027J-00 for simple@ietf.org; Mon, 01 Mar 2004 01:47:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxhC7-00023Z-00 for simple@ietf.org; Mon, 01 Mar 2004 01:46:28 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AxhBN-0001ue-00 for simple@ietf.org; Mon, 01 Mar 2004 01:45:41 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 29 Feb 2004 22:45:23 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i216iUvV016524; Sun, 29 Feb 2004 22:44:31 -0800 (PST) Received: from cisco.com (sin-vpn-client-20-17.cisco.com [10.68.20.17]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGK32978; Mon, 1 Mar 2004 01:44:27 -0500 (EST) Message-ID: <4042DBCA.9050007@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger CC: simple@ietf.org Subject: Re: [Simple] RE: Advanced IM requirements References: <4A3384433CE2AB46A63468CB207E209DB1A213@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 01:44:26 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Eric Burger wrote: > I agree. Again, this highlights why IMDN is at the CPIM, and not SIP, level. > > Further, what is the use case for MDN in session mode? Would anyone EVER use it? I doubt it: if you are in a session, presumably you are interactive, which means you have OOB methods for knowing the message wasn't read (e.g., no response from the other person). I agree it doesn't seem like something that normally would be used. But there may be some cases. I may want explicit confirmation that a particular message has not only been delivered, but read. (This might require the UAS to demand some explicit confirmation from the end user before sending the confirmation.) Another case is with an IM conference. If I send a message to the mixer, requesting confirmation, ideally that would be an end-to-all-ends confirmation. The mixer would have to request and receive confirmation from all recipients before confirming to sender. > Given that assertion, can we say IMDN's are page mode messages. Based on above, I say NO. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Mar 1 01:49:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09329 for ; Mon, 1 Mar 2004 01:49:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhF2-0005jr-MU for simple-archive@odin.ietf.org; Mon, 01 Mar 2004 01:49:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i216nSS0022053 for simple-archive@odin.ietf.org; Mon, 1 Mar 2004 01:49:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhF2-0005jc-D9 for simple-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 01:49:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09320 for ; Mon, 1 Mar 2004 01:49:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxhEz-0002Fu-00 for simple-web-archive@ietf.org; Mon, 01 Mar 2004 01:49:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxhDz-0002BD-00 for simple-web-archive@ietf.org; Mon, 01 Mar 2004 01:48:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxhDo-00027e-00; Mon, 01 Mar 2004 01:48:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhDd-0005cx-BZ; Mon, 01 Mar 2004 01:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhD4-0005cX-4M for simple@optimus.ietf.org; Mon, 01 Mar 2004 01:47:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09275 for ; Mon, 1 Mar 2004 01:47:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxhD0-00027J-00 for simple@ietf.org; Mon, 01 Mar 2004 01:47:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxhC7-00023Z-00 for simple@ietf.org; Mon, 01 Mar 2004 01:46:28 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AxhBN-0001ue-00 for simple@ietf.org; Mon, 01 Mar 2004 01:45:41 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 29 Feb 2004 22:45:23 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i216iUvV016524; Sun, 29 Feb 2004 22:44:31 -0800 (PST) Received: from cisco.com (sin-vpn-client-20-17.cisco.com [10.68.20.17]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGK32978; Mon, 1 Mar 2004 01:44:27 -0500 (EST) Message-ID: <4042DBCA.9050007@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger CC: simple@ietf.org Subject: Re: [Simple] RE: Advanced IM requirements References: <4A3384433CE2AB46A63468CB207E209DB1A213@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 01:44:26 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric Burger wrote: > I agree. Again, this highlights why IMDN is at the CPIM, and not SIP, level. > > Further, what is the use case for MDN in session mode? Would anyone EVER use it? I doubt it: if you are in a session, presumably you are interactive, which means you have OOB methods for knowing the message wasn't read (e.g., no response from the other person). I agree it doesn't seem like something that normally would be used. But there may be some cases. I may want explicit confirmation that a particular message has not only been delivered, but read. (This might require the UAS to demand some explicit confirmation from the end user before sending the confirmation.) Another case is with an IM conference. If I send a message to the mixer, requesting confirmation, ideally that would be an end-to-all-ends confirmation. The mixer would have to request and receive confirmation from all recipients before confirming to sender. > Given that assertion, can we say IMDN's are page mode messages. Based on above, I say NO. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Mar 1 02:03:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12925 for ; Mon, 1 Mar 2004 02:03:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxhSq-00041g-00 for simple-archive@ietf.org; Mon, 01 Mar 2004 02:03:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxhRr-0003uf-00 for simple-archive@ietf.org; Mon, 01 Mar 2004 02:02:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxhRN-0003oC-00; Mon, 01 Mar 2004 02:02:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhRG-0007Yi-Rs; Mon, 01 Mar 2004 02:02:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhQt-0007TW-4j for simple@optimus.ietf.org; Mon, 01 Mar 2004 02:01:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11450 for ; Mon, 1 Mar 2004 02:01:40 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxhQp-0003mB-00 for simple@ietf.org; Mon, 01 Mar 2004 02:01:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxhQ4-0003g4-00 for simple@ietf.org; Mon, 01 Mar 2004 02:00:53 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AxhPV-0003Yv-00 for simple@ietf.org; Mon, 01 Mar 2004 02:00:17 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i21709T28919; Mon, 1 Mar 2004 09:00:09 +0200 (EET) X-Scanned: Mon, 1 Mar 2004 09:00:05 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i21705PA012155; Mon, 1 Mar 2004 09:00:05 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00spB7Yy; Mon, 01 Mar 2004 09:00:05 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i21704O29358; Mon, 1 Mar 2004 09:00:04 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 09:00:05 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 09:00:04 +0200 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] MSRP & Comedia X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797803@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP & Comedia Thread-Index: AcP+lLTM6HYaWkHRTxe2QnPjD/fJogAxaWXQ To: , , , , Cc: X-OriginalArrivalTime: 01 Mar 2004 07:00:04.0762 (UTC) FILETIME=[D2F077A0:01C3FF5A] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 09:00:03 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable In some cases, different INVITEs cause different applications to start = at the UAS. The way to differentiate between those INVITEs is sometimes = by using the sdp as a clue. For those devices, receiving INVITE with no = sdp might cause problems. The UAS needs to guess what application to = start. /Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Cullen Jennings > Sent: 27.February.2004 08:50 > To: Ben Campbell; Robert Sparks; Rohan Mahy; Adam Roach > Cc: simple@ietf.org > Subject: [Simple] MSRP & Comedia >=20 >=20 >=20 > This is a half baked idea that I am just tossing out as food=20 > for thought >=20 > Consider a systems where something like the UA that sends the=20 > answer sends > the VISIT.=20 >=20 > Consider the cases where A want to set up a MSRP session with B. >=20 > A is behind a NAT and does not want to use a relay. A sends=20 > an INVITE with > no offer. B sends an offer, gets back an answer and A sends the VISIT. > A -> inv -> B > A <- offer <- B > A -> answer -> B > A -> visit -> B >=20 > B is behind a NAT. A sends an offer and B sends an answer and=20 > A sends VISIT. > A -> offer -> B > A <- answer <- B > A <- visit <- B >=20 > A and B are behind NATS. A sends INVITE no offer, B knows=20 > relay is needed > and gets one and sends offer. >=20 > The underlying principal is basically if you don't know what=20 > port you are > going to receive media at (which is the case with a NAT) you=20 > should not be > making any offers and if you make an offer the assumption is=20 > that the other > side and send media (a VISIT) to that and have it work. >=20 > The fundamental thing I am trying to avoid is two vendors=20 > both saying they > have MSRP compliant systems yet still having them fail to be=20 > able to talk to > each other because they both expect the other one to host.=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Mar 1 02:04:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13293 for ; Mon, 1 Mar 2004 02:04:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhSv-00089x-Oa for simple-archive@odin.ietf.org; Mon, 01 Mar 2004 02:03:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2173nFP031363 for simple-archive@odin.ietf.org; Mon, 1 Mar 2004 02:03:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhSv-00089i-Ct for simple-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 02:03:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12939 for ; Mon, 1 Mar 2004 02:03:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxhSr-00041m-00 for simple-web-archive@ietf.org; Mon, 01 Mar 2004 02:03:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxhRs-0003um-00 for simple-web-archive@ietf.org; Mon, 01 Mar 2004 02:02:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxhRN-0003oC-00; Mon, 01 Mar 2004 02:02:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhRG-0007Yi-Rs; Mon, 01 Mar 2004 02:02:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhQt-0007TW-4j for simple@optimus.ietf.org; Mon, 01 Mar 2004 02:01:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11450 for ; Mon, 1 Mar 2004 02:01:40 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxhQp-0003mB-00 for simple@ietf.org; Mon, 01 Mar 2004 02:01:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxhQ4-0003g4-00 for simple@ietf.org; Mon, 01 Mar 2004 02:00:53 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AxhPV-0003Yv-00 for simple@ietf.org; Mon, 01 Mar 2004 02:00:17 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i21709T28919; Mon, 1 Mar 2004 09:00:09 +0200 (EET) X-Scanned: Mon, 1 Mar 2004 09:00:05 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i21705PA012155; Mon, 1 Mar 2004 09:00:05 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00spB7Yy; Mon, 01 Mar 2004 09:00:05 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i21704O29358; Mon, 1 Mar 2004 09:00:04 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 09:00:05 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 09:00:04 +0200 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] MSRP & Comedia X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797803@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP & Comedia Thread-Index: AcP+lLTM6HYaWkHRTxe2QnPjD/fJogAxaWXQ To: , , , , Cc: X-OriginalArrivalTime: 01 Mar 2004 07:00:04.0762 (UTC) FILETIME=[D2F077A0:01C3FF5A] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 09:00:03 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable In some cases, different INVITEs cause different applications to start = at the UAS. The way to differentiate between those INVITEs is sometimes = by using the sdp as a clue. For those devices, receiving INVITE with no = sdp might cause problems. The UAS needs to guess what application to = start. /Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Cullen Jennings > Sent: 27.February.2004 08:50 > To: Ben Campbell; Robert Sparks; Rohan Mahy; Adam Roach > Cc: simple@ietf.org > Subject: [Simple] MSRP & Comedia >=20 >=20 >=20 > This is a half baked idea that I am just tossing out as food=20 > for thought >=20 > Consider a systems where something like the UA that sends the=20 > answer sends > the VISIT.=20 >=20 > Consider the cases where A want to set up a MSRP session with B. >=20 > A is behind a NAT and does not want to use a relay. A sends=20 > an INVITE with > no offer. B sends an offer, gets back an answer and A sends the VISIT. > A -> inv -> B > A <- offer <- B > A -> answer -> B > A -> visit -> B >=20 > B is behind a NAT. A sends an offer and B sends an answer and=20 > A sends VISIT. > A -> offer -> B > A <- answer <- B > A <- visit <- B >=20 > A and B are behind NATS. A sends INVITE no offer, B knows=20 > relay is needed > and gets one and sends offer. >=20 > The underlying principal is basically if you don't know what=20 > port you are > going to receive media at (which is the case with a NAT) you=20 > should not be > making any offers and if you make an offer the assumption is=20 > that the other > side and send media (a VISIT) to that and have it work. >=20 > The fundamental thing I am trying to avoid is two vendors=20 > both saying they > have MSRP compliant systems yet still having them fail to be=20 > able to talk to > each other because they both expect the other one to host.=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Mar 1 02:20:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24106 for ; Mon, 1 Mar 2004 02:20:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxhjC-00064X-00 for simple-archive@ietf.org; Mon, 01 Mar 2004 02:20:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxhiJ-0005ye-00 for simple-archive@ietf.org; Mon, 01 Mar 2004 02:19:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axhhh-0005sT-00; Mon, 01 Mar 2004 02:19:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axhhg-0005Ob-Ks; Mon, 01 Mar 2004 02:19:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axhh9-0005CK-MP for simple@optimus.ietf.org; Mon, 01 Mar 2004 02:18:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23851 for ; Mon, 1 Mar 2004 02:18:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axhh5-0005r3-00 for simple@ietf.org; Mon, 01 Mar 2004 02:18:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxhgG-0005mu-00 for simple@ietf.org; Mon, 01 Mar 2004 02:17:36 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1Axhfx-0005hI-00 for simple@ietf.org; Mon, 01 Mar 2004 02:17:17 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 29 Feb 2004 23:15:47 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i217GkT4026054; Mon, 1 Mar 2004 02:16:46 -0500 (EST) Received: from cisco.com (sin-vpn-client-20-17.cisco.com [10.68.20.17]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGK33550; Mon, 1 Mar 2004 02:16:43 -0500 (EST) Message-ID: <4042E359.1030304@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Jonathan Rosenberg , Simple WG Subject: Re: pidf namespace, was: Re: [Simple] comments on draft-ietf-simple-rpid (long) References: <4041F046.7050207@dynamicsoft.com> <40429762.4070101@cs.columbia.edu> <4042BB0A.20908@dynamicsoft.com> <4042CB54.3080201@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 02:16:41 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > The only limitation of using targetNamespace that there can't be another > extension that also defines activity, relationship, etc., just in a > different namespace. From a practical perspective, this seems like an > advantage, not a drawback. Having two IETF extensions that use > > > and > > > seems to invite confusion to address non-problems (lack of coordination > [these are IETF extensions, after all] and shortage of English words). We've already done it: is defined in both urn:ietf:params:xml:ns:pidf:rpid-tuple and in urn:ietf:params:xml:ns:simple-prescaps-ext. It isn't too bad, because they can't be used in the same context. The rpid class can only be used directly below , while the prescaps class can only be used within . Paul Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Mar 1 02:21:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24163 for ; Mon, 1 Mar 2004 02:21:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhjI-0006DY-BQ for simple-archive@odin.ietf.org; Mon, 01 Mar 2004 02:20:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i217Kia5023845 for simple-archive@odin.ietf.org; Mon, 1 Mar 2004 02:20:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhjG-0006CW-W3 for simple-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 02:20:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24123 for ; Mon, 1 Mar 2004 02:20:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxhjD-00064c-00 for simple-web-archive@ietf.org; Mon, 01 Mar 2004 02:20:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxhiK-0005yl-00 for simple-web-archive@ietf.org; Mon, 01 Mar 2004 02:19:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axhhh-0005sT-00; Mon, 01 Mar 2004 02:19:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axhhg-0005Ob-Ks; Mon, 01 Mar 2004 02:19:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axhh9-0005CK-MP for simple@optimus.ietf.org; Mon, 01 Mar 2004 02:18:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23851 for ; Mon, 1 Mar 2004 02:18:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axhh5-0005r3-00 for simple@ietf.org; Mon, 01 Mar 2004 02:18:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxhgG-0005mu-00 for simple@ietf.org; Mon, 01 Mar 2004 02:17:36 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1Axhfx-0005hI-00 for simple@ietf.org; Mon, 01 Mar 2004 02:17:17 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 29 Feb 2004 23:15:47 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i217GkT4026054; Mon, 1 Mar 2004 02:16:46 -0500 (EST) Received: from cisco.com (sin-vpn-client-20-17.cisco.com [10.68.20.17]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGK33550; Mon, 1 Mar 2004 02:16:43 -0500 (EST) Message-ID: <4042E359.1030304@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Jonathan Rosenberg , Simple WG Subject: Re: pidf namespace, was: Re: [Simple] comments on draft-ietf-simple-rpid (long) References: <4041F046.7050207@dynamicsoft.com> <40429762.4070101@cs.columbia.edu> <4042BB0A.20908@dynamicsoft.com> <4042CB54.3080201@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 02:16:41 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > The only limitation of using targetNamespace that there can't be another > extension that also defines activity, relationship, etc., just in a > different namespace. From a practical perspective, this seems like an > advantage, not a drawback. Having two IETF extensions that use > > > and > > > seems to invite confusion to address non-problems (lack of coordination > [these are IETF extensions, after all] and shortage of English words). We've already done it: is defined in both urn:ietf:params:xml:ns:pidf:rpid-tuple and in urn:ietf:params:xml:ns:simple-prescaps-ext. It isn't too bad, because they can't be used in the same context. The rpid class can only be used directly below , while the prescaps class can only be used within . Paul Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Mar 1 03:02:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27259 for ; Mon, 1 Mar 2004 03:02:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiNs-0002oq-00 for simple-archive@ietf.org; Mon, 01 Mar 2004 03:02:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiMv-0002ib-00 for simple-archive@ietf.org; Mon, 01 Mar 2004 03:01:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxiMH-0002cZ-00; Mon, 01 Mar 2004 03:01:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxiMI-000518-Uo; Mon, 01 Mar 2004 03:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxiLs-0004tj-Qd for simple@optimus.ietf.org; Mon, 01 Mar 2004 03:00:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27088 for ; Mon, 1 Mar 2004 03:00:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiLo-0002Z1-00 for simple@ietf.org; Mon, 01 Mar 2004 03:00:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiKr-0002Qb-00 for simple@ietf.org; Mon, 01 Mar 2004 02:59:34 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1AxiJx-0002Ie-00 for simple@ietf.org; Mon, 01 Mar 2004 02:58:37 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i217wVL16310; Mon, 1 Mar 2004 09:58:31 +0200 (EET) X-Scanned: Mon, 1 Mar 2004 09:57:56 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i217vuGh013420; Mon, 1 Mar 2004 09:57:56 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00HntyFw; Mon, 01 Mar 2004 09:57:53 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i217vrO21048; Mon, 1 Mar 2004 09:57:53 +0200 (EET) Received: from nokia.com ([10.162.252.221]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 09:57:51 +0200 Message-ID: <4042ECFD.4010206@nokia.com> From: "Niemi Aki (Nokia-M/Espoo)" User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ext Rosen, Brian" CC: ext Jonathan Rosenberg , Markus.Isomaki@nokia.com, pkyzivat@cisco.com, hisham.khartabil@nokia.com, Miguel.An.Garcia@nokia.com, simple@ietf.org Subject: Re: [Simple] Chat sessions References: <313680C9A886D511A06000204840E1CF070B6479@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B6479@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2004 07:57:52.0021 (UTC) FILETIME=[E5963450:01C3FF62] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 09:57:49 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Brian, I've never argued for private messages over sidebars. I still maintain that sidebars and private messages are different and *complimentary* features, and that we need *both* to have a complete solution for IM conferences. Cheers, Aki ext Rosen, Brian wrote: > Aki > > When we were discussing sidebars, I made arguments like this against making > a sidebar > a separate session. Sidebars, I argued, are just media (mixing) changes, > they have > nothing to do with session management. > > I lost this argument, and I will be very unhappy if IM works differently. > One of > the reasons I lost it was the observation that a sidebar could include > participants > who are not main conference participants. I think you have the same issue > here. > > Brian > > >>-----Original Message----- >>From: Niemi Aki (Nokia-M/Espoo) [mailto:aki.niemi@nokia.com] >>Sent: Sunday, February 29, 2004 12:40 PM >>To: ext Jonathan Rosenberg >>Cc: Markus.Isomaki@nokia.com; Brian.Rosen@marconi.com; >>pkyzivat@cisco.com; hisham.khartabil@nokia.com; >>Miguel.An.Garcia@nokia.com; simple@ietf.org >>Subject: Re: [Simple] Chat sessions >> >> >> >> >>ext Jonathan Rosenberg wrote: >> >> >>>>3. As Aki explained, sidebars and private IMs within a conference >>>>are two different things. Sidebars are subconferences, that include >>>> a certain subset of the participants in the main conference. They >>>>need to be explicitly created and deleted. Private IMs within a >>>>conference are also targeted to a subset of the conference >>>>participants. But there is no need to setup a sidebar or any other >>>>additional context to send them. The recipients can simply be >>>>signaled within each message (as proposed by using CPIM To header). >>>> This seems to be a specific property of IM, as this sort of >>>>addressing would be impossible e.g. in RTP. In theory priate >>>>messaging facility could be supported by sidebars, but in this case >>>> the focus would need to have as many sidebars constantly setup, as >>>> there are different possible participant subset combinations. Way >>>>too complex and not needed. >>> >>> >>>I dont think that, functionally, what you are describing is >> >>different >> >>> from a sidebar. What differs is that the specifics of this media >>>type allow for a more efficient implementation of the sidebar than >>>would be possible for another media type, such as audio. >> >>Indeed, the >> >>>same is true for IM in general - why set up a session (ala >> >>msrp) when >> >>>you can just send a pager mode? >> >>The ultimate proof of difference in functionality is that private >>messages are usable and useful in a sidebar - in fact it makes no >>difference whether they're sent within the context of a conference, a >>conference sidebar, or a sidebar of a conference sidebar. >> >>Let me provide a concrete example of an already existing service (IRC) >>that has what I think is a close approximation of both sidebar and >>private message functionality. (BTW, I feel strongly that if MSRP >>conferences aren't as feature rich as IRC is, and provide the >>same user >>experience, we've failed miserably.) >> >>Channels in IRC have identities, e.g., #helsinki, and >>participant lists >>that are delivered in a very similar manner that the conference-info >>events would be delivered. Users join these channels using JOIN, at >>which time they get the participant list, and after that, >>updates e.g., >>whenever anyone leaves or joins the channel. >> >>Users can send private messages to the other participants in >>the channel: >> >> PRIVMSG foobar :Some nick you got there foobar! >> >>Usually, these messages are displayed in the same pane as the rest of >>the channel's messages, including information about the sender but >>marked accordingly as private. >> >>A user can also invite others to a sidebar of sorts, that is, a new >>channel, whose properties can be set such that it can be joined by >>invitation only. >> >> INVITE FunnyNick #my_channel >> INVITE BeerLover #my_channel >> INVITE ROOLZ #my_channel >> >>Joining this new channel as a result of an invitation (with JOIN) >>usually results in a new window, moving the focus of conversation away >>from the original channel, but still maintaining the original channel' >>and its messages active in the background. >> >>The users may again send messages either to the entire >>channel (MSG), or >>to only one participant (PRIVMSG). A recipient of an INVITE will >>generally make a choice just like in a SIP invitation whether >>or not to >>join the sidebar or not. Receiving a PRIVMSG requires no actions from >>the recipient. Indeed, it might even go unnoticed. >> >>Taking this into account, I fail to see how sidebars alone can be made >>to work in providing similar functionality in MSRP conferences. Either >>sidears or private messages alone won't result in the same level of >>functionality. >> >>Wrapping all private conversation inside a sidebar is incredibly >>inefficient and results in bad user experience, since there >>is no way to >>distinguish a REFER that is to a sidebar whose sole purpose >>is to send a >>single private message to the user or have a real ad-hoc conversation >>posibly consisting of a real exchange of messages. In fact, this would >>require 4 rounds of singalling (not including sidebar creation and >>tear-down), plus user interaction in between: >> >>REFER (to sidebar) >>200 OK >> >>-Query/inform user whether wants to join- >> >>INVITE (to sidebar) >>200 OK >>ACK >> >>(Note: would probably also require subscription to conference-info, >>because one would be interested to whom they are sending the private >>messages...) >> >>MSRP SEND >>MSRP OK >> >>BYE >>200 OK >> >>...as opposed to a single round of messages: >> >>MSRP SEND (private) >>200 OK >> >>(Note that enabling auto-answering wrt the REFER would in the >>worst case >>result in a sidebar bombardment, or having a user be moved over to a >>sidebar in the middle of, say, message composition.) >> >>The same level of functionality would also not be met with only using >>private messages. AFAIK, the purpose of a sidebar is to move the focus >>of the conversation temporarily outside the original conference. This >>requires being able to wrap a discussion into a separate >>context. A very >>important aspect of this is to let the user decide whether to >>joing such >>a sidebar, and when to join it. Determining to which context a >>particular received private message belongs to can in this >>case only be >>done in the recipients head - there are no protocol elements to help. >> >>As a conclusion, I don't see how sidebars alone can provide >>the required >>functionality. >> >> >>>So, the question is, do we see the perceived efficiency >> >>improvements >> >>>of a pager-mode sidebar as being sufficiently good to allow for >>>defining a separate sidebar mechanism for it? >> >>It is also about user interaction. When a user receives an >>INVITE for an >>MSRP session, it can make a choice just like in a voice call between >>accepting the call or rejecting it. Page mode doesn't provide that >>functionality. >> >>Cheers, >>Aki >> >> >>>-Jonathan R. >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Mar 1 03:03:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27300 for ; Mon, 1 Mar 2004 03:03:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxiNy-0005EG-35 for simple-archive@odin.ietf.org; Mon, 01 Mar 2004 03:02:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2182jHD020094 for simple-archive@odin.ietf.org; Mon, 1 Mar 2004 03:02:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxiNx-0005E1-OK for simple-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 03:02:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27276 for ; Mon, 1 Mar 2004 03:02:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiNt-0002p3-00 for simple-web-archive@ietf.org; Mon, 01 Mar 2004 03:02:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiMw-0002ik-00 for simple-web-archive@ietf.org; Mon, 01 Mar 2004 03:01:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxiMH-0002cZ-00; Mon, 01 Mar 2004 03:01:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxiMI-000518-Uo; Mon, 01 Mar 2004 03:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxiLs-0004tj-Qd for simple@optimus.ietf.org; Mon, 01 Mar 2004 03:00:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27088 for ; Mon, 1 Mar 2004 03:00:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiLo-0002Z1-00 for simple@ietf.org; Mon, 01 Mar 2004 03:00:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiKr-0002Qb-00 for simple@ietf.org; Mon, 01 Mar 2004 02:59:34 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1AxiJx-0002Ie-00 for simple@ietf.org; Mon, 01 Mar 2004 02:58:37 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i217wVL16310; Mon, 1 Mar 2004 09:58:31 +0200 (EET) X-Scanned: Mon, 1 Mar 2004 09:57:56 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i217vuGh013420; Mon, 1 Mar 2004 09:57:56 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00HntyFw; Mon, 01 Mar 2004 09:57:53 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i217vrO21048; Mon, 1 Mar 2004 09:57:53 +0200 (EET) Received: from nokia.com ([10.162.252.221]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 09:57:51 +0200 Message-ID: <4042ECFD.4010206@nokia.com> From: "Niemi Aki (Nokia-M/Espoo)" User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ext Rosen, Brian" CC: ext Jonathan Rosenberg , Markus.Isomaki@nokia.com, pkyzivat@cisco.com, hisham.khartabil@nokia.com, Miguel.An.Garcia@nokia.com, simple@ietf.org Subject: Re: [Simple] Chat sessions References: <313680C9A886D511A06000204840E1CF070B6479@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B6479@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2004 07:57:52.0021 (UTC) FILETIME=[E5963450:01C3FF62] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 09:57:49 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian, I've never argued for private messages over sidebars. I still maintain that sidebars and private messages are different and *complimentary* features, and that we need *both* to have a complete solution for IM conferences. Cheers, Aki ext Rosen, Brian wrote: > Aki > > When we were discussing sidebars, I made arguments like this against making > a sidebar > a separate session. Sidebars, I argued, are just media (mixing) changes, > they have > nothing to do with session management. > > I lost this argument, and I will be very unhappy if IM works differently. > One of > the reasons I lost it was the observation that a sidebar could include > participants > who are not main conference participants. I think you have the same issue > here. > > Brian > > >>-----Original Message----- >>From: Niemi Aki (Nokia-M/Espoo) [mailto:aki.niemi@nokia.com] >>Sent: Sunday, February 29, 2004 12:40 PM >>To: ext Jonathan Rosenberg >>Cc: Markus.Isomaki@nokia.com; Brian.Rosen@marconi.com; >>pkyzivat@cisco.com; hisham.khartabil@nokia.com; >>Miguel.An.Garcia@nokia.com; simple@ietf.org >>Subject: Re: [Simple] Chat sessions >> >> >> >> >>ext Jonathan Rosenberg wrote: >> >> >>>>3. As Aki explained, sidebars and private IMs within a conference >>>>are two different things. Sidebars are subconferences, that include >>>> a certain subset of the participants in the main conference. They >>>>need to be explicitly created and deleted. Private IMs within a >>>>conference are also targeted to a subset of the conference >>>>participants. But there is no need to setup a sidebar or any other >>>>additional context to send them. The recipients can simply be >>>>signaled within each message (as proposed by using CPIM To header). >>>> This seems to be a specific property of IM, as this sort of >>>>addressing would be impossible e.g. in RTP. In theory priate >>>>messaging facility could be supported by sidebars, but in this case >>>> the focus would need to have as many sidebars constantly setup, as >>>> there are different possible participant subset combinations. Way >>>>too complex and not needed. >>> >>> >>>I dont think that, functionally, what you are describing is >> >>different >> >>> from a sidebar. What differs is that the specifics of this media >>>type allow for a more efficient implementation of the sidebar than >>>would be possible for another media type, such as audio. >> >>Indeed, the >> >>>same is true for IM in general - why set up a session (ala >> >>msrp) when >> >>>you can just send a pager mode? >> >>The ultimate proof of difference in functionality is that private >>messages are usable and useful in a sidebar - in fact it makes no >>difference whether they're sent within the context of a conference, a >>conference sidebar, or a sidebar of a conference sidebar. >> >>Let me provide a concrete example of an already existing service (IRC) >>that has what I think is a close approximation of both sidebar and >>private message functionality. (BTW, I feel strongly that if MSRP >>conferences aren't as feature rich as IRC is, and provide the >>same user >>experience, we've failed miserably.) >> >>Channels in IRC have identities, e.g., #helsinki, and >>participant lists >>that are delivered in a very similar manner that the conference-info >>events would be delivered. Users join these channels using JOIN, at >>which time they get the participant list, and after that, >>updates e.g., >>whenever anyone leaves or joins the channel. >> >>Users can send private messages to the other participants in >>the channel: >> >> PRIVMSG foobar :Some nick you got there foobar! >> >>Usually, these messages are displayed in the same pane as the rest of >>the channel's messages, including information about the sender but >>marked accordingly as private. >> >>A user can also invite others to a sidebar of sorts, that is, a new >>channel, whose properties can be set such that it can be joined by >>invitation only. >> >> INVITE FunnyNick #my_channel >> INVITE BeerLover #my_channel >> INVITE ROOLZ #my_channel >> >>Joining this new channel as a result of an invitation (with JOIN) >>usually results in a new window, moving the focus of conversation away >>from the original channel, but still maintaining the original channel' >>and its messages active in the background. >> >>The users may again send messages either to the entire >>channel (MSG), or >>to only one participant (PRIVMSG). A recipient of an INVITE will >>generally make a choice just like in a SIP invitation whether >>or not to >>join the sidebar or not. Receiving a PRIVMSG requires no actions from >>the recipient. Indeed, it might even go unnoticed. >> >>Taking this into account, I fail to see how sidebars alone can be made >>to work in providing similar functionality in MSRP conferences. Either >>sidears or private messages alone won't result in the same level of >>functionality. >> >>Wrapping all private conversation inside a sidebar is incredibly >>inefficient and results in bad user experience, since there >>is no way to >>distinguish a REFER that is to a sidebar whose sole purpose >>is to send a >>single private message to the user or have a real ad-hoc conversation >>posibly consisting of a real exchange of messages. In fact, this would >>require 4 rounds of singalling (not including sidebar creation and >>tear-down), plus user interaction in between: >> >>REFER (to sidebar) >>200 OK >> >>-Query/inform user whether wants to join- >> >>INVITE (to sidebar) >>200 OK >>ACK >> >>(Note: would probably also require subscription to conference-info, >>because one would be interested to whom they are sending the private >>messages...) >> >>MSRP SEND >>MSRP OK >> >>BYE >>200 OK >> >>...as opposed to a single round of messages: >> >>MSRP SEND (private) >>200 OK >> >>(Note that enabling auto-answering wrt the REFER would in the >>worst case >>result in a sidebar bombardment, or having a user be moved over to a >>sidebar in the middle of, say, message composition.) >> >>The same level of functionality would also not be met with only using >>private messages. AFAIK, the purpose of a sidebar is to move the focus >>of the conversation temporarily outside the original conference. This >>requires being able to wrap a discussion into a separate >>context. A very >>important aspect of this is to let the user decide whether to >>joing such >>a sidebar, and when to join it. Determining to which context a >>particular received private message belongs to can in this >>case only be >>done in the recipients head - there are no protocol elements to help. >> >>As a conclusion, I don't see how sidebars alone can provide >>the required >>functionality. >> >> >>>So, the question is, do we see the perceived efficiency >> >>improvements >> >>>of a pager-mode sidebar as being sufficiently good to allow for >>>defining a separate sidebar mechanism for it? >> >>It is also about user interaction. When a user receives an >>INVITE for an >>MSRP session, it can make a choice just like in a voice call between >>accepting the call or rejecting it. Page mode doesn't provide that >>functionality. >> >>Cheers, >>Aki >> >> >>>-Jonathan R. >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Mar 1 03:23:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01349 for ; Mon, 1 Mar 2004 03:23:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axii7-0004nx-00 for simple-archive@ietf.org; Mon, 01 Mar 2004 03:23:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxihD-0004iP-00 for simple-archive@ietf.org; Mon, 01 Mar 2004 03:22:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axigh-0004cm-00; Mon, 01 Mar 2004 03:22:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axige-0006KU-1Q; Mon, 01 Mar 2004 03:22:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axifp-0006GA-Jl for simple@optimus.ietf.org; Mon, 01 Mar 2004 03:21:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00997 for ; Mon, 1 Mar 2004 03:21:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxicB-0004Ed-00 for simple@ietf.org; Mon, 01 Mar 2004 03:17:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxibI-0004Af-00 for simple@ietf.org; Mon, 01 Mar 2004 03:16:32 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1Axiae-0003yv-00 for simple@ietf.org; Mon, 01 Mar 2004 03:15:52 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 01 Mar 2004 00:18:59 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i218FLT4006038; Mon, 1 Mar 2004 03:15:21 -0500 (EST) Received: from cisco.com (sin-vpn-client-20-17.cisco.com [10.68.20.17]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGK35006; Mon, 1 Mar 2004 03:15:18 -0500 (EST) Message-ID: <4042F114.9020903@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] comments on prescaps References: <40420159.3040708@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Mar 2004 03:15:16 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Jonathan, More comments below. Thanks, Paul Jonathan Rosenberg wrote: >> 3.3