From saul@ag-projects.com Thu Nov 1 02:58:21 2012 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 C166221F850A for ; Thu, 1 Nov 2012 02:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=0.723, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBt5VEyGzSjX for ; Thu, 1 Nov 2012 02:58:21 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFA121F84FF for ; Thu, 1 Nov 2012 02:58:20 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 58461B35DB; Thu, 1 Nov 2012 10:58:19 +0100 (CET) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 50E1DB00F7; Thu, 1 Nov 2012 10:58:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Thu, 1 Nov 2012 10:58:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Bernard Aboba X-Mailer: Apple Mail (2.1085) Cc: "simple@ietf.org" Subject: Re: [Simple] SIMPLE and Emergency Services 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 Nov 2012 09:58:21 -0000 Hi Bernard, On Oct 31, 2012, at 11:08 PM, Bernard Aboba wrote: > In response to Olle's question about whether SIMPLE is an abject and = irredeemable failure, I would note that SIMPLE is still under = consideration for use in emergency services, if only because XMPP isn't = yet a viable alternative. For example, both NENA i3 and ECRIT PhoneBCP = mention SIMPLE, but refer to XMPP support of emergency services as = future work. In emergency scenarios, presence and address books are = typically not considered since the PSAP is neither a presentity nor a = watcher. Instead, SIMPLE is used as a way of conveying information = between the caller and PSAP, including location, a message body and = additional data.=20 >=20 > With SMS to 911 under active discussion with regulatory bodies, the = question about whether we can rely on SIMPLE for emergency use has = become a "hot issue". As an example, there has been a suggestion that = MESSAGE could be used to support conveyance of SMS text messages to a = "text gateway" that would then pass them on to the PSAP (possibly in a = different form, such as translating to TTY/TDD). Not only might this = help standardize the transport of SMS messages to 911, but it would also = support future uses of MESSAGE for next generation emergency services.=20= >=20 I see you are mentioning SIP MESSAGE all along, but (please someone = correct me if I'm wrong) the IM functionality advocated by SIMPLE is = MSRP, not SIP MESSAGE. For translating SMS messages SIP MESSAGE works, = but it lacks the concept of a 'session', so it doesn't fit well a model = for a conversation. > While documents like NENAi3 and ECRIT PhoneBCP still point to SIMPLE = specs, some folks have pointed to the lack of support for MESSAGE in SIP = trunking services as an indication that even basic uses of SIMPLE are = unlikely to see much deployment, and that alternatives for disabled = access to emergency services (such as RFC 4103 realtime text) should be = given priority.=20 Realtime text is another stream type negotiated with an INVITE, so I = guess MSRP could be used just fine for the same purpose by sending one = MSRP chunk with a single character at a time. There would be a bit of = overhead, however. >=20 > IMHO, unless XMPP for emergency uses is specified by IETF in the near = future, it is likely that SIMPLE will find its way into emergency = services architectures in some form. Since the IETF is still = recommending SIMPLE in documents such as ECRIT PhoneBCP, IMHO the IETF = has a responsibility to public safety to address interop issues that = will arise in next generation emergency services scenarios. AFAIK, = SIMPLE interop issues haven't killed anyone yet. Hopefully this will = remain true in the future. =20 I'm unfamiliar with those documents, but are we talking presence here? = Because this whole thing started about the presence part. To my = knowledge there are no interoperability problems with MSRP = implementations following the standard. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From pkyzivat@alum.mit.edu Thu Nov 1 07:41:35 2012 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 040C821F8CAB for ; Thu, 1 Nov 2012 07:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgnjtrBNBPY9 for ; Thu, 1 Nov 2012 07:41:34 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7A921F8DC4 for ; Thu, 1 Nov 2012 07:41:34 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta07.westchester.pa.mail.comcast.net with comcast id JDAy1k0020ldTLk57EhegV; Thu, 01 Nov 2012 14:41:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id JEhK1k0093ZTu2S3QEhKYY; Thu, 01 Nov 2012 14:41:19 +0000 Message-ID: <50928A1B.2030206@alum.mit.edu> Date: Thu, 01 Nov 2012 10:41:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: simple@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Simple] SIMPLE and Emergency Services 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 Nov 2012 14:41:35 -0000 On 11/1/12 5:58 AM, Saúl Ibarra Corretgé wrote: > Hi Bernard, > > On Oct 31, 2012, at 11:08 PM, Bernard Aboba wrote: > >> In response to Olle's question about whether SIMPLE is an abject and irredeemable failure, I would note that SIMPLE is still under consideration for use in emergency services, if only because XMPP isn't yet a viable alternative. For example, both NENA i3 and ECRIT PhoneBCP mention SIMPLE, but refer to XMPP support of emergency services as future work. In emergency scenarios, presence and address books are typically not considered since the PSAP is neither a presentity nor a watcher. Instead, SIMPLE is used as a way of conveying information between the caller and PSAP, including location, a message body and additional data. >> >> With SMS to 911 under active discussion with regulatory bodies, the question about whether we can rely on SIMPLE for emergency use has become a "hot issue". As an example, there has been a suggestion that MESSAGE could be used to support conveyance of SMS text messages to a "text gateway" that would then pass them on to the PSAP (possibly in a different form, such as translating to TTY/TDD). Not only might this help standardize the transport of SMS messages to 911, but it would also support future uses of MESSAGE for next generation emergency services. >> > > I see you are mentioning SIP MESSAGE all along, but (please someone correct me if I'm wrong) the IM functionality advocated by SIMPLE is MSRP, not SIP MESSAGE. For translating SMS messages SIP MESSAGE works, but it lacks the concept of a 'session', so it doesn't fit well a model for a conversation. IIRC, MESSAGE is indeed a *part* of SIMPLE. But its use is restricted to "page mode" messaging (analogous to SMS), and not for "session mode" messaging. Thanks, Paul >> While documents like NENAi3 and ECRIT PhoneBCP still point to SIMPLE specs, some folks have pointed to the lack of support for MESSAGE in SIP trunking services as an indication that even basic uses of SIMPLE are unlikely to see much deployment, and that alternatives for disabled access to emergency services (such as RFC 4103 realtime text) should be given priority. > > Realtime text is another stream type negotiated with an INVITE, so I guess MSRP could be used just fine for the same purpose by sending one MSRP chunk with a single character at a time. There would be a bit of overhead, however. > >> >> IMHO, unless XMPP for emergency uses is specified by IETF in the near future, it is likely that SIMPLE will find its way into emergency services architectures in some form. Since the IETF is still recommending SIMPLE in documents such as ECRIT PhoneBCP, IMHO the IETF has a responsibility to public safety to address interop issues that will arise in next generation emergency services scenarios. AFAIK, SIMPLE interop issues haven't killed anyone yet. Hopefully this will remain true in the future. > > I'm unfamiliar with those documents, but are we talking presence here? Because this whole thing started about the presence part. To my knowledge there are no interoperability problems with MSRP implementations following the standard. > > > Regards, > > -- > Saúl Ibarra Corretgé > AG Projects > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From saul@ag-projects.com Thu Nov 1 07:56:23 2012 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 70F8021F8D96 for ; Thu, 1 Nov 2012 07:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llaZmpX7AYlJ for ; Thu, 1 Nov 2012 07:56:22 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id DDD5021F8D7C for ; Thu, 1 Nov 2012 07:56:21 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 3A06EB35DB; Thu, 1 Nov 2012 15:56:19 +0100 (CET) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id AACD4B007B; Thu, 1 Nov 2012 15:56:19 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <50928A1B.2030206@alum.mit.edu> Date: Thu, 1 Nov 2012 15:56:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5EA82557-8DA3-4D73-A7FC-C87D7C4EF65F@ag-projects.com> References: <50928A1B.2030206@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1085) Cc: simple@ietf.org Subject: Re: [Simple] SIMPLE and Emergency Services 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 Nov 2012 14:56:23 -0000 >>=20 >> I see you are mentioning SIP MESSAGE all along, but (please someone = correct me if I'm wrong) the IM functionality advocated by SIMPLE is = MSRP, not SIP MESSAGE. For translating SMS messages SIP MESSAGE works, = but it lacks the concept of a 'session', so it doesn't fit well a model = for a conversation. >=20 > IIRC, MESSAGE is indeed a *part* of SIMPLE. But its use is restricted = to "page mode" messaging (analogous to SMS), and not for "session mode" = messaging. >=20 Thanks for the clarification, Paul! -- Sa=FAl Ibarra Corretg=E9 AG Projects From stpeter@stpeter.im Thu Nov 1 08:02:13 2012 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 0CFD521F8DB8 for ; Thu, 1 Nov 2012 08:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yj58QCwUaigK for ; Thu, 1 Nov 2012 08:02:12 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3B321F8D7C for ; Thu, 1 Nov 2012 08:02:12 -0700 (PDT) Received: from [64.101.72.26] (unknown [64.101.72.26]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3EE184011B for ; Thu, 1 Nov 2012 09:05:39 -0600 (MDT) Message-ID: <50928EF5.1070405@stpeter.im> Date: Thu, 01 Nov 2012 09:02:13 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "simple@ietf.org" References: <50928A33.4090306@stpeter.im> In-Reply-To: <50928A33.4090306@stpeter.im> X-Enigmail-Version: 1.4.5 X-Forwarded-Message-Id: <50928A33.4090306@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Simple] Fwd: [precis] spaces at end of nickname 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 Nov 2012 15:02:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Feedback appreciated. - -------- Original Message -------- Subject: [precis] spaces at end of nickname Date: Thu, 01 Nov 2012 08:41:55 -0600 From: Peter Saint-Andre To: precis@ietf.org In the context of groupchat rooms, most applications show a room roster of the participants. One way to spoof nicknames is to simply add one or more space characters at the end, because the spaces don't show up in the interface (thus "stpeter", "stpeter " with one space at the end, and "stpeter " with two spaces at the end would all appear to be the same person). This seems like an obvious hole that we can plug by disallowing trailing (and perhaps leading) spaces in nicknames. I'll forward this message to the SIMPLE WG and XMPP WG for their feedback, and also raise this issue during the PRECIS WG session next week. Peter _______________________________________________ precis mailing list precis@ietf.org https://www.ietf.org/mailman/listinfo/precis -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCSjvUACgkQNL8k5A2w/vzbFQCeM1OGQDTI/bdS6oneRfF7+tH3 RToAn2Ou9gA+mVKbnjKTv8YTyhKlcDUy =b45p -----END PGP SIGNATURE----- From saul@ag-projects.com Thu Nov 1 08:06:25 2012 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 5C9B821F8DD6 for ; Thu, 1 Nov 2012 08:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mv3LTcHo9lJb for ; Thu, 1 Nov 2012 08:06:25 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id D992121F8DD2 for ; Thu, 1 Nov 2012 08:06:24 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id EE310B35DB; Thu, 1 Nov 2012 16:06:23 +0100 (CET) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 3EC63B007B; Thu, 1 Nov 2012 16:06:23 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <50928EF5.1070405@stpeter.im> Date: Thu, 1 Nov 2012 16:06:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <68D8E3B8-4756-4711-BB1F-D2E0E979C563@ag-projects.com> References: <50928A33.4090306@stpeter.im> <50928EF5.1070405@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1085) Cc: "simple@ietf.org" Subject: Re: [Simple] Fwd: [precis] spaces at end of nickname 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 Nov 2012 15:06:25 -0000 Hi Peter, On Nov 1, 2012, at 4:02 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Feedback appreciated. >=20 >=20 > - -------- Original Message -------- > Subject: [precis] spaces at end of nickname > Date: Thu, 01 Nov 2012 08:41:55 -0600 > From: Peter Saint-Andre > To: precis@ietf.org >=20 > In the context of groupchat rooms, most applications show a room > roster of the participants. One way to spoof nicknames is to simply > add one or more space characters at the end, because the spaces don't > show up in the interface (thus "stpeter", "stpeter " with one space at > the end, and "stpeter " with two spaces at the end would all appear > to be the same person). This seems like an obvious hole that we can > plug by disallowing trailing (and perhaps leading) spaces in > nicknames. I'll forward this message to the SIMPLE WG and XMPP WG for > their feedback, and also raise this issue during the PRECIS WG session > next week. >=20 Trimming the nickname sounds reasonable to me, I don't see any case if = which those spaces could bear any meaning. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From ben@nostrum.com Thu Nov 1 08:07:26 2012 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 DB38721F8D01 for ; Thu, 1 Nov 2012 08:07:26 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdqCsNr2N8t2 for ; Thu, 1 Nov 2012 08:07:26 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E2B4D21F8DD2 for ; Thu, 1 Nov 2012 08:07:25 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qA1F7OtJ089133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Nov 2012 10:07:25 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <50928EF5.1070405@stpeter.im> Date: Thu, 1 Nov 2012 10:07:26 -0500 Content-Transfer-Encoding: 7bit Message-Id: <8BF6C00C-DB0C-4E9E-B5AA-CB04D1649659@nostrum.com> References: <50928A33.4090306@stpeter.im> <50928EF5.1070405@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "simple@ietf.org" Subject: Re: [Simple] Fwd: [precis] spaces at end of nickname 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 Nov 2012 15:07:27 -0000 +1. Should we generalize this to leading and trailing white space? On Nov 1, 2012, at 10:02 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Feedback appreciated. > > > - -------- Original Message -------- > Subject: [precis] spaces at end of nickname > Date: Thu, 01 Nov 2012 08:41:55 -0600 > From: Peter Saint-Andre > To: precis@ietf.org > > In the context of groupchat rooms, most applications show a room > roster of the participants. One way to spoof nicknames is to simply > add one or more space characters at the end, because the spaces don't > show up in the interface (thus "stpeter", "stpeter " with one space at > the end, and "stpeter " with two spaces at the end would all appear > to be the same person). This seems like an obvious hole that we can > plug by disallowing trailing (and perhaps leading) spaces in > nicknames. I'll forward this message to the SIMPLE WG and XMPP WG for > their feedback, and also raise this issue during the PRECIS WG session > next week. > > Peter > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlCSjvUACgkQNL8k5A2w/vzbFQCeM1OGQDTI/bdS6oneRfF7+tH3 > RToAn2Ou9gA+mVKbnjKTv8YTyhKlcDUy > =b45p > -----END PGP SIGNATURE----- > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From saul@ag-projects.com Thu Nov 1 08:10:24 2012 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 335FE21F8C82 for ; Thu, 1 Nov 2012 08:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.326 X-Spam-Level: X-Spam-Status: No, score=-1.326 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AymKMUj2+Il for ; Thu, 1 Nov 2012 08:10:23 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6D34F21F86FA for ; Thu, 1 Nov 2012 08:10:23 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id AC45BB35DB; Thu, 1 Nov 2012 16:10:22 +0100 (CET) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 3A3E2B007B; Thu, 1 Nov 2012 16:10:20 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <8BF6C00C-DB0C-4E9E-B5AA-CB04D1649659@nostrum.com> Date: Thu, 1 Nov 2012 16:10:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50928A33.4090306@stpeter.im> <50928EF5.1070405@stpeter.im> <8BF6C00C-DB0C-4E9E-B5AA-CB04D1649659@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1085) Cc: "simple@ietf.org" Subject: Re: [Simple] Fwd: [precis] spaces at end of nickname 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 Nov 2012 15:10:24 -0000 On Nov 1, 2012, at 4:07 PM, Ben Campbell wrote: > +1. Should we generalize this to leading and trailing white space? >=20 I think so. Spaces are not perceived depending on where you align the = text in a user interface. > On Nov 1, 2012, at 10:02 AM, Peter Saint-Andre = wrote: >=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >> Feedback appreciated. >>=20 >>=20 >> - -------- Original Message -------- >> Subject: [precis] spaces at end of nickname >> Date: Thu, 01 Nov 2012 08:41:55 -0600 >> From: Peter Saint-Andre >> To: precis@ietf.org >>=20 >> In the context of groupchat rooms, most applications show a room >> roster of the participants. One way to spoof nicknames is to simply >> add one or more space characters at the end, because the spaces don't >> show up in the interface (thus "stpeter", "stpeter " with one space = at >> the end, and "stpeter " with two spaces at the end would all appear >> to be the same person). This seems like an obvious hole that we can >> plug by disallowing trailing (and perhaps leading) spaces in >> nicknames. I'll forward this message to the SIMPLE WG and XMPP WG for >> their feedback, and also raise this issue during the PRECIS WG = session >> next week. >>=20 >> Peter >>=20 >> _______________________________________________ >> precis mailing list >> precis@ietf.org >> https://www.ietf.org/mailman/listinfo/precis >>=20 >>=20 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >>=20 >> iEYEARECAAYFAlCSjvUACgkQNL8k5A2w/vzbFQCeM1OGQDTI/bdS6oneRfF7+tH3 >> RToAn2Ou9gA+mVKbnjKTv8YTyhKlcDUy >> =3Db45p >> -----END PGP SIGNATURE----- >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple -- Sa=FAl Ibarra Corretg=E9 AG Projects From gunnar.hellstrom@omnitor.se Thu Nov 1 08:15:51 2012 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 85B5B21F8C9C for ; Thu, 1 Nov 2012 08:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0TzuNZasXEP for ; Thu, 1 Nov 2012 08:15:50 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id EFEA721F8C53 for ; Thu, 1 Nov 2012 08:15:49 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP; Thu, 1 Nov 2012 16:15:41 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id 9C1103A12B; Thu, 1 Nov 2012 16:15:41 +0100 (CET) Message-ID: <5092921D.9040905@omnitor.se> Date: Thu, 01 Nov 2012 16:15:41 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "simple@ietf.org" Subject: Re: [Simple] SIMPLE and Emergency Services 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 Nov 2012 15:15:51 -0000 All three SIP related text protocols are not only considered for emergency service use, they are actually implemented. I mean T.140/RFC 4103 real-time text, SIP Message and MSRP. They are all three required by RFC 6433, NENA NG-9-1-1 i3 technical specification and EENA NG-1-1-2 Long Term Definition. There was an interop event arranged by NENA a couple of weeks ago, dedicated to accessibiity to emergency services for people with disabilities, but also including many other media related features. Here is a link to what was done: http://www.nena.org/?NG911_ICE5 It is only feasible to implement what is specified in common specifications and standards. So, it is quite late in the process and urgent to both discuss exclusion of MSRP and inclusion of XMPP if any such change shall be ready when services made according to these specifications are put in operation. It would be natural to try to include XMPP in emergency service specifications, because of its dominance in the IM world. There is always a risk that some detail is lost in conversion to any of the other protocols. But there is a lot to consider when opening the emergency service speifications for one more protocol. Location, recording, multi-party calling, transfer, additional information, combination with video and audio, real-time flow, session start and end, call-back, protocol selection when calling etc. You said "Realtime text is another stream type negotiated with an INVITE, so I guess MSRP could be used just fine for the same purpose by sending one MSRP chunk with a single character at a time. There would be a bit of overhead, however." I want to kill the idea that real-time text would be sent character by character. All modern real-time text protocols are time-sampled, just like audio and video, but with longer sampling interval. RFC4103 is RTP based and uses a sampling interval of 300 ms. With the low overhead or RTP, and a maximum of 3.3 packets per second, it is very economical. The user acceptance for end-to-end delay is higher for real-time text than for video and audio. One second is easily accepted, and two seconds is still usable. Annoyance begins between two and three seconds. But presentation must be smooth, not in second-long jerks. There was once a draft in IETF for real-time text based on MSRP. It was dropped because of a fear that it would be too heavy and because there was already a solution for real-time text. However, any text protocol gains in usability by being used in a real-time manner with time sampling and smooth display. XMPP is about to get its real-time enhancement in an XMPP extension called XEP-0301 Real-time text, intended to improve the usability of XMPP based IM. If that is used by an emergency caller, it would need to be converted to RFC 4103 at the border to the emergency service according to current specifications in order to not lose its real-time flow. That will be a bit messy - negotiate XMPP to MSRP conversion for old time IM use of XMPP, but XMPP to RFC 4103 conversion when XMPP is used with its real-time text extension. It is maybe worth the effort to specify XMPP use in emergency services ( including its real-time extension) right away. Gunnar On 2012-11-01 10:58, Saúl Ibarra Corretgé wrote: > Hi Bernard, > > On Oct 31, 2012, at 11:08 PM, Bernard Aboba wrote: > >> In response to Olle's question about whether SIMPLE is an abject and irredeemable failure, I would note that SIMPLE is still under consideration for use in emergency services, if only because XMPP isn't yet a viable alternative. For example, both NENA i3 and ECRIT PhoneBCP mention SIMPLE, but refer to XMPP support of emergency services as future work. In emergency scenarios, presence and address books are typically not considered since the PSAP is neither a presentity nor a watcher. Instead, SIMPLE is used as a way of conveying information between the caller and PSAP, including location, a message body and additional data. >> >> With SMS to 911 under active discussion with regulatory bodies, the question about whether we can rely on SIMPLE for emergency use has become a "hot issue". As an example, there has been a suggestion that MESSAGE could be used to support conveyance of SMS text messages to a "text gateway" that would then pass them on to the PSAP (possibly in a different form, such as translating to TTY/TDD). Not only might this help standardize the transport of SMS messages to 911, but it would also support future uses of MESSAGE for next generation emergency services. >> > I see you are mentioning SIP MESSAGE all along, but (please someone correct me if I'm wrong) the IM functionality advocated by SIMPLE is MSRP, not SIP MESSAGE. For translating SMS messages SIP MESSAGE works, but it lacks the concept of a 'session', so it doesn't fit well a model for a conversation. > >> While documents like NENAi3 and ECRIT PhoneBCP still point to SIMPLE specs, some folks have pointed to the lack of support for MESSAGE in SIP trunking services as an indication that even basic uses of SIMPLE are unlikely to see much deployment, and that alternatives for disabled access to emergency services (such as RFC 4103 realtime text) should be given priority. > Realtime text is another stream type negotiated with an INVITE, so I guess MSRP could be used just fine for the same purpose by sending one MSRP chunk with a single character at a time. There would be a bit of overhead, however. > >> IMHO, unless XMPP for emergency uses is specified by IETF in the near future, it is likely that SIMPLE will find its way into emergency services architectures in some form. Since the IETF is still recommending SIMPLE in documents such as ECRIT PhoneBCP, IMHO the IETF has a responsibility to public safety to address interop issues that will arise in next generation emergency services scenarios. AFAIK, SIMPLE interop issues haven't killed anyone yet. Hopefully this will remain true in the future. > I'm unfamiliar with those documents, but are we talking presence here? Because this whole thing started about the presence part. To my knowledge there are no interoperability problems with MSRP implementations following the standard. > > > Regards, > > -- > Saúl Ibarra Corretgé > AG Projects > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From oej@edvina.net Thu Nov 1 08:38:26 2012 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 EF73A21F84A8 for ; Thu, 1 Nov 2012 08:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tqVw52qLk8B for ; Thu, 1 Nov 2012 08:38:25 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id B246C21F8A49 for ; Thu, 1 Nov 2012 08:38:15 -0700 (PDT) Received: from [192.168.40.19] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 183E6754A8A7; Thu, 1 Nov 2012 15:38:14 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_C96FB200-A0DC-4D28-8BB1-1442C01E3EC4" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 1 Nov 2012 16:38:13 +0100 Message-Id: <72B898CC-640D-46E1-A7D5-D372C02F53A1@edvina.net> References: To: Bernard Aboba X-Mailer: Apple Mail (2.1499) Cc: "simple@ietf.org" Subject: Re: [Simple] SIMPLE and Emergency Services 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 Nov 2012 15:38:27 -0000 --Apple-Mail=_C96FB200-A0DC-4D28-8BB1-1442C01E3EC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 31 okt 2012 kl. 23:08 skrev Bernard Aboba : > In response to Olle's question about whether SIMPLE is an abject and = irredeemable failure, I would note that SIMPLE is still under = consideration for use in emergency services, if only because XMPP isn't = yet a viable alternative. For example, both NENA i3 and ECRIT PhoneBCP = mention SIMPLE, but refer to XMPP support of emergency services as = future work. In emergency scenarios, presence and address books are = typically not considered since the PSAP is neither a presentity nor a = watcher. Instead, SIMPLE is used as a way of conveying information = between the caller and PSAP, including location, a message body and = additional data.=20 >=20 > With SMS to 911 under active discussion with regulatory bodies, the = question about whether we can rely on SIMPLE for emergency use has = become a "hot issue". As an example, there has been a suggestion that = MESSAGE could be used to support conveyance of SMS text messages to a = "text gateway" that would then pass them on to the PSAP (possibly in a = different form, such as translating to TTY/TDD). Not only might this = help standardize the transport of SMS messages to 911, but it would also = support future uses of MESSAGE for next generation emergency services.=20= >=20 > While documents like NENAi3 and ECRIT PhoneBCP still point to SIMPLE = specs, some folks have pointed to the lack of support for MESSAGE in SIP = trunking services as an indication that even basic uses of SIMPLE are = unlikely to see much deployment, and that alternatives for disabled = access to emergency services (such as RFC 4103 realtime text) should be = given priority.=20 >=20 > IMHO, unless XMPP for emergency uses is specified by IETF in the near = future, it is likely that SIMPLE will find its way into emergency = services architectures in some form. Since the IETF is still = recommending SIMPLE in documents such as ECRIT PhoneBCP, IMHO the IETF = has a responsibility to public safety to address interop issues that = will arise in next generation emergency services scenarios. AFAIK, = SIMPLE interop issues haven't killed anyone yet. Hopefully this will = remain true in the future. =20 Thank you for your response, Bernard. Yes, if the emergency services don't want to sign a contract with a = single vendor of both servers and clients, but wants to have a choice - = we need to fix interoperability. I do understand that many of the issues = we've discussed here doesn't apply - like XCAP documents and buddy = lists, so it MAY be easier, to use RFC language :-) Realtime Text with RFC 4103/T.140 is implemented in many places today = (and supported by Asterisk :-) ) so that's something that should not be ignored, regardless of plans to = support IM/Chat. /O >=20 > Olle E. Johansson said:=20 > "Any other thoughts in regards to SIMPLE? >=20 > Is it a failure or not? >=20 > Do we have a chance of fixing this within the IETF? >=20 > Is anyone interested in fixing it so we actually reach the WG goal of = interoperability?" >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail=_C96FB200-A0DC-4D28-8BB1-1442C01E3EC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
31 okt 2012 kl. = 23:08 skrev Bernard Aboba <bernard_aboba@hotmail.com>= ;:

In response to = Olle's question about whether SIMPLE is an abject and irredeemable = failure,  I would note that SIMPLE is still under consideration for = use in emergency services, if only because XMPP isn't yet a viable = alternative. With SMS to 911 under active = discussion with regulatory bodies, the question about whether we can = rely on SIMPLE for emergency use has become a "hot issue". As an = example, there has been a suggestion that MESSAGE could be used to = support conveyance of SMS text messages to a = "text gateway" that would then pass them on to the PSAP (possibly in a = different form, such as translating to TTY/TDD).  Not only might = this help standardize the transport of SMS messages to 911, but it would = also support future uses of MESSAGE for next generation emergency = services.


IMHO, unless XMPP for emergency = uses is specified by IETF in the near future, it is likely that SIMPLE = will find its way into emergency services architectures in some form. = Since the IETF is still recommending SIMPLE in documents such as ECRIT = PhoneBCP, IMHO the IETF has a responsibility to public safety to address = interop issues that will arise in next generation emergency services = scenarios. AFAIK, SIMPLE interop issues haven't killed anyone yet. = Hopefully this will remain true in the future. =
Thank you for your response, = Bernard.

Yes, if the emergency services don't = want to sign a contract with a single vendor of both servers and = clients, but wants to have a choice - we need to fix interoperability. I = do understand that many of the issues we've discussed here doesn't apply = - like XCAP documents and buddy lists, so it MAY be easier, to use RFC = language :-)

Realtime Text with RFC 4103/T.140 = is implemented in many places today (and supported by Asterisk :-) = )
so that's something that should not be ignored, regardless = of plans to support = IM/Chat.

/O


Olle E. Johansson said: 
"Any other thoughts =
in regards to SIMPLE?

Is it a failure or not?

Do we have a chance of fixing this within the IETF?

Is anyone interested in fixing it so we actually reach the WG goal of =
interoperability?"

=
_______________________________________________
Simple = mailing list
Simple@ietf.org
https://www.ietf.org= /mailman/listinfo/simple

= --Apple-Mail=_C96FB200-A0DC-4D28-8BB1-1442C01E3EC4-- From keith.drage@alcatel-lucent.com Thu Nov 1 08:44:42 2012 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 78E5521F8E90 for ; Thu, 1 Nov 2012 08:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.248 X-Spam-Level: X-Spam-Status: No, score=-110.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaMr5VY+gMuT for ; Thu, 1 Nov 2012 08:44:35 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0880E21F8E84 for ; Thu, 1 Nov 2012 08:44:33 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA1FiTle028060 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 1 Nov 2012 16:44:30 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 1 Nov 2012 16:44:29 +0100 From: "DRAGE, Keith (Keith)" To: Bernard Aboba , "simple@ietf.org" Date: Thu, 1 Nov 2012 16:44:28 +0100 Thread-Topic: [Simple] SIMPLE and Emergency Services Thread-Index: Ac23tEYifsr4U8I6S5iD86wKhQZZrwAkqW8g Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE202D2F6F6A9FRMRSSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [Simple] SIMPLE and Emergency Services 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 Nov 2012 15:44:42 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE202D2F6F6A9FRMRSSXCHMBSC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Release 11 of 3GPP IMS specifications add session based media to emergency = call usage in addition to voice and real time text. For messaging, that inc= ludes MSRP. While many countries are trying to ensure that PSAPs can handle SMS (which = is not session based), this needs to be regarded as something that exists w= here nothing else does - as it provides the responder with no ability to in= terrogate the user to obtain more information. For presence, nothing special has been specified by 3GPP. Keith ________________________________ From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= Bernard Aboba Sent: 31 October 2012 22:08 To: simple@ietf.org Subject: Re: [Simple] SIMPLE and Emergency Services In response to Olle's question about whether SIMPLE is an abject and irrede= emable failure, I would note that SIMPLE is still under consideration for = use in emergency services, if only because XMPP isn't yet a viable alternat= ive. For example, both NENA i3 and ECRIT PhoneBCP mention SIMPLE, but refer= to XMPP support of emergency services as future work. In emergency scenari= os, presence and address books are typically not considered since the PSAP = is neither a presentity nor a watcher. Instead, SIMPLE is used as a way of= conveying information between the caller and PSAP, including location, a m= essage body and additional data. With SMS to 911 under active discussion with regulatory bodies, the questio= n about whether we can rely on SIMPLE for emergency use has become a "hot i= ssue". As an example, there has been a suggestion that MESSAGE could be use= d to support conveyance of SMS text messages to a "text gateway" that would= then pass them on to the PSAP (possibly in a different form, such as trans= lating to TTY/TDD). Not only might this help standardize the transport of = SMS messages to 911, but it would also support future uses of MESSAGE for n= ext generation emergency services. While documents like NENAi3 and ECRIT PhoneBCP still point to SIMPLE specs,= some folks have pointed to the lack of support for MESSAGE in SIP trunking= services as an indication that even basic uses of SIMPLE are unlikely to s= ee much deployment, and that alternatives for disabled access to emergency = services (such as RFC 4103 realtime text) should be given priority. IMHO, unless XMPP for emergency uses is specified by IETF in the near futur= e, it is likely that SIMPLE will find its way into emergency services archi= tectures in some form. Since the IETF is still recommending SIMPLE in docum= ents such as ECRIT PhoneBCP, IMHO the IETF has a responsibility to public s= afety to address interop issues that will arise in next generation emergenc= y services scenarios. AFAIK, SIMPLE interop issues haven't killed anyone ye= t. Hopefully this will remain true in the future. Olle E. Johansson said: "Any other thoughts in regards to SIMPLE? Is it a failure or not? Do we have a chance of fixing this within the IETF? Is anyone interested in fixing it so we actually reach the WG goal of inter= operability?" --_000_EDC0A1AE77C57744B664A310A0B23AE202D2F6F6A9FRMRSSXCHMBSC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Release 11 of 3GPP IMS specifications = add session based media to emergency call usage in addition to voice and real t= ime text. For messaging, that includes MSRP.

 

While many countries are trying to ens= ure that PSAPs can handle SMS (which is not session based), this needs to be regarded as something that exists where nothing else does – as it provides the responder with no ability to interrogate the user to obtain mo= re information.

 

For presence, nothing special has been specified by 3GPP.

 

Keith

 

From:= simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: 31 October 2012 22:08<= br> To: simple@ietf.org
Subject: Re: [Simple] SIMPLE= and Emergency Services

 

In response to Olle's question about whether SI= MPLE is an abject and irredeemable failure,  I would note that SIMPLE is st= ill under consideration for use in emergency services, if only because XMPP isn= 't yet a viable alternative. For example, both NENA i3 and ECRIT PhoneBCP mention SIMPLE, but refer to XMPP support of emergency services as future work. In emergency scenarios, prese= nce and address books are typically not considered since the PSAP is neither a presentity nor a watcher.  Instead, SIMPLE is used as a way of conveyi= ng information between the caller and PSAP, including location, a message body= and additional data.

With SMS to 911 under active discussion with regulatory bodies, the question about whether we can rely o= n SIMPLE for emergency use has become a "hot issue". As an example, there has been a suggestion that MESSAGE could be used to support conveyance of SMS text messages to a "text gateway" that would then pass them on to the PSAP (possibly= in a different form, such as translating to TTY/TDD).  Not only might thi= s help standardize the transport of SMS messages to 911, but it would also support future uses of MESSAGE for next generation emergency services.



While documents like NENAi3 and ECRIT PhoneBCP still p= oint to SIMPLE specs, some folks have pointed to the lack of support for MESSAGE= in SIP trunking services as an indication that even basic uses of SIMPLE are unlikely to see much deployment, and that alternatives for disabled access = to emergency services (such as RFC 4103 realtime text) should be given priorit= y. 



IMHO, unless XMPP for emergency uses is specified by I= ETF in the near future, it is likely that SIMPLE will find its way into emergen= cy services architectures in some form. Since the IETF is still recommending SIMPLE in documents such as ECRIT PhoneBCP, IMHO the IETF has a responsibil= ity to public safety to address interop issues that will arise in next generati= on emergency services scenarios. AFAIK, SIMPLE interop issues haven't killed anyone yet. Hopefully this will remain true in the future.



Olle E. Johansson said: = 

"A=
ny other thoughts in regards to SIMPLE?
=
 
Is it a failure or not?
 
Do we have a chance of fixing this within the IETF?
 
Is anyone interested in fixing it so we actually reach the WG goal of int=
eroperability?"
 
 
--_000_EDC0A1AE77C57744B664A310A0B23AE202D2F6F6A9FRMRSSXCHMBSC_-- From pkyzivat@alum.mit.edu Thu Nov 1 09:11:05 2012 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 1749021F8DAD for ; Thu, 1 Nov 2012 09:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAY25qqoQv4x for ; Thu, 1 Nov 2012 09:11:04 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 4A64521F8D9B for ; Thu, 1 Nov 2012 09:11:03 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta12.westchester.pa.mail.comcast.net with comcast id JDvj1k0021uE5Es5CGB8Ws; Thu, 01 Nov 2012 16:11:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id JGBM1k00C3ZTu2S3cGBMRh; Thu, 01 Nov 2012 16:11:21 +0000 Message-ID: <50929F15.8080502@alum.mit.edu> Date: Thu, 01 Nov 2012 12:11:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: simple@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Simple] SIMPLE and Emergency Services 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 Nov 2012 16:11:05 -0000 On 11/1/12 11:44 AM, DRAGE, Keith (Keith) wrote: > Release 11 of 3GPP IMS specifications add session based media to > emergency call usage in addition to voice and real time text. For > messaging, that includes MSRP. PSAPs are going to provide an interesting and motivated testbed for SIMPLE interoperability. We know there will be an IMS SIMPLE client to the PSAPS. Unless the PSAP sw is built on an IMS platform, that will guarantee one point where interop will be required. Thanks, Paul > While many countries are trying to ensure that PSAPs can handle SMS > (which is not session based), this needs to be regarded as something > that exists where nothing else does – as it provides the responder with > no ability to interrogate the user to obtain more information. > > For presence, nothing special has been specified by 3GPP. > > Keith > > ------------------------------------------------------------------------ > > *From:*simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] *On > Behalf Of *Bernard Aboba > *Sent:* 31 October 2012 22:08 > *To:* simple@ietf.org > *Subject:* Re: [Simple] SIMPLE and Emergency Services > > > *In response to Olle's question about whether SIMPLE is an abject and > irredeemable failure, I would note that SIMPLE is still under > consideration for use in emergency services, if only because XMPP > isn't yet a viable alternative. For example, both NENA i3 and ECRIT > PhoneBCP mention SIMPLE, but refer to XMPP support of emergency > services as future work. In emergency scenarios, presence and address > books are typically not considered since the PSAP is neither a > presentity nor a watcher. Instead, SIMPLE is used as a way of > conveying information between the caller and PSAP, including location, > a message body and additional data. * > > With SMS to 911 under active discussion with regulatory bodies, the > question about whether we can rely on SIMPLE for emergency use has > become a "hot issue". As an example, there has been a suggestion that > MESSAGE could be used to support conveyance of SMS text messages to a > "text gateway" that would then pass them on to the PSAP (possibly in a > different form, such as translating to TTY/TDD). Not only might this > help standardize the transport of SMS messages to 911, but it would also > support future uses of MESSAGE for next generation emergency services. > > > > While documents like NENAi3 and ECRIT PhoneBCP still point to SIMPLE > specs, some folks have pointed to the lack of support for MESSAGE in SIP > trunking services as an indication that even basic uses of SIMPLE are > unlikely to see much deployment, and that alternatives for disabled > access to emergency services (such as RFC 4103 realtime text) should be > given priority. > > > > IMHO, unless XMPP for emergency uses is specified by IETF in the near > future, it is likely that SIMPLE will find its way into emergency > services architectures in some form. Since the IETF is still > recommending SIMPLE in documents such as ECRIT PhoneBCP, IMHO the IETF > has a responsibility to public safety to address interop issues that > will arise in next generation emergency services scenarios. AFAIK, > SIMPLE interop issues haven't killed anyone yet. Hopefully this will > remain true in the future. > > > > Olle E. Johansson said: > > "Any other thoughts in regards to SIMPLE? > > > > Is it a failure or not? > > > > Do we have a chance of fixing this within the IETF? > > > > Is anyone interested in fixing it so we actually reach the WG goal of interoperability?" > > > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From pkyzivat@alum.mit.edu Thu Nov 1 09:22:18 2012 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 E5B0121F8FCD for ; Thu, 1 Nov 2012 09:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJ7io-YlCV8P for ; Thu, 1 Nov 2012 09:22:17 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 551D321F8FCB for ; Thu, 1 Nov 2012 09:22:17 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta12.westchester.pa.mail.comcast.net with comcast id JFtC1k0071c6gX85CGNMpN; Thu, 01 Nov 2012 16:22:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id JGMU1k00p3ZTu2S3jGMURt; Thu, 01 Nov 2012 16:21:29 +0000 Message-ID: <5092A1B5.7090208@alum.mit.edu> Date: Thu, 01 Nov 2012 12:22:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: simple@ietf.org References: <50928A33.4090306@stpeter.im> <50928EF5.1070405@stpeter.im> <8BF6C00C-DB0C-4E9E-B5AA-CB04D1649659@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Simple] Fwd: [precis] spaces at end of nickname 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 Nov 2012 16:22:18 -0000 On 11/1/12 11:10 AM, Saúl Ibarra Corretgé wrote: > > On Nov 1, 2012, at 4:07 PM, Ben Campbell wrote: > >> +1. Should we generalize this to leading and trailing white space? >> > > I think so. Spaces are not perceived depending on where you align the text in a user interface. Agree with above. In addition I think whitespace other than 'space' should be excluded (maybe it already is), and multiple sequential embedded spaces should be excluded. (Will you notice the difference between "St Peter" and "St Peter")? Thanks, Paul From stpeter@stpeter.im Thu Nov 1 09:58:12 2012 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 D1A6821F887B for ; Thu, 1 Nov 2012 09:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ydh29Lsc3qbq for ; Thu, 1 Nov 2012 09:58:11 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 90D3921F8866 for ; Thu, 1 Nov 2012 09:57:49 -0700 (PDT) Received: from [64.101.72.26] (unknown [64.101.72.26]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8D3524011B; Thu, 1 Nov 2012 11:01:16 -0600 (MDT) Message-ID: <5092AA0E.3070208@stpeter.im> Date: Thu, 01 Nov 2012 10:57:50 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Paul Kyzivat References: <50928A33.4090306@stpeter.im> <50928EF5.1070405@stpeter.im> <8BF6C00C-DB0C-4E9E-B5AA-CB04D1649659@nostrum.com> <5092A1B5.7090208@alum.mit.edu> In-Reply-To: <5092A1B5.7090208@alum.mit.edu> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: simple@ietf.org Subject: Re: [Simple] Fwd: [precis] spaces at end of nickname 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 Nov 2012 16:58:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/1/12 10:22 AM, Paul Kyzivat wrote: > On 11/1/12 11:10 AM, Saúl Ibarra Corretgé wrote: >> >> On Nov 1, 2012, at 4:07 PM, Ben Campbell wrote: >> >>> +1. Should we generalize this to leading and trailing white >>> space? >>> >> >> I think so. Spaces are not perceived depending on where you align >> the text in a user interface. > > Agree with above. > > In addition I think whitespace other than 'space' should be > excluded (maybe it already is), Yes, all whitespace needs to be mapped to U+0020. > and multiple sequential embedded spaces should be excluded. (Will > you notice the difference between "St Peter" and "St Peter")? Probably not. This was suggested on the XMPP list, too. I think it's a good idea. Peter Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCSqg4ACgkQNL8k5A2w/vz4yQCggZ5Ve9Qbt2qvamFgNaK+inTp YcwAniFHpQ1Yrp30rfiO7HHS2jfiIVxv =qUxV -----END PGP SIGNATURE----- From oej@edvina.net Thu Nov 1 11:27:21 2012 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 4FB1A21F8E33 for ; Thu, 1 Nov 2012 11:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWMkiwtISMuT for ; Thu, 1 Nov 2012 11:27:20 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id C098721F8C2B for ; Thu, 1 Nov 2012 11:27:19 -0700 (PDT) Received: from [192.168.40.19] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 73FD9754A8A7; Thu, 1 Nov 2012 18:27:17 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_ED92D10D-6823-4F42-B3D3-E37C48A639B8" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 1 Nov 2012 19:27:16 +0100 Message-Id: <13B3F973-7BFC-42EA-A970-BA9E60925A7B@edvina.net> References: To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1499) Cc: Bernard Aboba , "simple@ietf.org" Subject: Re: [Simple] SIMPLE and Emergency Services 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 Nov 2012 18:27:21 -0000 --Apple-Mail=_ED92D10D-6823-4F42-B3D3-E37C48A639B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 1 nov 2012 kl. 16:44 skrev "DRAGE, Keith (Keith)" = : > Release 11 of 3GPP IMS specifications add session based media to = emergency call usage in addition to voice and real time text. For = messaging, that includes MSRP. > =20 > While many countries are trying to ensure that PSAPs can handle SMS = (which is not session based), this needs to be regarded as something = that exists where nothing else does =96 as it provides the responder = with no ability to interrogate the user to obtain more information. > =20 > For presence, nothing special has been specified by 3GPP. Keith, Please guide me through this. Is 3gpp not using the OMA specs?=20 For me that is classified as "special" and not part of the IETF specs. = :-) If not, have 3gpp tested interoperability of SIMPLE across vendors? The = ability to add buddies and share buddy lists, regardless of client? Just = curious of the process. /O > =20 > Keith > =20 > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On = Behalf Of Bernard Aboba > Sent: 31 October 2012 22:08 > To: simple@ietf.org > Subject: Re: [Simple] SIMPLE and Emergency Services > =20 > In response to Olle's question about whether SIMPLE is an abject and = irredeemable failure, I would note that SIMPLE is still under = consideration for use in emergency services, if only because XMPP isn't = yet a viable alternative. For > example, both NENA i3 and ECRIT PhoneBCP mention SIMPLE, but refer to = XMPP > support of emergency services as future work. In emergency scenarios, = presence > and address books are typically not considered since the PSAP is = neither a > presentity nor a watcher. Instead, SIMPLE is used as a way of = conveying > information between the caller and PSAP, including location, a message = body and > additional data.=20 >=20 > With SMS to 911 under active > discussion with regulatory bodies, the question about whether we can = rely on > SIMPLE for emergency use has become a "hot issue". As an example, > there has been a suggestion that MESSAGE could be used to support = conveyance of SMS text messages to a > "text gateway" that would then pass them on to the PSAP (possibly in > a different form, such as translating to TTY/TDD). Not only might = this > help standardize the transport of SMS messages to 911, but it would = also > support future uses of MESSAGE for next generation emergency services.=20= >=20 >=20 >=20 >=20 >=20 >=20 > While documents like NENAi3 and ECRIT PhoneBCP still point > to SIMPLE specs, some folks have pointed to the lack of support for = MESSAGE in > SIP trunking services as an indication that even basic uses of SIMPLE = are > unlikely to see much deployment, and that alternatives for disabled = access to > emergency services (such as RFC 4103 realtime text) should be given = priority.=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > IMHO, unless XMPP for emergency uses is specified by IETF > in the near future, it is likely that SIMPLE will find its way into = emergency > services architectures in some form. Since the IETF is still = recommending > SIMPLE in documents such as ECRIT PhoneBCP, IMHO the IETF has a = responsibility > to public safety to address interop issues that will arise in next = generation > emergency services scenarios. AFAIK, SIMPLE interop issues haven't = killed > anyone yet. Hopefully this will remain true in the future.=20 >=20 >=20 >=20 >=20 >=20 >=20 > Olle E. Johansson said:=20 >=20 >=20 > "Any other thoughts in regards to SIMPLE? > =20 > Is it a failure or not? > =20 > Do we have a chance of fixing this within the IETF? > =20 > Is anyone interested in fixing it so we actually reach the WG goal of = interoperability?" > =20 > =20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail=_ED92D10D-6823-4F42-B3D3-E37C48A639B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
1 nov 2012 kl. = 16:44 skrev "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.= com>:

Release 11 of 3GPP IMS = specifications add session based media to emergency call usage in = addition to voice and real time text. For messaging, that includes = MSRP.
 
While many = countries are trying to ensure that PSAPs can handle SMS (which is not = session based), this needs to be regarded as something that exists where = nothing else does =96 as it provides the responder with no ability to = interrogate the user to obtain more = information.
 
For = presence, nothing special has been specified by = 3GPP.
Keith,
Please = guide me through this. Is 3gpp not using the OMA = specs? 

For me that is classified as = "special" and not part of the IETF specs. = :-)

If not, have 3gpp tested interoperability = of SIMPLE across vendors? The ability to add buddies and share buddy = lists, regardless of client? Just curious of the = process.

/O

 
 
 simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Bernard = Aboba
Sent: 31 October 2012 = 22:08
To: simple@ietf.org
Subject: Re: [Simple] SIMPLE and = Emergency Services
 For example, both NENA i3 and ECRIT PhoneBCP mention SIMPLE, but refer to = XMPP support of emergency services as future work. In emergency scenarios, = presence and address books are typically not considered since the PSAP is neither = a presentity nor a watcher.  Instead, SIMPLE is used as a way of = conveying information between the caller and PSAP, including location, a message = body and additional data.
With SMS to = 911 under active discussion with regulatory bodies, the question about whether we can = rely on SIMPLE for emergency use has become a "hot issue". As an example, there has been a suggestion that MESSAGE could be used to support conveyance of SMS text = messages to a "text gateway" that would then pass them on to the PSAP (possibly in a different form, such as translating to TTY/TDD).  Not only might = this help standardize the transport of SMS messages to 911, but it would also support future uses of MESSAGE for next generation emergency services. =


While documents like NENAi3 and ECRIT = PhoneBCP still point to SIMPLE specs, some folks have pointed to the lack of support for = MESSAGE in SIP trunking services as an indication that even basic uses of SIMPLE = are unlikely to see much deployment, and that alternatives for disabled = access to emergency services (such as RFC 4103 realtime text) should be given = priority. 


IMHO, unless XMPP for emergency uses is = specified by IETF in the near future, it is likely that SIMPLE will find its way into = emergency services architectures in some form. Since the IETF is still = recommending SIMPLE in documents such as ECRIT PhoneBCP, IMHO the IETF has a = responsibility to public safety to address interop issues that will arise in next = generation emergency services scenarios. AFAIK, SIMPLE interop issues haven't = killed anyone yet. Hopefully this will remain true in the future. =


Olle E. Johansson said: 
"Any other thoughts in regards to =
SIMPLE?
 
Simple@ietf.org

To: =?iso-8859-1?B?U2H6bCBJYmFycmEgQ29ycmV0Z+k=?= 
Date: Thu, 1 Nov 2012 11:34:28 -0700
Importance: Normal
In-Reply-To: 
References: , 
MIME-Version: 1.0
X-OriginalArrivalTime: 01 Nov 2012 18:34:28.0482 (UTC) FILETIME=[86B1DE20:01CDB85F]
Cc: "simple@ietf.org" 
Subject: Re: [Simple] SIMPLE and Emergency Services
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 Nov 2012 18:34:31 -0000

--_6768b62c-b049-46ca-96aa-4fc4c22bd7d2_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Saul wrote:=20

> I see you are mentioning SIP MESSAGE all along=2C but (please someone cor=
rect me if I'm wrong) the IM functionality advocated by SIMPLE is MSRP=2C n=
ot SIP MESSAGE. For translating SMS messages SIP MESSAGE works=2C but it la=
cks the concept of a 'session'=2C so it doesn't fit well a model for a conv=
ersation.

[BA] NENA i3 requires implementation of both MSRP and MESSAGE at the PSAP. =
 ECRIT PhoneBCP also mentions both.  So for emergency  uses=2C both MSRP an=
d MESSAGE are potentially relevant.=20

> Realtime text is another stream type negotiated with an INVITE=2C so I gu=
ess MSRP could be used just fine for the same purpose by sending one MSRP c=
hunk with a single character at a time. There would be a bit of overhead=2C=
 however.

[BA]  Currently the Access Board and other regulatory bodies do not have MS=
RP on the list of approved "realtime text" standards.=20

> I'm unfamiliar with those documents=2C but are we talking presence here? =
Because this whole thing started about the presence part. To my knowledge t=
here are no interoperability problems with MSRP implementations following t=
he standard.

[BA] Presence and address books are not relevant to emergency services beca=
use the PSAP is neither a presentity nor a watcher.
 		 	   		  =

--_6768b62c-b049-46ca-96aa-4fc4c22bd7d2_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





Saul wrote: 

>=3B =
I see you are mentioning SIP MESSAGE all along=2C but (please someone corre=
ct me if I'm wrong) the IM functionality advocated by SIMPLE is MSRP=2C not=
 SIP MESSAGE. For translating SMS messages SIP MESSAGE works=2C but it lack=
s the concept of a 'session'=2C so it doesn't fit well a model for a conver=
sation.

[BA] NENA i3 requires implementation of both MSRP and MESSAG=
E at the PSAP. =3B ECRIT PhoneBCP also mentions both. =3B So for em=
ergency =3B uses=2C both MSRP and MESSAGE are potentially relevant. 
>=3B Realtime text is another stream type negotiated with an INVITE=
=2C so I guess MSRP could be used just fine for the same purpose by sending=
 one MSRP chunk with a single character at a time. There would be a bit of =
overhead=2C however.

[BA] =3B Currently the Access Board and oth=
er regulatory bodies do not have MSRP on the list of approved "realtime tex=
t" standards. 

>=3B I'm unfamiliar with those documents=2C but are=
 we talking presence here? Because this whole thing started about the prese=
nce part. To my knowledge there are no interoperability problems with MSRP =
implementations following the standard.

[BA] Presence and address bo=
oks are not relevant to emergency services because the PSAP is neither a pr=
esentity nor a watcher.
 		 	   		  

=

--_6768b62c-b049-46ca-96aa-4fc4c22bd7d2_--

From keith.drage@alcatel-lucent.com  Thu Nov  1 11:40:23 2012
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 7EF9A21F9339 for ; Thu,  1 Nov 2012 11:40:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.248
X-Spam-Level: 
X-Spam-Status: No, score=-110.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFwvezForbJd for ; Thu,  1 Nov 2012 11:40:20 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id DF82221F9340 for ; Thu,  1 Nov 2012 11:40:19 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA1IeDXr010761 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 1 Nov 2012 19:40:13 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 1 Nov 2012 19:40:13 +0100
From: "DRAGE, Keith (Keith)" 
To: "Olle E. Johansson" 
Date: Thu, 1 Nov 2012 19:40:11 +0100
Thread-Topic: [Simple] SIMPLE and Emergency Services
Thread-Index: Ac24Xo06g5uztCE2T3ebyiI2uJsdQgAALH6w
Message-ID: 
References:   <13B3F973-7BFC-42EA-A970-BA9E60925A7B@edvina.net>
In-Reply-To: <13B3F973-7BFC-42EA-A970-BA9E60925A7B@edvina.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE202D2F6F6E3FRMRSSXCHMBSC_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Cc: Bernard Aboba , "simple@ietf.org" 
Subject: Re: [Simple] SIMPLE and Emergency Services
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 Nov 2012 18:40:23 -0000

--_000_EDC0A1AE77C57744B664A310A0B23AE202D2F6F6E3FRMRSSXCHMBSC_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

As regards presence usage in 3GPP, my statement about presence related to e=
mergency usage only.

As a capability, 3GPP specified presence in release 6, in 3GPP TS 24.141. T=
his is an endorsement of IETF SIMPLE documents with the minor exception of =
collection of presence information about the user using existing 3GPP inter=
nal interfaces (e.g. status from HSS, location from GMLC), which are then a=
dapted into SIMPLE protocols.

OMA subsequently specified their stuff which enhances and expands on IETF S=
IMPLE.

TISPAN took the 3GPP presence usage, but took the OMA XDM stuff to cover th=
e list management.

GSMA took the OMA documents to create RCS.

Operators could be deploying any of this, but I suspect they are using RCS =
primarily.

And as said, none of this applies to emergency call to my knowledge, except=
 possibly in the context of the PSAP being a normal user and being able to =
watch with those capabilities.

Keith

________________________________
From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of=
 Olle E. Johansson
Sent: 01 November 2012 18:27
To: DRAGE, Keith (Keith)
Cc: Bernard Aboba; simple@ietf.org
Subject: Re: [Simple] SIMPLE and Emergency Services


1 nov 2012 kl. 16:44 skrev "DRAGE, Keith (Keith)" >:


Release 11 of 3GPP IMS specifications add session based media to emergency =
call usage in addition to voice and real time text. For messaging, that inc=
ludes MSRP.

While many countries are trying to ensure that PSAPs can handle SMS (which =
is not session based), this needs to be regarded as something that exists w=
here nothing else does - as it provides the responder with no ability to in=
terrogate the user to obtain more information.

For presence, nothing special has been specified by 3GPP.
Keith,
Please guide me through this. Is 3gpp not using the OMA specs?

For me that is classified as "special" and not part of the IETF specs. :-)

If not, have 3gpp tested interoperability of SIMPLE across vendors? The abi=
lity to add buddies and share buddy lists, regardless of client? Just curio=
us of the process.

/O



Keith

________________________________
From: simple-bounces@ietf.org [mailto:simpl=
e-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: 31 October 2012 22:08
To: simple@ietf.org
Subject: Re: [Simple] SIMPLE and Emergency Services

In response to Olle's question about whether SIMPLE is an abject and irrede=
emable failure,  I would note that SIMPLE is still under consideration for =
use in emergency services, if only because XMPP isn't yet a viable alternat=
ive. For example, both NENA i3 and ECRIT PhoneBCP mention SIMPLE, but refer=
 to XMPP support of emergency services as future work. In emergency scenari=
os, presence and address books are typically not considered since the PSAP =
is neither a presentity nor a watcher.  Instead, SIMPLE is used as a way of=
 conveying information between the caller and PSAP, including location, a m=
essage body and additional data.
With SMS to 911 under active discussion with regulatory bodies, the questio=
n about whether we can rely on SIMPLE for emergency use has become a "hot i=
ssue". As an example, there has been a suggestion that MESSAGE could be use=
d to support conveyance of SMS text messages to a "text gateway" that would=
 then pass them on to the PSAP (possibly in a different form, such as trans=
lating to TTY/TDD).  Not only might this help standardize the transport of =
SMS messages to 911, but it would also support future uses of MESSAGE for n=
ext generation emergency services.



While documents like NENAi3 and ECRIT PhoneBCP still point to SIMPLE specs,=
 some folks have pointed to the lack of support for MESSAGE in SIP trunking=
 services as an indication that even basic uses of SIMPLE are unlikely to s=
ee much deployment, and that alternatives for disabled access to emergency =
services (such as RFC 4103 realtime text) should be given priority.



IMHO, unless XMPP for emergency uses is specified by IETF in the near futur=
e, it is likely that SIMPLE will find its way into emergency services archi=
tectures in some form. Since the IETF is still recommending SIMPLE in docum=
ents such as ECRIT PhoneBCP, IMHO the IETF has a responsibility to public s=
afety to address interop issues that will arise in next generation emergenc=
y services scenarios. AFAIK, SIMPLE interop issues haven't killed anyone ye=
t. Hopefully this will remain true in the future.



Olle E. Johansson said:

"Any other thoughts in regards to SIMPLE?



Is it a failure or not?



Do we have a chance of fixing this within the IETF?



Is anyone interested in fixing it so we actually reach the WG goal of inter=
operability?"




_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple


--_000_EDC0A1AE77C57744B664A310A0B23AE202D2F6F6E3FRMRSSXCHMBSC_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


















As regards presence usage in 3GPP, my
statement about presence related to emergency usage only.=




 



As a capability, 3GPP specified presen=
ce
in release 6, in 3GPP TS 24.141. This is an endorsement of IETF SIMPLE
documents with the minor exception of collection of presence information ab=
out
the user using existing 3GPP internal interfaces (e.g. status from HSS,
location from GMLC), which are then adapted into SIMPLE protocols.



 



OMA subsequently specified their stuff
which enhances and expands on IETF SIMPLE.



 



TISPAN took the 3GPP presence usage, b=
ut
took the OMA XDM stuff to cover the list management.



 



GSMA took the OMA documents to create =
RCS.



 



Operators could be deploying any of th=
is,
but I suspect they are using RCS primarily.



 



And as said, none of this applies to
emergency call to my knowledge, except possibly in the context of the PSAP
being a normal user and being able to watch with those capabilities.



 



Keith



 


















From:=

simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Olle E. Johansson

Sent: 01 November 2012 18:27=


To: DRAGE, Keith (Keith)

Cc: Bernard Aboba; simple@ie=
tf.org

Subject: Re: [Simple] SIMPLE=
 and
Emergency Services






 



 






















Release 11 of 3GPP IMS specifications =
add
session based media to emergency call usage in addition to voice and real t=
ime
text. For messaging, that includes MSRP.









 









While many countries are trying to ens=
ure
that PSAPs can handle SMS (which is not session based), this needs to be
regarded as something that exists where nothing else does – as it
provides the responder with no ability to interrogate the user to obtain mo=
re
information.









 









For presence, nothing special has been
specified by 3GPP.









Keith,









Please guide me through this. Is 3gpp not using the OMA specs? =
;









 









For me that is classified as "special" and not part of th=
e
IETF specs. :-)









 









If not, have 3gpp tested interoperability of SIMPLE across vendors?=
 The
ability to add buddies and share buddy lists, regardless of client? Just
curious of the process.









 









/O

























 









Keith<=
/o:p>









 
























From:=
 simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On
Behalf Of Bernar=
d
Aboba

Sent: 31 October 2012 22:08

To: simple@ietf.org

Subject: Re: [Simple] SIMPLE and Emergenc=
y
Services














 









In response to Olle's question about whether SI=
MPLE
is an abject and irredeemable failure,  I would note that SIMPLE is st=
ill
under consideration for use in emergency services, if only because XMPP isn=
't
yet a viable alternative. <=
/span>For example, both NENA i3 an=
d
ECRIT PhoneBCP mention SIMPLE, but refer to XMPP support of emergency servi=
ces
as future work. In emergency scenarios, presence and address books are
typically not considered since the PSAP is neither a presentity nor a
watcher.  Instead, SIMPLE is used as a way of conveying information
between the caller and PSAP, including location, a message body and additio=
nal
data. 











With SMS to 911 under active
discussion with regulatory bodies, the question about whether we can rely o=
n
SIMPLE for emergency use has become a "hot issue". As an example,
there has been a suggestion that MESSAGE could be used to support conveyance of SMS text messages to a
"text gateway" that would then pass them on to the PSAP (possibly=
 in
a different form, such as translating to TTY/TDD).  Not only might thi=
s
help standardize the transport of SMS messages to 911, but it would also
support future uses of MESSAGE for next generation emergency services. 







































While documents like NENAi3 and ECRIT PhoneBCP still p=
oint
to SIMPLE specs, some folks have pointed to the lack of support for MESSAGE=
 in
SIP trunking services as an indication that even basic uses of SIMPLE are
unlikely to see much deployment, and that alternatives for disabled access =
to
emergency services (such as RFC 4103 realtime text) should be given priorit=
y. 









































IMHO, unless XMPP for emergency uses is specified by I=
ETF
in the near future, it is likely that SIMPLE will find its way into emergen=
cy
services architectures in some form. Since the IETF is still recommending
SIMPLE in documents such as ECRIT PhoneBCP, IMHO the IETF has a responsibil=
ity
to public safety to address interop issues that will arise in next generati=
on
emergency services scenarios. AFAIK, SIMPLE interop issues haven't killed
anyone yet. Hopefully this will remain true in the future. 









































Olle E. Johansson said: 









"A=
ny other thoughts in regards to SIMPLE?
 
Is it a failure or not?
<=
font
size=3D3 face=3DCalibri> 
Do we have a chance of fixing this within the IETF?
 
Is anyone interested in fixing it so we actually reach the WG goal of int=
eroperability?"
 
 






_______________________________________________

Simple mailing list

Simple@ietf.org

https://www.ietf.org/mailman/listinfo/simple=










 












--_000_EDC0A1AE77C57744B664A310A0B23AE202D2F6F6E3FRMRSSXCHMBSC_--

From bernard_aboba@hotmail.com  Thu Nov  1 11:45:55 2012
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 AD1F321F9360 for ; Thu,  1 Nov 2012 11:45:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.548
X-Spam-Level: 
X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNNsBIpPGA3i for ; Thu,  1 Nov 2012 11:45:55 -0700 (PDT)
Received: from blu0-omc4-s17.blu0.hotmail.com (blu0-omc4-s17.blu0.hotmail.com [65.55.111.156]) by ietfa.amsl.com (Postfix) with ESMTP id A018721F935D for ; Thu,  1 Nov 2012 11:45:54 -0700 (PDT)
Received: from BLU002-W201 ([65.55.111.136]) by blu0-omc4-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 1 Nov 2012 11:45:51 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_4af246f1-3bb1-494f-8ff9-8cee7b476232_"
X-Originating-IP: [131.107.0.81]
From: Bernard Aboba 
To: "Olle E. Johansson" 
Date: Thu, 1 Nov 2012 11:45:52 -0700
Importance: Normal
In-Reply-To: <13B3F973-7BFC-42EA-A970-BA9E60925A7B@edvina.net>
References:  , <13B3F973-7BFC-42EA-A970-BA9E60925A7B@edvina.net>
MIME-Version: 1.0
X-OriginalArrivalTime: 01 Nov 2012 18:45:51.0763 (UTC) FILETIME=[1DF64630:01CDB861]
Cc: "simple@ietf.org" 
Subject: Re: [Simple] SIMPLE and Emergency Services
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 Nov 2012 18:45:55 -0000

--_4af246f1-3bb1-494f-8ff9-8cee7b476232_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Olle said:

"have 3gpp tested interoperability of SIMPLE across vendors? The ability to=
 add buddies and share buddy lists=2C regardless of client? Just curious of=
 the process."

[BA] AFAIK=2C there has been no interoperability testing of SIMPLE in emerg=
ency services scenarios (e.g. NENA ICE)=2C and I am not aware of any emerge=
ncy service providers that support either MSRP or MESSAGE.  The vast majori=
ty of SIP service providers also do not support SIMPLE=2C even for basic sc=
enarios such as sending/receiving SMS via MESSAGE.   Given the potential ti=
melines for shutdown of POTS (e.g. projections indicate that POTS will not =
longer be economically viable by 2018) and the transition to next generatio=
n emergency services (by the time POTS is shut down=2C we better have NG PS=
APs)=2C there is still quite a bit of work to do.=20




 		 	   		  =

--_4af246f1-3bb1-494f-8ff9-8cee7b476232_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





Olle said:

"have 3gpp tes=
ted interoperability of SIMPLE across vendors? The ability to add buddies a=
nd share buddy lists=2C regardless of client? Just curious of the process."=


[BA] AFAIK=2C there has been no interoperability testing of SIMPLE =
in emergency services scenarios (e.g. NENA ICE)=2C and I am not aware of an=
y emergency service providers that support either MSRP or MESSAGE. =3B =
The vast majority of SIP service providers also do not support SIMPLE=2C ev=
en for basic scenarios such as sending/receiving SMS via MESSAGE. =3B&n=
bsp=3B Given the potential timelines for shutdown of POTS (e.g. projections=
 indicate that POTS will not longer be economically viable by 2018) and the=
 transition to next generation emergency services (by the time POTS is shut=
 down=2C we better have NG PSAPs)=2C there is still quite a bit of work to =
do. 




 		 	   		  

=

--_4af246f1-3bb1-494f-8ff9-8cee7b476232_--

From oej@edvina.net  Thu Nov  1 11:53:29 2012
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 26ECF21F8D1C for ; Thu,  1 Nov 2012 11:53:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.445
X-Spam-Level: 
X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.153,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VnFUD8kalat for ; Thu,  1 Nov 2012 11:53:28 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 4C77521F8D13 for ; Thu,  1 Nov 2012 11:53:28 -0700 (PDT)
Received: from [192.168.40.19] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 5620F754A8A7; Thu,  1 Nov 2012 18:53:27 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail=_636D7CEA-C753-4C15-A5BA-085B322F58AA"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: "Olle E. Johansson" 
In-Reply-To: 
Date: Thu, 1 Nov 2012 19:53:25 +0100
Message-Id: <89EE0268-FC93-4FA0-BC59-1994C8472F5C@edvina.net>
References:  , <13B3F973-7BFC-42EA-A970-BA9E60925A7B@edvina.net> 
To: Bernard Aboba 
X-Mailer: Apple Mail (2.1499)
Cc: "simple@ietf.org" 
Subject: Re: [Simple] SIMPLE and Emergency Services
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 Nov 2012 18:53:29 -0000

--Apple-Mail=_636D7CEA-C753-4C15-A5BA-085B322F58AA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


1 nov 2012 kl. 19:45 skrev Bernard Aboba :

> Olle said:
>=20
> "have 3gpp tested interoperability of SIMPLE across vendors? The =
ability to add buddies and share buddy lists, regardless of client? Just =
curious of the process."
>=20
> [BA] AFAIK, there has been no interoperability testing of SIMPLE in =
emergency services scenarios (e.g. NENA ICE), and I am not aware of any =
emergency service providers that support either MSRP or MESSAGE.  The =
vast majority of SIP service providers also do not support SIMPLE, even =
for basic scenarios such as sending/receiving SMS via MESSAGE.   Given =
the potential timelines for shutdown of POTS (e.g. projections indicate =
that POTS will not longer be economically viable by 2018) and the =
transition to next generation emergency services (by the time POTS is =
shut down, we better have NG PSAPs), there is still quite a bit of work =
to do.=20
>=20
Thanks for your information.

I'm personally a bit involved in the Swedish implementation of emergency =
services, so this is important information. In Sweden, the goal is to =
allow enterprises to call directly, bypassing the SIP trunks. That way =
we could possibly get more support for non-phone-call SIP, like MESSAGE =
or MSRP.

My questions to Keith was more general - not specific to emergency =
services. Sorry, I should have changed the subject.

/O=

--Apple-Mail=_636D7CEA-C753-4C15-A5BA-085B322F58AA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1


1 nov 2012 kl. =
19:45 skrev Bernard Aboba <bernard_aboba@hotmail.com>=
;:

Olle said:

"have 3gpp tested interoperability of =
SIMPLE across vendors? The ability to add buddies and share buddy lists, =
regardless of client? Just curious of the process."

[BA] AFAIK, =
there has been no interoperability testing of SIMPLE in emergency =
services scenarios (e.g. NENA ICE), and I am not aware of any emergency =
service providers that support either MSRP or MESSAGE.  The vast =
majority of SIP service providers also do not support SIMPLE, even for =
basic scenarios such as sending/receiving SMS via MESSAGE.   =
Given the potential timelines for shutdown of POTS (e.g. projections =
indicate that POTS will not longer be economically viable by 2018) and =
the transition to next generation emergency services (by the time POTS =
is shut down, we better have NG PSAPs), there is still quite a bit of =
work to do. 

Thanks for your information.

I'm personally =
a bit involved in the Swedish implementation of emergency services, so =
this is important information. In Sweden, the goal is to allow =
enterprises to call directly, bypassing the SIP trunks. That way we =
could possibly get more support for non-phone-call SIP, like MESSAGE or =
MSRP.

My questions to Keith was more general - =
not specific to emergency services. Sorry, I should have changed the =
subject.

/O
=

--Apple-Mail=_636D7CEA-C753-4C15-A5BA-085B322F58AA--

From oej@edvina.net  Thu Nov  1 12:21:05 2012
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 972B821F946E for ; Thu,  1 Nov 2012 12:21:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.32
X-Spam-Level: 
X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=-0.022,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7df-V2s3Kni for ; Thu,  1 Nov 2012 12:21:04 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 4206321F946C for ; Thu,  1 Nov 2012 12:21:03 -0700 (PDT)
Received: from [192.168.40.19] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id E3AC5754A8A7; Thu,  1 Nov 2012 19:21:01 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail=_BE2B0F8D-257B-41EB-B651-6B044BC1C0C2"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: "Olle E. Johansson" 
In-Reply-To: 
Date: Thu, 1 Nov 2012 20:20:59 +0100
Message-Id: 
References:   <13B3F973-7BFC-42EA-A970-BA9E60925A7B@edvina.net> 
To: "DRAGE, Keith (Keith)" 
X-Mailer: Apple Mail (2.1499)
Cc: Bernard Aboba , "simple@ietf.org" 
Subject: Re: [Simple] =?windows-1252?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=85_?= =?windows-1252?q?=28new_subject=29?=
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 Nov 2012 19:21:05 -0000

--Apple-Mail=_BE2B0F8D-257B-41EB-B651-6B044BC1C0C2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


1 nov 2012 kl. 19:40 skrev "DRAGE, Keith (Keith)" =
:

> As regards presence usage in 3GPP, my statement about presence related =
to emergency usage only.
> =20
> As a capability, 3GPP specified presence in release 6, in 3GPP TS =
24.141. This is an endorsement of IETF SIMPLE documents with the minor =
exception of collection of presence information about the user using =
existing 3GPP internal interfaces (e.g. status from HSS, location from =
GMLC), which are then adapted into SIMPLE protocols.
> =20
> OMA subsequently specified their stuff which enhances and expands on =
IETF SIMPLE.
> =20
> TISPAN took the 3GPP presence usage, but took the OMA XDM stuff to =
cover the list management.
> =20
> GSMA took the OMA documents to create RCS.
> =20
> Operators could be deploying any of this, but I suspect they are using =
RCS primarily.
> =20
> And as said, none of this applies to emergency call to my knowledge, =
except possibly in the context of the PSAP being a normal user and being =
able to watch with those capabilities.

Keith,
Thanks for taking me through that dance... I now have a better =
understanding.

What is the current relationship betwen OMA and the IETF? ANy =
cooperation, like between 3Gpp and the IETF?

/O

> =20
> Keith
> =20
> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On =
Behalf Of Olle E. Johansson
> Sent: 01 November 2012 18:27
> To: DRAGE, Keith (Keith)
> Cc: Bernard Aboba; simple@ietf.org
> Subject: Re: [Simple] SIMPLE and Emergency Services
> =20
> =20
> 1 nov 2012 kl. 16:44 skrev "DRAGE, Keith (Keith)" =
:
>=20
>=20
> Release 11 of 3GPP IMS specifications add session based media to =
emergency call usage in addition to voice and real time text. For =
messaging, that includes MSRP.
> =20
> While many countries are trying to ensure that PSAPs can handle SMS =
(which is not session based), this needs to be regarded as something =
that exists where nothing else does =96 as it provides the responder =
with no ability to interrogate the user to obtain more information.
> =20
> For presence, nothing special has been specified by 3GPP.
> Keith,
> Please guide me through this. Is 3gpp not using the OMA specs?=20
> =20
> For me that is classified as "special" and not part of the IETF specs. =
:-)
> =20
> If not, have 3gpp tested interoperability of SIMPLE across vendors? =
The ability to add buddies and share buddy lists, regardless of client? =
Just curious of the process.
> =20
> /O
>=20
>=20
> =20
> Keith
> =20
> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On =
Behalf Of Bernard Aboba
> Sent: 31 October 2012 22:08
> To: simple@ietf.org
> Subject: Re: [Simple] SIMPLE and Emergency Services
> =20
> In response to Olle's question about whether SIMPLE is an abject and =
irredeemable failure,  I would note that SIMPLE is still under =
consideration for use in emergency services, if only because XMPP isn't =
yet a viable alternative. For example, both NENA i3 and ECRIT PhoneBCP =
mention SIMPLE, but refer to XMPP support of emergency services as =
future work. In emergency scenarios, presence and address books are =
typically not considered since the PSAP is neither a presentity nor a =
watcher.  Instead, SIMPLE is used as a way of conveying information =
between the caller and PSAP, including location, a message body and =
additional data.
>=20
> With SMS to 911 under active
> discussion with regulatory bodies, the question about whether we can =
rely on
> SIMPLE for emergency use has become a "hot issue". As an example,
> there has been a suggestion that MESSAGE could be used to support =
conveyance of SMS text messages to a
> "text gateway" that would then pass them on to the PSAP (possibly in
> a different form, such as translating to TTY/TDD).  Not only might =
this
> help standardize the transport of SMS messages to 911, but it would =
also
> support future uses of MESSAGE for next generation emergency services.=20=

>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> While documents like NENAi3 and ECRIT PhoneBCP still point to SIMPLE =
specs, some folks have pointed to the lack of support for MESSAGE in SIP =
trunking services as an indication that even basic uses of SIMPLE are =
unlikely to see much deployment, and that alternatives for disabled =
access to emergency services (such as RFC 4103 realtime text) should be =
given priority.=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> IMHO, unless XMPP for emergency uses is specified by IETF in the near =
future, it is likely that SIMPLE will find its way into emergency =
services architectures in some form. Since the IETF is still =
recommending SIMPLE in documents such as ECRIT PhoneBCP, IMHO the IETF =
has a responsibility to public safety to address interop issues that =
will arise in next generation emergency services scenarios. AFAIK, =
SIMPLE interop issues haven't killed anyone yet. Hopefully this will =
remain true in the future.
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> Olle E. Johansson said:=20
>=20
>=20
>=20
>=20
> "Any other thoughts in regards to SIMPLE?
> =20
> Is it a failure or not?
> =20
> Do we have a chance of fixing this within the IETF?
> =20
> Is anyone interested in fixing it so we actually reach the WG goal of =
interoperability?"
> =20
> =20
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple
> =20


--Apple-Mail=_BE2B0F8D-257B-41EB-B651-6B044BC1C0C2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


1 nov 2012 kl. =
19:40 skrev "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.=
com>:

As regards =
presence usage in 3GPP, my statement about presence related to emergency =
usage only.
 
As a =
capability, 3GPP specified presence in release 6, in 3GPP TS 24.141. =
This is an endorsement of IETF SIMPLE documents with the minor exception =
of collection of presence information about the user using existing 3GPP =
internal interfaces (e.g. status from HSS, location from GMLC), which =
are then adapted into SIMPLE =
protocols.
 
OMA =
subsequently specified their stuff which enhances and expands on IETF =
SIMPLE.
 
TISPAN took =
the 3GPP presence usage, but took the OMA XDM stuff to cover the list =
management.
 
GSMA took =
the OMA documents to create RCS.
Operators could be deploying any of =
this, but I suspect they are using RCS =
primarily.
 
And as =
said, none of this applies to emergency call to my knowledge, except =
possibly in the context of the PSAP being a normal user and being able =
to watch with those capabilities.

Keith,=
Thanks for taking me through that dance... I now have a = better understanding.

What is the current = relationship betwen OMA and the IETF? ANy cooperation, like between 3Gpp = and the IETF?

/O

 
In response to Olle's question about whether = SIMPLE is an abject and irredeemable failure,  I would note that = SIMPLE is still under consideration for use in emergency services, if = only because XMPP isn't yet a viable alternative. With = SMS to 911 under active discussion with regulatory bodies, the question about whether we can = rely on SIMPLE for emergency use has become a "hot issue". As an example, there has been a suggestion that MESSAGE could be used to support conveyance of SMS text = messages to a "text gateway" that would then pass them on to the PSAP (possibly in a different form, such as translating to TTY/TDD).  Not only might = this help standardize the transport of SMS messages to 911, but it would also support future uses of MESSAGE for next generation emergency services. =









Olle E. Johansson = said: 
"Any other thoughts in regards to =
SIMPLE?
 
Is it a failure or =
not?
 
Do we have a chance of fixing this within the =
IETF?
 
Is anyone interested in fixing it so we actually reach the WG =
goal of =
interoperability?"

X-Mailer: Apple Mail (2.1499)
Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: Bernard Aboba , "DRAGE, Keith \(Keith\)" , "simple@ietf.org" 
Subject: Re: [Simple] =?windows-1252?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=85_?= =?windows-1252?q?=28new_subject=29?=
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 Nov 2012 19:53:35 -0000

On Nov 1, 2012, at 2:20 PM, "Olle E. Johansson"  wrote:

> What is the current relationship betwen OMA and the IETF? ANy =
cooperation, like between 3Gpp and the IETF?
>=20


There is a liaison, but I don't think it's been very active for a while =
now.=20=

From hannes.tschofenig@gmx.net  Thu Nov  1 13:09:06 2012
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 6A9A121F9631 for ; Thu,  1 Nov 2012 13:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.373
X-Spam-Level: 
X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BW70Hjld5Y3V for ; Thu,  1 Nov 2012 13:09:06 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 77A9421F962F for ; Thu,  1 Nov 2012 13:09:05 -0700 (PDT)
Received: (qmail invoked by alias); 01 Nov 2012 20:09:03 -0000
Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.103]) [88.115.216.191] by mail.gmx.net (mp001) with SMTP; 01 Nov 2012 21:09:03 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+E23E3iteE34ghwzC/BFH0iJ2GNot0b2wOn5Vte0 saLxWvexPFTq7L
Date: Thu, 01 Nov 2012 22:08:48 +0200
Message-ID: 
From: Hannes Tschofenig 
To: Ben Campbell 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
X-Y-GMX-Trusted: 0
Cc: Bernard Aboba , "DRAGE, Keith \(Keith\)" , "	simple@ietf.org" 
Subject: Re: [Simple] =?utf-8?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=E2=80=A6_?= =?utf-8?q?=28new_subject=29?=
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 Nov 2012 20:09:06 -0000

TXVycmF5IHdhcyB0aGUgbGlhaXNvbiBwZXJzb24gdG8gdGhlIE9NQSBmcm9tIHRoZSBJRVRGIHNp
ZGUuIE11cnJheSByZWNlbnRseSBkaXNjb250aW51ZWQgaGlzIHBhcnRpY2lwYXRpb24gaW4gdGhl
IE9NQSAoZHVlIHRvIGEgam9iIGNoYW5nZSkuIFdlIGRpc2N1c3NlZCB0aGUgbmVlZCB0byBhcHBv
aW50IGEgbmV3IGxpYWlzb24gcGVyc29uIGluIHRoZSBJQUIgYW5kIGNhbWUgdG8gdGhlIGNvbmNs
dXNpb24gdGhhdCBubyBuZXcgYXBwb2ludG1lbnQgaXMgbmVjZXNzYXJ5OyB0aGUgcmVxdWlyZWQg
bmVlZCB0byBpbnRlcmFjdCB3aXRoIHRoZSBPTUEgaGFkIGRlY3JlYXNlZCBvdmVyIHRpbWUuIAoK
RG9lcyBhbnlvbmUgb24gdGhpcyBsaXN0IGJlbGlldmUgdGhhdCB0aGVyZSBpcyBhIG5lZWQgZm9y
IGNvb3BlcmF0aW9uIHdpdGggdGhlIE9NQT8KCkNpYW8KSGFubmVzCgpTZW50IGZyb20gbXkgQVNV
UyBQYWQKCkJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPiB3cm90ZToKCj4KPk9uIE5vdiAx
LCAyMDEyLCBhdCAyOjIwIFBNLCAiT2xsZSBFLiBKb2hhbnNzb24iIDxvZWpAZWR2aW5hLm5ldD4g
d3JvdGU6Cj4KPj4gV2hhdCBpcyB0aGUgY3VycmVudCByZWxhdGlvbnNoaXAgYmV0d2VuIE9NQSBh
bmQgdGhlIElFVEY/IEFOeSBjb29wZXJhdGlvbiwgbGlrZSBiZXR3ZWVuIDNHcHAgYW5kIHRoZSBJ
RVRGPwo+PiAKPgo+Cj5UaGVyZSBpcyBhIGxpYWlzb24sIGJ1dCBJIGRvbid0IHRoaW5rIGl0J3Mg
YmVlbiB2ZXJ5IGFjdGl2ZSBmb3IgYSB3aGlsZSBub3cuIAo+X19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KPlNpbXBsZSBtYWlsaW5nIGxpc3QKPlNpbXBsZUBp
ZXRmLm9yZwo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaW1wbGUK


From gunnar.hellstrom@omnitor.se  Thu Nov  1 13:40:09 2012
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 61DE621F95F4 for ; Thu,  1 Nov 2012 13:40:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level: 
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pz-ZPCY7C31F for ; Thu,  1 Nov 2012 13:40:08 -0700 (PDT)
Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 4708E21F9630 for ; Thu,  1 Nov 2012 13:40:06 -0700 (PDT)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Thu,  1 Nov 2012 21:39:58 +0100 (CET)
Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id 904573A187 for ; Thu,  1 Nov 2012 21:39:58 +0100 (CET)
Message-ID: <5092DE1E.9010506@omnitor.se>
Date: Thu, 01 Nov 2012 21:39:58 +0100
From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: simple@ietf.org
References:  , <13B3F973-7BFC-42EA-A970-BA9E60925A7B@edvina.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090301060308000700050106"
Subject: Re: [Simple] SIMPLE and Emergency Services
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 Nov 2012 20:40:09 -0000

This is a multi-part message in MIME format.
--------------090301060308000700050106
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

  Bernard Aboba wrote:
> [BA] AFAIK, there has been no interoperability testing of SIMPLE in 
> emergency services scenarios (e.g. NENA ICE), and I am not aware of 
> any emergency service providers that support either MSRP or MESSAGE. 
NENA ICE5 results say:

Testing covered a range of subjects that included:

  * Testing of methods for handling text messages within the i3 architecture

See http://www.nena.org/?NG911_ICE5


/Gunnar



--------------090301060308000700050106
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
 Bernard Aboba wrote:

    

    
[BA] AFAIK, there has been no interoperability testing
      of SIMPLE in emergency services scenarios (e.g. NENA ICE), and I
      am not aware of any emergency service providers that support
      either MSRP or MESSAGE.  

    NENA ICE5 results say:

    

     Testing covered a range of
      subjects that included:

    
    
      
  • Testing of methods for handling
          text messages within the i3 architecture
    • 
    

    See http://www.nena.org/?NG911_ICE5

    

    

    /Gunnar

    

    

  


--------------090301060308000700050106--

From oej@edvina.net  Thu Nov  1 14:05:48 2012
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 A834E21F970B for ; Thu,  1 Nov 2012 14:05:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SeKA8fDPynI for ; Thu,  1 Nov 2012 14:05:48 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 21C5B21F95E5 for ; Thu,  1 Nov 2012 14:05:47 -0700 (PDT)
Received: from [IPv6:2001:16d8:cc57:1000::42:1005] (unknown [IPv6:2001:16d8:cc57:1000::42:1005]) by smtp7.webway.se (Postfix) with ESMTPA id 1FC9E754A8A7; Thu,  1 Nov 2012 21:05:46 +0000 (UTC)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: "Olle E. Johansson" 
In-Reply-To: <1DFB1BAD-F430-4D56-B167-98A4562FB43F@nostrum.com>
Date: Thu, 1 Nov 2012 22:05:45 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <13B3F973-7BFC-42EA-A970-BA9E60925A7B@edvina.net>   <1DFB1BAD-F430-4D56-B167-98A4562FB43F@nostrum.com>
To: Ben Campbell 
X-Mailer: Apple Mail (2.1499)
Cc: Bernard Aboba , "DRAGE, Keith \(Keith\)" , "simple@ietf.org" 
Subject: Re: [Simple] =?windows-1252?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=85_?= =?windows-1252?q?=28new_subject=29?=
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 Nov 2012 21:05:48 -0000

1 nov 2012 kl. 20:52 skrev Ben Campbell :

>=20
> On Nov 1, 2012, at 2:20 PM, "Olle E. Johansson"  =
wrote:
>=20
>> What is the current relationship betwen OMA and the IETF? ANy =
cooperation, like between 3Gpp and the IETF?
>>=20
>=20
>=20
> There is a liaison, but I don't think it's been very active for a =
while now.

Follow-up question:
When it was active, did any contributions from OMA make it into RFCs?

/O=

From oej@edvina.net  Thu Nov  1 14:13:10 2012
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 E961A21F8DBA for ; Thu,  1 Nov 2012 14:13:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.318
X-Spam-Level: 
X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcRkJ5mStm3A for ; Thu,  1 Nov 2012 14:13:09 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id D8FDB21F8D5C for ; Thu,  1 Nov 2012 14:13:06 -0700 (PDT)
Received: from [192.168.40.19] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id CD6DD754A8A7; Thu,  1 Nov 2012 21:13:05 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: "Olle E. Johansson" 
In-Reply-To: 
Date: Thu, 1 Nov 2012 22:13:05 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.1499)
Cc: Bernard Aboba , "DRAGE, Keith \(Keith\)" , "	simple@ietf.org" 
Subject: Re: [Simple] =?windows-1252?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=85_?= =?windows-1252?q?=28new_subject=29?=
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 Nov 2012 21:13:10 -0000

1 nov 2012 kl. 21:08 skrev Hannes Tschofenig =
:

> Murray was the liaison person to the OMA from the IETF side. Murray =
recently discontinued his participation in the OMA (due to a job =
change). We discussed the need to appoint a new liaison person in the =
IAB and came to the conclusion that no new appointment is necessary; the =
required need to interact with the OMA had decreased over time.=20
>=20
> Does anyone on this list believe that there is a need for cooperation =
with the OMA?

For me, it is too early to answer. I'm just trying to assemble =
information about how we ended up where we are with all these =
organizations working with SIMPLE, not contributing back and leaving the =
IETF with huge gaps and a set of specs that seems uncomplete and not =
focused on developers being able to produce running interoperable code.=20=


I have no insights in the politics at that time, so I have no insight =
into why OMA produced all these documents without trying to feed them =
back to the IETF.

My opinion on OMA cooperation is that if we can kick off work in this =
group to complete and/or correct IETF simple into an interoperable state =
for buddy lists and Xcap, and we see a need for using OMA documents =
within the IETF we can revisit your question and produce an answer.=20

Any other opinions?

/O=

From ibc@aliax.net  Thu Nov  1 14:15:02 2012
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 9862F21F96C2 for ; Thu,  1 Nov 2012 14:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level: 
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtJugOf-ujLD for ; Thu,  1 Nov 2012 14:15:02 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5690A21F8E65 for ; Thu,  1 Nov 2012 14:15:01 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id k13so2377593lbo.31 for ; Thu, 01 Nov 2012 14:15:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=pvr/SuDK/fmE0/nss17bcydbVVOttcOxO6ioDY+dIEw=; b=JGKYKgLxwh7ruk//ey7dagp+6mkF6DfC2OpjRPiTnQ7+hF7VAW1ifbqK86x8A/3QEs RjRMefbUY3xv/vAlnzbq5w/eSKfo5y2g2bViEhaLejG8a1EYfGy4qzCnKpjEw4fSFLH9 yNBodPO23QkyiihYST3ksIzuwYTzom4EkvSDqy6M3svCqDYhMt0BsZB0IRFGswgt1mtk kBZDMjuyzeb5GF4rmotBoja3weXCjUhaigkCTOqtziml71SQ+6JqvL77LDdT+3ssfSYL 3c3eRoq7J9UzXiS7ohfYWyJdtuUxWf+tPRtZmuJqpFe8u0kGgGINVk0dnRf3afPdYGpX SFrw==
Received: by 10.152.109.145 with SMTP id hs17mr38553782lab.5.1351804500132; Thu, 01 Nov 2012 14:15:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.114.2.71 with HTTP; Thu, 1 Nov 2012 14:14:39 -0700 (PDT)
In-Reply-To: 
References:   <13B3F973-7BFC-42EA-A970-BA9E60925A7B@edvina.net>   <1DFB1BAD-F430-4D56-B167-98A4562FB43F@nostrum.com> 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 1 Nov 2012 22:14:39 +0100
Message-ID: 
To: "Olle E. Johansson" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnhB+56flMu/2y19NQ4mD756RrWQ9S7UA/pYC4VJ7epahJfZOYYBm28slxEzn6ZrHXgrHGh
Cc: Bernard Aboba , "DRAGE, Keith \(Keith\)" , "simple@ietf.org" 
Subject: Re: [Simple] =?utf-8?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=E2=80=A6_?= =?utf-8?q?=28new_subject=29?=
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 Nov 2012 21:15:02 -0000

2012/11/1 Olle E. Johansson :
> Follow-up question:
> When it was active, did any contributions from OMA make it into RFCs?

No. OMA publishes its own specification documents.

--
I=C3=B1aki Baz Castillo


From oej@edvina.net  Thu Nov  1 14:22:34 2012
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 D2CE621F8ADE for ; Thu,  1 Nov 2012 14:22:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.315
X-Spam-Level: 
X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EFmGDRjh7d0 for ; Thu,  1 Nov 2012 14:22:34 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 55F2A21F89D7 for ; Thu,  1 Nov 2012 14:22:34 -0700 (PDT)
Received: from [192.168.40.19] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id EC13E754A8A7; Thu,  1 Nov 2012 21:22:32 +0000 (UTC)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: "Olle E. Johansson" 
In-Reply-To: 
Date: Thu, 1 Nov 2012 22:22:31 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D550DB6-1C16-418B-BD5B-829A5FFFC401@edvina.net>
References:   <13B3F973-7BFC-42EA-A970-BA9E60925A7B@edvina.net>   <1DFB1BAD-F430-4D56-B167-98A4562FB43F@nostrum.com>  
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
X-Mailer: Apple Mail (2.1499)
Cc: Bernard Aboba , "DRAGE, Keith \(Keith\)" , "simple@ietf.org" 
Subject: Re: [Simple] =?windows-1252?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=85_?= =?windows-1252?q?=28new_subject=29?=
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 Nov 2012 21:22:34 -0000

1 nov 2012 kl. 22:14 skrev I=F1aki Baz Castillo :

> 2012/11/1 Olle E. Johansson :
>> Follow-up question:
>> When it was active, did any contributions from OMA make it into RFCs?
>=20
> No. OMA publishes its own specification documents.

Right, but they could have cooperated and been contributing anyway to =
the IETF docs...

SIP forum has a some documents too, but have been built them on RFCs and =
where RFCs where missing, initiated work to create them - like GIN.

/O=

From ben@nostrum.com  Thu Nov  1 14:46:21 2012
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 CEA1821F94C9 for ; Thu,  1 Nov 2012 14:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.4
X-Spam-Level: 
X-Spam-Status: No, score=-102.4 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGFFlkcgT4fD for ; Thu,  1 Nov 2012 14:46:21 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0D02D21F94BB for ; Thu,  1 Nov 2012 14:46:20 -0700 (PDT)
Received: from [10.0.1.6] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qA1Lk1ev028595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Nov 2012 16:46:02 -0500 (CDT) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ben Campbell 
In-Reply-To: <7D550DB6-1C16-418B-BD5B-829A5FFFC401@edvina.net>
Date: Thu, 1 Nov 2012 16:46:00 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <6373E76B-5C9A-42EA-966E-F184D49FC793@nostrum.com>
References:   <13B3F973-7BFC-42EA-A970-BA9E60925A7B@edvina.net>   <1DFB1BAD-F430-4D56-B167-98A4562FB43F@nostrum.com>   <7D550DB6-1C16-418B-BD5B-829A5FFFC401@edvina.net>
To: "Olle E. Johansson" 
X-Mailer: Apple Mail (2.1499)
Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: Bernard Aboba , "DRAGE, Keith \(Keith\)" , "simple@ietf.org" 
Subject: Re: [Simple] =?windows-1252?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=85_?= =?windows-1252?q?=28new_subject=29?=
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 Nov 2012 21:46:22 -0000

On Nov 1, 2012, at 4:22 PM, "Olle E. Johansson"  wrote:

>=20
> 1 nov 2012 kl. 22:14 skrev I=F1aki Baz Castillo :
>=20
>> 2012/11/1 Olle E. Johansson :
>>> Follow-up question:
>>> When it was active, did any contributions from OMA make it into =
RFCs?
>>=20
>> No. OMA publishes its own specification documents.
>=20
> Right, but they could have cooperated and been contributing anyway to =
the IETF docs...
>=20
> SIP forum has a some documents too, but have been built them on RFCs =
and where RFCs where missing, initiated work to create them - like GIN.

Does anyone know if SIP Forum had any discussions on any of the SIMPLE =
interop topics?=20

>=20
> /O


From ben@nostrum.com  Thu Nov  1 14:47:26 2012
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 A951021F8FEA for ; Thu,  1 Nov 2012 14:47:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.525
X-Spam-Level: 
X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zo7yGSXYGRJV for ; Thu,  1 Nov 2012 14:47:25 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A3EBE21F94BB for ; Thu,  1 Nov 2012 14:47:25 -0700 (PDT)
Received: from [10.0.1.6] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qA1LlOIr028684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 1 Nov 2012 16:47:25 -0500 (CDT) (envelope-from ben@nostrum.com)
From: Ben Campbell 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <5D1564A2-1F40-4017-B16D-5A6A70D92969@nostrum.com>
Date: Thu, 1 Nov 2012 16:47:24 -0500
To: Simple WG 
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Subject: [Simple] SIMPLE Interop Threads
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 Nov 2012 21:47:26 -0000

(as SIMPLE chair)

Hi Everyone,

We've recently had several very interesting thread about the =
interoperability issues in SIMPLE and what could be done to improve =
them. I'd like to see those discussions make progress. But please keep =
in mind that the work group is very close to completion on all it's =
milestones. (For the purpose of this thread, lets please ignore the =
question about whether that means "successful" completion). SIMPLE will =
almost certainly close in the near future.

That doesn't mean new work can't happen. It does mean that any such work =
will need to go through the normal RAI processes for substantially new =
work. Normally that means taking a proposal to DISPATCH. Success in =
DISPATCH will require the interested parties to (roughly) agree on the =
nature of the problem to be solved, and the scope of the work needed to =
do so. A problem statement in the form of an Internet-Draft  would be =
extremely helpful.

I suggest that the interested parties take the following concrete =
actions:

1) Work toward a rough consensus of the problem to be solved, and a =
rough idea of the scope of the work. What are the gaps in the standards =
that make interop hard? Where's the low hanging fruit? Please feel free =
to continue discussion on the SIMPLE list, with that goal in mind. (This =
also sounds like an interesting effort for the SIP Forum [nudge]  )

2) Bring a proposal to the DISPATCH list in time for the IETF-86 agenda =
deadlines. Continue discussion about the scope of work there.

3) Figure out next steps in DISPATCH, based on the scope, interest, and =
energy demonstrated there.

Again, I don't mean to stop the current discussion--please continue it, =
and feel free to use the SIMPLE list to help everyone get thoughts =
together to  make a concrete proposal to DISPATCH.

Thanks!

Ben.=

From bernard_aboba@hotmail.com  Thu Nov  1 14:54:01 2012
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 D95B321F9627 for ; Thu,  1 Nov 2012 14:54:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.335
X-Spam-Level: 
X-Spam-Status: No, score=-102.335 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29SfSsRreX6G for ; Thu,  1 Nov 2012 14:54:01 -0700 (PDT)
Received: from blu0-omc4-s3.blu0.hotmail.com (blu0-omc4-s3.blu0.hotmail.com [65.55.111.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5C81321F9622 for ; Thu,  1 Nov 2012 14:54:01 -0700 (PDT)
Received: from BLU402-EAS282 ([65.55.111.136]) by blu0-omc4-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 1 Nov 2012 14:54:00 -0700
X-Originating-IP: [131.107.0.76]
X-EIP: [6ZVdE769Ipdw1R1ap0QJVJytlrkfJ7M8]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
MIME-Version: 1.0
From: Bernard Aboba 
To: =?utf-8?Q?Ben_Campbell?= 
Importance: Normal
Date: Thu, 1 Nov 2012 21:53:57 +0000
Content-Type: multipart/alternative; boundary="_9F4D7C23-02C5-4EFF-8BD1-50E4383512AA_"
X-OriginalArrivalTime: 01 Nov 2012 21:54:00.0996 (UTC) FILETIME=[66DE8640:01CDB87B]
Cc: "=?utf-8?Q?simple@ietf.org?=" 
Subject: Re: [Simple] =?utf-8?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=E2=80=A6_?= =?utf-8?q?=28new_subject=29?=
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 Nov 2012 21:54:02 -0000

--_9F4D7C23-02C5-4EFF-8BD1-50E4383512AA_
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"

QmVuIGFza2VkOg0KDQogDQoNCiANCg0KIA0KDQogDQoNCiANCg0KIA0KDQrigJxEb2VzIGFueW9u
ZSBrbm93IGlmIFNJUCBGb3J1bSBoYWQgYW55IGRpc2N1c3Npb25zIG9uIGFueSBvZiB0aGUgU0lN
UExFIGludGVyb3AgdG9waWNzPyDigJwNCg0KW0JBXSBTSU1QTEUgd2FzIG91dCBvZiBzY29wZSBm
b3IgdGhlIFNJUGNvbm5lY3QgMS4xIFNJUCB0cnVua2luZyBwcm9maWxlLiAgSXQgbWlnaHQgYmUg
c29tZXRoaW5nIHRoYXQgY291bGQgYmUgY29uc2lkZXJlZCBTSVBjb25uZWN0IDIuMCwgYnV0IHdp
dGhvdXQgZXZpZGVuY2Ugb2YgdGFrZXVwIGluIFNJUCBzZXJ2aWNlIHByb3ZpZGVycyB0aGF0IG1p
Z2h0IGJlIGRpZmZpY3VsdC4=

--_9F4D7C23-02C5-4EFF-8BD1-50E4383512AA_
Content-Transfer-Encoding: base64
Content-Type: text/html; charset="utf-8"

PGh0bWw+PGhlYWQ+PHN0eWxlIGRhdGEtZXh0ZXJuYWxzdHlsZT0idHJ1ZSI+CnAuTXNvTGlzdFBh
cmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGggewptYXJn
aW4tdG9wOjBpbjsKbWFyZ2luLXJpZ2h0OjBpbjsKbWFyZ2luLWJvdHRvbTowaW47Cm1hcmdpbi1s
ZWZ0Oi41aW47Cm1hcmdpbi1ib3R0b206LjAwMDFwdDsKfQoKcC5Nc29MaXN0UGFyYWdyYXBoQ3hT
cEZpcnN0LCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCBkaXYuTXNvTGlzdFBhcmFncmFw
aEN4U3BGaXJzdCwgcC5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgbGkuTXNvTGlzdFBhcmFn
cmFwaEN4U3BNaWRkbGUsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgcC5Nc29MaXN0
UGFyYWdyYXBoQ3hTcExhc3QsIGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCwgZGl2Lk1zb0xp
c3RQYXJhZ3JhcGhDeFNwTGFzdCB7Cm1hcmdpbi10b3A6MGluOwptYXJnaW4tcmlnaHQ6MGluOwpt
YXJnaW4tYm90dG9tOjBpbjsKbWFyZ2luLWxlZnQ6LjVpbjsKbWFyZ2luLWJvdHRvbTouMDAwMXB0
OwpsaW5lLWhlaWdodDoxMTUlOwp9Cjwvc3R5bGU+PHN0eWxlPjwhLS0KLkVtYWlsUXVvdGUgewpw
YWRkaW5nLWxlZnQ6NHB0OwptYXJnaW4tbGVmdDoxcHQ7CmJvcmRlci1sZWZ0LWNvbG9yOnJnYigx
MjgsIDAsIDApOwpib3JkZXItbGVmdC13aWR0aDoycHg7CmJvcmRlci1sZWZ0LXN0eWxlOnNvbGlk
Owp9Ci0tPjwvc3R5bGU+PC9oZWFkPjxib2R5PjxkaXYgZGF0YS1leHRlcm5hbHN0eWxlPSJmYWxz
ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksJ1NlZ29lIFVJJyxNZWlyeW8sJ01pY3Jvc29m
dCBZYUhlaSBVSScsJ01pY3Jvc29mdCBKaGVuZ0hlaSBVSScsJ01hbGd1biBHb3RoaWMnLCdLaG1l
ciBVSScsJ05pcm1hbGEgVUknLFR1bmdhLCdMYW8gVUknLEVicmltYSxzYW5zLXNlcmlmO2ZvbnQt
c2l6ZToxNnB4OyI+PGRpdj5CZW4gYXNrZWQ6PC9kaXY+PGZvbnQgc2l6ZT0iMiI+PGRpdj4mbmJz
cDs8L2Rpdj48ZGl2IGRhdGEtc2lnbmF0dXJlYmxvY2s9InRydWUiPiZuYnNwOzwvZGl2PjxzcGFu
IHN0eWxlPSJmb250LXNpemU6IDEwcHQ7Ij48ZGl2PiZuYnNwOzwvZGl2PjxkaXYgZGF0YS1zaWdu
YXR1cmVibG9jaz0idHJ1ZSI+Jm5ic3A7PC9kaXY+PGRpdiBkYXRhLXNpZ25hdHVyZWJsb2NrPSJ0
cnVlIj4mbmJzcDs8L2Rpdj48ZGl2PiZuYnNwOzwvZGl2PjxkaXYgZGF0YS1mb2N1c2Zyb21wb2lu
dGVyPSJ0cnVlIj7igJxEb2VzIGFueW9uZSBrbm93IGlmIFNJUCBGb3J1bSBoYWQgYW55IGRpc2N1
c3Npb25zIG9uIGFueSBvZiB0aGUgU0lNUExFIGludGVyb3AgdG9waWNzPyZuYnNwO+KAnDxicj4K
PGJyPgpbQkFdJm5ic3A7U0lNUExFIHdhcyBvdXQgb2Ygc2NvcGUgZm9yIHRoZSBTSVBjb25uZWN0
IDEuMSBTSVAgdHJ1bmtpbmcgcHJvZmlsZS4mbmJzcDsgSXQgbWlnaHQgYmUgc29tZXRoaW5nIHRo
YXQgY291bGQgYmUgY29uc2lkZXJlZCBTSVBjb25uZWN0IDIuMCwgYnV0IHdpdGhvdXQgZXZpZGVu
Y2Ugb2YgdGFrZXVwIGluIFNJUCBzZXJ2aWNlIHByb3ZpZGVycyB0aGF0IG1pZ2h0IGJlIGRpZmZp
Y3VsdC4gPGJyPgo8YnI+CjwvZGl2Pjwvc3Bhbj48L2ZvbnQ+CgoKPC9kaXY+PC9ib2R5PjwvaHRt
bD4=

--_9F4D7C23-02C5-4EFF-8BD1-50E4383512AA_--

From keith.drage@alcatel-lucent.com  Thu Nov  1 16:00:57 2012
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 270BE21F9620 for ; Thu,  1 Nov 2012 16:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.249
X-Spam-Level: 
X-Spam-Status: No, score=-108.249 tagged_above=-999 required=5 tests=[AWL=-1.999, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67aak60cE1QM for ; Thu,  1 Nov 2012 16:00:56 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 210CD21F95F5 for ; Thu,  1 Nov 2012 16:00:55 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA1N03nb022739 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Nov 2012 00:00:22 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 2 Nov 2012 00:00:21 +0100
From: "DRAGE, Keith (Keith)" 
To: Hannes Tschofenig , Ben Campbell 
Date: Fri, 2 Nov 2012 00:00:20 +0100
Thread-Topic: [Simple] SIMPLE and OMA and 3Gpp and RCS and... (new subject)
Thread-Index: Ac24bNChgK4YiBkyT+qj8JGiZCAiiAAFxTBQ
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Cc: Bernard Aboba , "	simple@ietf.org" 
Subject: Re: [Simple] SIMPLE and OMA and 3Gpp and RCS and... (new subject)
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 Nov 2012 23:00:57 -0000

So I guess that IETF has therefore abandoned RFC 5727.

OMA last asked for 6 header fields to be registered. As far as I understand=
 they were told they needed a standards track RFC to do this. Identifying n=
o need for cooperation tells me that IETF is quite happy they have their ow=
n version of the SIP specification.

Keith

> -----Original Message-----
> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
> Sent: 01 November 2012 20:09
> To: Ben Campbell
> Cc: Olle E. Johansson; Bernard Aboba; DRAGE, Keith (Keith);
> simple@ietf.org
> Subject: Re: [Simple] SIMPLE and OMA and 3Gpp and RCS and... (new subject=
)
>=20
> Murray was the liaison person to the OMA from the IETF side. Murray
> recently discontinued his participation in the OMA (due to a job change).
> We discussed the need to appoint a new liaison person in the IAB and came
> to the conclusion that no new appointment is necessary; the required need
> to interact with the OMA had decreased over time.
>=20
> Does anyone on this list believe that there is a need for cooperation wit=
h
> the OMA?
>=20
> Ciao
> Hannes
>=20
> Sent from my ASUS Pad
>=20
> Ben Campbell  wrote:
>=20
> >
> >On Nov 1, 2012, at 2:20 PM, "Olle E. Johansson"  wrote:
> >
> >> What is the current relationship betwen OMA and the IETF? ANy
> cooperation, like between 3Gpp and the IETF?
> >>
> >
> >
> >There is a liaison, but I don't think it's been very active for a while
> now.
> >_______________________________________________
> >Simple mailing list
> >Simple@ietf.org
> >https://www.ietf.org/mailman/listinfo/simple

From ben@nostrum.com  Thu Nov  1 16:10:08 2012
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 28C6221F96CE for ; Thu,  1 Nov 2012 16:10:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.54
X-Spam-Level: 
X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Dr5FA4o-xwZ for ; Thu,  1 Nov 2012 16:10:07 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3F01D21F96BF for ; Thu,  1 Nov 2012 16:10:07 -0700 (PDT)
Received: from [10.0.1.6] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qA1N9xQQ036402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Nov 2012 18:09:59 -0500 (CDT) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ben Campbell 
In-Reply-To: 
Date: Thu, 1 Nov 2012 18:09:59 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <8901840E-9C96-4555-813B-5900B2532796@nostrum.com>
References:  
To: "DRAGE, Keith (Keith)" 
X-Mailer: Apple Mail (2.1499)
Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: Bernard Aboba , "	simple@ietf.org" 
Subject: Re: [Simple] SIMPLE and OMA and 3Gpp and RCS and... (new subject)
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 Nov 2012 23:10:08 -0000

On Nov 1, 2012, at 6:00 PM, "DRAGE, Keith (Keith)" =
 wrote:

> So I guess that IETF has therefore abandoned RFC 5727.

I'm trying to figure out how "abandoning 5727" follows from "no liaison =
manager for OMA". I'm not getting it; can you elaborate?

>=20
> OMA last asked for 6 header fields to be registered. As far as I =
understand they were told they needed a standards track RFC to do this. =
Identifying no need for cooperation tells me that IETF is quite happy =
they have their own version of the SIP specification.
>=20

I don't think choosing not to assign a liaison manager implies we expect =
no cooperation. You don't need an IETF assigned liaison manager to =
someone bring a draft to the IETF, do you?

> Keith
>=20
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
>> Sent: 01 November 2012 20:09
>> To: Ben Campbell
>> Cc: Olle E. Johansson; Bernard Aboba; DRAGE, Keith (Keith);
>> simple@ietf.org
>> Subject: Re: [Simple] SIMPLE and OMA and 3Gpp and RCS and... (new =
subject)
>>=20
>> Murray was the liaison person to the OMA from the IETF side. Murray
>> recently discontinued his participation in the OMA (due to a job =
change).
>> We discussed the need to appoint a new liaison person in the IAB and =
came
>> to the conclusion that no new appointment is necessary; the required =
need
>> to interact with the OMA had decreased over time.
>>=20
>> Does anyone on this list believe that there is a need for cooperation =
with
>> the OMA?
>>=20
>> Ciao
>> Hannes
>>=20
>> Sent from my ASUS Pad
>>=20
>> Ben Campbell  wrote:
>>=20
>>>=20
>>> On Nov 1, 2012, at 2:20 PM, "Olle E. Johansson"  =
wrote:
>>>=20
>>>> What is the current relationship betwen OMA and the IETF? ANy
>> cooperation, like between 3Gpp and the IETF?
>>>>=20
>>>=20
>>>=20
>>> There is a liaison, but I don't think it's been very active for a =
while
>> now.
>>> _______________________________________________
>>> Simple mailing list
>>> Simple@ietf.org
>>> https://www.ietf.org/mailman/listinfo/simple


From ben@nostrum.com  Thu Nov  1 16:12:30 2012
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 551C221F97FA for ; Thu,  1 Nov 2012 16:12:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.55
X-Spam-Level: 
X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzRueLbmPs0z for ; Thu,  1 Nov 2012 16:12:29 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A798821F96F7 for ; Thu,  1 Nov 2012 16:12:29 -0700 (PDT)
Received: from [10.0.1.6] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qA1NCGu8036701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Nov 2012 18:12:16 -0500 (CDT) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ben Campbell 
In-Reply-To: <8901840E-9C96-4555-813B-5900B2532796@nostrum.com>
Date: Thu, 1 Nov 2012 18:12:16 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <2C5ED210-3C72-4D6A-84A2-50A8229D4C91@nostrum.com>
References:   <8901840E-9C96-4555-813B-5900B2532796@nostrum.com>
To: "DRAGE, Keith (Keith)" 
X-Mailer: Apple Mail (2.1499)
Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: Bernard Aboba , "	simple@ietf.org" 
Subject: Re: [Simple] SIMPLE and OMA and 3Gpp and RCS and... (new subject)
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 Nov 2012 23:12:30 -0000

On Nov 1, 2012, at 6:09 PM, Ben Campbell  wrote:

>=20
> On Nov 1, 2012, at 6:00 PM, "DRAGE, Keith (Keith)" =
 wrote:
>=20
>> So I guess that IETF has therefore abandoned RFC 5727.
>=20
> I'm trying to figure out how "abandoning 5727" follows from "no =
liaison manager for OMA". I'm not getting it; can you elaborate?
>=20
>>=20
>> OMA last asked for 6 header fields to be registered. As far as I =
understand they were told they needed a standards track RFC to do this. =
Identifying no need for cooperation tells me that IETF is quite happy =
they have their own version of the SIP specification.
>>=20
>=20
> I don't think choosing not to assign a liaison manager implies we =
expect no cooperation. You don't need an IETF assigned liaison manager =
to someone bring a draft to the IETF, do you?

Okay, that was a cut-paste disaster. s/ "to someone bring" / "for =
someone to bring"

>=20
>> Keith
>>=20
>>> -----Original Message-----
>>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
>>> Sent: 01 November 2012 20:09
>>> To: Ben Campbell
>>> Cc: Olle E. Johansson; Bernard Aboba; DRAGE, Keith (Keith);
>>> simple@ietf.org
>>> Subject: Re: [Simple] SIMPLE and OMA and 3Gpp and RCS and... (new =
subject)
>>>=20
>>> Murray was the liaison person to the OMA from the IETF side. Murray
>>> recently discontinued his participation in the OMA (due to a job =
change).
>>> We discussed the need to appoint a new liaison person in the IAB and =
came
>>> to the conclusion that no new appointment is necessary; the required =
need
>>> to interact with the OMA had decreased over time.
>>>=20
>>> Does anyone on this list believe that there is a need for =
cooperation with
>>> the OMA?
>>>=20
>>> Ciao
>>> Hannes
>>>=20
>>> Sent from my ASUS Pad
>>>=20
>>> Ben Campbell  wrote:
>>>=20
>>>>=20
>>>> On Nov 1, 2012, at 2:20 PM, "Olle E. Johansson"  =
wrote:
>>>>=20
>>>>> What is the current relationship betwen OMA and the IETF? ANy
>>> cooperation, like between 3Gpp and the IETF?
>>>>>=20
>>>>=20
>>>>=20
>>>> There is a liaison, but I don't think it's been very active for a =
while
>>> now.
>>>> _______________________________________________
>>>> Simple mailing list
>>>> Simple@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/simple
>=20


From keith.drage@alcatel-lucent.com  Thu Nov  1 16:23:29 2012
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 D536521F9304 for ; Thu,  1 Nov 2012 16:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.582
X-Spam-Level: 
X-Spam-Status: No, score=-109.582 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHaAkTYt4gz2 for ; Thu,  1 Nov 2012 16:23:28 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9950221F8876 for ; Thu,  1 Nov 2012 16:22:59 -0700 (PDT)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA1NMK2m011312 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Nov 2012 00:22:31 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 2 Nov 2012 00:22:18 +0100
From: "DRAGE, Keith (Keith)" 
To: Ben Campbell 
Date: Fri, 2 Nov 2012 00:22:17 +0100
Thread-Topic: [Simple] SIMPLE and OMA and 3Gpp and RCS and... (new subject)
Thread-Index: Ac24hlmo3zKkUwyHSWG0497G7xlt1AAASVBA
Message-ID: 
References:   <8901840E-9C96-4555-813B-5900B2532796@nostrum.com> <2C5ED210-3C72-4D6A-84A2-50A8229D4C91@nostrum.com>
In-Reply-To: <2C5ED210-3C72-4D6A-84A2-50A8229D4C91@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Cc: Bernard Aboba , " simple@ietf.org" 
Subject: Re: [Simple] SIMPLE and OMA and 3Gpp and RCS and... (new subject)
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 Nov 2012 23:23:30 -0000

I think you got the point. I can't help it if you don't think it is an issu=
e.=20

We'll see if OMA come back or not to test if you are right or wrong.


Keith

> -----Original Message-----
> From: Ben Campbell [mailto:ben@nostrum.com]
> Sent: 01 November 2012 23:12
> To: DRAGE, Keith (Keith)
> Cc: Hannes Tschofenig; Olle E. Johansson; Bernard Aboba; simple@ietf.org
> Subject: Re: [Simple] SIMPLE and OMA and 3Gpp and RCS and... (new subject=
)
>=20
>=20
> On Nov 1, 2012, at 6:09 PM, Ben Campbell  wrote:
>=20
> >
> > On Nov 1, 2012, at 6:00 PM, "DRAGE, Keith (Keith)"  lucent.com> wrote:
> >
> >> So I guess that IETF has therefore abandoned RFC 5727.
> >
> > I'm trying to figure out how "abandoning 5727" follows from "no liaison
> manager for OMA". I'm not getting it; can you elaborate?
> >
> >>
> >> OMA last asked for 6 header fields to be registered. As far as I
> understand they were told they needed a standards track RFC to do this.
> Identifying no need for cooperation tells me that IETF is quite happy the=
y
> have their own version of the SIP specification.
> >>
> >
> > I don't think choosing not to assign a liaison manager implies we expec=
t
> no cooperation. You don't need an IETF assigned liaison manager to someon=
e
> bring a draft to the IETF, do you?
>=20
> Okay, that was a cut-paste disaster. s/ "to someone bring" / "for someone
> to bring"
>=20
> >
> >> Keith
> >>
> >>> -----Original Message-----
> >>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
> >>> Sent: 01 November 2012 20:09
> >>> To: Ben Campbell
> >>> Cc: Olle E. Johansson; Bernard Aboba; DRAGE, Keith (Keith);
> >>> simple@ietf.org
> >>> Subject: Re: [Simple] SIMPLE and OMA and 3Gpp and RCS and... (new
> subject)
> >>>
> >>> Murray was the liaison person to the OMA from the IETF side. Murray
> >>> recently discontinued his participation in the OMA (due to a job
> change).
> >>> We discussed the need to appoint a new liaison person in the IAB and
> came
> >>> to the conclusion that no new appointment is necessary; the required
> need
> >>> to interact with the OMA had decreased over time.
> >>>
> >>> Does anyone on this list believe that there is a need for cooperation
> with
> >>> the OMA?
> >>>
> >>> Ciao
> >>> Hannes
> >>>
> >>> Sent from my ASUS Pad
> >>>
> >>> Ben Campbell  wrote:
> >>>
> >>>>
> >>>> On Nov 1, 2012, at 2:20 PM, "Olle E. Johansson" 
> wrote:
> >>>>
> >>>>> What is the current relationship betwen OMA and the IETF? ANy
> >>> cooperation, like between 3Gpp and the IETF?
> >>>>>
> >>>>
> >>>>
> >>>> There is a liaison, but I don't think it's been very active for a
> while
> >>> now.
> >>>> _______________________________________________
> >>>> Simple mailing list
> >>>> Simple@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/simple
> >


From stpeter@stpeter.im  Thu Nov  1 20:13:34 2012
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 90BD721F9409 for ; Thu,  1 Nov 2012 20:13:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.587
X-Spam-Level: 
X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YioYq0BkzHlk for ; Thu,  1 Nov 2012 20:13:34 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 11D1621F93D5 for ; Thu,  1 Nov 2012 20:13:34 -0700 (PDT)
Received: from [192.168.1.2] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E84624011B for ; Thu,  1 Nov 2012 21:17:02 -0600 (MDT)
Message-ID: <50933A5D.30102@stpeter.im>
Date: Thu, 01 Nov 2012 21:13:33 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: "simple@ietf.org" 
References: <5092FB3E.5020002@stpeter.im>
In-Reply-To: <5092FB3E.5020002@stpeter.im>
X-Enigmail-Version: 1.4.5
X-Forwarded-Message-Id: <5092FB3E.5020002@stpeter.im>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [Simple] Fwd: Re: [precis] spaces at end of nickname
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, 02 Nov 2012 03:13:34 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI. This would supplement the existing rule about whitespace, which is:

   3.  Non-ASCII space characters from the "N" category defined under
       Section 6.14 of [I-D.ietf-precis-framework] MUST be mapped to
       U+0020 SPACE.

Peter

- -------- Original Message --------
Subject: Re: [precis] spaces at end of nickname
Date: Thu, 01 Nov 2012 16:44:14 -0600
From: Peter Saint-Andre 
To: precis@ietf.org

On 11/1/12 9:28 AM, Salvatore Loreto wrote:
> On 11/1/12 4:27 PM, Joe Hildebrand (jhildebr) wrote:
>> On 11/1/12 9:22 AM, "Alexey Melnikov"
>>  wrote:
>> 
>>> +1 (both leading and trailing whitespaces are already 
>>> disallowed in usernames).
>> +1
>> 
> +1

OK, I propose adding the following rules to Section 2:

   4.  Leading and trailing whitespace (i.e., one or more instances of
       the ASCII space character at the beginning or end of a nickname)
       MUST be removed.

   5.  Interior sequences of more than one ASCII space character MUST be
       mapped to a single ASCII space character.

Peter

_______________________________________________
precis mailing list
precis@ietf.org
https://www.ietf.org/mailman/listinfo/precis


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCTOl0ACgkQNL8k5A2w/vy/4gCfRbjh8wM5Db4Md5+U1H4wPVm6
qbsAoPKWSAdIE/hguVCeEiY04RaFbsPo
=Tl7J
-----END PGP SIGNATURE-----

From oej@edvina.net  Fri Nov  2 00:09:57 2012
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 9988021F960E for ; Fri,  2 Nov 2012 00:09:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.463
X-Spam-Level: 
X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmsXSyZBd8ph for ; Fri,  2 Nov 2012 00:09:57 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id DB5ED21F934E for ; Fri,  2 Nov 2012 00:09:49 -0700 (PDT)
Received: from [192.168.40.19] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 8F1ED754A8A7; Fri,  2 Nov 2012 07:09:47 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: "Olle E. Johansson" 
In-Reply-To: <5D1564A2-1F40-4017-B16D-5A6A70D92969@nostrum.com>
Date: Fri, 2 Nov 2012 08:09:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <88B3606C-74D4-4DA5-B1D1-D3385D725597@edvina.net>
References: <5D1564A2-1F40-4017-B16D-5A6A70D92969@nostrum.com>
To: Ben Campbell 
X-Mailer: Apple Mail (2.1499)
Cc: Simple WG 
Subject: Re: [Simple] SIMPLE Interop Threads
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, 02 Nov 2012 07:09:57 -0000

1 nov 2012 kl. 22:47 skrev Ben Campbell :

> (as SIMPLE chair)
>=20
> Hi Everyone,
>=20
> We've recently had several very interesting thread about the =
interoperability issues in SIMPLE and what could be done to improve =
them. I'd like to see those discussions make progress. But please keep =
in mind that the work group is very close to completion on all it's =
milestones. (For the purpose of this thread, lets please ignore the =
question about whether that means "successful" completion). SIMPLE will =
almost certainly close in the near future.
>=20
> That doesn't mean new work can't happen. It does mean that any such =
work will need to go through the normal RAI processes for substantially =
new work. Normally that means taking a proposal to DISPATCH. Success in =
DISPATCH will require the interested parties to (roughly) agree on the =
nature of the problem to be solved, and the scope of the work needed to =
do so. A problem statement in the form of an Internet-Draft  would be =
extremely helpful.
>=20
> I suggest that the interested parties take the following concrete =
actions:
>=20
> 1) Work toward a rough consensus of the problem to be solved, and a =
rough idea of the scope of the work. What are the gaps in the standards =
that make interop hard? Where's the low hanging fruit? Please feel free =
to continue discussion on the SIMPLE list, with that goal in mind. (This =
also sounds like an interesting effort for the SIP Forum [nudge]  )
>=20
> 2) Bring a proposal to the DISPATCH list in time for the IETF-86 =
agenda deadlines. Continue discussion about the scope of work there.
>=20
> 3) Figure out next steps in DISPATCH, based on the scope, interest, =
and energy demonstrated there.
>=20
> Again, I don't mean to stop the current discussion--please continue =
it, and feel free to use the SIMPLE list to help everyone get thoughts =
together to  make a concrete proposal to DISPATCH.

Ben!
Thanks for your support of this issue and a very clear structure for us =
to follow.

There are members of the SIP Forum board on this list.=20

I hope that they got the message that this is an issue that currently =
stops implementation and sales of SIP products that implement SIMPLE in =
favour of single-vendor solutions or alternatives like XMPP. For some =
members that's not a problem, but for general market growth I see it as =
a huge problem that should be a concern for the forum.

/O=

From saul@ag-projects.com  Fri Nov  2 01:49:07 2012
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 B7D5521F9677 for ; Fri,  2 Nov 2012 01:49:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[AWL=0.310,  BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPJiaNTfqW4g for ; Fri,  2 Nov 2012 01:49:07 -0700 (PDT)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id A9FE821F965E for ; Fri,  2 Nov 2012 01:49:06 -0700 (PDT)
Received: by mail.sipthor.net (Postfix, from userid 5001) id 3BF00B019B; Fri,  2 Nov 2012 09:49:04 +0100 (CET)
Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 5D2C9B0061; Fri,  2 Nov 2012 09:49:04 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= 
In-Reply-To: 
Date: Fri, 2 Nov 2012 09:49:03 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2C9DA935-CBBD-4DCF-A2A4-FF0139FB62B2@ag-projects.com>
References:  
To: Olle E. Johansson 
X-Mailer: Apple Mail (2.1085)
Cc: Bernard Aboba , "DRAGE, Keith \(Keith\)" , "	simple@ietf.org" 
Subject: Re: [Simple] =?windows-1252?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=85_?= =?windows-1252?q?=28new_subject=29?=
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, 02 Nov 2012 08:49:07 -0000

Hi Olle,

On Nov 1, 2012, at 10:13 PM, Olle E. Johansson wrote:

>=20
> 1 nov 2012 kl. 21:08 skrev Hannes Tschofenig =
:
>=20
>> Murray was the liaison person to the OMA from the IETF side. Murray =
recently discontinued his participation in the OMA (due to a job =
change). We discussed the need to appoint a new liaison person in the =
IAB and came to the conclusion that no new appointment is necessary; the =
required need to interact with the OMA had decreased over time.=20
>>=20
>> Does anyone on this list believe that there is a need for cooperation =
with the OMA?
>=20
> For me, it is too early to answer. I'm just trying to assemble =
information about how we ended up where we are with all these =
organizations working with SIMPLE, not contributing back and leaving the =
IETF with huge gaps and a set of specs that seems uncomplete and not =
focused on developers being able to produce running interoperable code.=20=

>=20
> I have no insights in the politics at that time, so I have no insight =
into why OMA produced all these documents without trying to feed them =
back to the IETF.
>=20
> My opinion on OMA cooperation is that if we can kick off work in this =
group to complete and/or correct IETF simple into an interoperable state =
for buddy lists and Xcap, and we see a need for using OMA documents =
within the IETF we can revisit your question and produce an answer.=20
>=20

OMA has its own set of documents, and some of the stuff they specified =
is interesting and useful, for example the support for external =
references in pres-rules. If we have external references in pres-rules =
we can create a template and then any operation is performed just in the =
resource-lists document, which then avoids any atomicity related =
problem. There are downsides, however:

  - They define their own AUID 'org.openmobilealliance.pres-rules', so =
managing policy for the same AoR must be done with the same kind of =
devices: either all pure-IETF or pure-OMA, but if you mix them, which =
document should the server look at? Right now all Open Source SIP server =
that I know of treat both documents the same, which is wrong, different =
AUIDs shouldn't override each other. FWIW, I'm in the process of fixing =
this in OpenSIPS.

  - Having a oma pres-rules document which just points to a =
resource-lists document means that we can no longer get the policy for a =
watcher by just looking at pre-rules. This makes me think that we need a =
single document to store a buddy-list, which also contains the  policy =
for each buddy.=20


Regards,

--
Sa=FAl Ibarra Corretg=E9
AG Projects




From ibc@aliax.net  Fri Nov  2 03:47:18 2012
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 8F0F321F9936 for ; Fri,  2 Nov 2012 03:47:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.531
X-Spam-Level: 
X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yi6X-xq5eLgl for ; Fri,  2 Nov 2012 03:47:18 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id BDD5E21F9935 for ; Fri,  2 Nov 2012 03:47:17 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id b11so2720613lam.31 for ; Fri, 02 Nov 2012 03:47:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=+aYNUggoVuUJ8o28zo/0hgLDMccZiFFfA7L3vtuGEBA=; b=oO2g3aetYlXXX2fVq7SVIG+kbBoLoMi+GUpkwaNADE03oaFy9iyPAdL0B1BJaT9QWX fYsy0bFhnNckEUjWAPRrB2Em4+k69atEEaSmWcsE2o6suNU/ZKhVWdSrnuHEIMNWFa3z pMBHnl5irhESG2IE/eiKmRuSJkpb876TtpA2uXgyvKnewjIduT2wQg9YciKhlxN72VHg rB4+SWyntfsswNrzGkSPtpEndgFyq4B6YMGVbMNja21XuMWm0QCoujAuKpg/2JxxIxwR baWyr193e/hkHOTCUklPXS4cxggPUC1UJmT2PpXkroMsg0LkOddRBc4AlsGE4Jwbvtt7 tErw==
Received: by 10.112.25.42 with SMTP id z10mr572385lbf.103.1351853236257; Fri, 02 Nov 2012 03:47:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.114.2.71 with HTTP; Fri, 2 Nov 2012 03:46:56 -0700 (PDT)
In-Reply-To: <2C9DA935-CBBD-4DCF-A2A4-FF0139FB62B2@ag-projects.com>
References:   <2C9DA935-CBBD-4DCF-A2A4-FF0139FB62B2@ag-projects.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Fri, 2 Nov 2012 11:46:56 +0100
Message-ID: 
To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnF21FTfA7RFXoSGBkJBRlZBwxTRlR2+2PAhG5CqQ8ku0dpyxIZDUNedhMz6GKULS1Q+XDD
Cc: Bernard Aboba , "DRAGE, Keith \(Keith\)" , "simple@ietf.org" 
Subject: Re: [Simple] =?utf-8?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=E2=80=A6_?= =?utf-8?q?=28new_subject=29?=
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, 02 Nov 2012 10:47:18 -0000

2012/11/2 Sa=C3=BAl Ibarra Corretg=C3=A9 :
> - Having a oma pres-rules document which just points to a resource-lists =
document means that we can no longer get the policy for a watcher by just l=
ooking at pre-rules. This makes me think that we need a single document to =
store a buddy-list, which also contains the  policy for each buddy.

SO what I say and repeat 1000 times: authorization MUST be an
*attribute* of each buddy. Period. Drop "users lists" named
"allowed-buddies" / "blocked-buddies", that's not the way to go.

buddylist:
--------------------
sip:alice@example.com {
  presence-subscribe-to: true,
  presence-allowed: true,
  presence-blocked: false
}

sip:bob@example.com {
  presence-subscribed-to: true,
  presence-allowed: true,
  presence-blocked: true
}
--------------------

And that's all. This is easy to render for the watcher and easy to
process for the server. Single "document" with buddies and their
attributes.

No need for "external references to other XCAP documents in any other
server in the world", no need for generating a coredump if the same
buddy is contained in "oma_my_buddies" list and "my_blocked_contacts"
list and "oma_PoC_contacts" list and "oma_featured_buddies" list.



--
I=C3=B1aki Baz Castillo


From saul@ag-projects.com  Fri Nov  2 05:00:44 2012
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 0789521F9970 for ; Fri,  2 Nov 2012 05:00:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.417
X-Spam-Level: 
X-Spam-Status: No, score=-1.417 tagged_above=-999 required=5 tests=[AWL=0.271,  BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0YF0Odnwxeo for ; Fri,  2 Nov 2012 05:00:43 -0700 (PDT)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7CE21F996F for ; Fri,  2 Nov 2012 05:00:43 -0700 (PDT)
Received: by mail.sipthor.net (Postfix, from userid 5001) id E658CB35DA; Fri,  2 Nov 2012 13:00:41 +0100 (CET)
Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 30855B00F7; Fri,  2 Nov 2012 13:00:41 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= 
In-Reply-To: 
Date: Fri, 2 Nov 2012 13:00:40 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4BB9B7CC-7866-4406-BE3B-20A266D34E53@ag-projects.com>
References:   <2C9DA935-CBBD-4DCF-A2A4-FF0139FB62B2@ag-projects.com> 
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
X-Mailer: Apple Mail (2.1085)
Cc: Bernard Aboba , "DRAGE, Keith \(Keith\)" , "simple@ietf.org" 
Subject: Re: [Simple] =?windows-1252?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=85_?= =?windows-1252?q?=28new_subject=29?=
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, 02 Nov 2012 12:00:44 -0000

On Nov 2, 2012, at 11:46 AM, I=F1aki Baz Castillo wrote:

> 2012/11/2 Sa=FAl Ibarra Corretg=E9 :
>> - Having a oma pres-rules document which just points to a =
resource-lists document means that we can no longer get the policy for a =
watcher by just looking at pre-rules. This makes me think that we need a =
single document to store a buddy-list, which also contains the  policy =
for each buddy.
>=20
> SO what I say and repeat 1000 times: authorization MUST be an
> *attribute* of each buddy. Period. Drop "users lists" named
> "allowed-buddies" / "blocked-buddies", that's not the way to go.
>=20

And when did I say otherwise? :-O

> buddylist:
> --------------------
> sip:alice@example.com {
>  presence-subscribe-to: true,
>  presence-allowed: true,
>  presence-blocked: false
> }
>=20
> sip:bob@example.com {
>  presence-subscribed-to: true,
>  presence-allowed: true,
>  presence-blocked: true
> }
> --------------------
>=20
> And that's all. This is easy to render for the watcher and easy to
> process for the server. Single "document" with buddies and their
> attributes.
>=20
> No need for "external references to other XCAP documents in any other
> server in the world", no need for generating a coredump if the same
> buddy is contained in "oma_my_buddies" list and "my_blocked_contacts"
> list and "oma_PoC_contacts" list and "oma_featured_buddies" list.
>=20

This is what we did in our addressbook implementation, while maintaining =
compatibility to the highest possible degree.

--
Sa=FAl Ibarra Corretg=E9
AG Projects




From ibc@aliax.net  Fri Nov  2 05:07:43 2012
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 A01C521F99CA for ; Fri,  2 Nov 2012 05:07:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.531
X-Spam-Level: 
X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3lhEU7nSmEZ for ; Fri,  2 Nov 2012 05:07:43 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id CEC9621F99C4 for ; Fri,  2 Nov 2012 05:07:42 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id b11so2771789lam.31 for ; Fri, 02 Nov 2012 05:07:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=dZ9ToGHoDM1DPbN6QeE4RFCLSCif5wyvKJkr0yv5WlY=; b=aGRpCea7mO6UjCaAgz/LacNc6hHUVHtNGzJOmNeNtMBELQNi3pwyuhe8BI5r82LZkW ceqttYHq3BrO378eCtJO6jvhHl9sqmHxrKaV9v6dN/k6bbypY/D0amAoCmMbcYDQfjdL bW+YGczieTMqiSAhZ95PNazuYnBK1ioSoXAgBn1rLFfVEJrkfPQGKKB413C0GsHKUxZ6 wbefYZXed6Fg71IpMs6NMwjX2XJAZ9ZmWNDNRaECJtm//Ef1BTvKTJjqFUCtaHCoq7Kb VSt43klT5eq/2W8RZZJXu7ReWlTbbdI+L0YfwzNFDIOjly7q3UnfCoSKBGgG9lii0awq kNwQ==
Received: by 10.152.110.42 with SMTP id hx10mr1482301lab.0.1351858061338; Fri, 02 Nov 2012 05:07:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.114.2.71 with HTTP; Fri, 2 Nov 2012 05:07:21 -0700 (PDT)
In-Reply-To: <4BB9B7CC-7866-4406-BE3B-20A266D34E53@ag-projects.com>
References:   <2C9DA935-CBBD-4DCF-A2A4-FF0139FB62B2@ag-projects.com>  <4BB9B7CC-7866-4406-BE3B-20A266D34E53@ag-projects.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Fri, 2 Nov 2012 13:07:21 +0100
Message-ID: 
To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlFaD5JXzZXsl7zMklmnwVSVTle7JF/3mnaBciVLn+CW49Q0/XWNRpNiTvqF2gGo5vd8pw9
Cc: Bernard Aboba , "DRAGE, Keith \(Keith\)" , "simple@ietf.org" 
Subject: Re: [Simple] =?utf-8?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=E2=80=A6_?= =?utf-8?q?=28new_subject=29?=
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, 02 Nov 2012 12:07:43 -0000

2012/11/2 Sa=C3=BAl Ibarra Corretg=C3=A9 :

>> buddylist:
>> --------------------
>> sip:alice@example.com {
>>  presence-subscribe-to: true,
>>  presence-allowed: true,
>>  presence-blocked: false
>> }
>>
>> sip:bob@example.com {
>>  presence-subscribed-to: true,
>>  presence-allowed: true,
>>  presence-blocked: true
>> }
>> --------------------
>>
>> And that's all. This is easy to render for the watcher and easy to
>> process for the server. Single "document" with buddies and their
>> attributes.
>>
>> No need for "external references to other XCAP documents in any other
>> server in the world", no need for generating a coredump if the same
>> buddy is contained in "oma_my_buddies" list and "my_blocked_contacts"
>> list and "oma_PoC_contacts" list and "oma_featured_buddies" list.
>>
>
> This is what we did in our addressbook implementation, while maintaining =
compatibility to the highest possible degree.

And what is the point in "mantaining compatibility" if no other SIMPLE
client will understand the advanced document format of your
resource-list document? (they will probably delete it and regenerate
it).

And, if we just need a single document (based on buddies with
attributes) why do we need so many scattered XML/XCAP documents in the
server? and why does the presence server need to deal with N XML
documents and external references between them?

Why do we need a "RLS document" for presence subscription if we can
set an attribute "presence-subscribe-to" for each buddy in our
buddylist so the server already knows which users to subscribe to? Why
do we need a pres-rules documents if authorization rules are given via
buddy attributes? why do we need 95% of SIMPLE/XCAP specs if a single
document is enough?

And why to mantain "backward compatibility" if there is NO one full
working SIMPLE client out of walled gardens (apart from Blink which,
finally, works well but just when using the server infrastructure
designed for it)?




--
I=C3=B1aki Baz Castillo


From saul@ag-projects.com  Fri Nov  2 05:25:47 2012
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 A4A2921F93C1 for ; Fri,  2 Nov 2012 05:25:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.447
X-Spam-Level: 
X-Spam-Status: No, score=-1.447 tagged_above=-999 required=5 tests=[AWL=0.241,  BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-WkcR4RJYzn for ; Fri,  2 Nov 2012 05:25:47 -0700 (PDT)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id C866E21F93BE for ; Fri,  2 Nov 2012 05:25:46 -0700 (PDT)
Received: by mail.sipthor.net (Postfix, from userid 5001) id 1A9C9B35DA; Fri,  2 Nov 2012 13:25:45 +0100 (CET)
Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 1DA7AB007E; Fri,  2 Nov 2012 13:25:43 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= 
In-Reply-To: 
Date: Fri, 2 Nov 2012 13:25:42 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <2C9DA935-CBBD-4DCF-A2A4-FF0139FB62B2@ag-projects.com>  <4BB9B7CC-7866-4406-BE3B-20A266D34E53@ag-projects.com> 
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
X-Mailer: Apple Mail (2.1085)
Cc: Bernard Aboba , "DRAGE, Keith \(Keith\)" , "simple@ietf.org" 
Subject: Re: [Simple] =?windows-1252?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=85_?= =?windows-1252?q?=28new_subject=29?=
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, 02 Nov 2012 12:25:47 -0000

On Nov 2, 2012, at 1:07 PM, I=F1aki Baz Castillo wrote:

> 2012/11/2 Sa=FAl Ibarra Corretg=E9 :
>=20
>>> buddylist:
>>> --------------------
>>> sip:alice@example.com {
>>> presence-subscribe-to: true,
>>> presence-allowed: true,
>>> presence-blocked: false
>>> }
>>>=20
>>> sip:bob@example.com {
>>> presence-subscribed-to: true,
>>> presence-allowed: true,
>>> presence-blocked: true
>>> }
>>> --------------------
>>>=20
>>> And that's all. This is easy to render for the watcher and easy to
>>> process for the server. Single "document" with buddies and their
>>> attributes.
>>>=20
>>> No need for "external references to other XCAP documents in any =
other
>>> server in the world", no need for generating a coredump if the same
>>> buddy is contained in "oma_my_buddies" list and =
"my_blocked_contacts"
>>> list and "oma_PoC_contacts" list and "oma_featured_buddies" list.
>>>=20
>>=20
>> This is what we did in our addressbook implementation, while =
maintaining compatibility to the highest possible degree.
>=20
> And what is the point in "mantaining compatibility" if no other SIMPLE
> client will understand the advanced document format of your
> resource-list document? (they will probably delete it and regenerate
> it).
>=20
> And, if we just need a single document (based on buddies with
> attributes) why do we need so many scattered XML/XCAP documents in the
> server? and why does the presence server need to deal with N XML
> documents and external references between them?
>=20
> Why do we need a "RLS document" for presence subscription if we can
> set an attribute "presence-subscribe-to" for each buddy in our
> buddylist so the server already knows which users to subscribe to? Why
> do we need a pres-rules documents if authorization rules are given via
> buddy attributes? why do we need 95% of SIMPLE/XCAP specs if a single
> document is enough?
>=20
> And why to mantain "backward compatibility" if there is NO one full
> working SIMPLE client out of walled gardens (apart from Blink which,
> finally, works well but just when using the server infrastructure
> designed for it)?
>=20
>=20

You misundertood. That how we did it *for now*. I never ever mentioned =
there shouldn't be a better way nor that this is how I (personally) =
would like SIMPLE presence to look like. But I can't just simply =
implement a solution which only works with myself. Hence the backwards =
compatibility.

I'd love to see a better model endorsed by SIMPLE and then happily =
implement it. I think we do share this goal :-)

--
Sa=FAl Ibarra Corretg=E9
AG Projects




From ibc@aliax.net  Fri Nov  2 05:28:04 2012
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 C1A6B21F941A for ; Fri,  2 Nov 2012 05:28:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level: 
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=-0.005,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O55kBcuc76n1 for ; Fri,  2 Nov 2012 05:28:04 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0A71121F93C1 for ; Fri,  2 Nov 2012 05:28:03 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id b11so2785486lam.31 for ; Fri, 02 Nov 2012 05:28:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=HMOZXDPU4jBlHzl07NnST6vK6zd7iulxuUk82ggWCSE=; b=OXjskuqU0pEEgE/3Ku/sHCBwfzH9+FnTDrvisUlmfCnlNRyFpiX+C9EgSGNjcCKZA+ Hdw/5A1WktXXe5h44UvIoWExTsDfBlSfWWsj2ZbzpMbPHCcrRADgAJ0tWUxko50dp1uG sueAsXCBQGan5Pp5peMS7Ap5HlTOc9ee1Cf0GgtSowbFsylDFqu45qdpRcr5iuLsvo/+ VNYRTaXCKGEKuE+sU3H3WJDt/+oypukGabCG6G+DtCCIzaGzlIWIXIdlFIiZRBHaAjlD 1ZXBiV7v88Tau/YeyhYYi4JOdpCXwIocLI8D3uo2Z5oWwuo6zwFLnxln/v+XHUl5D4GL tGCw==
Received: by 10.152.109.145 with SMTP id hs17mr1538690lab.5.1351859282734; Fri, 02 Nov 2012 05:28:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.114.2.71 with HTTP; Fri, 2 Nov 2012 05:27:42 -0700 (PDT)
In-Reply-To: 
References:   <2C9DA935-CBBD-4DCF-A2A4-FF0139FB62B2@ag-projects.com>  <4BB9B7CC-7866-4406-BE3B-20A266D34E53@ag-projects.com>  
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Fri, 2 Nov 2012 13:27:42 +0100
Message-ID: 
To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmvXizeV1s6e9331vFgbsP3KqEOL6W2W5exOi7zxLnEPrnAf/Y/2h8JsRNyTWxXUj89yzW+
Cc: Bernard Aboba , "DRAGE, Keith \(Keith\)" , "simple@ietf.org" 
Subject: Re: [Simple] =?utf-8?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=E2=80=A6_?= =?utf-8?q?=28new_subject=29?=
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, 02 Nov 2012 12:28:04 -0000

2012/11/2 Sa=C3=BAl Ibarra Corretg=C3=A9 :
> You misundertood. That how we did it *for now*. I never ever mentioned th=
ere shouldn't be a better way nor that this is how I (personally) would lik=
e SIMPLE presence to look like. But I can't just simply implement a solutio=
n which only works with myself. Hence the backwards compatibility.

"backwards compatibility" with what?


> I'd love to see a better model endorsed by SIMPLE and then happily implem=
ent it. I think we do share this goal :-)

Sure we agree here. The key is: reusing SIMPLE/XCAP specs? or making
something better from scratch (after learning from current SIMPLE/XMPP
specs)?


--
I=C3=B1aki Baz Castillo


From saul@ag-projects.com  Fri Nov  2 05:30:23 2012
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 7388B21F8C19 for ; Fri,  2 Nov 2012 05:30:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.471
X-Spam-Level: 
X-Spam-Status: No, score=-1.471 tagged_above=-999 required=5 tests=[AWL=0.217,  BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJFGBmb9-7Bd for ; Fri,  2 Nov 2012 05:30:22 -0700 (PDT)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id B82F021F8982 for ; Fri,  2 Nov 2012 05:30:22 -0700 (PDT)
Received: by mail.sipthor.net (Postfix, from userid 5001) id 27270B35DC; Fri,  2 Nov 2012 13:30:21 +0100 (CET)
Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 7057BB007E; Fri,  2 Nov 2012 13:30:21 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= 
In-Reply-To: 
Date: Fri, 2 Nov 2012 13:30:21 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <02F714E4-F44F-4E6B-AA13-00BD1F9F8239@ag-projects.com>
References:   <2C9DA935-CBBD-4DCF-A2A4-FF0139FB62B2@ag-projects.com>  <4BB9B7CC-7866-4406-BE3B-20A266D34E53@ag-projects.com>   
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
X-Mailer: Apple Mail (2.1085)
Cc: Bernard Aboba , "DRAGE, Keith \(Keith\)" , "simple@ietf.org" 
Subject: Re: [Simple] =?windows-1252?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=85_?= =?windows-1252?q?=28new_subject=29?=
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, 02 Nov 2012 12:30:23 -0000

On Nov 2, 2012, at 1:27 PM, I=F1aki Baz Castillo wrote:

> 2012/11/2 Sa=FAl Ibarra Corretg=E9 :
>> You misundertood. That how we did it *for now*. I never ever =
mentioned there shouldn't be a better way nor that this is how I =
(personally) would like SIMPLE presence to look like. But I can't just =
simply implement a solution which only works with myself. Hence the =
backwards compatibility.
>=20
> "backwards compatibility" with what?
>=20

With the current specs, obviously.

>=20
>> I'd love to see a better model endorsed by SIMPLE and then happily =
implement it. I think we do share this goal :-)
>=20
> Sure we agree here. The key is: reusing SIMPLE/XCAP specs? or making
> something better from scratch (after learning from current SIMPLE/XMPP
> specs)?
>=20

That's a different discussion.

--
Sa=FAl Ibarra Corretg=E9
AG Projects




From ibc@aliax.net  Fri Nov  2 05:31:32 2012
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 7180221F8A24 for ; Fri,  2 Nov 2012 05:31:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level: 
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=-0.005,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qX8QSSgdFOgF for ; Fri,  2 Nov 2012 05:31:31 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4806D21F8958 for ; Fri,  2 Nov 2012 05:31:31 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id b11so2787894lam.31 for ; Fri, 02 Nov 2012 05:31:30 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=by111m5BcgRFrROJkaTtJ5/ACVYTqla5AjRC4WrjAO8=; b=C7bl9uDm/M12OhZ/TQ4oImtlGImjc5cSGuCzWLPYeayw5+vEQ78OHQLxpO3HpT76ul DoguCEbuVTf8ThkKl5M/EvUDo9Pcr9rcWPgGqD98WfZ0PQFesz4ppf87EPqMV9F2GjxS /iQbtYHBgrCr33bJpUYHt0QT2ASOX8tGXcgh0yNFf0AsrDTHu/niHm/MM/V/mQSnpJtI dhtWL7523OTMDVdKXvWU4eHvzZH7G7Y1WjqQGlo9aq3JxrW37yN38BmyTSK9h0+OHD+2 ORpBjQeqwWBwK8FiJT6OMC0tFGmRhUmzabD0HofpOGUaEjTCZVEXX29orK8bV16by5gu JZMg==
Received: by 10.112.26.131 with SMTP id l3mr712868lbg.26.1351859490145; Fri, 02 Nov 2012 05:31:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.114.2.71 with HTTP; Fri, 2 Nov 2012 05:31:09 -0700 (PDT)
In-Reply-To: <02F714E4-F44F-4E6B-AA13-00BD1F9F8239@ag-projects.com>
References:   <2C9DA935-CBBD-4DCF-A2A4-FF0139FB62B2@ag-projects.com>  <4BB9B7CC-7866-4406-BE3B-20A266D34E53@ag-projects.com>    <02F714E4-F44F-4E6B-AA13-00BD1F9F8239@ag-projects.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Fri, 2 Nov 2012 13:31:09 +0100
Message-ID: 
To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlxUe1GI3TZR4LWbXzOKVx8KzDf17xZRsouw9K2VlDg2VbsfJKbwxywvtOowplUX6nkNJVS
Cc: Bernard Aboba , "DRAGE, Keith \(Keith\)" , "simple@ietf.org" 
Subject: Re: [Simple] =?utf-8?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=E2=80=A6_?= =?utf-8?q?=28new_subject=29?=
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, 02 Nov 2012 12:31:32 -0000

2012/11/2 Sa=C3=BAl Ibarra Corretg=C3=A9 :
>> "backwards compatibility" with what?
>
> With the current specs, obviously.

XDDDDDDDD


--
I=C3=B1aki Baz Castillo


From ibc@aliax.net  Fri Nov  2 06:10:35 2012
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 0626721F89FD for ; Fri,  2 Nov 2012 06:10:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.606
X-Spam-Level: 
X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=0.071,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLNpmDCLNC+O for ; Fri,  2 Nov 2012 06:10:34 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 285B621F89D2 for ; Fri,  2 Nov 2012 06:10:33 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id b11so2814778lam.31 for ; Fri, 02 Nov 2012 06:10:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=vORuyBVvuh09bQEVqQ4YaIf48lnNbAiAL+BipBC3d+U=; b=VJppaGnVsDBfEcMJAqFr7FQEPeYnI016rEbidCrQGcTg47HqKhCPZJosaHJQVj52Hq Qmg8LZpoMbR4MKRLS5iDM3LTou5aEG96BgX1cpBFHggAML5YS+zL0276FB/rYmMreutv 6diYOIQP9P3dfe42DNAheR85XzaHX7vtan4n3+BAqa7GGNGhWIeV8iON2ewtJO2H0BIj /bv8cJoRInVGl9PIFFSyS/Ro9o6tI5dGocHZB/nOW8iPtxB+LJt69GS5f4WN2WMXLNmk 3y/Jxd/0cH/Sn8MA2QYoPJ89RUlWfY/QhEgR4cQZUuPcE4LA689lD4yMgji4NO4WZTbx SzQQ==
Received: by 10.112.29.9 with SMTP id f9mr775267lbh.22.1351861832846; Fri, 02 Nov 2012 06:10:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.114.2.71 with HTTP; Fri, 2 Nov 2012 06:10:12 -0700 (PDT)
In-Reply-To: <5D1564A2-1F40-4017-B16D-5A6A70D92969@nostrum.com>
References: <5D1564A2-1F40-4017-B16D-5A6A70D92969@nostrum.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Fri, 2 Nov 2012 14:10:12 +0100
Message-ID: 
To: Ben Campbell 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQm8dAwsHHkjkcdV/Xh3VUZTEBCD1Xs/sXIhY03cgb7qJLGOya9oEV4b8oIblmJvqXF1QhNs
Cc: Simple WG 
Subject: Re: [Simple] SIMPLE Interop Threads
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, 02 Nov 2012 13:10:35 -0000

Ben, really thanks a lot for your feedback and proposal for continuing
the discussions. We will do our best efforts to provide the points you
ask for.



2012/11/1 Ben Campbell :
> (as SIMPLE chair)
>
> Hi Everyone,
>
> We've recently had several very interesting thread about the interoperabi=
lity issues in SIMPLE and what could be done to improve them. I'd like to s=
ee those discussions make progress. But please keep in mind that the work g=
roup is very close to completion on all it's milestones. (For the purpose o=
f this thread, lets please ignore the question about whether that means "su=
ccessful" completion). SIMPLE will almost certainly close in the near futur=
e.
>
> That doesn't mean new work can't happen. It does mean that any such work =
will need to go through the normal RAI processes for substantially new work=
. Normally that means taking a proposal to DISPATCH. Success in DISPATCH wi=
ll require the interested parties to (roughly) agree on the nature of the p=
roblem to be solved, and the scope of the work needed to do so. A problem s=
tatement in the form of an Internet-Draft  would be extremely helpful.
>
> I suggest that the interested parties take the following concrete actions=
:
>
> 1) Work toward a rough consensus of the problem to be solved, and a rough=
 idea of the scope of the work. What are the gaps in the standards that mak=
e interop hard? Where's the low hanging fruit? Please feel free to continue=
 discussion on the SIMPLE list, with that goal in mind. (This also sounds l=
ike an interesting effort for the SIP Forum [nudge]  )
>
> 2) Bring a proposal to the DISPATCH list in time for the IETF-86 agenda d=
eadlines. Continue discussion about the scope of work there.
>
> 3) Figure out next steps in DISPATCH, based on the scope, interest, and e=
nergy demonstrated there.
>
> Again, I don't mean to stop the current discussion--please continue it, a=
nd feel free to use the SIMPLE list to help everyone get thoughts together =
to  make a concrete proposal to DISPATCH.
>
> Thanks!
>
> Ben.
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple



--=20
I=C3=B1aki Baz Castillo


From ben@nostrum.com  Fri Nov  2 07:20:26 2012
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 9B43F21F8AC8 for ; Fri,  2 Nov 2012 07:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.407
X-Spam-Level: 
X-Spam-Status: No, score=-102.407 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNUW5SRH0l1Y for ; Fri,  2 Nov 2012 07:20:26 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 458CE21F8AC2 for ; Fri,  2 Nov 2012 07:20:22 -0700 (PDT)
Received: from [10.0.1.6] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qA2EK59F027173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Nov 2012 09:20:06 -0500 (CDT) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ben Campbell 
In-Reply-To: 
Date: Fri, 2 Nov 2012 09:20:05 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <52C2C109-CFBD-4577-AF63-E36F82F6A809@nostrum.com>
References:   <2C9DA935-CBBD-4DCF-A2A4-FF0139FB62B2@ag-projects.com>  <4BB9B7CC-7866-4406-BE3B-20A266D34E53@ag-projects.com>   
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
X-Mailer: Apple Mail (2.1499)
Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: Bernard Aboba , "DRAGE, Keith \(Keith\)" , "simple@ietf.org" 
Subject: Re: [Simple] =?windows-1252?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=85_?= =?windows-1252?q?=28new_subject=29?=
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, 02 Nov 2012 14:20:26 -0000

(as individual)

On Nov 2, 2012, at 7:27 AM, I=F1aki Baz Castillo  wrote:

>> I'd love to see a better model endorsed by SIMPLE and then happily =
implement it. I think we do share this goal :-)
>=20
> Sure we agree here. The key is: reusing SIMPLE/XCAP specs? or making
> something better from scratch (after learning from current SIMPLE/XMPP
> specs)?

Do you really believe nothing is salvageable? For example, would you =
jettison all of the below?

-- Using SIP in the first place
-- SIP Events
-- RLS
-- SIP Message
-- MSRP
-- XCAP
-- etc

=46rom the discussions so far, it sounds like most of the complaints are =
in the area of reusing user lists between clients (e.g. contact lists, =
presence rules, etc). Do people really hate the entire SIMPLE suite, or =
is it just an XCAP issue.

If the scope of the work is "start over from scratch", then it seems =
like we would be better served starting with XMPP. I'd be very surprised =
if we could get support for creating "yet another presence and IM =
protocol".

We've been there before and it wasn't pretty.






From radhika.r.roy.civ@mail.mil  Fri Nov  2 07:41:22 2012
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 5813D21F87B4 for ; Fri,  2 Nov 2012 07:41:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.927
X-Spam-Level: 
X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.372,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6lcO5QDfk6b for ; Fri,  2 Nov 2012 07:41:21 -0700 (PDT)
Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.9]) by ietfa.amsl.com (Postfix) with ESMTP id 741BA21F8AAC for ; Fri,  2 Nov 2012 07:41:21 -0700 (PDT)
Received: from UCOLHP3M.easf.csd.disa.mil (131.64.100.152) by ucolhp2w.easf.csd.disa.mil (131.64.100.9) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 2 Nov 2012 14:41:01 +0000
Received: from UCOLHP9H.easf.csd.disa.mil ([169.254.5.171]) by UCOLHP3M.easf.csd.disa.mil ([131.64.100.152]) with mapi id 14.02.0309.003; Fri, 2 Nov 2012 14:41:00 +0000
From: "Roy, Radhika R CIV (US)" 
To: Ben Campbell , =?Windows-1252?Q?I=F1aki_Baz_Castillo?= 
Thread-Topic: =?Windows-1252?Q?[Simple]_SIMPLE_and_OMA_and_3Gpp_and_RCS_and=85_(new_sub?= =?Windows-1252?Q?ject)?=
Thread-Index: AQHNuQU/vgk3FIIRWEuLGSQng3VFCZfWmkPA
Date: Fri, 2 Nov 2012 14:40:58 +0000
Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF486515F0@ucolhp9h.easf.csd.disa.mil>
References:   <2C9DA935-CBBD-4DCF-A2A4-FF0139FB62B2@ag-projects.com>  <4BB9B7CC-7866-4406-BE3B-20A266D34E53@ag-projects.com>    <52C2C109-CFBD-4577-AF63-E36F82F6A809@nostrum.com>
In-Reply-To: <52C2C109-CFBD-4577-AF63-E36F82F6A809@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [131.64.62.4]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000E_01CDB8E6.851ECEB0"
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 02 Nov 2012 07:42:47 -0700
Cc: Bernard Aboba , "DRAGE, Keith \(Keith\)" , "simple@ietf.org" 
Subject: Re: [Simple] =?windows-1252?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=85_?= =?windows-1252?q?=28new_subject=29?=
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, 02 Nov 2012 14:41:22 -0000

------=_NextPart_000_000E_01CDB8E6.851ECEB0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Folks:

Like Ben, I also believe that to start from the scratch is a non-starter =
as
people do not know yet what the "magic model" exists to have the golden
opportunity of interworking.=20

No one is sure how all these interoperability problems will be solved as
people are adding a lot intelligence based on requirements what they =
feel
need to be added in IM and Presence.

It indicates one fundamental thing: These applications are popular and =
will
be used now and in the future not only as a stand-alone application, but
integration with audio, and video including emergency calls.

So, it would be prudent for all of us who have gained real in-depth
understanding after working in building specs, developing, and =
implementing
SIMPLE and XMPP to guide the entire commercial industry to adopt a kind =
of
standard-based IM and Presence model.

Let us be prepared that all of these will be a kind of learn, adopt, =
modify,
and create at time goes on in supporting and building the popular
application protocols like IM and Presence.

BR/Radhika


-----Original Message-----
From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf =
Of
Ben Campbell
Sent: Friday, November 02, 2012 10:20 AM
To: I=F1aki Baz Castillo
Cc: Bernard Aboba; DRAGE, Keith (Keith); simple@ietf.org
Subject: Re: [Simple] SIMPLE and OMA and 3Gpp and RCS and=85 (new =
subject)

(as individual)

On Nov 2, 2012, at 7:27 AM, I=F1aki Baz Castillo  wrote:

>> I'd love to see a better model endorsed by SIMPLE and then happily
implement it. I think we do share this goal :-)
>=20
> Sure we agree here. The key is: reusing SIMPLE/XCAP specs? or making
> something better from scratch (after learning from current SIMPLE/XMPP
> specs)?

Do you really believe nothing is salvageable? For example, would you
jettison all of the below?

-- Using SIP in the first place
-- SIP Events
-- RLS
-- SIP Message
-- MSRP
-- XCAP
-- etc

>From the discussions so far, it sounds like most of the complaints are =
in
the area of reusing user lists between clients (e.g. contact lists, =
presence
rules, etc). Do people really hate the entire SIMPLE suite, or is it =
just an
XCAP issue.

If the scope of the work is "start over from scratch", then it seems =
like we
would be better served starting with XMPP. I'd be very surprised if we =
could
get support for creating "yet another presence and IM protocol".

We've been there before and it wasn't pretty.





_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

------=_NextPart_000_000E_01CDB8E6.851ECEB0
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw
ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g
R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290
IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG
A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE
AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/
PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X
3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt
upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7
f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK
AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ
gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/
ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1
K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx
Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO
8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K
ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA
MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM
MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN
MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww
CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE
SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9
ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V
hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR
9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV
lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9
eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh
eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js
L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL
CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB
BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku
Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth
LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN
AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E
wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF
NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp
8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh
iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw
DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM
MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x
MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu
IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk
BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm
b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd
Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma
9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u
rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD
VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny
bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc
MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y
9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v
RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud
EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5
ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU
AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ
G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/
VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O
vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF
eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5
uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ
MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow
XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww
CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ
s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4
zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY
zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf
VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G
A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU
uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG
A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC
AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs
oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB
AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U
Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC
hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul
M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl
cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3
i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW
LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y
U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz
SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5
eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv
dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg
Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xMjExMDIxNDQwNDdaMCMGCSqGSIb3DQEJBDEWBBT1McpxHJQsy1HvpeNj4+gk
GgCmfDBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC
BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x
CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG
A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm
oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E
MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB
AQUABIIBALfPhjW9ZMvXSc3nhyolFtOIhBSOa9SAJFUmhDmRNwMCjRGs2Ybeah/2tci1Ih00Ydmm
KEy2b87DEB+V2QzmNABkf+PU4PQVHC+0xUWkvdu6I+Pt+FQleluKBKzjJNIWvjclmvHG30VX59FP
0qPPMPueYn3k+yM2YPOPDore6b7PZ0lbLqGJ6onJr06XuJjJjRodjSYVY4pN+oCxtXc6iD0ShERl
IBfIOPC+JEcDmNNp1paaYuNS8+8qoYsVDla2vULbEKoFnHrxsuxq2s4baQTqqoaStN1KV7pl9WaI
bVjn5ZI0l7l0E9S/O3BNQ+dkf7wmtGPwrqZi7vWtI4gbjCMAAAAAAAA=

------=_NextPart_000_000E_01CDB8E6.851ECEB0--

From saul@ag-projects.com  Fri Nov  2 07:44:49 2012
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 C167B1F0C42 for ; Fri,  2 Nov 2012 07:44:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.191
X-Spam-Level: 
X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.897,  BAYES_00=-2.599, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_91=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWzSysQNyJm8 for ; Fri,  2 Nov 2012 07:44:48 -0700 (PDT)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 988AD21F8AC1 for ; Fri,  2 Nov 2012 07:44:48 -0700 (PDT)
Received: by mail.sipthor.net (Postfix, from userid 5001) id 3BEADB019B; Fri,  2 Nov 2012 15:44:47 +0100 (CET)
Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 585DEB00F7; Fri,  2 Nov 2012 15:44:46 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= 
In-Reply-To: <52C2C109-CFBD-4577-AF63-E36F82F6A809@nostrum.com>
Date: Fri, 2 Nov 2012 15:44:45 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <01FF046F-341E-43B8-BB3B-A9FAC9BFB78B@ag-projects.com>
References:   <2C9DA935-CBBD-4DCF-A2A4-FF0139FB62B2@ag-projects.com>  <4BB9B7CC-7866-4406-BE3B-20A266D34E53@ag-projects.com>    <52C2C109-CFBD-4577-AF63-E36F82F6A809@nostrum.com>
To: Ben Campbell 
X-Mailer: Apple Mail (2.1085)
Cc: Bernard Aboba , "DRAGE, Keith \(Keith\)" , "simple@ietf.org" 
Subject: Re: [Simple] =?windows-1252?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=85_?= =?windows-1252?q?=28new_subject=29?=
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, 02 Nov 2012 14:44:50 -0000

Hi Ben,

On Nov 2, 2012, at 3:20 PM, Ben Campbell wrote:

> (as individual)
>=20
> On Nov 2, 2012, at 7:27 AM, I=F1aki Baz Castillo  =
wrote:
>=20
>>> I'd love to see a better model endorsed by SIMPLE and then happily =
implement it. I think we do share this goal :-)
>>=20
>> Sure we agree here. The key is: reusing SIMPLE/XCAP specs? or making
>> something better from scratch (after learning from current =
SIMPLE/XMPP
>> specs)?
>=20
> Do you really believe nothing is salvageable? For example, would you =
jettison all of the below?
>=20
> -- Using SIP in the first place
> -- SIP Events
> -- RLS
> -- SIP Message
> -- MSRP
> -- XCAP
> -- etc
>=20
> =46rom the discussions so far, it sounds like most of the complaints =
are in the area of reusing user lists between clients (e.g. contact =
lists, presence rules, etc). Do people really hate the entire SIMPLE =
suite, or is it just an XCAP issue.

IM and SIP events are nice, the problem I've experienced with SIMPLE was =
letter P. The fact that a complex protocol (XCAP) was used along with =
multiple documents, and stretching resource-lists to contain a buddylist =
is what creates trouble. Actually XCAP is fine for storage, if we remove =
that default namespace problem and find a way to have something like =
xcap-diff which contains full contacts every time.

>=20
> If the scope of the work is "start over from scratch", then it seems =
like we would be better served starting with XMPP. I'd be very surprised =
if we could get support for creating "yet another presence and IM =
protocol".
>=20
> We've been there before and it wasn't pretty.
>=20

Not sure if anybody has had problems with the IM part, but I'm pretty =
sure I=F1aki is talking just a bout the presence part, just as I am.

Now, assuming we are just considering presence here, we could go either =
way: create a completely new spec which reuses nothing from the current =
(or maybe SIP events) or try to reuse what would "make sense" without =
compromising the whole design. The problem is that if we go the reusing =
route, is it acceptable that all specified documents are discarded,a  =
new document type is created and XCAP default namespace handling is =
fixed? I would not be backward compatible, of course.

IMHO this is the key point before starting to design any solution to the =
problem, because if it won't be accepted / adopted no matter how clever =
it is, we better do something else.


My 2 cents. Regards,

--
Sa=FAl Ibarra Corretg=E9
AG Projects




From emil@sip-communicator.org  Fri Nov  2 08:45:53 2012
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 9DCE71F0C49 for ; Fri,  2 Nov 2012 08:45:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.569
X-Spam-Level: 
X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.730,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KWXJEMf9ICd for ; Fri,  2 Nov 2012 08:45:52 -0700 (PDT)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 807611F0C42 for ; Fri,  2 Nov 2012 08:45:52 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id hm2so1233782wib.1 for ; Fri, 02 Nov 2012 08:45:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=vYrd/k0GtGP4QWAsS+mKaqZHjAKeHA2xPBzxlC9dQM4=; b=cYKZb+Ndt+ccEM2w28LzmKjpmf56a9lxWJb8JeZlQNyOsaWuEBMvANAFN51ZjENX+D wFBNjG9Wvk92MMmSQD4oYwJFfpdjyEx7SxDOk3/8rymHNvRIum45z58P0lgb27uYP6g8 CVdAOUehbSmFb6SM4Fk7OvtpM0eJWrnlNTBLbvzSloepVqXvHQOPoiSyTAsf+QuIfUeH Hb12Sxdi1r8i8DNpWYv3kMxtjm0oRYT4t5KK4osG6e1Cv2iBEIJdH8gDraIVnDg5AIOA GEAvsf0xNvY5VmwkKwrhzFM1e0pZL9iP8zv5WOX3OYb4s4ogD+4XegmaXbvri5VxBZ64 GtbQ==
Received: by 10.216.204.35 with SMTP id g35mr841041weo.0.1351871151662; Fri, 02 Nov 2012 08:45:51 -0700 (PDT)
Received: from camionet.local ([2a01:e35:2e2c:f600:85c0:46b:4fb5:c356]) by mx.google.com with ESMTPS id o3sm3147630wiz.9.2012.11.02.08.45.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 08:45:50 -0700 (PDT)
Message-ID: <5093EAB0.30909@jitsi.org>
Date: Fri, 02 Nov 2012 16:45:52 +0100
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Ben Campbell 
References:   <2C9DA935-CBBD-4DCF-A2A4-FF0139FB62B2@ag-projects.com>  <4BB9B7CC-7866-4406-BE3B-20A266D34E53@ag-projects.com>    <52C2C109-CFBD-4577-AF63-E36F82F6A809@nostrum.com>
In-Reply-To: <52C2C109-CFBD-4577-AF63-E36F82F6A809@nostrum.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnuoSExVWzzhpVAE9M7zA5vEcX9izgcqnuztnos7+tL+T+leb0BojFsaMiiSK82gOWEFIJd
Cc: Bernard Aboba , "DRAGE, Keith \(Keith\)" , "simple@ietf.org" 
Subject: Re: [Simple] =?windows-1252?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=85_?= =?windows-1252?q?=28new_subject=29?=
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, 02 Nov 2012 15:45:53 -0000

Hey all,

Since it's rant time ...

On 02.11.12, 15:20, Ben Campbell wrote:
> (as individual)
>=20
> On Nov 2, 2012, at 7:27 AM, I=F1aki Baz Castillo 
> wrote:
>=20
>>> I'd love to see a better model endorsed by SIMPLE and then
>>> happily implement it. I think we do share this goal :-)
>>=20
>> Sure we agree here. The key is: reusing SIMPLE/XCAP specs? or
>> making something better from scratch (after learning from current
>> SIMPLE/XMPP specs)?
>=20
> Do you really believe nothing is salvageable? For example, would you
> jettison all of the below?
>=20
> -- Using SIP in the first place -- SIP Events -- RLS -- SIP Message=20
> -- MSRP -- XCAP -- etc

I've never really understood how one could justify the use of a
completely different protocol to send IMs ... as if SIP was not complex
and evolved enough to handle this. And then that new protocols is just
so awesome that one can't have different chat sessions with different
people unless they setup different connections/sockets for every
conversation. Seriously?

Then, because the above was clearly not fun enough, we add yet another
completely different protocol for storing contacts lists.

I don't know the history but the result is just way beyond my understandi=
ng.

XMPP, MSN, Yahoo! Messenger, Gadu-Gadu, ICQ, AIM (before and after they
converged in OSCAR), Skype, they all managed to handle IM, presence and
contact storage with a single protocol.

SIP needed three.

Today those are implemented within different server-side applications
that then need to be deployed together. They need to be configured to
share user bases and policies. This hinders deployment and .. well ...
almost no one does it.

If there's a remake then could we please consider consolidating the
whole thing?

>> From the discussions so far, it sounds like most of the complaints
>> are in the area of reusing user lists between clients (e.g. contact
>> lists, presence rules, etc). Do people really hate the entire
>> SIMPLE suite, or is it just an XCAP issue.
>=20
> If the scope of the work is "start over from scratch", then it seems
> like we would be better served starting with XMPP.=20

We've seen relative ease of adoption with solutions of this kind:

draft-ivov-xmpp-cusax

I am by no means insisting that a similar model has to be adopted by a
SIMPLE successor but it has to be at least that easy to deploy.
Preferably easier.

Emil

> I'd be very
> surprised if we could get support for creating "yet another presence
> and IM protocol".


>=20
> We've been there before and it wasn't pretty.
>=20
>=20
>=20
>=20
>=20
> _______________________________________________ Simple mailing list=20
> Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple
>=20

--=20
https://jitsi.org



From saul@ag-projects.com  Fri Nov  2 08:53:50 2012
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 A599F21F89DF for ; Fri,  2 Nov 2012 08:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.566
X-Spam-Level: 
X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[AWL=0.122,  BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHPl399Da6lh for ; Fri,  2 Nov 2012 08:53:50 -0700 (PDT)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id B102D21F89DA for ; Fri,  2 Nov 2012 08:53:49 -0700 (PDT)
Received: by mail.sipthor.net (Postfix, from userid 5001) id C38D5B35DC; Fri,  2 Nov 2012 16:53:48 +0100 (CET)
Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id BBD1FB007E; Fri,  2 Nov 2012 16:53:47 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= 
In-Reply-To: <5093EAB0.30909@jitsi.org>
Date: Fri, 2 Nov 2012 16:53:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <406B58B9-42EC-4070-ACCC-D364ADE218CB@ag-projects.com>
References:   <2C9DA935-CBBD-4DCF-A2A4-FF0139FB62B2@ag-projects.com>  <4BB9B7CC-7866-4406-BE3B-20A266D34E53@ag-projects.com>    <52C2C109-CFBD-4577-AF63-E36F82F6A809@nostrum.com> <5093EAB0.30909@jitsi.org>
To: Emil Ivov 
X-Mailer: Apple Mail (2.1085)
Cc: Bernard Aboba , "DRAGE, Keith \(Keith\)" , "simple@ietf.org" 
Subject: Re: [Simple] =?windows-1252?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=85_?= =?windows-1252?q?=28new_subject=29?=
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, 02 Nov 2012 15:53:50 -0000

On Nov 2, 2012, at 4:45 PM, Emil Ivov wrote:

> Hey all,
>=20
> Since it's rant time ...
>=20
> On 02.11.12, 15:20, Ben Campbell wrote:
>> (as individual)
>>=20
>> On Nov 2, 2012, at 7:27 AM, I=F1aki Baz Castillo 
>> wrote:
>>=20
>>>> I'd love to see a better model endorsed by SIMPLE and then
>>>> happily implement it. I think we do share this goal :-)
>>>=20
>>> Sure we agree here. The key is: reusing SIMPLE/XCAP specs? or
>>> making something better from scratch (after learning from current
>>> SIMPLE/XMPP specs)?
>>=20
>> Do you really believe nothing is salvageable? For example, would you
>> jettison all of the below?
>>=20
>> -- Using SIP in the first place -- SIP Events -- RLS -- SIP Message=20=

>> -- MSRP -- XCAP -- etc
>=20
> I've never really understood how one could justify the use of a
> completely different protocol to send IMs ... as if SIP was not =
complex
> and evolved enough to handle this. And then that new protocols is just
> so awesome that one can't have different chat sessions with different
> people unless they setup different connections/sockets for every
> conversation. Seriously?
>=20

If memory serves correctly, you could stay connected with your relay and =
send all sessions through it, since session multiplexing over a single =
TCP connection is supported.

> Then, because the above was clearly not fun enough, we add yet another
> completely different protocol for storing contacts lists.
>=20
> I don't know the history but the result is just way beyond my =
understanding.
>=20
> XMPP, MSN, Yahoo! Messenger, Gadu-Gadu, ICQ, AIM (before and after =
they
> converged in OSCAR), Skype, they all managed to handle IM, presence =
and
> contact storage with a single protocol.
>=20
> SIP needed three.
>=20

Very good point.

> Today those are implemented within different server-side applications
> that then need to be deployed together. They need to be configured to
> share user bases and policies. This hinders deployment and .. well ...
> almost no one does it.
>=20
> If there's a remake then could we please consider consolidating the
> whole thing?
>=20
>>> =46rom the discussions so far, it sounds like most of the complaints
>>> are in the area of reusing user lists between clients (e.g. contact
>>> lists, presence rules, etc). Do people really hate the entire
>>> SIMPLE suite, or is it just an XCAP issue.
>>=20
>> If the scope of the work is "start over from scratch", then it seems
>> like we would be better served starting with XMPP.=20
>=20
> We've seen relative ease of adoption with solutions of this kind:
>=20
> draft-ivov-xmpp-cusax
>=20
> I am by no means insisting that a similar model has to be adopted by a
> SIMPLE successor but it has to be at least that easy to deploy.
> Preferably easier.
>=20

Thanks for your input Emil!


Regards,

--
Sa=FAl Ibarra Corretg=E9
AG Projects




From ag@ag-projects.com  Fri Nov  2 09:28:46 2012
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 BEED911E80D7 for ; Fri,  2 Nov 2012 09:28:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.688
X-Spam-Level: 
X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDYyfnfp71cH for ; Fri,  2 Nov 2012 09:28:46 -0700 (PDT)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id B7FCC11E80BF for ; Fri,  2 Nov 2012 09:28:42 -0700 (PDT)
Received: by mail.sipthor.net (Postfix, from userid 5001) id 02F38B35DD; Fri,  2 Nov 2012 17:28:39 +0100 (CET)
Received: from ag-retina-5.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id 45FECB00F7; Fri,  2 Nov 2012 17:28:39 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: Adrian Georgescu 
In-Reply-To: <52C2C109-CFBD-4577-AF63-E36F82F6A809@nostrum.com>
Date: Fri, 2 Nov 2012 17:28:38 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <17F5A3BF-04B1-49A1-8EAF-17CFAC09677D@ag-projects.com>
References:   <2C9DA935-CBBD-4DCF-A2A4-FF0139FB62B2@ag-projects.com>  <4BB9B7CC-7866-4406-BE3B-20A266D34E53@ag-projects.com>    <52C2C109-CFBD-4577-AF63-E36F82F6A809@nostrum.com>
To: Ben Campbell 
X-Mailer: Apple Mail (2.1283)
Cc: Bernard Aboba , "DRAGE, Keith \(Keith\)" , "simple@ietf.org" 
Subject: Re: [Simple] =?windows-1252?q?SIMPLE_and_OMA_and_3Gpp_and_RCS_and=85_?= =?windows-1252?q?=28new_subject=29?=
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, 02 Nov 2012 16:28:46 -0000

On Nov 2, 2012, at 3:20 PM, Ben Campbell wrote:

> (as individual)
>=20
> On Nov 2, 2012, at 7:27 AM, I=F1aki Baz Castillo  =
wrote:
>=20
>>> I'd love to see a better model endorsed by SIMPLE and then happily =
implement it. I think we do share this goal :-)
>>=20
>> Sure we agree here. The key is: reusing SIMPLE/XCAP specs? or making
>> something better from scratch (after learning from current =
SIMPLE/XMPP
>> specs)?
>=20
> Do you really believe nothing is salvageable? For example, would you =
jettison all of the below?
>=20
> -- Using SIP in the first place
> -- SIP Events
> -- RLS
> -- SIP Message
> -- MSRP
> -- XCAP
> -- etc
>=20
> =46rom the discussions so far, it sounds like most of the complaints =
are in the area of reusing user lists between clients (e.g. contact =
lists, presence rules, etc). Do people really hate the entire SIMPLE =
suite, or is it just an XCAP issue.

To narrow it down, again.

It is an XCAP issue that is related to storage of the presence rules. =
The SIP Presence Agent must be able to read it too. It should be a =
single document that stores both the contacts and their policy.

This is the only really issue in my opinion.

Adrian
=20=

From ben@nostrum.com  Fri Nov  2 13:33:58 2012
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 E914121F9A57 for ; Fri,  2 Nov 2012 13:33:58 -0700 (PDT)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1+TzsYwMpIe for ; Fri,  2 Nov 2012 13:33:58 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2EE21F9A56 for ; Fri,  2 Nov 2012 13:33:57 -0700 (PDT)
Received: from [10.12.11.26] ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qA2KXvEt063579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 2 Nov 2012 15:33:57 -0500 (CDT) (envelope-from ben@nostrum.com)
From: Ben Campbell 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 2 Nov 2012 15:33:57 -0500
References: <20121101121722.29094.73706.idtracker@ietfa.amsl.com>
To: Simple WG 
Message-Id: <195EC89C-4C54-4D5E-9C1F-14D0115DD57E@nostrum.com>
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism)
Subject: [Simple] Fwd: Help the NomCom
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, 02 Nov 2012 20:33:59 -0000

Hi,

Please give the NomCom all possible assistance.

Thanks!

Ben.

Begin forwarded message:

> From: NomCom Chair 
>=20
> The IETF Nominations Committee (NomCom) continues to seek input from
> the IETF Community. The NomCom would greatly appreciate any help you
> could provide in making members of your working group aware of ways in
> which they can provide valuable feedback to the NomCom.
>=20
> In order to ensure that your input is received in time to be useful, =
the=20
> NomCom needs to receive community feedback on or before Sunday, =
November 11.
>=20
> The final list of candidates (as per RFC 5680) that the NomCom is=20
> considering for open positions can be found at:=20
> https://www.ietf.org/group/nomcom/2012/input/
>=20
> The NomCom will be holding office hours during IETF 85, Monday-
> Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes=20
> comments on specific individuals, as well as general feedback related =
to=20
> any of the positions that NomCom is considering.
>=20
> Note: A list of leadership positions that the NomCom is considering =
can be=20
> found at: https://www.ietf.org/group/nomcom/2012/
>=20
> If the NomCom office hours are inconvenient for you or if you cannot=20=

> attend IETF 85, the NomCom is happy to take community input via email=20=

> to nomcom12 at ietf.org. Additionally, the NomCom is happy to arrange =
a=20
> meeting outside of office hours, just send us email and we can set=20
> something up.
>=20
> Comments on specific candidates can also be provided to the NomCom
> via the web feedback tool:=20
> https://www.ietf.org/group/nomcom/2012/input/
>=20
> Thank you for your help,
> - Matt Lepinski
>  nomcom-chair at ietf.org


From mary.ietf.barnes@gmail.com  Sun Nov  4 05:15:57 2012
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 EE4FF21F85F0 for ; Sun,  4 Nov 2012 05:15:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.257
X-Spam-Level: 
X-Spam-Status: No, score=-103.257 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzHwLwhFu9RO for ; Sun,  4 Nov 2012 05:15:57 -0800 (PST)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id AF5A021F85E3 for ; Sun,  4 Nov 2012 05:15:56 -0800 (PST)
Received: by mail-la0-f44.google.com with SMTP id b11so3790169lam.31 for ; Sun, 04 Nov 2012 05:15:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n6xQ63mF0ID9eQ7W4JXVYbLLvDQ/ZpyUaplGhdsU6HE=; b=GFp9YYpyHTJDddwTqdNY4S/AlsKV3IzZAORe+/uKdkQOfG2COgPXN+uYy804k24HDn EMH0LgP/m6t0JYZjmFnV/VdWEjDurssjPwe3WXyWrm+kf6g2ywrRUkUleXE2JWs3YEjw EwrQ/DX7VgGwXoqbL5Zjb2UaJdHWMosRg8EtkWllLcHfvmJENagJsB/fQkwxQ2QSpxQC +KldcOI5JK94Xq6FCw3l4ASIroCG6wNKZDIEFJirbuqxhccbD3lPZcuM8BYGW8LN2Pxq d46iw5suoXIBwBg5PZMEBPJnwdqpp5xa7DXh/swK6XkMDXiUSvVeAz7BAf45vDEt+QTY J9BA==
MIME-Version: 1.0
Received: by 10.112.24.6 with SMTP id q6mr2945024lbf.24.1352034955569; Sun, 04 Nov 2012 05:15:55 -0800 (PST)
Received: by 10.114.69.139 with HTTP; Sun, 4 Nov 2012 05:15:55 -0800 (PST)
In-Reply-To: <2C5ED210-3C72-4D6A-84A2-50A8229D4C91@nostrum.com>
References:   <8901840E-9C96-4555-813B-5900B2532796@nostrum.com> <2C5ED210-3C72-4D6A-84A2-50A8229D4C91@nostrum.com>
Date: Sun, 4 Nov 2012 07:15:55 -0600
Message-ID: 
From: Mary Barnes 
To: Ben Campbell 
Content-Type: multipart/alternative; boundary=e0cb4efe2a0a40295d04cdab2bc7
Cc: Bernard Aboba , "DRAGE, Keith \(Keith\)" , "simple@ietf.org" 
Subject: Re: [Simple] SIMPLE and OMA and 3Gpp and RCS and... (new subject)
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 Nov 2012 13:15:58 -0000

--e0cb4efe2a0a40295d04cdab2bc7
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Nov 1, 2012 at 6:12 PM, Ben Campbell  wrote:

>
> On Nov 1, 2012, at 6:09 PM, Ben Campbell  wrote:
>
> >
> > On Nov 1, 2012, at 6:00 PM, "DRAGE, Keith (Keith)" <
> keith.drage@alcatel-lucent.com> wrote:
> >
> >> So I guess that IETF has therefore abandoned RFC 5727.
> >
> > I'm trying to figure out how "abandoning 5727" follows from "no liaison
> manager for OMA". I'm not getting it; can you elaborate?
> >
> >>
> >> OMA last asked for 6 header fields to be registered. As far as I
> understand they were told they needed a standards track RFC to do this.
> Identifying no need for cooperation tells me that IETF is quite happy they
> have their own version of the SIP specification.
> >>
> >
> > I don't think choosing not to assign a liaison manager implies we expect
> no cooperation. You don't need an IETF assigned liaison manager to someone
> bring a draft to the IETF, do you?
>
> Okay, that was a cut-paste disaster. s/ "to someone bring" / "for someone
> to bring"
>
[MB] Correct, you do not need an IETF appointed liaison manager in order to
work with another SDO/forum. There is an email address for any liaison
statements to be sent and those are generally distributed to the
appropriate parties.  The drafts run the normal course through the process.
 Note, that IETF only recently decided they did not need a liaison manager
for OMA as the individual that was in that role was no longer able to do
it.  But, the assessment at that time was that one was not needed. The onus
is not on IETF to drive the contributions from another SDO.  The onus is on
the individuals that are driving the work.  [/MB]

>
> >
> >> Keith
> >>
> >>> -----Original Message-----
> >>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
> >>> Sent: 01 November 2012 20:09
> >>> To: Ben Campbell
> >>> Cc: Olle E. Johansson; Bernard Aboba; DRAGE, Keith (Keith);
> >>> simple@ietf.org
> >>> Subject: Re: [Simple] SIMPLE and OMA and 3Gpp and RCS and... (new
> subject)
> >>>
> >>> Murray was the liaison person to the OMA from the IETF side. Murray
> >>> recently discontinued his participation in the OMA (due to a job
> change).
> >>> We discussed the need to appoint a new liaison person in the IAB and
> came
> >>> to the conclusion that no new appointment is necessary; the required
> need
> >>> to interact with the OMA had decreased over time.
> >>>
> >>> Does anyone on this list believe that there is a need for cooperation
> with
> >>> the OMA?
> >>>
> >>> Ciao
> >>> Hannes
> >>>
> >>> Sent from my ASUS Pad
> >>>
> >>> Ben Campbell  wrote:
> >>>
> >>>>
> >>>> On Nov 1, 2012, at 2:20 PM, "Olle E. Johansson" 
> wrote:
> >>>>
> >>>>> What is the current relationship betwen OMA and the IETF? ANy
> >>> cooperation, like between 3Gpp and the IETF?
> >>>>>
> >>>>
> >>>>
> >>>> There is a liaison, but I don't think it's been very active for a
> while
> >>> now.
> >>>> _______________________________________________
> >>>> Simple mailing list
> >>>> Simple@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/simple
> >
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple
>

--e0cb4efe2a0a40295d04cdab2bc7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On Thu, N=
ov 1, 2012 at 6:12 PM, Ben Campbell <ben@nostrum.com> wrote:




On Nov 1, 2012, at 6:09 PM, Ben Campbell <ben@nostrum.com> wrote:



>

> On Nov 1, 2012, at 6:00 PM, "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com=
> wrote:

>

>> So I guess that IETF has therefore abandoned RFC 5727.

>

> I'm trying to figure out how "abandoning 5727" follows f=
rom "no liaison manager for OMA". I'm not getting it; can you=
 elaborate?

>

>>

>> OMA last asked for 6 header fields to be registered. As far as I u=
nderstand they were told they needed a standards track RFC to do this. Iden=
tifying no need for cooperation tells me that IETF is quite happy they have=
 their own version of the SIP specification.


>>

>

> I don't think choosing not to assign a liaison manager implies we =
expect no cooperation. You don't need an IETF assigned liaison manager =
to someone bring a draft to the IETF, do you?




Okay, that was a cut-paste disaster. s/ "to someone bring" =
/ "for someone to bring"
[MB] Correct, you d=
o not need an IETF appointed liaison manager in order to work with another =
SDO/forum. There is an email address for any liaison statements to be sent =
and those are generally distributed to the appropriate parties. =A0The draf=
ts run the normal course through the process. =A0Note, that IETF only recen=
tly decided they did not need a liaison manager for OMA as the individual t=
hat was in that role was no longer able to do it. =A0But, the assessment at=
 that time was that one was not needed. The onus is not on IETF to drive th=
e contributions from another SDO. =A0The onus is on the individuals that ar=
e driving the work. =A0[/MB]=A0






>

>> Keith

>>

>>> -----Original Message-----

>>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]

>>> Sent: 01 November 2012 20:09

>>> To: Ben Campbell

>>> Cc: Olle E. Johansson; Bernard Aboba; DRAGE, Keith (Keith);
>>> simple@ietf.org

>>> Subject: Re: [Simple] SIMPLE and OMA and 3Gpp and RCS and... (=
new subject)

>>>

>>> Murray was the liaison person to the OMA from the IETF side. M=
urray

>>> recently discontinued his participation in the OMA (due to a j=
ob change).

>>> We discussed the need to appoint a new liaison person in the I=
AB and came

>>> to the conclusion that no new appointment is necessary; the re=
quired need

>>> to interact with the OMA had decreased over time.

>>>

>>> Does anyone on this list believe that there is a need for coop=
eration with

>>> the OMA?

>>>

>>> Ciao

>>> Hannes

>>>

>>> Sent from my ASUS Pad

>>>

>>> Ben Campbell <ben@nostru=
m.com> wrote:

>>>

>>>>

>>>> On Nov 1, 2012, at 2:20 PM, "Olle E. Johansson" =
<oej@edvina.net> wrote:

>>>>

>>>>> What is the current relationship betwen OMA and the IE=
TF? ANy

>>> cooperation, like between 3Gpp and the IETF?

>>>>>

>>>>

>>>>

>>>> There is a liaison, but I don't think it's been ve=
ry active for a while

>>> now.

>>>> _______________________________________________

>>>> Simple mailing list

>>>> Simple@ietf.org

>>>> https://www.ietf.org/mailman/listinfo/simple

>



_______________________________________________

Simple mailing list

Simple@ietf.org

=
https://www.ietf.org/mailman/listinfo/simple





--e0cb4efe2a0a40295d04cdab2bc7--

From mary.ietf.barnes@gmail.com  Sun Nov  4 05:18:57 2012
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 50B6621F8632 for ; Sun,  4 Nov 2012 05:18:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.275
X-Spam-Level: 
X-Spam-Status: No, score=-103.275 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwyzKIjpv3kk for ; Sun,  4 Nov 2012 05:18:56 -0800 (PST)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id DA95B21F8453 for ; Sun,  4 Nov 2012 05:18:55 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id k13so3815284lbo.31 for ; Sun, 04 Nov 2012 05:18:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=frECB7tB+U0MZn88XEziqfkK5u9utTNsZsK5tTM+oPc=; b=iSluvCGyE6K1/7m1ZG/jCy2EzTv12p66qUjaM8jyGqLTYsaOqBiOyZ6XWPUcBJZl7p v4teuXxQzSUaNUPYVZ2zw9CXhKYQ6nq4ovK8u+is7/DlMNVrqJNQeT4e6sOfsURCQ96X VvXcaQF8vU5qdUmR7TCeG8iWHtTaC1mS2kVT7sSK7b9zhEn3srN98O+3Rhkrej8PYzNS dlzRhC6Q1Hr+nvRvJW9UWmnBIxN5WfoeBHsIo5lpIb2g8D+jC0Pl1jnaEUQI144xHSVu sUEggZODQT/MlRfgkclrXXlWfZT9T0AzmBdFuZVUhcLuKyv1k7pvToiy1UNmpSZ3ah7C IdEw==
MIME-Version: 1.0
Received: by 10.112.50.106 with SMTP id b10mr2869658lbo.122.1352035134763; Sun, 04 Nov 2012 05:18:54 -0800 (PST)
Received: by 10.114.69.139 with HTTP; Sun, 4 Nov 2012 05:18:54 -0800 (PST)
In-Reply-To: 
References:   <8901840E-9C96-4555-813B-5900B2532796@nostrum.com> <2C5ED210-3C72-4D6A-84A2-50A8229D4C91@nostrum.com> 
Date: Sun, 4 Nov 2012 07:18:54 -0600
Message-ID: 
From: Mary Barnes 
To: "DRAGE, Keith (Keith)" 
Content-Type: multipart/alternative; boundary=f46d0401fe59ee747e04cdab358a
Cc: Bernard Aboba , "simple@ietf.org" 
Subject: Re: [Simple] SIMPLE and OMA and 3Gpp and RCS and... (new subject)
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 Nov 2012 13:18:57 -0000

--f46d0401fe59ee747e04cdab358a
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Nov 1, 2012 at 6:22 PM, DRAGE, Keith (Keith) <
keith.drage@alcatel-lucent.com> wrote:

> I think you got the point. I can't help it if you don't think it is an
> issue.
>
[MB] It's to clear to me what point you think Ben got as he lighted there
are two separate things. [/MB]

>
> We'll see if OMA come back or not to test if you are right or wrong.
>
[MB] A message has been sent to OMA that we are not appointing a new
liaison manager:
https://datatracker.ietf.org/liaison/1213/
If OMA believes that is a problem, then they should reply to the IETF and
we can discuss if there is a need. Since it seems you have a vested
interest in this area, are you willing to serve as the IETF liaison?  One
of the issues when Murray stepped down was that there wasn't an obvious
individual that could take on the role. [/MB]

>
>
> Keith
>
> > -----Original Message-----
> > From: Ben Campbell [mailto:ben@nostrum.com]
> > Sent: 01 November 2012 23:12
> > To: DRAGE, Keith (Keith)
> > Cc: Hannes Tschofenig; Olle E. Johansson; Bernard Aboba; simple@ietf.org
> > Subject: Re: [Simple] SIMPLE and OMA and 3Gpp and RCS and... (new
> subject)
> >
> >
> > On Nov 1, 2012, at 6:09 PM, Ben Campbell  wrote:
> >
> > >
> > > On Nov 1, 2012, at 6:00 PM, "DRAGE, Keith (Keith)"
>  > lucent.com> wrote:
> > >
> > >> So I guess that IETF has therefore abandoned RFC 5727.
> > >
> > > I'm trying to figure out how "abandoning 5727" follows from "no liaison
> > manager for OMA". I'm not getting it; can you elaborate?
> > >
> > >>
> > >> OMA last asked for 6 header fields to be registered. As far as I
> > understand they were told they needed a standards track RFC to do this.
> > Identifying no need for cooperation tells me that IETF is quite happy
> they
> > have their own version of the SIP specification.
> > >>
> > >
> > > I don't think choosing not to assign a liaison manager implies we
> expect
> > no cooperation. You don't need an IETF assigned liaison manager to
> someone
> > bring a draft to the IETF, do you?
> >
> > Okay, that was a cut-paste disaster. s/ "to someone bring" / "for someone
> > to bring"
> >
> > >
> > >> Keith
> > >>
> > >>> -----Original Message-----
> > >>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
> > >>> Sent: 01 November 2012 20:09
> > >>> To: Ben Campbell
> > >>> Cc: Olle E. Johansson; Bernard Aboba; DRAGE, Keith (Keith);
> > >>> simple@ietf.org
> > >>> Subject: Re: [Simple] SIMPLE and OMA and 3Gpp and RCS and... (new
> > subject)
> > >>>
> > >>> Murray was the liaison person to the OMA from the IETF side. Murray
> > >>> recently discontinued his participation in the OMA (due to a job
> > change).
> > >>> We discussed the need to appoint a new liaison person in the IAB and
> > came
> > >>> to the conclusion that no new appointment is necessary; the required
> > need
> > >>> to interact with the OMA had decreased over time.
> > >>>
> > >>> Does anyone on this list believe that there is a need for cooperation
> > with
> > >>> the OMA?
> > >>>
> > >>> Ciao
> > >>> Hannes
> > >>>
> > >>> Sent from my ASUS Pad
> > >>>
> > >>> Ben Campbell  wrote:
> > >>>
> > >>>>
> > >>>> On Nov 1, 2012, at 2:20 PM, "Olle E. Johansson" 
> > wrote:
> > >>>>
> > >>>>> What is the current relationship betwen OMA and the IETF? ANy
> > >>> cooperation, like between 3Gpp and the IETF?
> > >>>>>
> > >>>>
> > >>>>
> > >>>> There is a liaison, but I don't think it's been very active for a
> > while
> > >>> now.
> > >>>> _______________________________________________
> > >>>> Simple mailing list
> > >>>> Simple@ietf.org
> > >>>> https://www.ietf.org/mailman/listinfo/simple
> > >
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple
>

--f46d0401fe59ee747e04cdab358a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On Thu, N=
ov 1, 2012 at 6:22 PM, DRAGE, Keith (Keith) <keith.drage@al=
catel-lucent.com> wrote:


I think you got=
 the point. I can't help it if you don't think it is an issue.


[MB] It's to clear to me what point you think Ben got=
 as he lighted there are two separate things. [/MB]=A0




We'll see if OMA come back or not to test if you are right or wrong.
[MB] A message has been sent to OMA that we are not appo=
inting a new liaison manager:


If OMA believes that is a problem, then they should reply to the IETF =
and we can discuss if there is a need. Since it seems you have a vested int=
erest in this area, are you willing to serve as the IETF liaison? =A0One of=
 the issues when Murray stepped down was that there wasn't an obvious i=
ndividual that could take on the role. [/MB]







Keith




> -----Original Message-----

> From: Ben Campbell [mailto:ben@nost=
rum.com]

> Sent: 01 November 2012 23:12

> To: DRAGE, Keith (Keith)

> Cc: Hannes Tschofenig; Olle E. Johansson; Bernard Aboba; simple@ietf.org

> Subject: Re: [Simple] SIMPLE and OMA and 3Gpp and RCS and... (new subj=
ect)

>

>


> On Nov 1, 2012, at 6:09 PM, Be=
n Campbell <ben@nostrum.com> w=
rote:

>

> >

> > On Nov 1, 2012, at 6:00 PM, "DRAGE, Keith (Keith)" <=
keith.drage@alcatel-

> lucent.com> wro=
te:

> >

> >> So I guess that IETF has therefore abandoned RFC 5727.

> >

> > I'm trying to figure out how "abandoning 5727" foll=
ows from "no liaison

> manager for OMA". I'm not getting it; can you elaborate?

> >

> >>

> >> OMA last asked for 6 header fields to be registered. As far a=
s I

> understand they were told they needed a standards track RFC to do this=
.

> Identifying no need for cooperation tells me that IETF is quite happy =
they

> have their own version of the SIP specification.

> >>

> >

> > I don't think choosing not to assign a liaison manager implie=
s we expect

> no cooperation. You don't need an IETF assigned liaison manager to=
 someone

> bring a draft to the IETF, do you?

>

> Okay, that was a cut-paste disaster. s/ "to someone bring" /=
 "for someone

> to bring"

>

> >

> >> Keith

> >>

> >>> -----Original Message-----

> >>> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]

> >>> Sent: 01 November 2012 20:09

> >>> To: Ben Campbell

> >>> Cc: Olle E. Johansson; Bernard Aboba; DRAGE, Keith (Keith=
);

> >>> simple@ietf.org
> >>> Subject: Re: [Simple] SIMPLE and OMA and 3Gpp and RCS and=
... (new

> subject)

> >>>

> >>> Murray was the liaison person to the OMA from the IETF si=
de. Murray

> >>> recently discontinued his participation in the OMA (due t=
o a job

> change).

> >>> We discussed the need to appoint a new liaison person in =
the IAB and

> came

> >>> to the conclusion that no new appointment is necessary; t=
he required

> need

> >>> to interact with the OMA had decreased over time.

> >>>

> >>> Does anyone on this list believe that there is a need for=
 cooperation

> with

> >>> the OMA?

> >>>

> >>> Ciao

> >>> Hannes

> >>>

> >>> Sent from my ASUS Pad

> >>>

> >>> Ben Campbell <ben@n=
ostrum.com> wrote:

> >>>

> >>>>

> >>>> On Nov 1, 2012, at 2:20 PM, "Olle E. Johansson&q=
uot; <oej@edvina.net>

> wrote:

> >>>>

> >>>>> What is the current relationship betwen OMA and t=
he IETF? ANy

> >>> cooperation, like between 3Gpp and the IETF?

> >>>>>

> >>>>

> >>>>

> >>>> There is a liaison, but I don't think it's be=
en very active for a

> while

> >>> now.

> >>>> _______________________________________________

> >>>> Simple mailing list

> >>>> Simple@ietf.org

> >>>> https://www.ietf.org/mailman/listinfo/simple

> >



_______________________________________________

Simple mailing list

Simple@ietf.org

=
https://www.ietf.org/mailman/listinfo/simple





--f46d0401fe59ee747e04cdab358a--

From peter.dunkley@crocodile-rcs.com  Tue Nov  6 04:51:04 2012
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 B4FB821F8861 for ; Tue,  6 Nov 2012 04:51:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUTTaU9wRcui for ; Tue,  6 Nov 2012 04:51:04 -0800 (PST)
Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 16CFB21F88A3 for ; Tue,  6 Nov 2012 04:51:04 -0800 (PST)
Received: (qmail 10407 invoked by uid 0); 6 Nov 2012 12:50:40 -0000
Received: from unknown (HELO just121.justhost.com) (173.254.28.121) by oproxy12.bluehost.com with SMTP; 6 Nov 2012 12:50:40 -0000
Received: from [127.0.0.1] (port=42191 helo=crocodile-rcs.com) by just121.justhost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TVic4-0003Ta-CO for simple@ietf.org; Tue, 06 Nov 2012 05:50:40 -0700
Received: from 213.221.117.228 ([213.221.117.228]) (SquirrelMail authenticated user peter.dunkley@crocodile-rcs.com) by crocodile-rcs.com with HTTP; Tue, 6 Nov 2012 12:50:40 -0000
Message-ID: <4c3dd3b34a958ba1c090772fb99f2a17.squirrel@crocodile-rcs.com>
Date: Tue, 6 Nov 2012 12:50:40 -0000
From: "Peter Dunkley" 
To: simple@ietf.org
User-Agent: SquirrelMail/1.4.22
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Identified-User: {:just121.justhost.com:crocodi1:just121.justhost.com} {sentby:program running on server}
Subject: [Simple] MSRP over WebSocket
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: Tue, 06 Nov 2012 12:51:04 -0000

Hello,

I have been working on this draft
(http://tools.ietf.org/html/draft-pd-msrp-websocket-01) to enable MSRP to
be used over WebSocket transport.  The latest Kamailio code-base in Git
contains an MSRP over WebSocket server implementation.

Can anyone advise as to whether there is interest in moving this draft
forward, and if so, what the correct process for doing so is?

Regards,

Peter Dunkley

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd


From ben@nostrum.com  Tue Nov  6 06:31:29 2012
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 755F921F893B for ; Tue,  6 Nov 2012 06:31:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.204
X-Spam-Level: 
X-Spam-Status: No, score=-101.204 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23tdSGqIXZ9s for ; Tue,  6 Nov 2012 06:31:29 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0026D21F8906 for ; Tue,  6 Nov 2012 06:31:28 -0800 (PST)
Received: from [130.129.96.108] (dhcp-606c.meeting.ietf.org [130.129.96.108]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qA6EVO56097237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 Nov 2012 08:31:25 -0600 (CST) (envelope-from ben@nostrum.com)
References: <4c3dd3b34a958ba1c090772fb99f2a17.squirrel@crocodile-rcs.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <4c3dd3b34a958ba1c090772fb99f2a17.squirrel@crocodile-rcs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <05B1626A-2B70-49AB-BA90-26AEDE007629@nostrum.com>
X-Mailer: iPad Mail (10A403)
From: Ben Campbell 
Date: Tue, 6 Nov 2012 09:31:26 -0500
To: Peter Dunkley 
Received-SPF: pass (nostrum.com: 130.129.96.108 is authenticated by a trusted mechanism)
Cc: "simple@ietf.org" 
Subject: Re: [Simple] MSRP over WebSocket
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: Tue, 06 Nov 2012 14:31:29 -0000

(As SIMPLE chair)

Hi Peter,

Thanks for sending this. However, the SIMPLE working group is near the end o=
f its charter, and will likely close soon. The best way to gauge interest at=
 this point is to send email to the DISPATCH mailing list: dispatch@ietf.org=


DISPATCH is responsible for investigating potential new work in the RAI area=
 that does not fit into an existing work group charter. Fortunately many of t=
he SIMPLE participants are also active in DISPATCH.

Thanks!

Ben.

On Nov 6, 2012, at 7:50 AM, "Peter Dunkley"  wrote:

> Hello,
>=20
> I have been working on this draft
> (http://tools.ietf.org/html/draft-pd-msrp-websocket-01) to enable MSRP to
> be used over WebSocket transport.  The latest Kamailio code-base in Git
> contains an MSRP over WebSocket server implementation.
>=20
> Can anyone advise as to whether there is interest in moving this draft
> forward, and if so, what the correct process for doing so is?
>=20
> Regards,
>=20
> Peter Dunkley
>=20
> --=20
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
>=20
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple

From peter.dunkley@crocodile-rcs.com  Tue Nov  6 07:07:36 2012
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 D924121F89C7 for ; Tue,  6 Nov 2012 07:07:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.432
X-Spam-Level: 
X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzAx1sWKjBUp for ; Tue,  6 Nov 2012 07:07:36 -0800 (PST)
Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id 5860821F8921 for ; Tue,  6 Nov 2012 07:07:36 -0800 (PST)
Received: (qmail 31014 invoked by uid 0); 6 Nov 2012 15:07:13 -0000
Received: from unknown (HELO just121.justhost.com) (173.254.28.121) by oproxy8.bluehost.com with SMTP; 6 Nov 2012 15:07:13 -0000
Received: from [127.0.0.1] (port=53262 helo=crocodile-rcs.com) by just121.justhost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TVkkC-0007I7-Tt; Tue, 06 Nov 2012 08:07:13 -0700
Received: from 213.221.117.228 ([213.221.117.228]) (SquirrelMail authenticated user peter.dunkley@crocodile-rcs.com) by crocodile-rcs.com with HTTP; Tue, 6 Nov 2012 15:07:13 -0000
Message-ID: <68535c5132917fb0bd71bcee69dcd14c.squirrel@crocodile-rcs.com>
In-Reply-To: <05B1626A-2B70-49AB-BA90-26AEDE007629@nostrum.com>
References: <4c3dd3b34a958ba1c090772fb99f2a17.squirrel@crocodile-rcs.com> <05B1626A-2B70-49AB-BA90-26AEDE007629@nostrum.com>
Date: Tue, 6 Nov 2012 15:07:13 -0000
From: "Peter Dunkley" 
To: "Ben Campbell" 
User-Agent: SquirrelMail/1.4.22
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Identified-User: {:just121.justhost.com:crocodi1:just121.justhost.com} {sentby:program running on server}
Cc: "simple@ietf.org" 
Subject: Re: [Simple] MSRP over WebSocket
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: Tue, 06 Nov 2012 15:07:37 -0000

Thanks Ben,

I have forwarded my original mail to DISPATCH.

Thanks again,

Peter

> (As SIMPLE chair)
>
> Hi Peter,
>
> Thanks for sending this. However, the SIMPLE working group is near the end
> of its charter, and will likely close soon. The best way to gauge interest
> at this point is to send email to the DISPATCH mailing list:
> dispatch@ietf.org
>
> DISPATCH is responsible for investigating potential new work in the RAI
> area that does not fit into an existing work group charter. Fortunately
> many of the SIMPLE participants are also active in DISPATCH.
>
> Thanks!
>
> Ben.
>
> On Nov 6, 2012, at 7:50 AM, "Peter Dunkley"
>  wrote:
>
>> Hello,
>>
>> I have been working on this draft
>> (http://tools.ietf.org/html/draft-pd-msrp-websocket-01) to enable MSRP
>> to
>> be used over WebSocket transport.  The latest Kamailio code-base in Git
>> contains an MSRP over WebSocket server implementation.
>>
>> Can anyone advise as to whether there is interest in moving this draft
>> forward, and if so, what the correct process for doing so is?
>>
>> Regards,
>>
>> Peter Dunkley
>>
>> --
>> Peter Dunkley
>> Technical Director
>> Crocodile RCS Ltd
>>
>> _______________________________________________
>> Simple mailing list
>> Simple@ietf.org
>> https://www.ietf.org/mailman/listinfo/simple
>


-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd


From internet-drafts@ietf.org  Sat Nov 17 08:06:30 2012
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 A9B4D21F8B69; Sat, 17 Nov 2012 08:06:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.481
X-Spam-Level: 
X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vE0j966TTMX9; Sat, 17 Nov 2012 08:06:30 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C324021F880D; Sat, 17 Nov 2012 08:06:11 -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: 4.36
Message-ID: <20121117160611.10411.74381.idtracker@ietfa.amsl.com>
Date: Sat, 17 Nov 2012 08:06:11 -0800
Cc: simple@ietf.org
Subject: [Simple] I-D Action: draft-ietf-simple-chat-17.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: Sat, 17 Nov 2012 16:06:30 -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 Presence Le=
veraging 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-17.txt
	Pages           : 42
	Date            : 2012-11-17

Abstract:
   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.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-simple-chat

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-simple-chat-17

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-simple-chat-17


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From miguel.a.garcia@ericsson.com  Sat Nov 17 08:30:37 2012
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 1B22921F844C for ; Sat, 17 Nov 2012 08:30:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CEVeQSNfV0l for ; Sat, 17 Nov 2012 08:30:36 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id EAD2321F844A for ; Sat, 17 Nov 2012 08:30:35 -0800 (PST)
X-AuditID: c1b4fb30-b7f936d0000018b3-35-50a7bbaa4207
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 8B.89.06323.AABB7A05; Sat, 17 Nov 2012 17:30:35 +0100 (CET)
Received: from [159.107.48.101] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Sat, 17 Nov 2012 17:30:34 +0100
Message-ID: <50A7BBA9.7040904@ericsson.com>
Date: Sat, 17 Nov 2012 17:30:33 +0100
From: "Miguel A. Garcia" 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: simple@ietf.org
References: <20121117160611.10411.74381.idtracker@ietfa.amsl.com>
In-Reply-To: <20121117160611.10411.74381.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDJMWRmVeSWpSXmKPExsUyM+Jvje7q3csDDBZJWiyc+I/VgdFjyZKf TAGMUVw2Kak5mWWpRfp2CVwZT3dtYyw4JFlx+9FplgbGZpEuRk4OCQETiZu7HjJC2GISF+6t ZwOxhQROMkrs/uPQxcgFZK9hlNhw9QAzSIJXQFtiyrrpTCA2i4CqxKXuiWDNbALmEq0bN7J3 MXJwiAoES8y5xg9RLihxcuYTFhBbREBY4uuKLnYQW1jAXuL4tyVMELscJTqPPQOLcwo4Sbxe 8wIszixgK3FhznUWCFteYvvbOcwQ9ZoSk28uZZ7AKDALyYpZSFpmIWlZwMi8ipE9NzEzJ73c fBMjMMQObvltsINx032xQ4zSHCxK4rx6qvv9hQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDm +jYUXc/X1phqXfnh47PVM5k6i58m34pd+VpH7V3Co5qU0/bnZn9WOsWZJVDyQFpMcN3zHKtp h5xvRh6cF2HE/ErQ1Xxzq2rM1fLNOopbLNOmSi75+X1ToOkF5gjJ6Lcbuaxtf89W/L/kyr6M MKPnadf2X+S/I/Nx2TqLNU809y5y/3zl5s8HSizFGYmGWsxFxYkATLqO7P8BAAA=
Subject: Re: [Simple] I-D Action: draft-ietf-simple-chat-17.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: Sat, 17 Nov 2012 16:30:37 -0000

Hi:

So, the long awaited version -17 of the MSRP chat draft has been posted. 
This version addresses all the comments received in the IESG review and 
various directorates that also took a look at the draft. Among others, 
these are the most relevant changes.

- Added definitions of "identifier" and "to log in".
- New Section 4.1 lists all the Policy Attributes of the chat room in a 
single section.
- Clarified that congestion can occur due to the chat room application or 
due to some other application.
- Clarified that the MSRP switch should learn the recipient's 
capabilities through the 'accept-wrapped-types' in SDP. Procedures as for 
what to do if the MSRP switch is aware that a recipient does not support 
a given media type.
- Quite a few clarifications around chunked messages. It was clarified 
when the MSRP switch has to delete the temporarily stored state. Also, 
how to deal with situations where the connection is broken before the 
reception of the last chunk.
- Added a length limit to MSRP nicknames: they must be between 1 and 1023 
octets, after UTF-8 encoding.
- Fixed a bug: the error result code is 425 rather than 423 in the examples.
- Added more security considerations around the usage of TLS, policies to 
preserve a nickname once the use logs off, confusable nicknames, 
rendering of nicknames that contain scripts or code, and anonymity when 
using TLS with certificates.

 From the authors' perspective, we believe the draft is ready. I will 
contact the IESG members to verify that the current version satisfies 
their comments.

/Miguel

On 17/11/2012 17:06, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.
>
> 	Title           : Multi-party Chat Using the Message Session Relay Protocol (MSRP)
> 	Author(s)       : Aki Niemi
>                            Miguel A. Garcia-Martin
>                            Geir A. Sandbakken
> 	Filename        : draft-ietf-simple-chat-17.txt
> 	Pages           : 42
> 	Date            : 2012-11-17
>
> Abstract:
>     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.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-simple-chat
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-simple-chat-17
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-simple-chat-17
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple
>
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From pkyzivat@alum.mit.edu  Mon Nov 19 08:10:27 2012
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 BD59D21F84EA for ; Mon, 19 Nov 2012 08:10:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.397
X-Spam-Level: 
X-Spam-Status: No, score=-0.397 tagged_above=-999 required=5 tests=[AWL=0.040,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJVLW36ibaCw for ; Mon, 19 Nov 2012 08:10:27 -0800 (PST)
Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id F15EF21F849F for ; Mon, 19 Nov 2012 08:10:26 -0800 (PST)
Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta07.westchester.pa.mail.comcast.net with comcast id RRGR1k0071HzFnQ57UASgw; Mon, 19 Nov 2012 16:10:26 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id RUAR1k01X3ZTu2S3aUASrP; Mon, 19 Nov 2012 16:10:26 +0000
Message-ID: <50AA59F0.5020103@alum.mit.edu>
Date: Mon, 19 Nov 2012 11:10:24 -0500
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: simple@ietf.org
References: <20121117160611.10411.74381.idtracker@ietfa.amsl.com> <50A7BBA9.7040904@ericsson.com>
In-Reply-To: <50A7BBA9.7040904@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Simple] I-D Action: draft-ietf-simple-chat-17.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: Mon, 19 Nov 2012 16:10:28 -0000

AFAICT, this draft has addressed all the concerns I previously raised.
In looking through it, I came across some small editorial issues:

Figure 1, near the bottom, has a dangling "|".

In section 4.1:

    Nicknames:   Whether the chat room accepts users to be recognized
       with a nickname.  See Section 7, Section 7.1, and Section 8 for
       details.  Also, the scope of uniqueness of the nickname: the chat
       room (conference instance), a real or domain, a server, etc.

Something is wrong in the last sentence - "a real" *what*?

Section 5.2: s/The chat room them uses/The chat room then uses/

Section 6.2: in the last paragraph, at the end, s/URI.m/URI./

	Thanks,
	Paul

On 11/17/12 11:30 AM, Miguel A. Garcia wrote:
> Hi:
>
> So, the long awaited version -17 of the MSRP chat draft has been posted.
> This version addresses all the comments received in the IESG review and
> various directorates that also took a look at the draft. Among others,
> these are the most relevant changes.
>
> - Added definitions of "identifier" and "to log in".
> - New Section 4.1 lists all the Policy Attributes of the chat room in a
> single section.
> - Clarified that congestion can occur due to the chat room application
> or due to some other application.
> - Clarified that the MSRP switch should learn the recipient's
> capabilities through the 'accept-wrapped-types' in SDP. Procedures as
> for what to do if the MSRP switch is aware that a recipient does not
> support a given media type.
> - Quite a few clarifications around chunked messages. It was clarified
> when the MSRP switch has to delete the temporarily stored state. Also,
> how to deal with situations where the connection is broken before the
> reception of the last chunk.
> - Added a length limit to MSRP nicknames: they must be between 1 and
> 1023 octets, after UTF-8 encoding.
> - Fixed a bug: the error result code is 425 rather than 423 in the
> examples.
> - Added more security considerations around the usage of TLS, policies
> to preserve a nickname once the use logs off, confusable nicknames,
> rendering of nicknames that contain scripts or code, and anonymity when
> using TLS with certificates.
>
>  From the authors' perspective, we believe the draft is ready. I will
> contact the IESG members to verify that the current version satisfies
> their comments.
>
> /Miguel
>
> On 17/11/2012 17:06, internet-drafts@ietf.org wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>   This draft is a work item of the SIP for Instant Messaging and
>> Presence Leveraging Extensions Working Group of the IETF.
>>
>>     Title           : Multi-party Chat Using the Message Session Relay
>> Protocol (MSRP)
>>     Author(s)       : Aki Niemi
>>                            Miguel A. Garcia-Martin
>>                            Geir A. Sandbakken
>>     Filename        : draft-ietf-simple-chat-17.txt
>>     Pages           : 42
>>     Date            : 2012-11-17
>>
>> Abstract:
>>     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.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-simple-chat
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-simple-chat-17
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-simple-chat-17
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> Simple mailing list
>> Simple@ietf.org
>> https://www.ietf.org/mailman/listinfo/simple
>>
>>
>


From ben@nostrum.com  Mon Nov 19 13:12:47 2012
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 C37C821F8750 for ; Mon, 19 Nov 2012 13:12:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.408
X-Spam-Level: 
X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgaroXGTzcca for ; Mon, 19 Nov 2012 13:12:47 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 48DEC21F8739 for ; Mon, 19 Nov 2012 13:12:45 -0800 (PST)
Received: from [10.12.11.26] ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qAJLCe4h079405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Nov 2012 15:12:40 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ben Campbell 
In-Reply-To: <50A7BBA9.7040904@ericsson.com>
Date: Mon, 19 Nov 2012 15:12:41 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <014CCF1E-A698-4351-9246-6CBBC8B37BAD@nostrum.com>
References: <20121117160611.10411.74381.idtracker@ietfa.amsl.com> <50A7BBA9.7040904@ericsson.com>
To: "Miguel A. Garcia" 
X-Mailer: Apple Mail (2.1499)
Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism)
Cc: simple@ietf.org
Subject: Re: [Simple] I-D Action: draft-ietf-simple-chat-17.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: Mon, 19 Nov 2012 21:12:47 -0000

Thanks Miguel. I think this version is much improved. But of course, =
here's a few questions and comments:

Questions:=20

5.2 : There is new normative language in section 5.2 concerning the use =
of "accept-types" and "accept-wrapped-types" Do I read it correctly that =
and endpoint SHOULD (i.e. RECOMMENDED) include accept-wrapped-types, and =
a focus MAY do so? Do we allow either to include anything _other_ than =
message/cpim in accept-types?  If not, what does it mean to include only =
message/CPIM in "accept-types" and not include "accept-wrapped-types"?

The last paragraph of 5.2 says that the focus must inform the switch of =
the chat room capabilities of each participant, and that it does this =
with the SDP "chatroom" attribute. Do we assume anything about how the =
focus and switch communicate? I thought the chatroom attribute was more =
about how the focus communicates this with _endpoints_.

6.1, paragraph starting with "Once the MSRP switch receives the last =
chunk..."

Should that really be a normative "MUST discard"? Seems like this is an =
implementation question more than a protocol question. Could we merely =
say "the MSRP switch discards..."?

Editorial:

6.1, 3rd paragraph: Seems like this paragraph is now redundant due to =
the additions in 5.2.

7.1, third paragraph: "... character may be result encoded in more than =
one
      octet"
do you mean ...: may be as a result encoded..."?

11, paragraph 5: I think the reader may be confused into thinking you =
mean force the SDP offer/answer to occur over TLS, rather than using the =
offer/answer to force the MSRP session to be over TLS.


On Nov 17, 2012, at 10:30 AM, Miguel A. Garcia =
 wrote:

> Hi:
>=20
> So, the long awaited version -17 of the MSRP chat draft has been =
posted. This version addresses all the comments received in the IESG =
review and various directorates that also took a look at the draft. =
Among others, these are the most relevant changes.
>=20
> - Added definitions of "identifier" and "to log in".
> - New Section 4.1 lists all the Policy Attributes of the chat room in =
a single section.
> - Clarified that congestion can occur due to the chat room application =
or due to some other application.
> - Clarified that the MSRP switch should learn the recipient's =
capabilities through the 'accept-wrapped-types' in SDP. Procedures as =
for what to do if the MSRP switch is aware that a recipient does not =
support a given media type.
> - Quite a few clarifications around chunked messages. It was clarified =
when the MSRP switch has to delete the temporarily stored state. Also, =
how to deal with situations where the connection is broken before the =
reception of the last chunk.
> - Added a length limit to MSRP nicknames: they must be between 1 and =
1023 octets, after UTF-8 encoding.
> - Fixed a bug: the error result code is 425 rather than 423 in the =
examples.
> - Added more security considerations around the usage of TLS, policies =
to preserve a nickname once the use logs off, confusable nicknames, =
rendering of nicknames that contain scripts or code, and anonymity when =
using TLS with certificates.
>=20
> =46rom the authors' perspective, we believe the draft is ready. I will =
contact the IESG members to verify that the current version satisfies =
their comments.
>=20
> /Miguel
>=20
> On 17/11/2012 17:06, internet-drafts@ietf.org wrote:
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>>  This draft is a work item of the SIP for Instant Messaging and =
Presence Leveraging Extensions Working Group of the IETF.
>>=20
>> 	Title           : Multi-party Chat Using the Message Session =
Relay Protocol (MSRP)
>> 	Author(s)       : Aki Niemi
>>                           Miguel A. Garcia-Martin
>>                           Geir A. Sandbakken
>> 	Filename        : draft-ietf-simple-chat-17.txt
>> 	Pages           : 42
>> 	Date            : 2012-11-17
>>=20
>> Abstract:
>>    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.
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-simple-chat
>>=20
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-simple-chat-17
>>=20
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-simple-chat-17
>>=20
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> Simple mailing list
>> Simple@ietf.org
>> https://www.ietf.org/mailman/listinfo/simple
>>=20
>>=20
>=20
> --=20
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple


From pkyzivat@alum.mit.edu  Mon Nov 19 14:34:47 2012
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 9B68121F8597 for ; Mon, 19 Nov 2012 14:34:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.399
X-Spam-Level: 
X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2bnrQ303Xa0 for ; Mon, 19 Nov 2012 14:34:47 -0800 (PST)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id F27BA21F858B for ; Mon, 19 Nov 2012 14:34:46 -0800 (PST)
Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta04.westchester.pa.mail.comcast.net with comcast id RaZn1k00517dt5G54aamWY; Mon, 19 Nov 2012 22:34:46 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id Raal1k00i3ZTu2S3ZaaljA; Mon, 19 Nov 2012 22:34:46 +0000
Message-ID: <50AAB403.8090509@alum.mit.edu>
Date: Mon, 19 Nov 2012 17:34:43 -0500
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: simple@ietf.org
References: <20121117160611.10411.74381.idtracker@ietfa.amsl.com> <50A7BBA9.7040904@ericsson.com> <014CCF1E-A698-4351-9246-6CBBC8B37BAD@nostrum.com>
In-Reply-To: <014CCF1E-A698-4351-9246-6CBBC8B37BAD@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Simple] I-D Action: draft-ietf-simple-chat-17.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: Mon, 19 Nov 2012 22:34:47 -0000

On 11/19/12 4:12 PM, Ben Campbell wrote:
> Thanks Miguel. I think this version is much improved. But of course, here's a few questions and comments:
>
> Questions:
>
> 5.2 : There is new normative language in section 5.2 concerning the use of "accept-types" and "accept-wrapped-types" Do I read it correctly that and endpoint SHOULD (i.e. RECOMMENDED) include accept-wrapped-types, and a focus MAY do so? Do we allow either to include anything _other_ than message/cpim in accept-types?  If not, what does it mean to include only message/CPIM in "accept-types" and not include "accept-wrapped-types"?
>
> The last paragraph of 5.2 says that the focus must inform the switch of the chat room capabilities of each participant, and that it does this with the SDP "chatroom" attribute. Do we assume anything about how the focus and switch communicate? I thought the chatroom attribute was more about how the focus communicates this with _endpoints_.

This was in response to comments I made some time ago.
The point was to future-proof this, so that if in the future there is a 
new type (say message/cpim++) that something that implements that will 
be able to indicate support for both message/cpim and message/cpim++ and 
still be conforming to this spec.

(Of course, if both ends then support message/cpim++ and decide to use 
it, then they will cease to be operating in accord with this spec. 
Instead they will be following some new spec that calls for use of 
message/cpim++.)

	Thanks,
	Paul

From miguel.a.garcia@ericsson.com  Tue Nov 20 00:48:58 2012
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 0F12221F86EC for ; Tue, 20 Nov 2012 00:48:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmSbYXXjVbjD for ; Tue, 20 Nov 2012 00:48:57 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8A19121F86E5 for ; Tue, 20 Nov 2012 00:48:56 -0800 (PST)
X-AuditID: c1b4fb25-b7f926d00000661f-da-50ab43f61153
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0E.AB.26143.6F34BA05; Tue, 20 Nov 2012 09:48:54 +0100 (CET)
Received: from [159.107.24.207] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Tue, 20 Nov 2012 09:48:53 +0100
Message-ID: <50AB43F5.9020803@ericsson.com>
Date: Tue, 20 Nov 2012 09:48:53 +0100
From: "Miguel A. Garcia" 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Ben Campbell 
References: <20121117160611.10411.74381.idtracker@ietfa.amsl.com> <50A7BBA9.7040904@ericsson.com> <014CCF1E-A698-4351-9246-6CBBC8B37BAD@nostrum.com>
In-Reply-To: <014CCF1E-A698-4351-9246-6CBBC8B37BAD@nostrum.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZGfG3Rveb8+oAgyOLlSzmd55mt1g48R+r A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJXRsegta8Eky4quddNZGxjb9LoYOTkkBEwk Fl+cygxhi0lcuLeerYuRi0NI4CSjxObeW4wQzhpGiaVHpjCBVPEKaEs8/DeVEcRmEVCVmLqh C6ybTcBconXjRvYuRg4OUYFgiTnX+CHKBSVOznzCAmKLCChJPG/eygJSwiwgLPG81wEkLCxg L3H82xImiFVTGCU+TJnDCFLDCZT4+90CpIZZwFbiwpzrLBC2vMT2t3PAtgoJaEpMvrmUeQKj 4Cwk22YhaZmFpGUBI/MqRvbcxMyc9HKjTYzAgDy45bfqDsY750QOMUpzsCiJ81pv3eMvJJCe WJKanZpakFoUX1Sak1p8iJGJg1OqgdFQutQn4J732ska/25PO6nP+4U/UMX3msrR6J8loWdn 5LaGtfJk/DdasLUyUOjqL+1G5fWvXTZNV53bcVUv1lPxV33V//9NuRe0d62P7Hp2QP3Hvcd9 k5NDiie9er5S4GRDIuOV45I35oV8L86M2i7efbP6ZsUrLkPT43LRB50/GgT7z5tVmqTEUpyR aKjFXFScCABQeZ21FgIAAA==
Cc: simple@ietf.org
Subject: Re: [Simple] I-D Action: draft-ietf-simple-chat-17.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: Tue, 20 Nov 2012 08:48:58 -0000

Hi Ben,

thanks for your comments. See inline answers.

On 19/11/2012 22:12, Ben Campbell wrote:
> Thanks Miguel. I think this version is much improved. But of course,
> here's a few questions and comments:
>
> Questions:
>
> 5.2 : There is new normative language in section 5.2 concerning the
> use of "accept-types" and "accept-wrapped-types" Do I read it
> correctly that and endpoint SHOULD (i.e. RECOMMENDED) include
> accept-wrapped-types, and a focus MAY do so?

Yeap, it is recommended, though optional. The reason is that the UE can 
(and will most likely) add a start "*" to indicate that it supports 
additional formats not explicitly signaled. So, if most endpoints add a 
start "*", then it is not clear what is the benefit of it.

Remember that MSRP mandates accept-types and leaves accept-wrapped-types 
as optional.

 > Do we allow either to
> include anything _other_ than message/cpim in accept-types?

Yes, we do. Bear in mind that and endpoint establishing a session will 
create SDP according to what it supports, before knowing that the session 
will end up in a chat server. So, we cannot mandate that the endpoint 
populates ONLY those values that are required by the server. We can 
mandate (and this is the spirit of the draft) that endpoints include at 
least those values required by the server, but we don't expect those 
values to be alone.

So, to answer your question, yes, it is allowed to have something else 
than message/cpim in the SDP offer, but that will not be used by this draft.


> If not,
> what does it mean to include only message/CPIM in "accept-types" and
> not include "accept-wrapped-types"?

It means that the endpoint can receive message/CPIM bodies, as required 
by this draft, but we don't know which kind of wrapped type the endpoint 
supports. Therefore, the MSRP server will not screen supported media 
types, and will blindly send all the content to the endpoint, 
independently of its media type.

>
> The last paragraph of 5.2 says that the focus must inform the switch
> of the chat room capabilities of each participant, and that it does
> this with the SDP "chatroom" attribute. Do we assume anything about
> how the focus and switch communicate? I thought the chatroom attribute
> was more about how the focus communicates this with _endpoints_.

The communication between the focus (SIP UA) and the MSRP switch is 
outside the scope of the document. I suspect most implementations 
implement a single function offering both focus and MSRP switch, in which 
case standardization is not required. I mean, this is an internal interface.

>
> 6.1, paragraph starting with "Once the MSRP switch receives the last
> chunk..."
>
> Should that really be a normative "MUST discard"? Seems like this is
> an implementation question more than a protocol question. Could we
> merely say "the MSRP switch discards..."?

Sounds good to me.

>
> Editorial:
>
> 6.1, 3rd paragraph: Seems like this paragraph is now redundant due to
> the additions in 5.2.

Fair enough. In Section 5.2 I have added a reminder of the mandatory 
nature of the accept-types, and have deleted that redundant paragraph in 
Section 6.1

>
> 7.1, third paragraph: "... character may be result encoded in more
> than one octet" do you mean ...: may be as a result encoded..."?

I meant "may result encoded". Fixed, thanks.

>
> 11, paragraph 5: I think the reader may be confused into thinking you
> mean force the SDP offer/answer to occur over TLS, rather than using
> the offer/answer to force the MSRP session to be over TLS.

True. I am clarifying the text.

Thanks,

      Miguel
>
>
> On Nov 17, 2012, at 10:30 AM, Miguel A. Garcia
>  wrote:
>
>> Hi:
>>
>> So, the long awaited version -17 of the MSRP chat draft has been
>> posted. This version addresses all the comments received in the IESG
>> review and various directorates that also took a look at the draft.
>> Among others, these are the most relevant changes.
>>
>> - Added definitions of "identifier" and "to log in". - New Section
>> 4.1 lists all the Policy Attributes of the chat room in a single
>> section. - Clarified that congestion can occur due to the chat room
>> application or due to some other application. - Clarified that the
>> MSRP switch should learn the recipient's capabilities through the
>> 'accept-wrapped-types' in SDP. Procedures as for what to do if the
>> MSRP switch is aware that a recipient does not support a given media
>> type. - Quite a few clarifications around chunked messages. It was
>> clarified when the MSRP switch has to delete the temporarily stored
>> state. Also, how to deal with situations where the connection is
>> broken before the reception of the last chunk. - Added a length
>> limit to MSRP nicknames: they must be between 1 and 1023 octets,
>> after UTF-8 encoding. - Fixed a bug: the error result code is 425
>> rather than 423 in the examples. - Added more security
>> considerations around the usage of TLS, policies to preserve a
>> nickname once the use logs off, confusable nicknames, rendering of
>> nicknames that contain scripts or code, and anonymity when using TLS
>> with certificates.
>>
>> From the authors' perspective, we believe the draft is ready. I will
>> contact the IESG members to verify that the current version
>> satisfies their comments.
>>
>> /Miguel
>>
>> On 17/11/2012 17:06, internet-drafts@ietf.org wrote:
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories. This draft is a work item of the SIP for Instant
>>> Messaging and Presence Leveraging Extensions Working Group of the
>>> IETF.
>>>
>>> Title           : Multi-party Chat Using the Message Session Relay
>>> Protocol (MSRP) Author(s)       : Aki Niemi Miguel A.
>>> Garcia-Martin Geir A. Sandbakken Filename        :
>>> draft-ietf-simple-chat-17.txt Pages           : 42 Date
>>> : 2012-11-17
>>>
>>> Abstract: 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.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-simple-chat
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-simple-chat-17
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-simple-chat-17
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________ Simple mailing
>>> list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple
>>>
>>>
>>
>> -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain
>> _______________________________________________ Simple mailing list
>> Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From miguel.a.garcia@ericsson.com  Tue Nov 20 03:24:06 2012
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 2E46221F8674 for ; Tue, 20 Nov 2012 03:24:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcTT4QyaloI5 for ; Tue, 20 Nov 2012 03:24:02 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4524C21F8687 for ; Tue, 20 Nov 2012 03:24:00 -0800 (PST)
X-AuditID: c1b4fb25-b7f926d00000661f-ee-50ab684ec0b4
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 6F.66.26143.E486BA05; Tue, 20 Nov 2012 12:23:59 +0100 (CET)
Received: from [159.107.24.207] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Tue, 20 Nov 2012 12:23:57 +0100
Message-ID: <50AB684D.3020504@ericsson.com>
Date: Tue, 20 Nov 2012 12:23:57 +0100
From: "Miguel A. Garcia" 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Paul Kyzivat 
References: <20121117160611.10411.74381.idtracker@ietfa.amsl.com> <50A7BBA9.7040904@ericsson.com> <50AA59F0.5020103@alum.mit.edu>
In-Reply-To: <50AA59F0.5020103@alum.mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgluLIzCtJLcpLzFFi42KZGfG3Rtc/Y3WAwdW7PBYrNhxgtVg48R+r A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXR8jSloEGl4ueOr6wNjK0yXYycHBICJhKt PZ/ZIWwxiQv31rN1MXJxCAmcZJSYsfsfE4SzhlHi4OR9rF2MHBy8AtoSd34ngpgsAqoSKxdo gvSyCZhLtG7cyA4SFhUIlphzjR8kzCsgKHFy5hMWkLCIgIbEpK1qICazgLDE814HkAphAXuJ 49+WQO1pZJS486+BESTBKaAj8ejkeyYQm1nAVuLCnOssELa8xPa3c5hBbCEBTYnJN5cyT2AU nIVk2ywkLbOQtCxgZF7FyJ6bmJmTXm60iREYige3/FbdwXjnnMghRmkOFiVxXuute/yFBNIT S1KzU1MLUovii0pzUosPMTJxcEo1MBqvs1bJE7s2R9pXqinDvODJdpuLpi1Cn5kPvfjIbPWi KHFbRLPI57AjkgpdDaUrVh3aOUnavWlT2b5IndppbsEpPzKim78fLX8T5xGSkH8wcqbCQsMV iumTvKfUnPA/aZZ19uORM05fvhTez7/Ber5vj/aH+Zvu+i+ad+Gk6N27yf3TlRxZGpRYijMS DbWYi4oTASPoaZETAgAA
Cc: simple@ietf.org
Subject: Re: [Simple] I-D Action: draft-ietf-simple-chat-17.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: Tue, 20 Nov 2012 11:24:06 -0000

Hi Paul,

Thanks for your comments. See inline answers.

On 19/11/2012 17:10, Paul Kyzivat wrote:
> AFAICT, this draft has addressed all the concerns I previously raised.
> In looking through it, I came across some small editorial issues:
>
> Figure 1, near the bottom, has a dangling "|".
>

fixed.

> In section 4.1:
>
>     Nicknames:   Whether the chat room accepts users to be recognized
>        with a nickname.  See Section 7, Section 7.1, and Section 8 for
>        details.  Also, the scope of uniqueness of the nickname: the chat
>        room (conference instance), a real or domain, a server, etc.
>
> Something is wrong in the last sentence - "a real" *what*?

It should say "a realm or domain".

>
> Section 5.2: s/The chat room them uses/The chat room then uses/

fixed.

>
> Section 6.2: in the last paragraph, at the end, s/URI.m/URI./

Fixed.

/Miguel


>
>      Thanks,
>      Paul
>
> On 11/17/12 11:30 AM, Miguel A. Garcia wrote:
>> Hi:
>>
>> So, the long awaited version -17 of the MSRP chat draft has been posted.
>> This version addresses all the comments received in the IESG review and
>> various directorates that also took a look at the draft. Among others,
>> these are the most relevant changes.
>>
>> - Added definitions of "identifier" and "to log in".
>> - New Section 4.1 lists all the Policy Attributes of the chat room in a
>> single section.
>> - Clarified that congestion can occur due to the chat room application
>> or due to some other application.
>> - Clarified that the MSRP switch should learn the recipient's
>> capabilities through the 'accept-wrapped-types' in SDP. Procedures as
>> for what to do if the MSRP switch is aware that a recipient does not
>> support a given media type.
>> - Quite a few clarifications around chunked messages. It was clarified
>> when the MSRP switch has to delete the temporarily stored state. Also,
>> how to deal with situations where the connection is broken before the
>> reception of the last chunk.
>> - Added a length limit to MSRP nicknames: they must be between 1 and
>> 1023 octets, after UTF-8 encoding.
>> - Fixed a bug: the error result code is 425 rather than 423 in the
>> examples.
>> - Added more security considerations around the usage of TLS, policies
>> to preserve a nickname once the use logs off, confusable nicknames,
>> rendering of nicknames that contain scripts or code, and anonymity when
>> using TLS with certificates.
>>
>>  From the authors' perspective, we believe the draft is ready. I will
>> contact the IESG members to verify that the current version satisfies
>> their comments.
>>
>> /Miguel
>>
>> On 17/11/2012 17:06, internet-drafts@ietf.org wrote:
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>   This draft is a work item of the SIP for Instant Messaging and
>>> Presence Leveraging Extensions Working Group of the IETF.
>>>
>>>     Title           : Multi-party Chat Using the Message Session Relay
>>> Protocol (MSRP)
>>>     Author(s)       : Aki Niemi
>>>                            Miguel A. Garcia-Martin
>>>                            Geir A. Sandbakken
>>>     Filename        : draft-ietf-simple-chat-17.txt
>>>     Pages           : 42
>>>     Date            : 2012-11-17
>>>
>>> Abstract:
>>>     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.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-simple-chat
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-simple-chat-17
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-simple-chat-17
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> Simple mailing list
>>> Simple@ietf.org
>>> https://www.ietf.org/mailman/listinfo/simple
>>>
>>>
>>
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From ben@nostrum.com  Tue Nov 20 07:08:29 2012
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 446D621F8756 for ; Tue, 20 Nov 2012 07:08:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.458
X-Spam-Level: 
X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Czff5F-TbR3r for ; Tue, 20 Nov 2012 07:08:28 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 36E9521F874F for ; Tue, 20 Nov 2012 07:08:28 -0800 (PST)
Received: from [10.0.1.9] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qAKF8OGX084816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Nov 2012 09:08:24 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ben Campbell 
In-Reply-To: <50AB43F5.9020803@ericsson.com>
Date: Tue, 20 Nov 2012 09:08:24 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <506702ED-8447-4BBF-B0C6-1AD2AD73A244@nostrum.com>
References: <20121117160611.10411.74381.idtracker@ietfa.amsl.com> <50A7BBA9.7040904@ericsson.com> <014CCF1E-A698-4351-9246-6CBBC8B37BAD@nostrum.com> <50AB43F5.9020803@ericsson.com>
To: "Miguel A. Garcia" 
X-Mailer: Apple Mail (2.1499)
Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: simple@ietf.org
Subject: Re: [Simple] I-D Action: draft-ietf-simple-chat-17.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: Tue, 20 Nov 2012 15:08:29 -0000

On Nov 20, 2012, at 2:48 AM, "Miguel A. Garcia" =
 wrote:

> Hi Ben,
>=20
> thanks for your comments. See inline answers.
>=20
> On 19/11/2012 22:12, Ben Campbell wrote:
>> Thanks Miguel. I think this version is much improved. But of course,
>> here's a few questions and comments:
>>=20
>> Questions:
>>=20
>> 5.2 : There is new normative language in section 5.2 concerning the
>> use of "accept-types" and "accept-wrapped-types" Do I read it
>> correctly that and endpoint SHOULD (i.e. RECOMMENDED) include
>> accept-wrapped-types, and a focus MAY do so?
>=20
> Yeap, it is recommended, though optional. The reason is that the UE =
can (and will most likely) add a start "*" to indicate that it supports =
additional formats not explicitly signaled. So, if most endpoints add a =
start "*", then it is not clear what is the benefit of it.
>=20
> Remember that MSRP mandates accept-types and leaves =
accept-wrapped-types as optional.

It's optional because you don't always need to enforce a wrapper, in =
which case you could just used accept-types. As  you say, there is no =
default. I don't recall 4975 stating a behavior for having only a =
wrapper type in accept-types and no accept-wrapped-types value. I don't =
think we can expect interoperable behavior.


>=20
> > Do we allow either to
>> include anything _other_ than message/cpim in accept-types?
>=20
> Yes, we do. Bear in mind that and endpoint establishing a session will =
create SDP according to what it supports, before knowing that the =
session will end up in a chat server. So, we cannot mandate that the =
endpoint populates ONLY those values that are required by the server. We =
can mandate (and this is the spirit of the draft) that endpoints include =
at least those values required by the server, but we don't expect those =
values to be alone.
>=20
> So, to answer your question, yes, it is allowed to have something else =
than message/cpim in the SDP offer, but that will not be used by this =
draft.

Okay.

>=20
>=20
>> If not,
>> what does it mean to include only message/CPIM in "accept-types" and
>> not include "accept-wrapped-types"?
>=20
> It means that the endpoint can receive message/CPIM bodies, as =
required by this draft, but we don't know which kind of wrapped type the =
endpoint supports. Therefore, the MSRP server will not screen supported =
media types, and will blindly send all the content to the endpoint, =
independently of its media type.

Again, I'm not sure how the endpoint will interpret that. (Maybe the =
switch only accepts empty message/cpim docs?). If the switch wants to =
accept anything, but only in a message/cpim wrapper, it should include =
an accept-wrapped-types with a "*".

>=20
>>=20
>> The last paragraph of 5.2 says that the focus must inform the switch
>> of the chat room capabilities of each participant, and that it does
>> this with the SDP "chatroom" attribute. Do we assume anything about
>> how the focus and switch communicate? I thought the chatroom =
attribute
>> was more about how the focus communicates this with _endpoints_.
>=20
> The communication between the focus (SIP UA) and the MSRP switch is =
outside the scope of the document. I suspect most implementations =
implement a single function offering both focus and MSRP switch, in =
which case standardization is not required. I mean, this is an internal =
interface.

I agree. But the text appears to say that it uses the SDP chatroom =
attribute to do so. Is that the intent?

[...]

>>=20
>> Editorial:
>>=20
>> 6.1, 3rd paragraph: Seems like this paragraph is now redundant due to
>> the additions in 5.2.
>=20
> Fair enough. In Section 5.2 I have added a reminder of the mandatory =
nature of the accept-types, and have deleted that redundant paragraph in =
Section 6.1
>=20
>>=20
>> 7.1, third paragraph: "... character may be result encoded in more
>> than one octet" do you mean ...: may be as a result encoded..."?
>=20
> I meant "may result encoded". Fixed, thanks.

I'm still not clear on what "may result encoded" means. Do you mean "may =
result in encoding..."?  (Or is result-encoded  a term of art I've =
missed?)

>=20
>>=20
>> 11, paragraph 5: I think the reader may be confused into thinking you
>> mean force the SDP offer/answer to occur over TLS, rather than using
>> the offer/answer to force the MSRP session to be over TLS.
>=20
> True. I am clarifying the text.
>=20
> Thanks,
>=20
>     Miguel
>>=20
>>=20
>> On Nov 17, 2012, at 10:30 AM, Miguel A. Garcia
>>  wrote:
>>=20
>>> Hi:
>>>=20
>>> So, the long awaited version -17 of the MSRP chat draft has been
>>> posted. This version addresses all the comments received in the IESG
>>> review and various directorates that also took a look at the draft.
>>> Among others, these are the most relevant changes.
>>>=20
>>> - Added definitions of "identifier" and "to log in". - New Section
>>> 4.1 lists all the Policy Attributes of the chat room in a single
>>> section. - Clarified that congestion can occur due to the chat room
>>> application or due to some other application. - Clarified that the
>>> MSRP switch should learn the recipient's capabilities through the
>>> 'accept-wrapped-types' in SDP. Procedures as for what to do if the
>>> MSRP switch is aware that a recipient does not support a given media
>>> type. - Quite a few clarifications around chunked messages. It was
>>> clarified when the MSRP switch has to delete the temporarily stored
>>> state. Also, how to deal with situations where the connection is
>>> broken before the reception of the last chunk. - Added a length
>>> limit to MSRP nicknames: they must be between 1 and 1023 octets,
>>> after UTF-8 encoding. - Fixed a bug: the error result code is 425
>>> rather than 423 in the examples. - Added more security
>>> considerations around the usage of TLS, policies to preserve a
>>> nickname once the use logs off, confusable nicknames, rendering of
>>> nicknames that contain scripts or code, and anonymity when using TLS
>>> with certificates.
>>>=20
>>> =46rom the authors' perspective, we believe the draft is ready. I =
will
>>> contact the IESG members to verify that the current version
>>> satisfies their comments.
>>>=20
>>> /Miguel
>>>=20
>>> On 17/11/2012 17:06, internet-drafts@ietf.org wrote:
>>>>=20
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories. This draft is a work item of the SIP for Instant
>>>> Messaging and Presence Leveraging Extensions Working Group of the
>>>> IETF.
>>>>=20
>>>> Title           : Multi-party Chat Using the Message Session Relay
>>>> Protocol (MSRP) Author(s)       : Aki Niemi Miguel A.
>>>> Garcia-Martin Geir A. Sandbakken Filename        :
>>>> draft-ietf-simple-chat-17.txt Pages           : 42 Date
>>>> : 2012-11-17
>>>>=20
>>>> Abstract: 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.
>>>>=20
>>>>=20
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-simple-chat
>>>>=20
>>>> There's also a htmlized version available at:
>>>> http://tools.ietf.org/html/draft-ietf-simple-chat-17
>>>>=20
>>>> A diff from the previous version is available at:
>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-simple-chat-17
>>>>=20
>>>>=20
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>=20
>>>> _______________________________________________ Simple mailing
>>>> list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple
>>>>=20
>>>>=20
>>>=20
>>> -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain
>>> _______________________________________________ Simple mailing list
>>> Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple
>>=20
>=20
> --=20
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain


From ben@nostrum.com  Tue Nov 20 15:40:09 2012
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 ABC3B21F84EB for ; Tue, 20 Nov 2012 15:40:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.466
X-Spam-Level: 
X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75feOQYynJ0i for ; Tue, 20 Nov 2012 15:40:09 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D261121F8446 for ; Tue, 20 Nov 2012 15:40:08 -0800 (PST)
Received: from [10.0.1.9] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qAKNe6NT035147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Nov 2012 17:40:07 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ben Campbell 
Date: Tue, 20 Nov 2012 17:40:05 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <7A18470F-054F-4827-83E5-ACB46D09B81D@nostrum.com>
References: <50A7BBA9.7040904@ericsson.com>
To: Simple WG 
X-Mailer: Apple Mail (2.1499)
Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Subject: [Simple] Fwd:  I-D Action: draft-ietf-simple-chat-17.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: Tue, 20 Nov 2012 23:40:09 -0000

(As Chair)

This version incorporates some non-trivial changes as a result of the =
IESG review. There's some new normative language. I think it is likely =
that there will be one or two more revisions, but I expect them to be =
pretty minor. That is, I expect the version that the ADs actually =
approves will be substantially similar to this one.

Please take a look, and verify that the changes do not introduce any new =
problems. If you have objections please send them to the authors and the =
list ASAP. I don't plan to call yet another formal WGLC at this point; =
so if there are no objections the draft will progress when it gets AD =
approval.

Thanks!

Ben.

Begin forwarded message:

> From: "Miguel A. Garcia" 
> Subject: Re: [Simple] I-D Action: draft-ietf-simple-chat-17.txt
> Date: November 17, 2012 10:30:33 AM CST
> To: simple@ietf.org
>=20
> Hi:
>=20
> So, the long awaited version -17 of the MSRP chat draft has been =
posted. This version addresses all the comments received in the IESG =
review and various directorates that also took a look at the draft. =
Among others, these are the most relevant changes.
>=20
> - Added definitions of "identifier" and "to log in".
> - New Section 4.1 lists all the Policy Attributes of the chat room in =
a single section.
> - Clarified that congestion can occur due to the chat room application =
or due to some other application.
> - Clarified that the MSRP switch should learn the recipient's =
capabilities through the 'accept-wrapped-types' in SDP. Procedures as =
for what to do if the MSRP switch is aware that a recipient does not =
support a given media type.
> - Quite a few clarifications around chunked messages. It was clarified =
when the MSRP switch has to delete the temporarily stored state. Also, =
how to deal with situations where the connection is broken before the =
reception of the last chunk.
> - Added a length limit to MSRP nicknames: they must be between 1 and =
1023 octets, after UTF-8 encoding.
> - Fixed a bug: the error result code is 425 rather than 423 in the =
examples.
> - Added more security considerations around the usage of TLS, policies =
to preserve a nickname once the use logs off, confusable nicknames, =
rendering of nicknames that contain scripts or code, and anonymity when =
using TLS with certificates.
>=20
> =46rom the authors' perspective, we believe the draft is ready. I will =
contact the IESG members to verify that the current version satisfies =
their comments.
>=20
> /Miguel
>=20
> On 17/11/2012 17:06, internet-drafts@ietf.org wrote:
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>>  This draft is a work item of the SIP for Instant Messaging and =
Presence Leveraging Extensions Working Group of the IETF.
>>=20
>> 	Title           : Multi-party Chat Using the Message Session =
Relay Protocol (MSRP)
>> 	Author(s)       : Aki Niemi
>>                           Miguel A. Garcia-Martin
>>                           Geir A. Sandbakken
>> 	Filename        : draft-ietf-simple-chat-17.txt
>> 	Pages           : 42
>> 	Date            : 2012-11-17
>>=20
>> Abstract:
>>    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.
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-simple-chat
>>=20
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-simple-chat-17
>>=20
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-simple-chat-17
>>=20
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> Simple mailing list
>> Simple@ietf.org
>> https://www.ietf.org/mailman/listinfo/simple
>>=20
>>=20
>=20
> --=20
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple


From miguel.a.garcia@ericsson.com  Wed Nov 21 02:31:56 2012
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 702B621F85E0 for ; Wed, 21 Nov 2012 02:31:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kT7zqdWmGNQ3 for ; Wed, 21 Nov 2012 02:31:55 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id F3EE621F85DF for ; Wed, 21 Nov 2012 02:31:54 -0800 (PST)
X-AuditID: c1b4fb30-b7f936d0000018b3-26-50acad99be03
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id BF.35.06323.99DACA05; Wed, 21 Nov 2012 11:31:53 +0100 (CET)
Received: from [159.107.24.205] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Wed, 21 Nov 2012 11:31:53 +0100
Message-ID: <50ACAD98.1040008@ericsson.com>
Date: Wed, 21 Nov 2012 11:31:52 +0100
From: "Miguel A. Garcia" 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Ben Campbell 
References: <20121117160611.10411.74381.idtracker@ietfa.amsl.com> <50A7BBA9.7040904@ericsson.com> <014CCF1E-A698-4351-9246-6CBBC8B37BAD@nostrum.com> <50AB43F5.9020803@ericsson.com> <506702ED-8447-4BBF-B0C6-1AD2AD73A244@nostrum.com>
In-Reply-To: <506702ED-8447-4BBF-B0C6-1AD2AD73A244@nostrum.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3Rnfm2jUBBj2HTC3md55mt1g48R+r A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJXx4lIrY8E5xYppp7eyNTDekepi5OSQEDCR WHVuNwuELSZx4d56NhBbSOAko8TN+wpdjFxA9hpGidMLpoAV8QpoSzTOagErYhFQlVjVf4kR xGYTMJdo3biRHcQWFfCVmHL8HztEvaDEyZlPwHpFBJQknjdvBbI5OJgFhCWe9zqAhIUF7CWO f1vCBLHrOaPE5G87wOo5gRIL9nWDzWcWsJW4MOc6C4QtL7H97RxmiEM1JSbfXMo8gVFwFpJ1 s5C0zELSsoCReRUje25iZk56ufkmRmBIHtzy22AH46b7YocYpTlYlMR59VT3+wsJpCeWpGan phakFsUXleakFh9iZOLglGpg3Gcq5KR3wGxP3NkQ7XXtPO0OfJFvunSnTp3z0pNnpsn1jpQb x/beVul12JBtceZWzs1Cu8kPzwgdtF2XyCJU4F3x9Gbs0h3/mDIWTxfoUHtsksp7/Pxx9c69 dq5hv2xXrJJkSRDxyqtw2ib4+e23ldeer5MxYY87n2vmV1G1nKdbIf1PhdlpJZbijERDLeai 4kQAW7X3DxcCAAA=
Cc: simple@ietf.org
Subject: Re: [Simple] I-D Action: draft-ietf-simple-chat-17.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: Wed, 21 Nov 2012 10:31:56 -0000

Hi Ben.

See further discussion below.

On 20/11/2012 16:08, Ben Campbell wrote:
>
> On Nov 20, 2012, at 2:48 AM, "Miguel A. Garcia"
>  wrote:
>
>> Hi Ben,
>>
>> thanks for your comments. See inline answers.
>>
>> On 19/11/2012 22:12, Ben Campbell wrote:
>>> Thanks Miguel. I think this version is much improved. But of
>>> course, here's a few questions and comments:
>>>
>>> Questions:
>>>
[snip]
>
>>
>>
>>> If not, what does it mean to include only message/CPIM in
>>> "accept-types" and not include "accept-wrapped-types"?
>>
>> It means that the endpoint can receive message/CPIM bodies, as
>> required by this draft, but we don't know which kind of wrapped type
>> the endpoint supports. Therefore, the MSRP server will not screen
>> supported media types, and will blindly send all the content to the
>> endpoint, independently of its media type.
>
> Again, I'm not sure how the endpoint will interpret that. (Maybe the
> switch only accepts empty message/cpim docs?). If the switch wants to
> accept anything, but only in a message/cpim wrapper, it should include
> an accept-wrapped-types with a "*".

Let's back up a bit an analyze the scenarios. We have two scenarios:

a) The endpoint declare all its supported media types in the 
accept-wrapped-types attribute in SDP. The MSRP switch will screen those 
types, and if the MSRP receives a wrapped media type that this endpoint 
does not support, it won't forward that e-mail to the endpoint.

b) The endpoint declares a few of the supported media types, but not all, 
because it adds an asterisk '*' to the accept-wrapped-types attribute in 
SDP. Or, alternatively, the endpoint does not declare any supported media 
types (there is no accept-wrapped-types at all in SDP). In this case, the 
MSRP switch will not screen the wrapped types in received messages, and 
will forward all of them to the endpoint. Therefore, the endpoint may 
receive some media types that is not able to render. This is the same 
scenario we may have with web browsers today. Some implementations will 
incorrectly render it in binary, others will point to a plug-in download, 
etc.

I don't know what else should we do from the standards point of view, 
besides what MSRP mandates and does not mandate.

>
>>
>>>
>>> The last paragraph of 5.2 says that the focus must inform the
>>> switch of the chat room capabilities of each participant, and that
>>> it does this with the SDP "chatroom" attribute. Do we assume
>>> anything about how the focus and switch communicate? I thought the
>>> chatroom attribute was more about how the focus communicates this
>>> with _endpoints_.
>>
>> The communication between the focus (SIP UA) and the MSRP switch is
>> outside the scope of the document. I suspect most implementations
>> implement a single function offering both focus and MSRP switch, in
>> which case standardization is not required. I mean, this is an
>> internal interface.
>
> I agree. But the text appears to say that it uses the SDP chatroom
> attribute to do so. Is that the intent?
>


No, that is not the intent. I will revise this paragraph to clarify that 
this interface is not SDP.

>
>>>
>>> Editorial:
>>>
>>> 6.1, 3rd paragraph: Seems like this paragraph is now redundant due
>>> to the additions in 5.2.
>>
>> Fair enough. In Section 5.2 I have added a reminder of the mandatory
>> nature of the accept-types, and have deleted that redundant
>> paragraph in Section 6.1
>>
>>>
>>> 7.1, third paragraph: "... character may be result encoded in
>>> more than one octet" do you mean ...: may be as a result
>>> encoded..."?
>>
>> I meant "may result encoded". Fixed, thanks.
>
> I'm still not clear on what "may result encoded" means. Do you mean
> "may result in encoding..."?  (Or is result-encoded  a term of art
> I've missed?)

Here I am using the term "result" as a verb, not as a noun. The 
definition of "result" in the Merriam-Webster dictionary is:

result: to proceed or arise as a consequence, effect, or conclusion. 
Example: 

So, I believe "may result encoded" is correct, isn't it?


/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From ben@nostrum.com  Wed Nov 21 14:26:42 2012
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 BB08C21F84B5 for ; Wed, 21 Nov 2012 14:26:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.473
X-Spam-Level: 
X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPRdpvZaWQas for ; Wed, 21 Nov 2012 14:26:42 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 232B121F849A for ; Wed, 21 Nov 2012 14:26:38 -0800 (PST)
Received: from [10.0.1.9] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qALMQYNb072798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Nov 2012 16:26:34 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ben Campbell 
In-Reply-To: <50ACAD98.1040008@ericsson.com>
Date: Wed, 21 Nov 2012 16:26:33 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20121117160611.10411.74381.idtracker@ietfa.amsl.com> <50A7BBA9.7040904@ericsson.com> <014CCF1E-A698-4351-9246-6CBBC8B37BAD@nostrum.com> <50AB43F5.9020803@ericsson.com> <506702ED-8447-4BBF-B0C6-1AD2AD73A244@nostrum.com> <50ACAD98.1040008@ericsson.com>
To: "Miguel A. Garcia" 
X-Mailer: Apple Mail (2.1499)
Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: simple@ietf.org
Subject: Re: [Simple] I-D Action: draft-ietf-simple-chat-17.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: Wed, 21 Nov 2012 22:26:42 -0000

Hi Miguel, see inline. Also, be advised I leave on holiday tomorrow, =
through 3 Dec, so I might be laggy on email during the next several =
days.

On Nov 21, 2012, at 4:31 AM, Miguel A. Garcia =
 wrote:

[...]

> [
>>=20
>>>> If not, what does it mean to include only message/CPIM in
>>>> "accept-types" and not include "accept-wrapped-types"?
>>>=20
>>> It means that the endpoint can receive message/CPIM bodies, as
>>> required by this draft, but we don't know which kind of wrapped type
>>> the endpoint supports. Therefore, the MSRP server will not screen
>>> supported media types, and will blindly send all the content to the
>>> endpoint, independently of its media type.
>>=20
>> Again, I'm not sure how the endpoint will interpret that. (Maybe the
>> switch only accepts empty message/cpim docs?). If the switch wants to
>> accept anything, but only in a message/cpim wrapper, it should =
include
>> an accept-wrapped-types with a "*".
>=20
> Let's back up a bit an analyze the scenarios. We have two scenarios:
>=20
> a) The endpoint declare all its supported media types in the =
accept-wrapped-types attribute in SDP. The MSRP switch will screen those =
types, and if the MSRP receives a wrapped media type that this endpoint =
does not support, it won't forward that e-mail to the endpoint.
>=20
> b) The endpoint declares a few of the supported media types, but not =
all, because it adds an asterisk '*' to the accept-wrapped-types =
attribute in SDP. Or, alternatively, the endpoint does not declare any =
supported media types (there is no accept-wrapped-types at all in SDP). =
In this case, the MSRP switch will not screen the wrapped types in =
received messages, and will forward all of them to the endpoint. =
Therefore, the endpoint may receive some media types that is not able to =
render. This is the same scenario we may have with web browsers today. =
Some implementations will incorrectly render it in binary, others will =
point to a plug-in download, etc.
>=20
> I don't know what else should we do from the standards point of view, =
besides what MSRP mandates and does not mandate.

My concern is we seem to allow the case of putting "message/cpim" in =
accept-wrapped-types, and _nothing_else_. While that doesn't violate =
4975, it creates a nonsensical case. That is, it can be interpreted to =
mean you can only accept message/cpim without content in it. I suppose =
some implementers might interpret it to mean you can accept message/cpim =
without restriction, but I don't think that will be universal.

So, if an endpoint or a switch includes message/cpim (or any other =
envelope type) it needs to also indicate one or more leaf types. It can =
do that in either accept-types or accept-wrapped-types, and it can =
wildcard it with a "*".=20

So, back to your scenarios, in the case of a), the endpoint needs to put =
message/cpim in accept-types, and the other media types in either =
accept-types or accept-wrapped types, depending on whether it wants to =
_require_ vs _allow_ the use of message/cpim. In case b), the endpoint =
either puts "message/cpim" in accept-types and "*" in =
accept-wrapped-types, or it just puts "*" in accept-type, depending on =
the same question as in a). In no case does it make sense for the =
endpoint to include nothing but "message/cpim".

It seems to me that we could make this easier by not getting too wrapped =
around the MSRP mechanics, and state more what the endpoints need to =
indicate semantically. For example, it seems like a chat endpoint MUST =
support message/cpim, and MAY require it. If it requires it, it MUST =
indicate what leaf types it supports, either explicitly or in the form =
of a wildcard.  A switch MUST support message/CPIM and SHOULD require =
it. If it requires it, it also MUST indicate what leaf types it =
supports...

Endpoints and switches use accept-types and accept-wrapped-types to do =
these things as described in RFC 4975.

>>>>=20
>>>> 7.1, third paragraph: "... character may be result encoded in
>>>> more than one octet" do you mean ...: may be as a result
>>>> encoded..."?
>>>=20
>>> I meant "may result encoded". Fixed, thanks.
>>=20
>> I'm still not clear on what "may result encoded" means. Do you mean
>> "may result in encoding..."?  (Or is result-encoded  a term of art
>> I've missed?)
>=20
> Here I am using the term "result" as a verb, not as a noun. The =
definition of "result" in the Merriam-Webster dictionary is:
>=20
> result: to proceed or arise as a consequence, effect, or conclusion. =
Example: 
>=20
> So, I believe "may result encoded" is correct, isn't it?
>=20
>=20

II get that you are using "result" as a verb. But "result encoded" =
doesn't parse.  I suggest either "As a result, the character may be =
encoded..." or "Therefore, the character may be encoded...". Or =
possibly, "This may result in the encoding of the character..."






From saul@ag-projects.com  Mon Nov 26 03:37:57 2012
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 1983821F84DA for ; Mon, 26 Nov 2012 03:37:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.688
X-Spam-Level: 
X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMXlc9KmB6Nx for ; Mon, 26 Nov 2012 03:37:56 -0800 (PST)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 45F2821F8482 for ; Mon, 26 Nov 2012 03:37:56 -0800 (PST)
Received: by mail.sipthor.net (Postfix, from userid 5001) id 7D5F3B35DC; Mon, 26 Nov 2012 12:37:54 +0100 (CET)
Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 3668EB00F7; Mon, 26 Nov 2012 12:37:41 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= 
In-Reply-To: <50A7BBA9.7040904@ericsson.com>
Date: Mon, 26 Nov 2012 12:37:40 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <85840D19-69E5-44A4-A24A-E078E45FB13E@ag-projects.com>
References: <20121117160611.10411.74381.idtracker@ietfa.amsl.com> <50A7BBA9.7040904@ericsson.com>
To: Miguel A. Garcia 
X-Mailer: Apple Mail (2.1085)
Cc: simple@ietf.org
Subject: Re: [Simple] I-D Action: draft-ietf-simple-chat-17.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: Mon, 26 Nov 2012 11:37:57 -0000

Hi,

On Nov 17, 2012, at 5:30 PM, Miguel A. Garcia wrote:

> Hi:
>=20
> So, the long awaited version -17 of the MSRP chat draft has been =
posted. This version addresses all the comments received in the IESG =
review and various directorates that also took a look at the draft. =
Among others, these are the most relevant changes.
>=20
> - Added definitions of "identifier" and "to log in".
> - New Section 4.1 lists all the Policy Attributes of the chat room in =
a single section.
> - Clarified that congestion can occur due to the chat room application =
or due to some other application.
> - Clarified that the MSRP switch should learn the recipient's =
capabilities through the 'accept-wrapped-types' in SDP. Procedures as =
for what to do if the MSRP switch is aware that a recipient does not =
support a given media type.
> - Quite a few clarifications around chunked messages. It was clarified =
when the MSRP switch has to delete the temporarily stored state. Also, =
how to deal with situations where the connection is broken before the =
reception of the last chunk.
> - Added a length limit to MSRP nicknames: they must be between 1 and =
1023 octets, after UTF-8 encoding.
> - Fixed a bug: the error result code is 425 rather than 423 in the =
examples.
> - Added more security considerations around the usage of TLS, policies =
to preserve a nickname once the use logs off, confusable nicknames, =
rendering of nicknames that contain scripts or code, and anonymity when =
using TLS with certificates.
>=20
> =46rom the authors' perspective, we believe the draft is ready. I will =
contact the IESG members to verify that the current version satisfies =
their comments.
>=20

I'm ok with this version. A couple of minor editorial comments though:

In sec 4.1: "Chunk reception timer:   The value of a time that" -> "The =
value of a timer that"

In sec 6.2 "whether a message was not deliver" -> "whether a message was =
not delivered"


Regards,

--
Sa=FAl Ibarra Corretg=E9
AG Projects