From miguel.a.garcia@ericsson.com Thu Dec 1 00:52:12 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2679021F8C43 for ; Thu, 1 Dec 2011 00:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSGHnM+yvOUc for ; Thu, 1 Dec 2011 00:52:08 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B1F3B21F8C3C for ; Thu, 1 Dec 2011 00:52:04 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-dc-4ed74033b1cf Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 6B.05.09514.33047DE4; Thu, 1 Dec 2011 09:52:03 +0100 (CET) Received: from [159.107.24.205] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Dec 2011 09:52:02 +0100 Message-ID: <4ED74032.1020606@ericsson.com> Date: Thu, 1 Dec 2011 09:52:02 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Ben Campbell References: <4E8E3299.6030407@alum.mit.edu> <4ECB89DF.1020803@ericsson.com> <4ECD3529.60204@alum.mit.edu> <357539B4-76E9-47AD-8E33-AC200C1BEE51@nostrum.com> <4ECE121F.6070908@ericsson.com> <522D1E1F-9A8F-4392-94E4-FBB73CB38190@nostrum.com> <4ED3E567.40104@alum.mit.edu> <99FCDF92-4AED-41DA-8353-A03861774D8A@nostrum.com> <4ED61221.2070405@ericsson.com> <4ED6AE9C.8030108@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: Simple WG , Paul Kyzivat Subject: Re: [Simple] draft-ietf-simple-chat-10 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 08:52:12 -0000 Hi Ben, The draft currently says that a nickname is associated with a URI of which the participant is known to the focus. I don't have a use case in mind where a conference server could link two different SIP AoRs and allow them to request the same nickname. It could be done, without standardization support, but I prefer not to consider this case. /Miguel On 30/11/2011 23:35, Ben Campbell wrote: > Given the "MUST NOT automatically assign" part, do we need to put any > constraints on what nicknames the conference server MAY allow? For > example, is it illegal to allow two different AoRs to use the same > nickname, if the service provider has some a priori knowledge that > they represent the same entity? > > On Nov 30, 2011, at 4:30 PM, Paul Kyzivat wrote: > >> I wouldn't object to this. >> >> Thanks, Paul >> >> On 11/30/11 7:23 PM, Miguel A. Garcia wrote: >>> Since we are converging, do you have any comments to the following >>> text? >>> >>> Once the conference server has reserved a nickname and has bound >>> it to a URI (e.g., a SIP Address-of-Record), the conference server >>> MAY allow the usage of the same nickname by the same user >>> (identified by the same URI, such as a SIP AoR) over a second MSRP >>> session. This might be the case if the user joins the same >>> conference from a different SIP UA. In this case, the user MAY >>> request the same or a different nickname than that used in >>> conjunction with the first MSRP session; the conference server MAY >>> accept the usage of the same nickname by the same user. The >>> conference server MUST NOT automatically assign the same nickname >>> to more than one MSRP session established from the same URI, >>> because this can create confusion to the user as whether the same >>> nickname is bound to the second MSRP session. >>> >>> /Miguel >>> >>> >>> >>> On 28/11/2011 21:18, Ben Campbell wrote: >>>> >>>> On Nov 28, 2011, at 1:47 PM, Paul Kyzivat wrote: >>>> >>>>> On 11/24/11 9:43 PM, Ben Campbell wrote: >>>>>> >>>>>> On Nov 24, 2011, at 7:39 AM, Ben Campbell wrote: >>>>>> >>>>>>> >>>>>>> On Nov 24, 2011, at 3:45 AM, Miguel A. Garcia wrote: >>>>>>> >>>>>>>> On 23/11/2011 19:42, Ben Campbell wrote: >>>>>>>>>> - the nickname is bound only to a session, not to an >>>>>>>>>> AOR. The nicknames for sessions must all be unique. >>>>>>>>> >>>>>>>>> I think this is the right answer, but I think it's >>>>>>>>> really "bound to an AoR in the scope of a session". It >>>>>>>>> seems like any scoping of nicknames beyond a specific >>>>>>>>> session should be a matter of local policy. Is there >>>>>>>>> anything that stops an implementation from binding a >>>>>>>>> nickname across multiple simultaneous sessions or >>>>>>>>> even multiple sequential sessions if it wants to? >>>>>>>>> >>>>>>>> >>>>>>>> I wouldn't like to see this option as the only one. I >>>>>>>> would like to join the conference with the same AOR from >>>>>>>> different devices and use the same nickname. Basically, >>>>>>>> I would like to hide the fact that I am using several >>>>>>>> devices to join the chat, and be known with a single >>>>>>>> nickname across all devices. >>>>>>> >>>>>>> Sure, but isn't that still a local policy choice on how >>>>>>> an implementation handles the same nicknames across >>>>>>> multiple MSRP sessions? >>>>>> >>>>>> To elaborate: Would it make sense to say something the >>>>>> effect that a nick is bound to an AoR for the scope of the >>>>>> MSRP session. A conference server MAY, as a matter of local >>>>>> policy, bind the nick at a higher scope. For example… [list >>>>>> a few use cases] >>>>>> >>>>>> Or do you think the other use cases need to be standardized? >>>>>> This is more of a user experience question than an interop >>>>>> question, as long as we have a way of telling a client it >>>>>> can't use a particular nickname. >>>>> >>>>> I think there can be room for policy differences here, if >>>>> people feel that to be important. But then the usage >>>>> mechanisms should be clear so that a UA can understand what it >>>>> is getting. >>>>> >>>>> I can see binding the nickname to an AOR for some duration, >>>>> thus guaranteeing that some other AOR can't use it. >>>>> >>>>> But there should then be some determinism as to whether such >>>>> a binding is then automatically applied to each session from >>>>> that AOR, or if it must be requested by each session that >>>>> wants it. >>>>> >>>>> And if the nickname can be used with more than one session of >>>>> the same AOR, then the lifetime of the binding needs to be >>>>> specified - is it till the last session using it terminates? >>>>> Or till the conference terminates? >>>>> >>>>> This will impact end user behavior: must the user specify the >>>>> nickname independently on each of his devices? And, *may* the >>>>> user use a different nickname from each of his devices even >>>>> though the AOR is the same? >>>> >>>> Ah, I think I see where you are going. >>>> >>>> My knee jerk reaction is that the client should have to >>>> re-request the nickname for each MSRP session. It would be >>>> dangerous for a conference server to simply assume that a second >>>> session from the same AoR should have the same nickname. My >>>> thoughts were more along the line of if a client was _allowed_ >>>> to use the same nickname in more than one MSRP session. >>>> >>>> It seems like that a conference server SHOULD NOT (or maybe MUST >>>> NOT) assume the same nickname applies for more than one session >>>> from the same AoR, but MAY allow it. Allowing a nickname means >>>> accepting a nickname request, but never means assuming a >>>> nickname for a session when none was explicitly requested on >>>> that session. >>>> >>>> The policy question is about what a conference server allows. Or >>>> more to the point, what it rejects. But never what it _assumes_. >>>> For example, reject a nickname request if it is already in use >>>> for another session in the same conference. Or, reject a >>>> nickname request if it is already in use by a different AoR in >>>> the same conference. Or reject it if it used by a different AoR >>>> for any active conference. Or if it was used in an active >>>> conference in the last XXX minutes. Or something else. >>>> >>>> >>>> Ben. >>> >> > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ben@nostrum.com Thu Dec 1 06:57:35 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7956F21F92C1 for ; Thu, 1 Dec 2011 06:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmDknZIvH3Np for ; Thu, 1 Dec 2011 06:57:34 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9E32E21F92C2 for ; Thu, 1 Dec 2011 06:57:34 -0800 (PST) Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pB1EvT9S057157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Dec 2011 08:57:29 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Ben Campbell In-Reply-To: <4ED74032.1020606@ericsson.com> Date: Thu, 1 Dec 2011 08:57:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <959C06F3-EEC8-4B81-B5C5-E6D1AC050CCF@nostrum.com> References: <4E8E3299.6030407@alum.mit.edu> <4ECB89DF.1020803@ericsson.com> <4ECD3529.60204@alum.mit.edu> <357539B4-76E9-47AD-8E33-AC200C1BEE51@nostrum.com> <4ECE121F.6070908@ericsson.com> <522D1E1F-9A8F-4392-94E4-FBB73CB38190@nostrum.com> <4ED3E567.40104@alum.mit.edu> <99FCDF92-4AED-41DA-8353-A03861774D8A@nostrum.com> <4ED61221.2070405@ericsson.com> <4ED6AE9C.8030108@alum.mit.edu> <4ED74032.1020606@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1251.1) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: Simple WG , Paul Kyzivat Subject: Re: [Simple] draft-ietf-simple-chat-10 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 14:57:35 -0000 On Dec 1, 2011, at 2:52 AM, Miguel A. Garcia wrote: > Hi Ben, >=20 > The draft currently says that a nickname is associated with a URI of = which the participant is known to the focus. I don't have a use case in = mind where a conference server could link two different SIP AoRs and = allow them to request the same nickname. It could be done, without = standardization support, but I prefer not to consider this case. >=20 Okay, I think I can live with it like it is :-) > /Miguel >=20 > On 30/11/2011 23:35, Ben Campbell wrote: >> Given the "MUST NOT automatically assign" part, do we need to put any >> constraints on what nicknames the conference server MAY allow? For >> example, is it illegal to allow two different AoRs to use the same >> nickname, if the service provider has some a priori knowledge that >> they represent the same entity? >>=20 >> On Nov 30, 2011, at 4:30 PM, Paul Kyzivat wrote: >>=20 >>> I wouldn't object to this. >>>=20 >>> Thanks, Paul >>>=20 >>> On 11/30/11 7:23 PM, Miguel A. Garcia wrote: >>>> Since we are converging, do you have any comments to the following >>>> text? >>>>=20 >>>> Once the conference server has reserved a nickname and has bound >>>> it to a URI (e.g., a SIP Address-of-Record), the conference server >>>> MAY allow the usage of the same nickname by the same user >>>> (identified by the same URI, such as a SIP AoR) over a second MSRP >>>> session. This might be the case if the user joins the same >>>> conference from a different SIP UA. In this case, the user MAY >>>> request the same or a different nickname than that used in >>>> conjunction with the first MSRP session; the conference server MAY >>>> accept the usage of the same nickname by the same user. The >>>> conference server MUST NOT automatically assign the same nickname >>>> to more than one MSRP session established from the same URI, >>>> because this can create confusion to the user as whether the same >>>> nickname is bound to the second MSRP session. >>>>=20 >>>> /Miguel >>>>=20 >>>>=20 >>>>=20 >>>> On 28/11/2011 21:18, Ben Campbell wrote: >>>>>=20 >>>>> On Nov 28, 2011, at 1:47 PM, Paul Kyzivat wrote: >>>>>=20 >>>>>> On 11/24/11 9:43 PM, Ben Campbell wrote: >>>>>>>=20 >>>>>>> On Nov 24, 2011, at 7:39 AM, Ben Campbell wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Nov 24, 2011, at 3:45 AM, Miguel A. Garcia wrote: >>>>>>>>=20 >>>>>>>>> On 23/11/2011 19:42, Ben Campbell wrote: >>>>>>>>>>> - the nickname is bound only to a session, not to an >>>>>>>>>>> AOR. The nicknames for sessions must all be unique. >>>>>>>>>>=20 >>>>>>>>>> I think this is the right answer, but I think it's >>>>>>>>>> really "bound to an AoR in the scope of a session". It >>>>>>>>>> seems like any scoping of nicknames beyond a specific >>>>>>>>>> session should be a matter of local policy. Is there >>>>>>>>>> anything that stops an implementation from binding a >>>>>>>>>> nickname across multiple simultaneous sessions or >>>>>>>>>> even multiple sequential sessions if it wants to? >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I wouldn't like to see this option as the only one. I >>>>>>>>> would like to join the conference with the same AOR from >>>>>>>>> different devices and use the same nickname. Basically, >>>>>>>>> I would like to hide the fact that I am using several >>>>>>>>> devices to join the chat, and be known with a single >>>>>>>>> nickname across all devices. >>>>>>>>=20 >>>>>>>> Sure, but isn't that still a local policy choice on how >>>>>>>> an implementation handles the same nicknames across >>>>>>>> multiple MSRP sessions? >>>>>>>=20 >>>>>>> To elaborate: Would it make sense to say something the >>>>>>> effect that a nick is bound to an AoR for the scope of the >>>>>>> MSRP session. A conference server MAY, as a matter of local >>>>>>> policy, bind the nick at a higher scope. For example=85 [list >>>>>>> a few use cases] >>>>>>>=20 >>>>>>> Or do you think the other use cases need to be standardized? >>>>>>> This is more of a user experience question than an interop >>>>>>> question, as long as we have a way of telling a client it >>>>>>> can't use a particular nickname. >>>>>>=20 >>>>>> I think there can be room for policy differences here, if >>>>>> people feel that to be important. But then the usage >>>>>> mechanisms should be clear so that a UA can understand what it >>>>>> is getting. >>>>>>=20 >>>>>> I can see binding the nickname to an AOR for some duration, >>>>>> thus guaranteeing that some other AOR can't use it. >>>>>>=20 >>>>>> But there should then be some determinism as to whether such >>>>>> a binding is then automatically applied to each session from >>>>>> that AOR, or if it must be requested by each session that >>>>>> wants it. >>>>>>=20 >>>>>> And if the nickname can be used with more than one session of >>>>>> the same AOR, then the lifetime of the binding needs to be >>>>>> specified - is it till the last session using it terminates? >>>>>> Or till the conference terminates? >>>>>>=20 >>>>>> This will impact end user behavior: must the user specify the >>>>>> nickname independently on each of his devices? And, *may* the >>>>>> user use a different nickname from each of his devices even >>>>>> though the AOR is the same? >>>>>=20 >>>>> Ah, I think I see where you are going. >>>>>=20 >>>>> My knee jerk reaction is that the client should have to >>>>> re-request the nickname for each MSRP session. It would be >>>>> dangerous for a conference server to simply assume that a second >>>>> session from the same AoR should have the same nickname. My >>>>> thoughts were more along the line of if a client was _allowed_ >>>>> to use the same nickname in more than one MSRP session. >>>>>=20 >>>>> It seems like that a conference server SHOULD NOT (or maybe MUST >>>>> NOT) assume the same nickname applies for more than one session >>>>> from the same AoR, but MAY allow it. Allowing a nickname means >>>>> accepting a nickname request, but never means assuming a >>>>> nickname for a session when none was explicitly requested on >>>>> that session. >>>>>=20 >>>>> The policy question is about what a conference server allows. Or >>>>> more to the point, what it rejects. But never what it _assumes_. >>>>> For example, reject a nickname request if it is already in use >>>>> for another session in the same conference. Or, reject a >>>>> nickname request if it is already in use by a different AoR in >>>>> the same conference. Or reject it if it used by a different AoR >>>>> for any active conference. Or if it was used in an active >>>>> conference in the last XXX minutes. Or something else. >>>>>=20 >>>>>=20 >>>>> Ben. >>>>=20 >>>=20 >>=20 >=20 > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain From internet-drafts@ietf.org Sun Dec 4 00:18:09 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0085021F91AB; Sun, 4 Dec 2011 00:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cz2KBQFenXM8; Sun, 4 Dec 2011 00:18:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7136F21F8F5F; Sun, 4 Dec 2011 00:18:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111204081808.9187.89709.idtracker@ietfa.amsl.com> Date: Sun, 04 Dec 2011 00:18:08 -0800 Cc: simple@ietf.org Subject: [Simple] I-D Action: draft-ietf-simple-chat-11.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 08:18:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP for Instant Messaging and Presenc= e Leveraging Extensions Working Group of the IETF. Title : Multi-party Chat Using the Message Session Relay Protoco= l (MSRP) Author(s) : Aki Niemi Miguel A. Garcia-Martin Geir A. Sandbakken Filename : draft-ietf-simple-chat-11.txt Pages : 35 Date : 2011-12-04 The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-simple-chat-11.txt From miguel.a.garcia@ericsson.com Wed Dec 14 23:08:26 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38141F0C43 for ; Wed, 14 Dec 2011 23:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sABQbQlGxOzf for ; Wed, 14 Dec 2011 23:08:25 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1B88F1F0C3F for ; Wed, 14 Dec 2011 23:08:24 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-96-4ee99ce745db Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 23.60.09514.7EC99EE4; Thu, 15 Dec 2011 08:08:23 +0100 (CET) Received: from [159.107.24.228] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Dec 2011 08:08:23 +0100 Message-ID: <4EE99CE6.3020405@ericsson.com> Date: Thu, 15 Dec 2011 08:08:22 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [Simple] MSRP chat: 'chatroom' attribute ABNF X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 07:08:26 -0000 I was doing some editorial fixes to the MSRP chat document, and then I went to validate the ABNF of the 'chatroom' attribute in SDP and the "Use-Nickname" header in MSRP. When doing this, I noticed an open area, for which I would like to get input from the working group. The current ABNF of the chatroom attribute is: attribute /= chatroom-attr chatroom-attr = chatroom-label ":" chat-token *(SP chat-token) The problem is that the syntax above always require a chat-token. So, it is not possible to write an SDP line without tokens: a=chatroom However, the text has text that may lead to this case, for example: A conference focus that includes the 'nicknames' token in the session description is signaling that the MSRP switch supports and the chat room allows to use the procedures specified in Section 7. A conference focus that includes the 'private-messages' in the SDP description is signaling that the MSRP switch supports and the chat room allows to use the procedures specified in Section 6.2. So, one can derive that if a conference focus does not have support for nicknames nor for private messages, it should write an empty attribute: a=chatroom The standalone a=chatroom signals that the MSRP switch understand this draft, in particular the convention to use Message/CPIM wrappers for sending regular messages. So, I suggest to modify the ABNF to support a standalone attribute in the following way: attribute =/ chatroom-attr chatroom-attr = chatroom-label [":" chat-token *(SP chat-token)] This accommodates both standalone and non-standalone attributes, such as: a=chatroom a=chatroom:private-messages a=chatroom:nickname private-messages I also suggest to add a couple of paragraphs indicating that it is fine to include a standalone 'chatroom' attribute: An example of a 'chatroom' attribute for an MSRP media stream where the endpoint, e..g, an MSRP switch, does not allow neither nicknames nor private messages. a=chatroom The 'chatroom' attribute without further modifiers (e.g., tokens) indicates that the endpoint supports the procedures described in this document for transferring MSRP messages to/from a multi-party conference. Does anyone have concerns with the above proposal? /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ben@nostrum.com Thu Dec 15 06:53:12 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB34621F8AF8 for ; Thu, 15 Dec 2011 06:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZsPSeAMAqsg for ; Thu, 15 Dec 2011 06:53:12 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7DE21F8AF5 for ; Thu, 15 Dec 2011 06:53:12 -0800 (PST) Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pBFEr8NB046725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Dec 2011 08:53:09 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Ben Campbell In-Reply-To: <4EE99CE6.3020405@ericsson.com> Date: Thu, 15 Dec 2011 08:53:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <95A31BBE-E018-4853-88D6-D2AB10FFF951@nostrum.com> References: <4EE99CE6.3020405@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1251.1) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] MSRP chat: 'chatroom' attribute ABNF X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 14:53:12 -0000 (as individual) On Dec 15, 2011, at 1:08 AM, Miguel A. Garcia wrote: [=85] >=20 > So, one can derive that if a conference focus does not have support = for nicknames nor for private messages, it should write an empty = attribute: a=3Dchatroom >=20 > The standalone a=3Dchatroom signals that the MSRP switch understand = this draft, in particular the convention to use Message/CPIM wrappers = for sending regular messages. >=20 > So, I suggest to modify the ABNF to support a standalone attribute in = the following way: >=20 > attribute =3D/ chatroom-attr > chatroom-attr =3D chatroom-label [":" chat-token > *(SP chat-token)] >=20 > This accommodates both standalone and non-standalone attributes, such = as: >=20 > a=3Dchatroom > a=3Dchatroom:private-messages > a=3Dchatroom:nickname private-messages >=20 > I also suggest to add a couple of paragraphs indicating that it is = fine to include a standalone 'chatroom' attribute: >=20 > An example of a 'chatroom' attribute for an MSRP media stream where > the endpoint, e..g, an MSRP switch, does not allow neither nicknames > nor private messages. >=20 > a=3Dchatroom >=20 > The 'chatroom' attribute > without further modifiers (e.g., tokens) indicates that the endpoint > supports the procedures described in this document for transferring > MSRP messages to/from a multi-party conference. >=20 >=20 > Does anyone have concerns with the above proposal? I concur with the proposal. Thanks! Ben.= From internet-drafts@ietf.org Thu Dec 15 23:48:19 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803AC21F8440; Thu, 15 Dec 2011 23:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ht6Nj34XgLtK; Thu, 15 Dec 2011 23:48:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C009A21F842C; Thu, 15 Dec 2011 23:48:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20111216074818.27088.47678.idtracker@ietfa.amsl.com> Date: Thu, 15 Dec 2011 23:48:18 -0800 Cc: simple@ietf.org Subject: [Simple] I-D Action: draft-ietf-simple-chat-12.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 07:48:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP for Instant Messaging and Presenc= e Leveraging Extensions Working Group of the IETF. Title : Multi-party Chat Using the Message Session Relay Protoco= l (MSRP) Author(s) : Aki Niemi Miguel A. Garcia-Martin Geir A. Sandbakken Filename : draft-ietf-simple-chat-12.txt Pages : 35 Date : 2011-12-15 The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-simple-chat-12.txt From saul@ag-projects.com Mon Dec 19 02:36:09 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1A321F8B6F for ; Mon, 19 Dec 2011 02:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTTdiniuhgmj for ; Mon, 19 Dec 2011 02:36:09 -0800 (PST) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id ADBCB21F8B6D for ; Mon, 19 Dec 2011 02:36:08 -0800 (PST) Received: by mail.sipthor.net (Postfix, from userid 5001) id 00117B01B4; Mon, 19 Dec 2011 11:36:06 +0100 (CET) Received: from [192.168.1.39] (96.Red-83-43-225.dynamicIP.rima-tde.net [83.43.225.96]) by mail.sipthor.net (Postfix) with ESMTPSA id D1FBBB017D; Mon, 19 Dec 2011 11:36:05 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Saul Ibarra Corretge In-Reply-To: <4EE99CE6.3020405@ericsson.com> Date: Mon, 19 Dec 2011 11:36:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EE99CE6.3020405@ericsson.com> To: Miguel A. Garcia X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] MSRP chat: 'chatroom' attribute ABNF X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 10:36:09 -0000 On Dec 15, 2011, at 8:08 AM, Miguel A. Garcia wrote: > I was doing some editorial fixes to the MSRP chat document, and then I = went to validate the ABNF of the 'chatroom' attribute in SDP and the = "Use-Nickname" header in MSRP. >=20 > When doing this, I noticed an open area, for which I would like to get = input from the working group. >=20 > The current ABNF of the chatroom attribute is: >=20 > attribute /=3D chatroom-attr > chatroom-attr =3D chatroom-label ":" chat-token > *(SP chat-token) >=20 > The problem is that the syntax above always require a chat-token. So, = it is not possible to write an SDP line without tokens: >=20 > a=3Dchatroom >=20 > However, the text has text that may lead to this case, for example: >=20 > A conference focus that includes the 'nicknames' token in the = session > description is signaling that the MSRP switch supports and the chat > room allows to use the procedures specified in Section 7. A > conference focus that includes the 'private-messages' in the SDP > description is signaling that the MSRP switch supports and the chat > room allows to use the procedures specified in Section 6.2. >=20 > So, one can derive that if a conference focus does not have support = for nicknames nor for private messages, it should write an empty = attribute: a=3Dchatroom >=20 > The standalone a=3Dchatroom signals that the MSRP switch understand = this draft, in particular the convention to use Message/CPIM wrappers = for sending regular messages. >=20 > So, I suggest to modify the ABNF to support a standalone attribute in = the following way: >=20 > attribute =3D/ chatroom-attr > chatroom-attr =3D chatroom-label [":" chat-token > *(SP chat-token)] >=20 > This accommodates both standalone and non-standalone attributes, such = as: >=20 > a=3Dchatroom > a=3Dchatroom:private-messages > a=3Dchatroom:nickname private-messages >=20 > I also suggest to add a couple of paragraphs indicating that it is = fine to include a standalone 'chatroom' attribute: >=20 > An example of a 'chatroom' attribute for an MSRP media stream where > the endpoint, e..g, an MSRP switch, does not allow neither nicknames > nor private messages. >=20 > a=3Dchatroom >=20 > The 'chatroom' attribute > without further modifiers (e.g., tokens) indicates that the endpoint > supports the procedures described in this document for transferring > MSRP messages to/from a multi-party conference. >=20 >=20 > Does anyone have concerns with the above proposal? >=20 Not at all. Sounds correct. Regards, --=20 Sa=FAl Ibarra Corretg=E9 AG Projects From prasun.bheri@gmail.com Thu Dec 22 00:09:21 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C0A21F8B73 for ; Thu, 22 Dec 2011 00:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5f+72imIfxG for ; Thu, 22 Dec 2011 00:09:20 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE9921F8B74 for ; Thu, 22 Dec 2011 00:09:20 -0800 (PST) Received: by ghbg18 with SMTP id g18so2311910ghb.31 for ; Thu, 22 Dec 2011 00:09:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=6rFJfsHlYajzVzSIqOfd1Rmpzh5wVb6dGX/9Hbdy/1I=; b=mKLkDkVhA1SFnjWmQ/pPMe3J8Iz7hY2Mhvj478yj+Lu1FZLKFtQG/CFW+GBb3cEw3R MplXkiHDps8sOAsdntRkqYeip4GOGTjpHPN7gOzP2hvBN4CGAjPvdzeP4ZF0bIJrXR6/ meKsF+DdbnAjA72k1C64I1lugT6vWiRvy61tU= Received: by 10.236.123.108 with SMTP id u72mr13436765yhh.45.1324541360208; Thu, 22 Dec 2011 00:09:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.207.9 with HTTP; Thu, 22 Dec 2011 00:08:39 -0800 (PST) From: prasun bheri Date: Thu, 22 Dec 2011 13:38:39 +0530 Message-ID: To: Simple@ietf.org Content-Type: multipart/alternative; boundary=20cf301b657b43fc4804b4a9d19e Subject: [Simple] MSRP - First SEND request purpose? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 08:09:21 -0000 --20cf301b657b43fc4804b4a9d19e Content-Type: text/plain; charset=ISO-8859-1 Hello Group, ref: RFC 4975 (MSRP) "The first SEND request serves to bind a connection to an MSRP session from the perspective of the passive endpoint. If the connection is not authenticated with TLS, and the active endpoint did not send an immediate request, the passive endpoint would have no way to determine who had connected, and would not be able to safely send any requests towards the active party until after the active party sends its first request." >From the passive end point of view: It knows the remote party's IP and port number from the SDP received. So upon 'TCP socket accept', it will know the remote party who is connected. Will it not be sufficent to bind this connection to an MSRP session? Thanks & Regards Prasun --20cf301b657b43fc4804b4a9d19e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Group,

ref: RFC 4975 (MSRP)
"T= he first SEND request serves to bind a connection to an MSRP
=A0 = =A0 =A0 session from the perspective of the passive endpoint. =A0If the
=A0 =A0 =A0 connection is not authenticated with TLS, and the active endpoi= nt
=A0 =A0 =A0 did not send an immediate request, the passive end= point would have
=A0 =A0 =A0 no way to determine who had connecte= d, and would not be able to
=A0 =A0 =A0 safely send any requests towards the active party until af= ter the
=A0 =A0 =A0 active party sends its first request."

From the passive end point of view:

It knows the remote party's IP and port number from the SDP receiv= ed.=A0
So upon 'TCP socket accept', it will know the remo= te party who is connected.
Will it not be sufficent to bind this = connection to an MSRP session?

Thanks & Regards
Prasun
--20cf301b657b43fc4804b4a9d19e-- From ben@nostrum.com Thu Dec 22 08:06:22 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B4D21F8B24 for ; Thu, 22 Dec 2011 08:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2q8CQx-K1Kwl for ; Thu, 22 Dec 2011 08:06:22 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E650421F8B22 for ; Thu, 22 Dec 2011 08:06:21 -0800 (PST) Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pBMG6Jui054517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Dec 2011 10:06:20 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Ben Campbell In-Reply-To: Date: Thu, 22 Dec 2011 10:06:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: prasun bheri X-Mailer: Apple Mail (2.1251.1) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: Simple@ietf.org Subject: Re: [Simple] MSRP - First SEND request purpose? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 16:06:22 -0000 On Dec 22, 2011, at 2:08 AM, prasun bheri wrote: > Hello Group, >=20 > ref: RFC 4975 (MSRP) > "The first SEND request serves to bind a connection to an MSRP > session from the perspective of the passive endpoint. If the > connection is not authenticated with TLS, and the active = endpoint > did not send an immediate request, the passive endpoint would = have > no way to determine who had connected, and would not be able to > safely send any requests towards the active party until after = the > active party sends its first request." >=20 > =46rom the passive end point of view: >=20 > It knows the remote party's IP and port number from the SDP received.=20= > So upon 'TCP socket accept', it will know the remote party who is = connected. > Will it not be sufficent to bind this connection to an MSRP session? >=20 HI Prasun, It's fairly easy for a malicious endpoint to forge a source IP address = and port number. The initial SEND request will contain the MSRP URI that = the passive endpoint sent to the active endpoint in the SDP exchange. = Since that URI is supposed to be hard to guess, that makes it = considerably harder for a malicious endpoint to pretend to be the = expected peer. Hope this helps! Ben.