From christer.holmberg@ericsson.com Thu Apr 1 03:23:43 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C27AD3A68A4 for ; Thu, 1 Apr 2010 03:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.334 X-Spam-Level: X-Spam-Status: No, score=-4.334 tagged_above=-999 required=5 tests=[AWL=1.135, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVyeyF3JJrxc for ; Thu, 1 Apr 2010 03:23:42 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 934EE3A6811 for ; Thu, 1 Apr 2010 03:23:42 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-69-4bb4744df6da Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 6A.8A.23532.D4474BB4; Thu, 1 Apr 2010 12:24:13 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 1 Apr 2010 12:24:12 +0200 From: Christer Holmberg To: 'Ben Campbell' Date: Thu, 1 Apr 2010 12:24:10 +0200 Thread-Topic: [Simple] Question on RFC 5438 Thread-Index: AcrQ1iiGLKNeMSexQ4WP95RAszFcwgAMz69w Message-ID: References: <1C21EA0F-703A-49B3-A7BC-055D44BC69F4@nostrum.com> In-Reply-To: <1C21EA0F-703A-49B3-A7BC-055D44BC69F4@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-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] Question on RFC 5438 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 10:23:43 -0000 Hi,=20 >Record-route only affects a dialog. Is that really true? As far as I understand, Record-Route is used to create= a route set. For INVITEs, that route set is valid for the duration of the = dialog, but is there actually text saying that it would always be the case? Anyway, my issue isn't about IMDN-Record-Route, because only supporting ent= ities need to support that. My issue is about IMDN-Route, and whether also = non-supporting entities (proxies etc) would have to support that in order t= o correctly route the IMDN MESSAGE request. Route would not have that probl= em, since any SIP entity is supposed to support it. >MESSAGE is typically out-of-dialog. Also, these "intermediaries" are not t= ypically proxies. They are acting as endpoints (aka b2buas), and we're prob= ably talking about a series of SIP=20 >transactions between the devices, not one end-to-end transaction.=20 I am not sure I understand. So, when the UAS sends the IMDN MESSAGE, it is going to insert the next IMD= N hop in the Request-URI, instead of the remote UA? Regards, Christer =20 Hi, =20 I have a question on RFC 5438. =20 The RFC defines a mechanism, where the receiver of a MESSAGE request can s= end a "receipt", using another MESSAGE request (IMDN MESSAGE), to the sende= r to the initial MESSAGE to indicate that it has been received. There is si= milar functionality in e-mail. =20 For this, the RFC defines new CPIM header fields, including IMDN-Record-Ro= ute and IMDN-Route, to establish a "route" for the IMDN MESSAGE, so that in= terested intermediaries can also receive it. Intermediaries can insert IMDN= -R-R in the initial MESSAGE, and the receiver then use the value to create = an IMDN-Route in the associated IMDN MESSAGE. Intermediaries are then suppo= sed to route the IMDN MESSAGE using IMDN-Route. =20 Now, the RFC seems to assume that the only intermediaries that will insert= IMDN-Record-Route is certain application servers, and I guess that is ok. =20 Section 12.2 says: =20 "In this context, intermediaries include application servers (including URI-List and store-and-forward servers) and gateways. SIP Proxies MUST NOT generate IMDNs but MUST forward them like any other SIP request." =20 BUT, if an AS has inserted IMDN-Record-Route, and there are also other pro= xies, aren't there cases when proxies are supposed to route based on the IM= DN-Route? Otherwise the IMDN MESSAGE may never reach the AS that inserted I= MDN-R-R. If so, that would require proxies to also support the IMDN extensi= on, but how can one ensure that (there is no Proxy-Require option-tag defin= ed)? =20 Now, I assume a reason for defining IMDN-Record-Route was because MESSAGE = does not allow Record-Route. =20 But, MESSAGE does allow Route, so my question is why Route can not be used= instead of IMDN-Route? Then there would be no issues with intermediaries n= ot supporting the extension. =20 So, unless I have missunderstood something, I think we would need to fix t= his. =20 Regards, =20 Christer =20 _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple =09 =09 From ibc@aliax.net Thu Apr 1 03:54:04 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7481D3A69BD for ; Thu, 1 Apr 2010 03:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.547 X-Spam-Level: X-Spam-Status: No, score=-0.547 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZ34abqzDu18 for ; Thu, 1 Apr 2010 03:54:03 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id B5EA03A69B2 for ; Thu, 1 Apr 2010 03:54:03 -0700 (PDT) Received: by pwi10 with SMTP id 10so913926pwi.31 for ; Thu, 01 Apr 2010 03:54:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.188.2 with HTTP; Thu, 1 Apr 2010 03:54:33 -0700 (PDT) In-Reply-To: References: <1C21EA0F-703A-49B3-A7BC-055D44BC69F4@nostrum.com> Date: Thu, 1 Apr 2010 12:54:33 +0200 Received: by 10.141.101.16 with SMTP id d16mr199021rvm.169.1270119273030; Thu, 01 Apr 2010 03:54:33 -0700 (PDT) Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] Question on RFC 5438 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 10:54:04 -0000 2010/4/1 Christer Holmberg : > > Hi, > >>Record-route only affects a dialog. > > Is that really true? As far as I understand, Record-Route is used to crea= te a route set. For INVITEs, that route set is valid for the duration of th= e dialog, but is there actually text saying that it would always be the cas= e? Record-Route is inserted in the initial INVITE/SUBscrIbE/REFER by a proxy which wants to remain in the dialog path for the duration of the dialog. This is called loose-route mechanism (introduced in RFC 3261). An initial request can also contain a Route header, but this is out of the scope of the loose-routing mechanism. > Anyway, my issue isn't about IMDN-Record-Route, because only supporting e= ntities need to support that. My issue is about IMDN-Route, and whether als= o non-supporting entities (proxies etc) would have to support that in order= to correctly route the IMDN MESSAGE request. Route would not have that pro= blem, since any SIP entity is supposed to support it. > >>MESSAGE is typically out-of-dialog. Also, these "intermediaries" are not = typically proxies. They are acting as endpoints (aka b2buas), and we're pro= bably talking about a series of SIP >>transactions between the devices, not one end-to-end transaction. > > I am not sure I understand. > > So, when the UAS sends the IMDN MESSAGE, it is going to insert the next I= MDN hop in the Request-URI, instead of the remote UA? If so, that looks like the deprecated strict routing defined in the obsoleted RFC 2543. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Thu Apr 1 04:05:29 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD3313A683B for ; Thu, 1 Apr 2010 04:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=-1.045, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfZ4MC2GSynf for ; Thu, 1 Apr 2010 04:05:29 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id B440E3A67F5 for ; Thu, 1 Apr 2010 04:05:27 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-ed-4bb47e16701c Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id DB.8F.23740.61E74BB4; Thu, 1 Apr 2010 13:05:58 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 1 Apr 2010 13:05:58 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Thu, 1 Apr 2010 13:05:56 +0200 Thread-Topic: [Simple] Question on RFC 5438 Thread-Index: AcrRibqRTibdkMaPTrOy3Qto7lIKjgAATFXw Message-ID: References: <1C21EA0F-703A-49B3-A7BC-055D44BC69F4@nostrum.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] Question on RFC 5438 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 11:05:29 -0000 Hi,=20 >>>Record-route only affects a dialog. >> >>Is that really true? As far as I understand, Record-Route=20 >>is used to create a route set. For INVITEs, that route set is=20 >>valid for the duration of the dialog, but is there actually=20 >>text saying that it would always be the case? >=20 >Record-Route is inserted in the initial=20 >INVITE/SUBscrIbE/REFER by a proxy which wants to remain in=20 >the dialog path for the duration of the dialog. This is=20 >called loose-route mechanism (introduced in RFC 3261). I know that. My point was that I can not find text saying that a route set = always need to be used for a dialog. However, that is not my main issue, so we don't need to discuss that. >An initial request can also contain a Route header, but this is out of the= scope of the loose-routing mechanism. >=20 >>Anyway, my issue isn't about IMDN-Record-Route, because=20 >>only supporting entities need to support that. My issue is=20 >>about IMDN-Route, and whether also non-supporting entities=20 >>(proxies etc) would have to support that in order to=20 >>correctly route the IMDN MESSAGE request. Route would not=20 >>have that problem, since any SIP entity is supposed to support it. >> >>>MESSAGE is typically out-of-dialog. Also, these "intermediaries" are=20 >>>not typically proxies. They are acting as endpoints (aka=20 >>>b2buas), and we're probably talking about a series of SIP=20 >>>transactions between the devices, not one end-to-end transaction. >> >>I am not sure I understand. >> >>So, when the UAS sends the IMDN MESSAGE, it is going to=20 >>insert the next IMDN hop in the Request-URI, instead of the remote UA? >=20 >If so, that looks like the deprecated strict routing defined in the obsole= ted RFC 2543. So, then help me understand how it will look like, so that non-aware interm= ediaries don't need to understand IMDN-Route :) Regards, Christer From ibc@aliax.net Thu Apr 1 04:08:46 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA9B73A67F5 for ; Thu, 1 Apr 2010 04:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.547 X-Spam-Level: X-Spam-Status: No, score=-0.547 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lk1yxfoGBu0l for ; Thu, 1 Apr 2010 04:08:46 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id F0CB73A67B4 for ; Thu, 1 Apr 2010 04:08:45 -0700 (PDT) Received: by pwi10 with SMTP id 10so920043pwi.31 for ; Thu, 01 Apr 2010 04:09:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.188.2 with HTTP; Thu, 1 Apr 2010 04:09:15 -0700 (PDT) In-Reply-To: References: <1C21EA0F-703A-49B3-A7BC-055D44BC69F4@nostrum.com> Date: Thu, 1 Apr 2010 13:09:15 +0200 Received: by 10.140.248.9 with SMTP id v9mr216250rvh.101.1270120155483; Thu, 01 Apr 2010 04:09:15 -0700 (PDT) Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] Question on RFC 5438 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 11:08:46 -0000 2010/4/1 I=C3=B1aki Baz Castillo : >> So, when the UAS sends the IMDN MESSAGE, it is going to insert the next = IMDN hop in the Request-URI, instead of the remote UA? > > If so, that looks like the deprecated strict routing defined in the > obsoleted RFC 2543. But it's not the case, it's more like the normal loose-routing: An IM may contain an IMDN-Record-Route header field (see Section 8 for details). If IMDN-Record-Route header fields appear in the IM, the IM Recipient constructing the IMDN MUST copy the contents of the IMDN-Record-Route header fields into IMDN-Route header fields in the IMDN and maintain their order. The IMDN is then sent to the URI in the top IMDN-Route header field. IMDN-Record-Route header fields do not make sense in an IMDN and therefore MUST NOT be placed in an IMDN. IMDN Recipients MUST ignore it if present. So this just means that an intermediary could insert a IMDN-Record-Route i nthe original MESSAGE. Then the recipient constructing the IMDN copies the values of IMDN-Record-Route into IMDN-Route header (mantaining the order). I expect the RURI of the IMDN request is still the From of the original IM, but the recipient must send the IMDN to the top value of the IMDN-Route header it has build. Then, this means that the request will arrive to an intermediary which previously added a IMDN-Record-Route, so IMHO it MUST support routing based on IMDN-Route. This is exactly the original question, right? And as I understand by reading section 8 the intermediary inserting IMDN-Record-Route must be able to route based on IMDN-Route: For the reasons stated above, an intermediary MAY choose to remain on the path of IMDNs for a specific IM. It can do so by adding a CPIM IMDN-Record-Route header field as the top IMDN-Record-Route header field. The value of this field MUST be the intermediary's own address. An intermediary that does not support this extension will obviously not add the IMDN-Record-Route header field. This allows IMDNs to traverse directly from the IM Recipient to the IM Sender even if the IM traversed an intermediary not supporting this extension. An intermediary receiving an IMDN checks the top IMDN-Route header field. If that header field carries the intermediary address, the intermediary removes that value and forwards the IMDN to the address indicated in the new top IMDN-Route header field. If no additional IMDN-Route header fields are present, the IMDN is forwarded to the address in the CPIM To header field. So, yes, it would be really easier if the recipient uses normal Route rather than IMDN-Route, so any SIP proxy could just add the IMDN-Record-Route without having to deal with routing based on IMDN-Route. But this would introduce two problems: 1) Usually proxies just allow Route headers for in-dialog requests (as a security protection). 2) It's cooler for the RFC authors to create two new headers rather than just one. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Thu Apr 1 04:11:10 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 931E63A683B for ; Thu, 1 Apr 2010 04:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.547 X-Spam-Level: X-Spam-Status: No, score=-0.547 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoDZwlWo9asj for ; Thu, 1 Apr 2010 04:11:09 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 986E63A67B4 for ; Thu, 1 Apr 2010 04:11:09 -0700 (PDT) Received: by pvh1 with SMTP id 1so329610pvh.31 for ; Thu, 01 Apr 2010 04:11:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.188.2 with HTTP; Thu, 1 Apr 2010 04:11:37 -0700 (PDT) In-Reply-To: References: <1C21EA0F-703A-49B3-A7BC-055D44BC69F4@nostrum.com> Date: Thu, 1 Apr 2010 13:11:37 +0200 Received: by 10.141.100.15 with SMTP id c15mr206841rvm.221.1270120297288; Thu, 01 Apr 2010 04:11:37 -0700 (PDT) Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] Question on RFC 5438 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 11:11:10 -0000 2010/4/1 Christer Holmberg : > So, then help me understand how it will look like, so that non-aware inte= rmediaries don't need to understand IMDN-Route :) As I've just replied in other mail, IMHO an intermediary not implementing routing based on IMDN-Route should not add a IMDN-Record-Route header. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Thu Apr 1 04:20:25 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10B733A68A4 for ; Thu, 1 Apr 2010 04:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.187 X-Spam-Level: X-Spam-Status: No, score=-4.187 tagged_above=-999 required=5 tests=[AWL=0.982, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4VNdgn-lMEc for ; Thu, 1 Apr 2010 04:20:22 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id A88B63A62C1 for ; Thu, 1 Apr 2010 04:19:39 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-d4-4bb481690f2f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 67.12.23532.96184BB4; Thu, 1 Apr 2010 13:20:09 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 1 Apr 2010 13:20:08 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Thu, 1 Apr 2010 13:20:09 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Thu, 1 Apr 2010 13:20:08 +0200 Thread-Topic: [Simple] Question on RFC 5438 Thread-Index: AcrRi8Wz9189XgboRK+w1UCWQ/EoXQAAF7UQ Message-ID: References: <1C21EA0F-703A-49B3-A7BC-055D44BC69F4@nostrum.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] Question on RFC 5438 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 11:20:25 -0000 Hi,=20 >>>So, when the UAS sends the IMDN MESSAGE, it is going to insert the next = IMDN hop in the Request-URI, instead of the remote UA? >> >>If so, that looks like the deprecated strict routing defined in the=20 >>obsoleted RFC 2543. >=20 >But it's not the case, it's more like the normal loose-routing: >=20 > An IM may contain an IMDN-Record-Route header field (see Section 8 > for details). If IMDN-Record-Route header fields appear in the IM, > the IM Recipient constructing the IMDN MUST copy the=20 > contents of the IMDN-Record-Route header fields into IMDN-Route header= =20 > fields in the IMDN and maintain their order. The IMDN is then sent to= the URI in > the top IMDN-Route header field. IMDN-Record-Route header fields do > not make sense in an IMDN and therefore MUST NOT be placed in an > IMDN. IMDN Recipients MUST ignore it if present. >=20 >=20 >So this just means that an intermediary could insert a=20 >IMDN-Record-Route i nthe original MESSAGE. Then the recipient=20 >constructing the IMDN copies the values of IMDN-Record-Route=20 >into IMDN-Route header (mantaining the order). I expect the=20 >RURI of the IMDN request is still the From of the original=20 >IM, but the recipient must send the IMDN to the top value of=20 >the IMDN-Route header it has build. >=20 >Then, this means that the request will arrive to an=20 >intermediary which previously added a IMDN-Record-Route, so=20 >IMHO it MUST support routing based on IMDN-Route. This is=20 >exactly the original question, right? Yes, that is the question. But, what if the UA e.g. routes all messages via some IMDN-unaware default = outbound proxy? This is normally done by adding a Route header pointing towards the outboun= d proxy. Yes, the UA can do it also now, but the problem is that the outbou= nd proxy is then not able to forward the request, since it does not underst= and IMDN-Route. >And as I understand by reading section 8 the intermediary inserting IMDN-R= ecord-Route must be able to route based on IMDN-Route: Yes. =20 >For the reasons stated above, an intermediary MAY choose to remain on >the path of IMDNs for a specific IM. It can do so by adding a CPIM >IMDN-Record-Route header field as the top IMDN-Record-Route header >field. The value of this field MUST be the intermediary's own >address. An intermediary that does not support this extension will >obviously not add the IMDN-Record-Route header field. This allows >IMDNs to traverse directly from the IM Recipient to the IM Sender >even if the IM traversed an intermediary not supporting this >extension. >=20 >An intermediary receiving an IMDN checks the top IMDN-Route header >field. If that header field carries the intermediary address, the >intermediary removes that value and forwards the IMDN to=20 >the address indicated in the new top IMDN-Route header field. If no additi= onal >IMDN-Route header fields are present, the IMDN is forwarded to the >address in the CPIM To header field. ...which is also a little strange. Why not route to the address in the R-UR= I? =20 >So, yes, it would be really easier if the recipient uses=20 >normal Route rather than IMDN-Route, so any SIP proxy could=20 >just add the IMDN-Record-Route without having to deal with=20 >routing based on IMDN-Route. But this would introduce two problems: >=20 >1) Usually proxies just allow Route headers for in-dialog=20 >requests (as a security protection). I have seen numerous of cases where non-in-dialog requests (dialog establis= hment requests, registration requests etc) have been sent with pre-defined = routes. >2) It's cooler for the RFC authors to create two new headers rather than j= ust one. Sure. It's more sexy to re-new rather than re-use :) Regards, Christer From ibc@aliax.net Thu Apr 1 04:29:13 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39EB13A68F2 for ; Thu, 1 Apr 2010 04:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.547 X-Spam-Level: X-Spam-Status: No, score=-0.547 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLPwlRyH4Ap2 for ; Thu, 1 Apr 2010 04:29:12 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 662F63A6857 for ; Thu, 1 Apr 2010 04:29:12 -0700 (PDT) Received: by pwi10 with SMTP id 10so928545pwi.31 for ; Thu, 01 Apr 2010 04:29:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.188.2 with HTTP; Thu, 1 Apr 2010 04:29:41 -0700 (PDT) In-Reply-To: References: <1C21EA0F-703A-49B3-A7BC-055D44BC69F4@nostrum.com> Date: Thu, 1 Apr 2010 13:29:41 +0200 Received: by 10.141.53.11 with SMTP id f11mr226232rvk.139.1270121381236; Thu, 01 Apr 2010 04:29:41 -0700 (PDT) Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] Question on RFC 5438 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 11:29:13 -0000 2010/4/1 Christer Holmberg : >>Then, this means that the request will arrive to an >>intermediary which previously added a IMDN-Record-Route, so >>IMHO it MUST support routing based on IMDN-Route. This is >>exactly the original question, right? > > Yes, that is the question. > > But, what if the UA e.g. routes all messages via some IMDN-unaware defaul= t outbound proxy? > > This is normally done by adding a Route header pointing towards the outbo= und proxy. Yes, the UA can do it also now, but the problem is that the outb= ound proxy is then not able to forward the request, since it does not under= stand IMDN-Route. Right :( >>An intermediary receiving an IMDN checks the top IMDN-Route header >>field. If that header field carries the intermediary address, the >>intermediary removes that value and forwards the IMDN to >>the address indicated in the new top IMDN-Route header field. If no addit= ional >>IMDN-Route header fields are present, the IMDN is forwarded to the >>address in the CPIM To header field. > > ...which is also a little strange. Why not route to the address in the R-= URI? Ops, I didn't realize that "If no additional IMDN-Route header fields are present, the IMDN is forwarded to the address in the CPIM To header field". This is really annoying. >>1) Usually proxies just allow Route headers for in-dialog >>requests (as a security protection). > > I have seen numerous of cases where non-in-dialog requests (dialog establ= ishment requests, registration requests etc) have been sent with pre-define= d routes. Yes, there are cases but as they introduce some security risks in some environments they are not allowed. >>2) It's cooler for the RFC authors to create two new headers rather than = just one. > > Sure. It's more sexy to re-new rather than re-use :) So we end with an unusable specification (again) :( --=20 I=C3=B1aki Baz Castillo From ben@nostrum.com Thu Apr 1 06:59:45 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D7493A682B for ; Thu, 1 Apr 2010 06:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugcgsgJo+5Ca for ; Thu, 1 Apr 2010 06:59:44 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 3B1C83A680D for ; Thu, 1 Apr 2010 06:59:43 -0700 (PDT) Received: from [10.0.1.12] (adsl-68-94-19-181.dsl.rcsntx.swbell.net [68.94.19.181]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o31E0B9u093360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Apr 2010 09:00:11 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Ben Campbell In-Reply-To: Date: Thu, 1 Apr 2010 09:00:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1C21EA0F-703A-49B3-A7BC-055D44BC69F4@nostrum.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1078) Received-SPF: pass (nostrum.com: 68.94.19.181 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] Question on RFC 5438 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 13:59:45 -0000 Let's back up a little bit. IMDN-route has nothing to do with SIP = proxies, and doesn't affect routing at the SIP layer in any way. It's = is a CPIM header, not a SIP header, and is theoretically not even = available to a SIP proxy. It could conceivably be encrypted. It might = even be carried in non-SIP protocols for one or more steps along the = way. These IMDN-Record-Route and IMDN-Route intermediaries are devices like = message list exploders and store-and-forward servers. These devices were = UASs in the original MESSAGE request, and likely act as UAC's to forward = the message somewhere else in an entirely new SIP transaction. If a endpoint or intermediary wants to send an IMDN that contains = IMDN-Route, it sends the IMDN to the first IMDN-Route entry. In SIP = terms, that means the R-URI will be the first IMDN-Route entry. On Apr 1, 2010, at 6:29 AM, I=F1aki Baz Castillo wrote: > 2010/4/1 Christer Holmberg : >=20 >>> Then, this means that the request will arrive to an >>> intermediary which previously added a IMDN-Record-Route, so >>> IMHO it MUST support routing based on IMDN-Route. This is >>> exactly the original question, right? >>=20 >> Yes, that is the question. >>=20 >> But, what if the UA e.g. routes all messages via some IMDN-unaware = default outbound proxy? >>=20 >> This is normally done by adding a Route header pointing towards the = outbound proxy. Yes, the UA can do it also now, but the problem is that = the outbound proxy is then not able to forward the request, since it = does not understand IMDN-Route. >=20 > Right :( >=20 >=20 >=20 >>> An intermediary receiving an IMDN checks the top IMDN-Route header >>> field. If that header field carries the intermediary address, the >>> intermediary removes that value and forwards the IMDN to >>> the address indicated in the new top IMDN-Route header field. If no = additional >>> IMDN-Route header fields are present, the IMDN is forwarded to the >>> address in the CPIM To header field. >>=20 >> ...which is also a little strange. Why not route to the address in = the R-URI? >=20 > Ops, I didn't realize that "If no additional IMDN-Route header fields > are present, the IMDN is forwarded to the address in the CPIM To > header field". This is really annoying. >=20 >=20 >=20 >>> 1) Usually proxies just allow Route headers for in-dialog >>> requests (as a security protection). >>=20 >> I have seen numerous of cases where non-in-dialog requests (dialog = establishment requests, registration requests etc) have been sent with = pre-defined routes. >=20 > Yes, there are cases but as they introduce some security risks in some > environments they are not allowed. >=20 >=20 >>> 2) It's cooler for the RFC authors to create two new headers rather = than just one. >>=20 >> Sure. It's more sexy to re-new rather than re-use :) >=20 > So we end with an unusable specification (again) :( >=20 >=20 >=20 > --=20 > I=F1aki Baz Castillo > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From Martin.Thomson@andrew.com Mon Apr 5 22:26:13 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24CBB3A686A; Mon, 5 Apr 2010 22:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.067 X-Spam-Level: X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[AWL=-1.068, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Jjo9DfWdxv6; Mon, 5 Apr 2010 22:26:03 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 02CE43A69FF; Mon, 5 Apr 2010 22:22:26 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:61473 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S16329260Ab0DFFWJ (ORCPT + 2 others); Tue, 6 Apr 2010 00:22:09 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 6 Apr 2010 00:22:08 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 6 Apr 2010 13:22:06 +0800 From: "Thomson, Martin" To: Simple WG , "Peterson, Jon" , "James M. Polk" Date: Tue, 6 Apr 2010 13:23:29 +0800 Thread-Topic: By-reference and by-value Thread-Index: AcrVSUqeyckad73EREiiZPDXKHf86Q== Message-ID: <8B0A9FCBB9832F43971E38010638454F03E3F3060A@SISPE7MB1.commscope.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: [Simple] By-reference and by-value X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 05:26:13 -0000 X-List-Received-Date: Tue, 06 Apr 2010 05:26:13 -0000 VGhlIHNpcGNvcmUtbG9jYXRpb24tY29udmV5YW5jZSByZWJvb3QgZGlzY3Vzc2lvbiBbMV0gcmFp c2VkIGFuIGludGVyZXN0aW5nIHByb2JsZW0uDQoNCiggSSd2ZSBzdGFydGVkIHRoaXMgZGlzY3Vz c2lvbiBvbiB0aGUgc2ltcGxlIFdHIGxpc3QsIHNpbmNlIHRoYXQgaXMgd2hlcmUgSSBiZWxpZXZl IG1vc3QgcHJlc2VuY2UgZGF0YSBtb2RlbCBleHBlcnRpc2UgaXMgbGlrZWx5IHRvIGJlIGNvbmNl bnRyYXRlZC4gIEkndmUgYmNjJ2Qgc2lwY29yZSBhbmQgZ2VvcHJpdiwgZnJvbSB3aGljaCB0aGVy ZSBtaWdodCBiZSBpbnRlcmVzdCBpbiB0aGlzIGRpc2N1c3Npb24uICkNCg0KT25lIGltcG9ydGFu dCBmZWF0dXJlIGlzIGNvbmN1cnJlbnQgY29udmV5YW5jZSBvZiBsb2NhdGlvbiBieS1yZWZlcmVu Y2UgYW5kIGJ5LXZhbHVlLiAgVGhpcyBpcyBhcHBsaWVkIGluIGRpZmZlcmVudCB3YXlzLg0KDQpJ biBvbmUgdXNlIGNhc2UsIGEgcmVjaXBpZW50IG1pZ2h0IHVzZSB0aGlzIHRvIGdldCB0aGUgbG9j YXRpb24gZm9yIG5vdywgYW5kIGhhdmUgYSBtZWFucyBvZiBnZXR0aW5nIGxvY2F0aW9uIGZvciBs YXRlci4gIFRoaXMgaXMgaW1wb3J0YW50IGZvciBlbWVyZ2VuY3kgY2FsbGluZyBhbmQgaXQgaXMg ZnVuZGFtZW50YWwgdG8gbG9jYXRpb24gaGlkaW5nIGluIEVDUklUIChkcmFmdC1pZXRmLWVjcml0 LWxvY2F0aW9uLWhpZGluZy1yZXEgYW5kIGRyYWZ0LWlldGYtZWNyaXQtcm91Z2gtbG9jKS4NCg0K Sm9uIHN1Z2dlc3RzIHRoYXQgIml0IGlzIGZhciBsZXNzIGJyaXR0bGUgdG8gZXh0ZW5kIFBJREYg dGhhbiB0byBhZGQgdGhpcyB0byBTSVAiLiAgQSBjbGFpbSB0aGF0IHNlZW1zIGFtcGx5IHN1cHBv cnRlZCBieSBleGhpYml0IEIgWzJdIGFuZCBpdHMgcGVyc2lzdGVudCBkcmFmdCBzdGF0dXMuDQoN CkknZCBsaWtlIHRvIGV4cGxvcmUgaG93IHdlIGFkZHJlc3MgdGhpcyBwcm9ibGVtIHdpdGggYSBQ SURGIGV4dGVuc2lvbi4NCg0KQW5kLi4uaWYgdGhpcyB3b3JrcyBvdXQsIHBlcmhhcHMgd2UgY2Fu IGFsc28ga2lsbCBhbm90aGVyIGJpcmQgWzNdIHdpdGggdGhlIHNhbWUgc3RvbmUuDQoNClRoZSBw cm9ibGVtLCBhcyBJIHNlZSBpdCwgaXMgdGhlIGluY2x1c2lvbiBvZiBwcmVzZW5jZSBzdGF0ZSBi eSByZWZlcmVuY2UsIHVzaW5nIGEgVVJJLiAgDQoNCk9yLCBpZiB3ZSB0aGluayBvZiB0aGUgVVJJ IGFzIGFuIHVubGlua2VkIHBzZXVkb255bSB3aXRoIGFzc29jaWF0ZWQgcHJlc2VuY2Ugc3RhdGUs IGl0IGlzIHRoZSBsaW5raW5nIG9mIHRoYXQgcHNldWRvbnltIHRvIGFub3RoZXIgZW50aXR5IHdp dGggdGhlIGludGVudCBvZiBhbHNvIGxpbmtpbmcgdGhlIHN0YXRlLg0KDQooIFRoYXQgbGFzdCBz dGF0ZW1lbnQgcHJvYmFibHkgbmVlZHMgYSBiaXQgbW9yZSBleHBsYW5hdGlvbi4gIEluIEhFTEQs IGEgTElTIGNyZWF0ZXMgYSBsb2NhdGlvbiBvYmplY3QuICBUaGUgc3ViamVjdCwgb3IgcHJlc2Vu dGl0eSwgb2YgdGhhdCBsb2NhdGlvbiBvYmplY3QgaXMgYSBkZXZpY2UuIA0KDQooIEZvciBwcml2 YWN5IHJlYXNvbnMsIHdlIGRvbid0IHdhbnQgdG8gbGluayB0aGUgZGV2aWNlIGlkZW50aXR5IHRv IHRoZSBsb2NhdGlvbi4gIFRoZSBkZXZpY2Ugb3duZXIvcnVsZSBtYWtlciBtaWdodCBub3Qgd2lz aCBmb3IgdGhhdCB0byBoYXBwZW4gLSB0aGlzIGxpbmthZ2UgbXVzdCBvY2N1ciB1bmRlciB0aGVp ciBjb250cm9sLiAgVGh1cywgdGhlIExJUyBjcmVhdGVzIGFuIHVubGlua2VkIHBzZXVkb255bSBm b3IgdGhlIGRldmljZSB0byB1c2UgYXMgdGhlIHByZXNlbnRpdHkgaWRlbnRpZmllciBbNF0uICkN Cg0KSWYgYW4gZW50aXR5IC0gdXNlciwgZGV2aWNlIG9yIG90aGVyd2lzZSAtIHdpc2hlcyBmb3Ig dGhpcyBpbmZvcm1hdGlvbiB0byBiZSBsaW5rZWQgd2l0aCB0aGVtLCB0aGV5IHRha2UgdGhlIGxv Y2F0aW9uIGluZm9ybWF0aW9uIGFuZCB1c2UgaXQgaW4gdGhlaXIgb3duIHByZXNlbmNlLg0KDQpX aGF0IHRoaXMgaW1wbGllcyBpcyB0aGF0IHdlIG5lZWQgYSB3YXkgdG8gbGluayBvbmUgcHJlc2Vu Y2UgZG9jdW1lbnQgdG8gYW5vdGhlciwgdXNpbmcgYSBVUkkuDQoNCllvdSBjYW4gYWxzbyBtYWRl IGEgZ29vZCBhcmd1bWVudCB0aGF0IHRoZSBsaW5rYWdlIHN0YXJ0IGZyb20gYW55IG9mIHRoZSBm b3VyIGZ1bmRhbWVudGFsIGVsZW1lbnRzIGluIHRoZSBkYXRhIG1vZGVsIFtSRkM0NDc5XTogdGhl IHVuLXR5cGVkIDx0dXBsZT4sIDxwZXJzb24+LCA8ZGV2aWNlPiwgb3IgPHNlcnZpY2U+Lg0KDQpU aGUgcmVmZXJlbmNlIGJlY29tZXMgdGhlICJzdGF0dXMiIG9mIHRoZSBlbGVtZW50LiAgVGh1cywg d2UgaGF2ZToNCg0KICA8cHJlc2VuY2UgZW50aXR5PSJwcmVzOmZvb0BleGFtcGxlLmNvbSI+DQog ICAgPHR1cGxlIGlkPSJzZzg5YWUiPg0KICAgICAgPHN0YXR1cz4NCiAgICAgICAgPGJyOnJlZmVy ZW5jZT5wcmVzOnRoaW5nQGV4YW1wbGUubmV0PC9icjpyZWZlcmVuY2U+DQogICAgICA8L3N0YXR1 cz4NCiAgICA8L3R1cGxlPg0KICAgIDxkbTpwZXJzb24gaWQ9InAxIj4NCiAgICAgIDxicjpyZWZl cmVuY2U+cHJlczpwZXJzb25AZXhhbXBsZS5uZXQ8L2JyOnJlZmVyZW5jZT4NCiAgICA8L2RtOnBl cnNvbj4NCiAgICA8ZG06ZGV2aWNlIGlkPSJwYzEyMiI+DQogICAgICA8YnI6cmVmZXJlbmNlPnBy ZXM6ZGV2aWNlQGV4YW1wbGUubmV0PC9icjpyZWZlcmVuY2U+DQogICAgICA8ZG06ZGV2aWNlSUQ+ bWFjOjhhc2Q3ZDdkNzA8L2RtOmRldmljZUlEPg0KICAgIDwvZG06ZGV2aWNlPg0KICA8L3ByZXNl bmNlPg0KDQpJbmZvcm1hdGlvbiBwcm92aWRlZCBieSBIRUxEIG9yIERIQ1AgcmVsYXRlcyB0byBh IGRldmljZSAoSEVMRCBpcyBjbGVhciBhYm91dCB0aGlzLCBhbmQgSSBhc3N1bWUgdGhlIHNhbWUg dG8gYmUgdHJ1ZSBmb3IgREhDUCkuICBGb3IgbG9jYXRpb24sIHRoZSByZWZlcmVuY2VkIGRvY3Vt ZW50IG1pZ2h0IGluY2x1ZGUgc3BlY2lmaWMgdHlwaW5nIGZvciB0aGUgcHJlc2VuY2UgZGF0YSB0 aGF0IGl0IGluY2x1ZGVzLCBvciBpdCBtaWdodCBiZSBpbnRlbnRpb25hbGx5IHNpbGVudC4NCg0K QSBQSURGIGRvY3VtZW50IHRoYXQgaW5jbHVkZXMgYSByZWZlcmVuY2UgY291bGQgc3BlY2lmeSB0 eXBlLCBieSBhZGRpbmcgdGhlIHJlZmVyZW5jZSB0byBhIHR5cGVkIGVsZW1lbnQuICBJbiB0aGlz IHNpbXBsZSBjYXNlLCB0aGlzIHdvdWxkIGJlIDxkZXZpY2U+LCBidXQgaXQncyBhbHNvIHBvc3Np YmxlIHRvIG1ha2UgYSBzdGF0ZW1lbnQgYWJvdXQgYSBwZXJzb24gLSBhbmQgdGhlaXIgcHJveGlt aXR5IHRvIHRoZSBkZXZpY2UgLSBieSB1c2luZyB0aGUgPHBlcnNvbj4gZWxlbWVudC4NCg0KVGhl IHJlZmVyZW5jZWQgZG9jdW1lbnQgbWlnaHQgdXNlIHR5cGVkIGVsZW1lbnRzLiAgT3IsIGJvdGgg ZG9jdW1lbnRzIGNvdWxkIGF2b2lkIGV4cGxpY2l0IHN0YXRlbWVudHMgb24gdHlwZS4gIFRoZXJl IGlzIG5vIHJlYWwgcmlzayBvZiBjb25mdXNpb24gLSBldmVuIGlmIGJvdGggZG9jdW1lbnRzIHNw ZWNpZnkgdHlwZSwgdGhpcyBvbmx5IGRlY2xhcmVzIHRoYXQgYm90aCBlbnRpdGllcyBzaGFyZSBw cmVzZW5jZSBkYXRhLg0KDQpJdCdzIHRlbXB0aW5nIHRvIHNwZWNpZnkgaG93IHRoaXMgaW5mb3Jt YXRpb24gaXMgc3Vic2VxdWVudGx5IGNvbXBvc2l0ZWQuICBIb3dldmVyLCBzb21lb25lIHdpdGgg ZmFyIG1vcmUgZXhwZXJpZW5jZSBpbiB0aGlzIGFyZWEgdGhhbiBJIHBvaW50ZWQgb3V0IHRoYXQg YW55IGF0dGVtcHQgdG8gZG8gc28gd291bGQgYmUgYm90aCBkZXN0cnVjdGl2ZSBhbmQgZnV0aWxl LiAgTGV0IHRoZSByZWNpcGllbnRzIGRlY2lkZSBob3cgdGhleSB3YW50IHRvIHN0cnVjdHVyZSB0 aGUgZGF0YS4NCg0KRm9yIGEgcHJlc2VuY2Ugc2VydmVyIHRoYXQgcmVjZWl2ZXMgYSBwdWJsaXNo IGNvbnRhaW5pbmcgdGhpcyBkYXRhLCB0aGV5IGNob29zZSBob3cgdGhpcyBpcyBwcmVzZW50ZWQg dG8gd2F0Y2hlcnMuICBUaGVyZSBpcyBhIGNob2ljZSBvdmVyIHdoYXQgdG8gcHJvdmlkZTogbm8g aW5mb3JtYXRpb24sIGluZm9ybWF0aW9uIHJldHJpZXZlZCBmcm9tIHRoZSByZWZlcmVuY2UgYW5k IGNvbXBvc2l0ZWQgc29tZWhvdywgb3IgdGhlIFVSSS4gIFBvbGljeSBhbHNvIGhhcyBhIHNheSBp biB0aGlzLg0KDQpJdCB3b3VsZCBiZSByZW1pc3Mgbm90IHRvIGFsc28gYWRkcmVzcyB0aGUgcG9s aWN5IGNvbmNlcm5zLiAgUkZDIDUwMjUgKHByZXNlbmNlIHBvbGljeSkgZGVzY3JpYmVzIHByb3Zp ZGUtKiBydWxlcyB0aGF0IGFyZSB1c2VkIHRvIGxpbWl0IHdoYXQgYSBwcmVzZW5jZSByZWNpcGll bnQgY2FuIHNlZS4gIFRoaXMgaXMgcGFydGljdWxhcmx5IGltcG9ydGFudCBpbiB0aGlzIGNhc2Uu DQoNClBvbGljeSBjYW4gYmUgY3JhZnRlZCB0byBhcHBseSB0byBhIHN1YnNjcmlwdGlvbiwgYnV0 IHRoZSBzYW1lIG1pZ2h0IG5vdCBiZSB0cnVlIG9mIHRoZSByZWZlcmVuY2UgdGhhdCBpcyB0aGVy ZWJ5IHJldmVhbGVkLiAgRnJvbSBhIHByaXZhY3kgcG9saWN5IHBlcnNwZWN0aXZlLCB0aGlzIGlz IGEgcHJvYmxlbS4gIFRoaXMgaXMgZXNwZWNpYWxseSBwcm9ibGVtYXRpYyB3aGVuIHlvdSBjb25z aWRlciB0aGF0IGEgcmVmZXJlbmNlIGNhbiBsaXZlIGxvbmdlciB0aGFuIHRoZSBzdWJzY3JpcHRp b24gdGhhdCByZXZlYWxlZCBpdC4NCg0KUkZDIDUwMjUgaGFzIHNwZWNpZmljIHBvbGljeSBwb2lu dHMgZm9yIGNvbnRyb2xsaW5nIGhvdyBlYWNoIHByZXNlbmNlIGF0dHJpYnV0ZSBpcyByZXZlYWxl ZC4gIEdlb3ByaXYtcG9saWN5IGV4dGVuZHMgdGhvc2UgZm9yIGJvdGggb2YgdGhlIGxvY2F0aW9u IHR5cGVzLiAgRGVmYXVsdCBpcyB0byBzdXBwcmVzcyB1bmtub3duIGF0dHJpYnV0ZXMsIHdoaWNo IGlzIGdvb2QsIGJ1dCBubyBleGlzdGluZyBlbGVtZW50IGhhcyB0aGUgc2FtZSBwb3RlbnRpYWwg Zm9yIGRhbWFnZSBhcyBhIHJlZmVyZW5jZS4NCg0KVGh1cywgd2UgbmVlZCB0byBkZWZpbmUgYSA8 cHJvdmlkZS1yZWZlcmVuY2U+IGV4dGVuc2lvbiB0byBwcmVzZW5jZSBwb2xpY3kuICBNb3Jlb3Zl ciwgdGhlIHJlbGF0ZWQgZGlzY3Vzc2lvbiBvbiB0aGUgaW1wbGljYXRpb25zIG9mIGluY2x1ZGlu ZyB0aGlzIGluIGEgcG9saWN5IG5lZWQgdG8gYmUgbWFkZSBjbGVhci4gIEJldHRlciB0aGF0IHRo YW4gcmVseSBvbiA8cHJvdmlkZS11bmtub3duLWF0dHJpYnV0ZT4gYW5kIHRoZSBhYmlsaXR5IG9m IHJ1bGUgbWFrZXJzIHRvIHJlY29nbml6ZSBhbGwgdGhlIHJpc2tzLg0KDQpNeSBpbnRlbnQgaXMg dG8gc3VibWl0IGEgZHJhZnQgdGhhdCBkZXNjcmliZXMgaG93IHRvIGluY2x1ZGUgYSByZWZlcmVu Y2UgaW4gYSBQSURGIGRvY3VtZW50IGFuZCBhbGwgdGhlIGNvbnNlcXVlbmNlcyBhcmlzaW5nIGZy b20gdGhhdC4NCg0KSSdkIGJlIGhhcHB5IHRvIGhlYXIgZnJvbSBzb21lb25lIHdobyBpcyB3aWxs aW5nIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSBvciBldmVuIHRvIHVuZGVydGFrZSB0aGUgZWZmb3J0 IHRoZW1zZWx2ZXMuDQoNCi0tTWFydGluDQoNClsxXSBUaHJlYWQgaGVhZDogPGh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXBjb3JlL2N1cnJlbnQvbXNnMDIyMDIuaHRtbD4N ClsyXSA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zaXBjb3JlLWxvY2F0 aW9uLWNvbnZleWFuY2U+DQpbM10gPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdh cmNpYS1nZW9wcml2LWluZGlyZWN0LXB1Ymxpc2g+IC4uLmFuZCBieSBraWxsLCBJIHJlYWxseSBt ZWFuIGl0LiAgVGhpcyBlZmZvcnQgaXMgbGlrZWx5IHN1YnN1bWVkIGJ5IHRoZSBwcm9wb3NlZCB3 b3JrLCB0aG91Z2ggYSBzZWN0aW9uIG9uIHRoZSBpbXBsaWNhdGlvbnMgc2VlbXMgYXBwcm9wcmlh dGUuDQpbNF0gRm9yIHRoZSBzYW1lIHJlYXNvbiwgb3VyIHByb2R1Y3QgZG9lcyBub3QgdXNlIHRo ZSA8ZGV2aWNlPiBlbGVtZW50LCBiZWNhdXNlIHRoYXQgcmVxdWlyZXMgYSBsaW5rYWdlIHRvIGRl dmljZSBpZGVudGl0eS4NCg== From wwwrun@rfc-editor.org Mon Apr 5 22:48:27 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19F5B3A68B0 for ; Mon, 5 Apr 2010 22:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mv-BJRbT0pFi for ; Mon, 5 Apr 2010 22:48:24 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id A85373A68AB for ; Mon, 5 Apr 2010 22:48:18 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 743B1E0799; Mon, 5 Apr 2010 22:48:12 -0700 (PDT) To: jdrosen@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, ben@nostrum.com, hisham.khartabil@gmail.com From: RFC Errata System Message-Id: <20100406054812.743B1E0799@rfc-editor.org> Date: Mon, 5 Apr 2010 22:48:12 -0700 (PDT) Cc: simple@ietf.org, martin.thomson@andrew.com, rfc-editor@rfc-editor.org Subject: [Simple] [Editorial Errata Reported] RFC4479 (2131) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 05:48:27 -0000 The following errata report has been submitted for RFC4479, "A Data Model for Presence". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4479&eid=2131 -------------------------------------- Type: Editorial Reported by: Martin Thomson Section: 7.1 Original Text ------------- Corrected Text -------------- Notes ----- The entity attribute of the element is mandatory. It contains a URI that identifies the presentity. The namespace prefix binding for "http://www.w3.org/2001/XMLSchema-instance" is not used in the example and need not appear. Not corrected here: the example uses an undefined URI scheme, mac:, to identify a device. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4479 (draft-ietf-simple-presence-data-model-07) -------------------------------------- Title : A Data Model for Presence Publication Date : July 2006 Author(s) : J. Rosenberg Category : PROPOSED STANDARD Source : SIP for Instant Messaging and Presence Leveraging Extensions Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From christer.holmberg@ericsson.com Tue Apr 6 10:23:54 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC733A695B for ; Tue, 6 Apr 2010 10:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.362 X-Spam-Level: X-Spam-Status: No, score=-4.362 tagged_above=-999 required=5 tests=[AWL=1.937, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5HVcd-oi4EH for ; Tue, 6 Apr 2010 10:23:53 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 020383A6969 for ; Tue, 6 Apr 2010 10:23:32 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-24-4bbb6e11cb46 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 2B.C0.23532.11E6BBB4; Tue, 6 Apr 2010 19:23:29 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 6 Apr 2010 19:23:28 +0200 From: Christer Holmberg To: Ben Campbell , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Tue, 6 Apr 2010 19:21:26 +0200 Thread-Topic: [Simple] Question on RFC 5438 Thread-Index: AcrRo6m2WVUNiIHgSyyxZhBmj2MgHAECezgM Message-ID: References: <1C21EA0F-703A-49B3-A7BC-055D44BC69F4@nostrum.com> , 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] Question on RFC 5438 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 17:23:54 -0000 Hi, >Let's back up a little bit. IMDN-route has nothing to do with SIP proxies,= and doesn't affect routing at the SIP layer in any way. It's is a CPIM he= ader, not a SIP header, and is theoretically not even available to a SIP pr= oxy. It could conceivably be encrypted. It might=20 >even be carried in non-SIP protocols for one or more steps along the way. > >These IMDN-Record-Route and IMDN-Route intermediaries are devices like mes= sage list exploders and store-and-forward servers. These devices were UASs = in the original MESSAGE request, and likely act as UAC's to forward the mes= sage somewhere else in an=20 >entirely new SIP transaction. > >If a endpoint or intermediary wants to send an IMDN that contains IMDN-Rou= te, it sends the IMDN to the first IMDN-Route entry. In SIP terms, that mea= ns the R-URI will be the first IMDN-Route entry. I guess that would work, but could you please tell we where in the RFC that= is described? In my opinion it is not clear, but I may of course have miss= ed something. Regards, Christer On Apr 1, 2010, at 6:29 AM, I=F1aki Baz Castillo wrote: > 2010/4/1 Christer Holmberg : > >>> Then, this means that the request will arrive to an >>> intermediary which previously added a IMDN-Record-Route, so >>> IMHO it MUST support routing based on IMDN-Route. This is >>> exactly the original question, right? >> >> Yes, that is the question. >> >> But, what if the UA e.g. routes all messages via some IMDN-unaware defau= lt outbound proxy? >> >> This is normally done by adding a Route header pointing towards the outb= ound proxy. Yes, the UA can do it also now, but the problem is that the out= bound proxy is then not able to forward the request, since it does not unde= rstand IMDN-Route. > > Right :( > > > >>> An intermediary receiving an IMDN checks the top IMDN-Route header >>> field. If that header field carries the intermediary address, the >>> intermediary removes that value and forwards the IMDN to >>> the address indicated in the new top IMDN-Route header field. If no add= itional >>> IMDN-Route header fields are present, the IMDN is forwarded to the >>> address in the CPIM To header field. >> >> ...which is also a little strange. Why not route to the address in the R= -URI? > > Ops, I didn't realize that "If no additional IMDN-Route header fields > are present, the IMDN is forwarded to the address in the CPIM To > header field". This is really annoying. > > > >>> 1) Usually proxies just allow Route headers for in-dialog >>> requests (as a security protection). >> >> I have seen numerous of cases where non-in-dialog requests (dialog estab= lishment requests, registration requests etc) have been sent with pre-defin= ed routes. > > Yes, there are cases but as they introduce some security risks in some > environments they are not allowed. > > >>> 2) It's cooler for the RFC authors to create two new headers rather tha= n just one. >> >> Sure. It's more sexy to re-new rather than re-use :) > > So we end with an unusable specification (again) :( > > > > -- > I=F1aki Baz Castillo > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple= From adam@nostrum.com Tue Apr 6 11:33:35 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6040B3A6AEC for ; Tue, 6 Apr 2010 11:33:35 -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.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaYV9MCgQrrQ for ; Tue, 6 Apr 2010 11:33:34 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id D8F5C28C152 for ; Tue, 6 Apr 2010 11:26:39 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o36IQWct060715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Apr 2010 13:26:33 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBB7CD8.3020504@nostrum.com> Date: Tue, 06 Apr 2010 13:26:32 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Christer Holmberg References: , <4BA00EA8.3010707@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040307040408070100060608" Cc: "'simple@ietf.org'" Subject: Re: [Simple] MSRP-ACM/SessMatch: Security Considerations and TLS usage X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 18:33:35 -0000 This is a multi-part message in MIME format. --------------040307040408070100060608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sorry it took me so long to get back to this. On 3/24/10 12:55, Mar 24, Christer Holmberg wrote: > Hi, > > >>> Could I get each of you to make a quick sanity check on the security considerations and TLS mutual authentication related >>> sections of the latest msrp-ACM and session matching drafts? There were a number of updates from the WGLC, and I want to >>> make sure we've not broken anything. The text in question is pretty short. >>> >> >> I could just be running low on sleep, but I can't begin to parse this sentence (from the security section of the sessmatch draft): >> >> >> Even if MSRP entities do not use the MSRP URI domain part to perform >> session matching, if the domain information is different in the SDP >> a=path attribute and the associated MSRP messages the MSRP entities >> might be able to determine whether one or more intermediaries have >> been inserted in the message path. >> >> I get lost in the stacked (very long) clauses. I'm not even certain what the main verb of the sentence is intended to be. Perhaps it >> would be clearer if it were broken up into several smaller sentences. >> > I agree the text is a little difficult to understand. I suggest replacing it with the following: > > "Since MSRP entities do not use the MSRP URI domain part to perform session matching, if intermediaries modify the SDP a=path attribute, but do not modify the corresponding information in the asscoiated MSRP messages, MSRP entities can by comparing the domain information determine that one or more intermediareis have been inserted in the message path." > > Is that more clear? > A little bit. Allow me to try to clarify it further. MSRP entities do not use the MSRP URL domain part to perform session matching. If intermediaries modify the "a=path" attribute in the SDP, but do not modify the corresponding information in the associated MSRP messages, then the endpoints can determine that such modifications have been performed by comparing the domain information in the SDP with the domain information in the MSRP messages. > ------------- > > >> In terms of what I would expect in a security considerations section, this is far too vague, and mostly involves hand-waving: >> >> If public certificates are used, a modification of the host part >> (without performing similar modifications in the associated MSRP >> messages) would in most cases trigger a certificate matching error, >> since the host part is used in order to match the certificate. >> >> Okay... and then? I think you need to point out that the MSRP session setup attempt fails under these circumstances. It is certainly >> outside the purview of this document to suggest that we discard the security properties of TLS wholesale. >> > True. That is not the intention. > > What about adding the following text to the end of the paragraph: > > ", and the MSRP session setup would fail. > Perhaps a new sentence at the end of the paragraph. "This mismatch would cause the MSRP session setup to fail." /a --------------040307040408070100060608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sorry it took me so long to get back to this.

On 3/24/10 12:55, Mar 24, Christer Holmberg wrote: 
Hi,

  
Could I get each of you to make a quick sanity check on the security considerations and TLS mutual authentication related 
sections of the latest msrp-ACM and session matching drafts? There were a number of updates from the WGLC, and I want to 
make sure we've not broken anything. The text in question is pretty short.
      

I could just be running low on sleep, but I can't begin to parse this sentence (from the security section of the sessmatch draft):


     Even if MSRP entities do not use the MSRP URI domain part to perform
     session matching, if the domain information is different in the SDP
     a=path attribute and the associated MSRP messages the MSRP entities
     might be able to determine whether one or more intermediaries have
     been inserted in the message path.

I get lost in the stacked (very long) clauses. I'm not even certain what the main verb of the sentence is intended to be. Perhaps it 
would be clearer if it were broken up into several smaller sentences.
    
I agree the text is a little difficult to understand. I suggest replacing it with the following:

"Since MSRP entities do not use the MSRP URI domain part to perform session matching, if intermediaries modify the SDP a=path attribute, but do not modify the corresponding information in the asscoiated MSRP messages, MSRP entities can by comparing the domain information determine that one or more intermediareis have been inserted in the message path." 

Is  that more clear?

A little bit. Allow me to try to clarify it further.

MSRP entities do not use the MSRP URL domain part to perform session matching. If intermediaries modify the "a=path" attribute in the SDP, but do not modify the corresponding information in the associated MSRP messages, then the endpoints can determine that such modifications have been performed by comparing the domain information in the SDP with the domain information in the MSRP messages.

-------------

  
In terms of what I would expect in a security considerations section, this is far too vague, and mostly involves hand-waving:

     If public certificates are used, a modification of the host part
     (without performing similar modifications in the associated MSRP
     messages) would in most cases trigger a certificate matching error,
     since the host part is used in order to match the certificate.

Okay... and then? I think you need to point out that the MSRP session setup attempt fails under these circumstances. It is certainly 
outside the purview of this document to suggest that we discard the security properties of TLS wholesale. 
    
True. That is not the intention.

What about adding the following text to the end of the paragraph:

        ", and the MSRP session setup would fail.

Perhaps a new sentence at the end of the paragraph. "This mismatch would cause the MSRP session setup to fail."


/a
--------------040307040408070100060608-- From adam@nostrum.com Tue Apr 6 11:34:43 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18823A6910 for ; Tue, 6 Apr 2010 11:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfPpRZmb38Li for ; Tue, 6 Apr 2010 11:34:41 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B6F0228C170 for ; Tue, 6 Apr 2010 11:29:12 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o36IT6QZ060883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Apr 2010 13:29:06 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBB7D72.5080303@nostrum.com> Date: Tue, 06 Apr 2010 13:29:06 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Christer Holmberg References: , <4BA00EA8.3010707@nostrum.com> , <222C25ED-326A-4C20-8003-DD84DC4F3B91@nostrum.com> , <08A820A9-761A-43D4-AD2B-95BD02D96DCE@nostrum.com> , In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'simple@ietf.org'" Subject: Re: [Simple] MSRP-ACM/SessMatch: Security Considerations and TLS usage X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 18:34:43 -0000 On 3/25/10 14:39, Mar 25, Christer Holmberg wrote: >>>>>>> This does not apply if the host part is modified between two MSRP relays, >>>>>>> >>>>>> since relays do not have access to the SDP information and use the >>>>>>> >>>>>> From-Path URI host for the certificate matching. >>>>>>> >>>>>> >>>>>>> >>>>>> Shouldn't this say "To-Path"? It's the entity forming the outgoing connection that verifies the server identity, right? >>>>>>> >>>>>> >>>>> >>>>>> >>>>> My understanding is that the From-Path is used, but I can double check that. >>>>>> >>>>> >>>>>> >>>>> Ben, can you verify whether the From-Path is used? >>>>>> >>>>> >>>>>> >>>>> I think both are used. The TLS client authenticates the server is the server it wants to talk to. That's done based on the >>>>>> >>>>> To-Path. >>>>>> >>>>> >>>> >>>>> >>>>Section 6.3 of 4976 says the following: >>>>> >>>> >>>>> >>>> "When a relay receives an AUTH request, the first thing it does is to >>>>> >>>> authenticate and authorize the previous hop and the client at the far >>>>> >>>> end. If there are no other relays between this relay and the client, >>>>> >>>> then these are the same thing. >>>>> >>>> >>>>> >>>> When the previous hop is a relay, authentication is done with TLS >>>>> >>>> using mutual authentication. If the TLS client presented a host >>>>> >>>> certificate, the relay checks that the subjectAltName in the >>>>> >>>> certificate of the TLS client matches the hostname in the first From- >>>>> >>>> Path URI." >>>>> >>>> >>>>> >>>>>> >>>>> 4976 also talks about receiving an_AUTH_ request over a mutually authenticated TLS connection, in which case the >>>>>> >>>>> TLS_server_ compares the client cert against the from-path. >>>>>> >>>>> >>>> >>>>> >>>> Correct. That is the text I am referring to above. >>>>> >>>> >>>>> >>>>>> >>>>> It seems to me that this should apply to the first request received on a connection, regardless of type--but I don't see any >>>>>> >>>>> similar language for non-AUTH requests. >>>>>> >>>>> >>>> >>>>> >>>>AUTH isn't sent between relays, is it? >>>>> >>>> >>> >>>> >>>It can be, when you have more than one relay on behalf of the same endpoint. >>>> >>> >> >>> >>Ok. >>> >> >>> >>But, regarding the From-Path issue, do you share my understanding (based on the text above)? >>> >> >>> >> >I think so, but let me restate to make sure I understand your intent correctly: When performing mutual authentication between MSRP relays, the TLS server >> >authenticates the TLS client by comparing the client certificate against the first URI in the From-Path header field of the first MSRP request it received. >> > That is my understanding, yes. > > Adam, are you ok with that explanation also? > Mostly. Based on Ben's comments, my understanding is that the connection will actually be verified using the To-Path (by the TLS client) any using the From-Path (by the TLS server). Perhaps "...and use the To-Path and From-Path hosts for certificate matching purposes." /a From ben@nostrum.com Tue Apr 6 11:36:51 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 272513A69BC for ; Tue, 6 Apr 2010 11:36:51 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zstFn3o9tbWq for ; Tue, 6 Apr 2010 11:36:49 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id C177628C12A for ; Tue, 6 Apr 2010 11:33:09 -0700 (PDT) Received: from [10.0.1.12] (adsl-68-94-8-111.dsl.rcsntx.swbell.net [68.94.8.111]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o36IX29o061186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 Apr 2010 13:33:03 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Ben Campbell In-Reply-To: Date: Tue, 6 Apr 2010 13:32:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <65FA8304-8A41-4D40-86C6-5F212F9D8CC1@nostrum.com> References: <1C21EA0F-703A-49B3-A7BC-055D44BC69F4@nostrum.com> , To: Christer Holmberg X-Mailer: Apple Mail (2.1078) Cc: Simple WG Subject: Re: [Simple] Question on RFC 5438 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 18:36:51 -0000 On Apr 6, 2010, at 12:21 PM, Christer Holmberg wrote: > Hi, >=20 >> Let's back up a little bit. IMDN-route has nothing to do with SIP = proxies, and doesn't affect routing at the SIP layer in any way. It's = is a CPIM header, not a SIP header, and is theoretically not even = available to a SIP proxy. It could conceivably be encrypted. It might=20 >> even be carried in non-SIP protocols for one or more steps along the = way. >>=20 >> These IMDN-Record-Route and IMDN-Route intermediaries are devices = like message list exploders and store-and-forward servers. These devices = were UASs in the original MESSAGE request, and likely act as UAC's to = forward the message somewhere else in an=20 >> entirely new SIP transaction. >>=20 >> If a endpoint or intermediary wants to send an IMDN that contains = IMDN-Route, it sends the IMDN to the first IMDN-Route entry. In SIP = terms, that means the R-URI will be the first IMDN-Route entry. >=20 > I guess that would work, but could you please tell we where in the RFC = that is described? In my opinion it is not clear, but I may of course = have missed something. >=20 Section 7.1.1, paragraph 4, and section 8 paragraph 5 each say that the = IMDN is sent to the topmost IMDN-Route header. It doesn't go into = details on how one constructs the R-URI. But that's pretty much what = "send to a URI" means in SIP. Section 12.1, paragraph 1 says that SIP proxies MUST NOT generate IMDNs = but MUST forward them like they would any other SIP request. > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 > On Apr 1, 2010, at 6:29 AM, I=F1aki Baz Castillo wrote: >=20 >> 2010/4/1 Christer Holmberg : >>=20 >>>> Then, this means that the request will arrive to an >>>> intermediary which previously added a IMDN-Record-Route, so >>>> IMHO it MUST support routing based on IMDN-Route. This is >>>> exactly the original question, right? >>>=20 >>> Yes, that is the question. >>>=20 >>> But, what if the UA e.g. routes all messages via some IMDN-unaware = default outbound proxy? >>>=20 >>> This is normally done by adding a Route header pointing towards the = outbound proxy. Yes, the UA can do it also now, but the problem is that = the outbound proxy is then not able to forward the request, since it = does not understand IMDN-Route. >>=20 >> Right :( >>=20 >>=20 >>=20 >>>> An intermediary receiving an IMDN checks the top IMDN-Route header >>>> field. If that header field carries the intermediary address, the >>>> intermediary removes that value and forwards the IMDN to >>>> the address indicated in the new top IMDN-Route header field. If no = additional >>>> IMDN-Route header fields are present, the IMDN is forwarded to the >>>> address in the CPIM To header field. >>>=20 >>> ...which is also a little strange. Why not route to the address in = the R-URI? >>=20 >> Ops, I didn't realize that "If no additional IMDN-Route header fields >> are present, the IMDN is forwarded to the address in the CPIM To >> header field". This is really annoying. >>=20 >>=20 >>=20 >>>> 1) Usually proxies just allow Route headers for in-dialog >>>> requests (as a security protection). >>>=20 >>> I have seen numerous of cases where non-in-dialog requests (dialog = establishment requests, registration requests etc) have been sent with = pre-defined routes. >>=20 >> Yes, there are cases but as they introduce some security risks in = some >> environments they are not allowed. >>=20 >>=20 >>>> 2) It's cooler for the RFC authors to create two new headers rather = than just one. >>>=20 >>> Sure. It's more sexy to re-new rather than re-use :) >>=20 >> So we end with an unusable specification (again) :( >>=20 >>=20 >>=20 >> -- >> I=F1aki Baz Castillo >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Tue Apr 6 14:11:08 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7B303A6A04 for ; Tue, 6 Apr 2010 14:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.757 X-Spam-Level: X-Spam-Status: No, score=-4.757 tagged_above=-999 required=5 tests=[AWL=1.242, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acpVCZRPJJjr for ; Tue, 6 Apr 2010 14:11:08 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 96DE83A69D7 for ; Tue, 6 Apr 2010 14:11:07 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-66-4bbba3671182 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 72.0E.23532.763ABBB4; Tue, 6 Apr 2010 23:11:04 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 6 Apr 2010 23:11:03 +0200 From: Christer Holmberg To: Adam Roach Date: Tue, 6 Apr 2010 23:08:12 +0200 Thread-Topic: MSRP-ACM/SessMatch: Security Considerations and TLS usage Thread-Index: AcrVtsVngOjKd8pDT66CPI9HBGWLxQAFn8eC Message-ID: References: , <4BA00EA8.3010707@nostrum.com> , <4BBB7CD8.3020504@nostrum.com> In-Reply-To: <4BBB7CD8.3020504@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "'simple@ietf.org'" Subject: Re: [Simple] MSRP-ACM/SessMatch: Security Considerations and TLS usage X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 21:11:09 -0000 Hi Adam, >Sorry it took me so long to get back to this. No problem - I know you're busy with the stuff going on in MARTINI etc :) Anyway, I am ok with your text suggestions below, and will incorporate them= in the next version of the draft. Thanks! Regards, Christer On 3/24/10 12:55, Mar 24, Christer Holmberg wrote: Hi, Could I get each of you to make a quick sanity check on the security consid= erations and TLS mutual authentication related sections of the latest msrp-ACM and session matching drafts? There were a n= umber of updates from the WGLC, and I want to make sure we've not broken anything. The text in question is pretty short. I could just be running low on sleep, but I can't begin to parse this sente= nce (from the security section of the sessmatch draft): Even if MSRP entities do not use the MSRP URI domain part to perform session matching, if the domain information is different in the SDP a=3Dpath attribute and the associated MSRP messages the MSRP entities might be able to determine whether one or more intermediaries have been inserted in the message path. I get lost in the stacked (very long) clauses. I'm not even certain what th= e main verb of the sentence is intended to be. Perhaps it would be clearer if it were broken up into several smaller sentences. I agree the text is a little difficult to understand. I suggest replacing i= t with the following: "Since MSRP entities do not use the MSRP URI domain part to perform session= matching, if intermediaries modify the SDP a=3Dpath attribute, but do not = modify the corresponding information in the asscoiated MSRP messages, MSRP = entities can by comparing the domain information determine that one or more= intermediareis have been inserted in the message path." Is that more clear? A little bit. Allow me to try to clarify it further. MSRP entities do not use the MSRP URL domain part to perform session matchi= ng. If intermediaries modify the "a=3Dpath" attribute in the SDP, but do no= t modify the corresponding information in the associated MSRP messages, the= n the endpoints can determine that such modifications have been performed b= y comparing the domain information in the SDP with the domain information i= n the MSRP messages. ------------- In terms of what I would expect in a security considerations section, this = is far too vague, and mostly involves hand-waving: If public certificates are used, a modification of the host part (without performing similar modifications in the associated MSRP messages) would in most cases trigger a certificate matching error, since the host part is used in order to match the certificate. Okay... and then? I think you need to point out that the MSRP session setup= attempt fails under these circumstances. It is certainly outside the purview of this document to suggest that we discard the securit= y properties of TLS wholesale. True. That is not the intention. What about adding the following text to the end of the paragraph: ", and the MSRP session setup would fail. Perhaps a new sentence at the end of the paragraph. "This mismatch would ca= use the MSRP session setup to fail." /a From adam@nostrum.com Tue Apr 6 16:53:15 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA803A69AB for ; Tue, 6 Apr 2010 16:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFG2ipH1CLHd for ; Tue, 6 Apr 2010 16:53:14 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 6008F3A6905 for ; Tue, 6 Apr 2010 16:53:14 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o36Nr6Xh084650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Apr 2010 18:53:06 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBBC962.5010204@nostrum.com> Date: Tue, 06 Apr 2010 18:53:06 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: "Thomson, Martin" References: <8B0A9FCBB9832F43971E38010638454F03E3F3060A@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E3F3060A@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Simple WG , "Peterson, Jon" Subject: Re: [Simple] By-reference and by-value X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 23:53:15 -0000 On 4/6/10 00:23, Apr 6, Thomson, Martin wrote: > My intent is to submit a draft that describes how to include a reference in a PIDF document and all the consequences arising from that. > > I'd be happy to hear from someone who is willing to provide assistance or even to undertake the effort themselves. > I would strongly encourage you to familiarize yourself with XML External Entities and XML Inclusions before you head down the path of inventing this particular wheel. I think you can both save yourself a lot of effort *and* leverage built-in features of the deployed XML libraries people are already using. See: http://www.w3.org/TR/REC-xml/#sec-external-ent http://www.w3.org/TR/xinclude/ /a From Martin.Thomson@andrew.com Tue Apr 6 17:37:23 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F423A6944 for ; Tue, 6 Apr 2010 17:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hlr1cxahtyRg for ; Tue, 6 Apr 2010 17:37:22 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 9C2EF3A62C1 for ; Tue, 6 Apr 2010 17:37:21 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:49080 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S16912417Ab0DGAhT (ORCPT ); Tue, 6 Apr 2010 19:37:19 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 6 Apr 2010 19:37:19 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 7 Apr 2010 08:37:15 +0800 From: "Thomson, Martin" To: Adam Roach Date: Wed, 7 Apr 2010 08:38:39 +0800 Thread-Topic: [Simple] By-reference and by-value Thread-Index: AcrV5FB3HH8ed6onTteIy5UnHRn7+QAA1QeQ Message-ID: <8B0A9FCBB9832F43971E38010638454F03E3F30734@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03E3F3060A@SISPE7MB1.commscope.com> <4BBBC962.5010204@nostrum.com> In-Reply-To: <4BBBC962.5010204@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: Simple WG , "Peterson, Jon" Subject: Re: [Simple] By-reference and by-value X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2010 00:37:23 -0000 QWRhbSB3cm90ZToNCj4gSSB3b3VsZCBzdHJvbmdseSBlbmNvdXJhZ2UgeW91IHRvIGZhbWlsaWFy aXplIHlvdXJzZWxmIHdpdGggWE1MIEV4dGVybmFsDQo+IEVudGl0aWVzIGFuZCBYTUwgSW5jbHVz aW9ucyBiZWZvcmUgeW91IGhlYWQgZG93biB0aGUgcGF0aCBvZiBpbnZlbnRpbmcNCj4gdGhpcyBw YXJ0aWN1bGFyIHdoZWVsLiANCg0KU2luY2UgdGhlIGhvc3QgZG9jdW1lbnQgYW5kIHJlZmVyZW5j ZWQgZG9jdW1lbnQgYXJlIHByZXNlbmNlIGRvY3VtZW50cywgWE1MIGV4dGVybmFsIGVudGl0aWVz IGFyZSBub3QgcmVhbGx5IHZpYWJsZS4gIEFkZGl0aW9uYWwgYXR0cmlidXRlcyB3b3VsZCBuZWVk IHRvIGJlIHVzZWQgdGhhdCB3b3VsZCBhbGxvdyB0aGUgcHJvY2Vzc29yIHRvIHNlbGVjdCB0aGUg Y29ycmVjdCBwb3J0aW9uIG9mIHRoZSByZWZlcmVuY2VkIGRvY3VtZW50Lg0KDQpUaGVyZSB3ZXJl IGEgbnVtYmVyIG9mIHJlYXNvbnMgd2h5IEkgZGlkbid0IGNvbnNpZGVyIHhpbmNsdWRlIHRvIGJl IGFuIG9wdGlvbi4NCg0KT25lIHJlYXNvbiB3YXMgdGhlIGZhY3QgdGhhdCBjb21wb3NpdGlvbiBu ZWVkcyB0byBiZSBwZXJmb3JtZWQgYnkgdGhlIGVudGl0eSB0aGF0IGRlcmVmZXJlbmNlcyB0aGUg VVJJLiAgSWYgYSBwdWJsaXNoZXIgd2VyZSB0byByZWZlcmVuY2UgYSBQSURGIGRvY3VtZW50IHdp dGhvdXQgc2VlaW5nIGl0LCBpdCB3b3VsZCBiZSBkaWZmaWN1bHQgdG8gY29uc3RydWN0IGFuIHhp bmNsdWRlIHN0YXRlbWVudC4NCg0KTWlndWVsIGFuZCBJIGhhZCBhIGxvbmcgZGlzY3Vzc2lvbiBv biBQSURGIGNvbXBvc2l0aW9uIHdoZW4gdGFsa2luZyBhYm91dCBpbmRpcmVjdCBwdWJsaXNoLiAg VGhlIGNvbmNsdXNpb24gb2YgdGhhdCBkaXNjdXNzaW9uIHdhcyB0aGF0IHdlIGNvdWxkIG5vdCBh Z3JlZSBvbiB3aGF0IHRoZSBkZXNpcmVkIG91dGNvbWVzIHdvdWxkIGJlLiAgSXQgd2FzIG9ubHkg YWZ0ZXIgSSB0YWxrZWQgd2l0aCB5b3UgYWJvdXQgdGhpcyB0aGF0IHlvdSBzdWdnZXN0ZWQgdGhh dCB3ZSBhdm9pZCBzcGVjaWZ5aW5nIGFueXRoaW5nIHJlbGF0aW5nIHRvIHRoZSBjb21wb3NpdGlv biBvZiB0aGUgZG9jdW1lbnRzLg0KDQpPdGhlciBtaW5vciBpc3N1ZXMgYXJpc2UsIHN1Y2ggYXMg dGhlIGFiaWxpdHkgb2YgYW4geGluY2x1ZGUgcHJvY2Vzc29yIHRvIGRlcmVmZXJlbmNlIHNpcDog VVJJcyBhbmQgZGVhbCB3aXRoIGR5bmFtaWMgY29udGVudC4gIA0KDQpJdCBzZWVtcyBlYXNpZXIg KGZyb20gYSBzcGVjaWZpY2F0aW9uIHN0YW5kcG9pbnQpIHRvIG1ha2UgdGhlIHJlZmVyZW5jZSAi c29mdCIuICBUaGF0IGlzLCB0aGUgcmVmZXJlbmNlIHNpbXBseSBzdGF0ZXMgdGhhdCB0aGlzIHBy ZXNlbnRpdHkgc2hhcmVzIHN0YXRlIHdpdGggdGhpcyBvdGhlciBwcmVzZW50aXR5LiAgV2hhdCBp bmZlcmVuY2VzIGFyZSBtYWRlIGZyb20gdGhpcyBhc3NlcnRpb24gYW5kIGFueSBzdWJzZXF1ZW50 IGNvbXBvc2l0aW9uIHdhcyB0byBiZSBsZWZ0IG91dCBvZiBzY29wZS4NCg0KLS1NYXJ0aW4NCg== From christer.holmberg@ericsson.com Wed Apr 7 06:07:41 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B06DF3A6828 for ; Wed, 7 Apr 2010 06:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.292 X-Spam-Level: X-Spam-Status: No, score=-3.292 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UiEvwQktHqI for ; Wed, 7 Apr 2010 06:07:41 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A3F313A67D1 for ; Wed, 7 Apr 2010 06:07:40 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-45-4bbc83980784 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 23.0F.23740.8938CBB4; Wed, 7 Apr 2010 15:07:37 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 7 Apr 2010 15:07:36 +0200 From: Christer Holmberg To: Adam Roach Date: Wed, 7 Apr 2010 15:07:36 +0200 Thread-Topic: MSRP-ACM/SessMatch: Security Considerations and TLS usage Thread-Index: AcrVtwxqN4HG1DXVTjC/30INOis2yAAnCUOA Message-ID: References: , <4BA00EA8.3010707@nostrum.com> , <222C25ED-326A-4C20-8003-DD84DC4F3B91@nostrum.com> , <08A820A9-761A-43D4-AD2B-95BD02D96DCE@nostrum.com> , <4BBB7D72.5080303@nostrum.com> In-Reply-To: <4BBB7D72.5080303@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-Brightmail-Tracker: AAAAAA== Cc: "'simple@ietf.org'" Subject: Re: [Simple] MSRP-ACM/SessMatch: Security Considerations and TLS usage X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2010 13:07:41 -0000 Hi,=20 >>Adam, are you ok with that explanation also? >> =20 > >Mostly. Based on Ben's comments, my understanding is that the=20 >connection will actually be verified using the To-Path (by=20 >the TLS client) any using the From-Path (by the TLS server).=20 >Perhaps "...and use the To-Path and From-Path hosts for=20 >certificate matching purposes." I will add that. Thanks! Regards, Christer From christer.holmberg@ericsson.com Thu Apr 8 00:55:22 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 219F63A6A01 for ; Thu, 8 Apr 2010 00:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.302 X-Spam-Level: X-Spam-Status: No, score=-3.302 tagged_above=-999 required=5 tests=[AWL=-0.704, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnVVnAqHr8qU for ; Thu, 8 Apr 2010 00:55:21 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 9C90D3A69EF for ; Thu, 8 Apr 2010 00:54:43 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-21-4bbd8bbf1f30 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 51.26.23740.FBB8DBB4; Thu, 8 Apr 2010 09:54:39 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 8 Apr 2010 09:54:38 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Thu, 8 Apr 2010 09:54:38 +0200 From: Christer Holmberg To: "'simple@ietf.org'" Date: Thu, 8 Apr 2010 09:54:38 +0200 Thread-Topic: Draft new versions: ACM and sessmatch Thread-Index: AcrW8L0zKDzHI7TwSpqlPyDdii2Kjw== Message-ID: 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_FF84A09F50A6DC48ACB6714F4666CC745E21C7CEE7ESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Simple] Draft new versions: ACM and sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2010 07:55:22 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC745E21C7CEE7ESESSCMS0354e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted new versions of the ACM (-07) draft and SESSMATCH (-04) draf= ts. ACM: There are no changes from the previous version. I did a new version in= order to make the idnit tool happy (the xml2rfc tool now also seems to get= the boilerplate stuff right, so no manual fixes are needed) SESSMATCH: I did the changes based on the outcome of Adam's WGLC comments. Regards, Christer --_000_FF84A09F50A6DC48ACB6714F4666CC745E21C7CEE7ESESSCMS0354e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
I've submitted new versions of the ACM (-07) draft an= d SESSMATCH (-04) drafts.
 
ACM: There are no changes from the previous version. = I did a new version in order to make the idnit tool happy (the xml2rfc tool= now also seems to get the boilerplate stuff right, so no manual fixes are = needed)
 
SESSMATCH: I did the changes based on the outcome of = Adam's WGLC comments.
 
Regards,
 
Christer
 
 --_000_FF84A09F50A6DC48ACB6714F4666CC745E21C7CEE7ESESSCMS0354e_-- From root@core3.amsl.com Thu Apr 8 01:00:01 2010 Return-Path: X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 54F493A69EE; Thu, 8 Apr 2010 01:00:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100408080001.54F493A69EE@core3.amsl.com> Date: Thu, 8 Apr 2010 01:00:01 -0700 (PDT) Cc: simple@ietf.org Subject: [Simple] I-D Action:draft-ietf-simple-msrp-acm-07.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2010 08:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : An Alternative Connection Model for the Message Session Relay Protocol (MSRP) Author(s) : C. Holmberg, S. Blau Filename : draft-ietf-simple-msrp-acm-07.txt Pages : 9 Date : 2010-04-08 This document defines an alternative connection model for Message Session Relay Protocol (MSRP) User Agents (UAs), which uses the connection-oriended media (COMEDIA) mechanism in order to create the MSRP transport connection. The model allows MSRP UAs behind Network Address Translators (NATs) to negotiate which UA will initiate the establishment of the TCP connection, in order for MSRP messages to traverse the NAT. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-acm-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-simple-msrp-acm-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-08005031.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Apr 8 01:00:01 2010 Return-Path: X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5E8593A69F5; Thu, 8 Apr 2010 01:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100408080001.5E8593A69F5@core3.amsl.com> Date: Thu, 8 Apr 2010 01:00:01 -0700 (PDT) Cc: simple@ietf.org Subject: [Simple] I-D Action:draft-ietf-simple-msrp-sessmatch-04.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2010 08:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Session Matching Update for the Message Session Relay Protocol (MSRP) Author(s) : C. Holmberg, S. Blau Filename : draft-ietf-simple-msrp-sessmatch-04.txt Pages : 6 Date : 2010-04-08 This document updates the session matching procedure defined in sections 5.4 and 7.3 of RFC 4975, so that an Message Session Relay Protocol (MSRP) User Agent (UA) only uses the session-id part of the MSRP URI in order to perform the consistency checks. The update allows intermediaries, Application Layer Gateways (ALGs), to modify the address information in the MSRP URI of the Session Description Protocol (SDP) a=path attribute, without the need for the intermediaries to terminate and do the correlating modifications in the associated MSRP messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-sessmatch-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-simple-msrp-sessmatch-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-08005325.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Apr 8 12:00:02 2010 Return-Path: X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4DD013A6AC4; Thu, 8 Apr 2010 12:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100408190002.4DD013A6AC4@core3.amsl.com> Date: Thu, 8 Apr 2010 12:00:02 -0700 (PDT) Cc: simple@ietf.org Subject: [Simple] I-D Action:draft-ietf-simple-chat-06.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2010 19:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Multi-party Chat Using the Message Session Relay Protocol (MSRP) Author(s) : A. Niemi, et al. Filename : draft-ietf-simple-chat-06.txt Pages : 30 Date : 2010-04-08 The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-simple-chat-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-08115525.I-D@ietf.org> --NextPart-- From geir.sandbakken@tandberg.com Thu Apr 8 12:07:37 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE0D63A6940 for ; Thu, 8 Apr 2010 12:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7v4MuJCBXe9 for ; Thu, 8 Apr 2010 12:07:36 -0700 (PDT) Received: from mail205.messagelabs.com (mail205.messagelabs.com [85.158.140.179]) by core3.amsl.com (Postfix) with SMTP id 9445E3A688C for ; Thu, 8 Apr 2010 12:07:31 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: geir.sandbakken@tandberg.com X-Msg-Ref: server-11.tower-205.messagelabs.com!1270753647!3538536!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 11227 invoked from network); 8 Apr 2010 19:07:27 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-11.tower-205.messagelabs.com with SMTP; 8 Apr 2010 19:07:27 -0000 Received: from ultra.eu.tandberg.int ([10.47.1.15]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Apr 2010 21:07:27 +0200 Received: from [10.47.2.227] (gaso-desktop.rd.tandberg.com [10.47.2.227]) by ultra.eu.tandberg.int (8.13.1/8.13.1) with ESMTP id o38J7RDO025699 for ; Thu, 8 Apr 2010 21:07:27 +0200 Message-ID: <4BBE2972.3000506@tandberg.com> Date: Thu, 08 Apr 2010 21:07:30 +0200 From: Geir Arne Sandbakken User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Simple Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 08 Apr 2010 19:07:27.0421 (UTC) FILETIME=[BAC27ED0:01CAD74E] Subject: [Simple] Multi-party Chat version 06 submitted X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2010 19:07:37 -0000 A new version of “Multi-party Chat Using the Message Session Relay Protocol (MSRP)” has been submitted. The new version can be found here: http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-06.txt Changes from version -05 from on the WGLC summary: - Changed Anonymous URI allocation and usage - Simplified Nickname examples only to utilize alice and bob as user part of SIP URIs - Various spelling and wording errors Geir Arne From ag@ag-projects.com Thu Apr 8 12:09:13 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 095853A68BE for ; Thu, 8 Apr 2010 12:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwIZHhkXRtd7 for ; Thu, 8 Apr 2010 12:09:12 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by core3.amsl.com (Postfix) with ESMTP id D64563A6940 for ; Thu, 8 Apr 2010 12:09:11 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 9BF79B01AE; Thu, 8 Apr 2010 21:09:07 +0200 (CEST) Received: from [192.168.1.124] (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 192E4B0191; Thu, 8 Apr 2010 21:09:07 +0200 (CEST) Message-Id: From: Adrian Georgescu To: Geir Arne Sandbakken In-Reply-To: <4BBE2972.3000506@tandberg.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Apr 2010 21:09:06 +0200 References: <4BBE2972.3000506@tandberg.com> X-Mailer: Apple Mail (2.936) Cc: Simple Subject: Re: [Simple] Multi-party Chat version 06 submitted X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2010 19:09:13 -0000 Good news! Adrian On Apr 8, 2010, at 9:07 PM, Geir Arne Sandbakken wrote: > A new version of =93Multi-party Chat Using the Message Session Relay =20= > Protocol (MSRP)=94 has been submitted. > > The new version can be found here: > http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-06.txt > > Changes from version -05 from on the WGLC summary: > - Changed Anonymous URI allocation and usage > - Simplified Nickname examples only to utilize alice and bob as user =20= > part of SIP URIs > - Various spelling and wording errors > > Geir Arne > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From ben@estacado.net Thu Apr 8 16:01:59 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A233A6967 for ; Thu, 8 Apr 2010 16:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U19E0pm3G--G for ; Thu, 8 Apr 2010 16:01:58 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 4AD823A6852 for ; Thu, 8 Apr 2010 16:01:56 -0700 (PDT) Received: from [10.0.1.12] (adsl-68-94-8-111.dsl.rcsntx.swbell.net [68.94.8.111]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o38N1eHh033762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Apr 2010 18:01:45 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-3-402719412 From: Ben Campbell In-Reply-To: Date: Thu, 8 Apr 2010 18:01:35 -0500 Message-Id: <3714450D-BC9E-4325-9E7B-551DC670F53F@estacado.net> References: To: Christer Holmberg X-Mailer: Apple Mail (2.1078) Cc: "'simple@ietf.org'" Subject: Re: [Simple] Draft new versions: ACM and sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2010 23:01:59 -0000 --Apple-Mail-3-402719412 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 (as individual) Hi Christer, I did a new detailed read of both drafts, and came up with a few new = comments. Some of these are on old text, so I apologize for not coming = up with them earlier. In my defense, I was trying to take a fresh look, = and consider the sort of comments we might get in an IETF last call. = They are all minor, and mostly editorial: ----------------------------- Comments on ACM-07: -- section 3,=20 Last sentence needs some elaboration. I think the important point is = that this should be supported for user agents that might be deployed = behind a NAT where they cannot accept inbound TCP connections, and = therefore could not accept MSRP sessions offered by a peer device = outside the NAT, right? -- Sections 4.* We need to be a little careful about normative language of the form of = "MSRP UAs MUST..." when that language is really scoped to "MSRP UAs = that support this extension MUST...". I certainly don't expect you to = say "MSRP UAs that support this extension" every single time, but I'm = afraid that sections could be quoted out of context. I see two reasonable ways to fix this. One would be to make sure each = section has some text that scopes the normative language to MSRP-ACM = UAs. Another, which might be less intrusive, would be to invent a new = term for UAs that support ACM (maybe "MSRP-ACM UA"?), define the term = early in the document (maybe in section 3), then use it consistently. = Although it wouldn't be a global replace, as there are some sections = (e.g. 4.4) that reasonably apply to all MSRP UAs. -- section 4.2, last bullet point: s/"NAT address:port"/"NAT address and port" -- section 4.2, first paragraph after bullet list: s/determinte/determine spurious quote at end. I suggest rewording the last sentence to the effect of "If SIP requests = crosses a SIP proxy before crossing a NAT,=85" -- section 4.2, "note" following first paragraph after the bullet list: Note is redundant with last sentence in previous paragraph. -- section 4.2, 2nd paragraph: Can you elaborate on the last sentence? -- section 4.2, 3rd paragraph: I'm not aware of anything in 4975 that says a UA always sends it's = certificate. If not doing mutual authn, then there's no reason to expect = the TLS client to send a client cert. --------------------------------- Comments on sessmatch-04: -- section 5, third paragraph, first 2 sentences: I think the meaning got a little confused here with all the = back-and-forth. Does the following say what you mean to say?: "With this update, MSRP entities no longer use the MSRP URI domain part = to perform session matching. But if intermediaries modify=85" On Apr 8, 2010, at 2:54 AM, Christer Holmberg wrote: > =20 > Hi, > =20 > I've submitted new versions of the ACM (-07) draft and SESSMATCH (-04) = drafts. > =20 > ACM: There are no changes from the previous version. I did a new = version in order to make the idnit tool happy (the xml2rfc tool now also = seems to get the boilerplate stuff right, so no manual fixes are needed) > =20 > SESSMATCH: I did the changes based on the outcome of Adam's WGLC = comments. > =20 > Regards, > =20 > Christer > =20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail-3-402719412 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
(as individual)

Hi = Christer,

I did a new detailed read of both = drafts, and came up with a few new comments. Some of these are on old = text, so I apologize for not coming up with them earlier. In my defense, = I was trying to take a fresh look, and consider the sort of comments we = might get in an IETF last call. They are all minor, and mostly = editorial:


-----------------------= ------
Comments on ACM-07:

-- section = 3, 

Last sentence needs some elaboration. = I think the important point is that this should be supported for user = agents that might be deployed behind a NAT where they cannot accept = inbound TCP connections, and therefore could not accept MSRP sessions = offered by a peer device outside the NAT, = right?

-- Sections = 4.*

We need to be a little careful about = normative language of the form of "MSRP UAs MUST..."  when that = language is really scoped to "MSRP UAs that support this extension = MUST...".  I certainly don't expect you to say "MSRP UAs that = support this extension" every single time, but I'm afraid that sections = could be quoted out of context.

I see two = reasonable ways to fix this. One would be to make sure each section has = some text that scopes the normative language to MSRP-ACM UAs. Another, = which might be less intrusive, would be to invent a new term for UAs = that support ACM (maybe "MSRP-ACM UA"?), define the term early in the = document (maybe in section 3), then use it consistently. Although it = wouldn't be a global replace, as there are some sections (e.g. 4.4) that = reasonably apply to all MSRP UAs.

-- section = 4.2, last bullet point:

s/"NAT = address:port"/"NAT address and port"

-- section = 4.2, first paragraph after bullet = list:

s/determinte/determine

=
spurious quote at end.

I suggest = rewording the last sentence to the effect of "If SIP requests crosses a = SIP proxy before crossing a NAT,=85"

-- section = 4.2, "note" following first paragraph after the bullet = list:

Note is redundant with last sentence in = previous paragraph.

-- section 4.2, 2nd = paragraph:

Can you elaborate on the last = sentence?

-- section 4.2, 3rd = paragraph:

I'm not aware of anything in 4975 = that says a UA always sends it's certificate. If not doing mutual authn, = then there's no reason to expect the TLS client to send a client = cert.

---------------------------------
Comments on sessmatch-04:

-- section 5, third = paragraph, first 2 sentences:

I think the = meaning got a little confused here with all the back-and-forth. Does the = following say what you mean to say?:

"With this = update, MSRP entities no longer use the MSRP URI domain part to perform = session matching. But if intermediaries = modify=85"



<= /div>




On Apr = 8, 2010, at 2:54 AM, Christer Holmberg wrote:

 
Hi,
 
I've submitted new = versions of the ACM (-07) draft and SESSMATCH (-04) = drafts.
 
ACM: There are no changes from the previous version. I did a = new version in order to make the idnit tool happy (the xml2rfc tool now = also seems to get the boilerplate stuff right, so no manual fixes are = needed)
 
SESSMATCH: I did the changes based on the outcome of Adam's = WGLC comments.
 
Regards,
 
Christer
 
_____________________________________= __________
Simple mailing list
Simple@ietf.org
https://www.ietf.org= /mailman/listinfo/simple

= --Apple-Mail-3-402719412-- From doolinwu@gmail.com Thu Apr 8 01:40:21 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4110F3A6933 for ; Thu, 8 Apr 2010 01:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-8TlnfAg4Js for ; Thu, 8 Apr 2010 01:40:20 -0700 (PDT) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id 69A323A67D9 for ; Thu, 8 Apr 2010 01:40:05 -0700 (PDT) Received: by ywh38 with SMTP id 38so1049030ywh.29 for ; Thu, 08 Apr 2010 01:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=pDTKsyS114vx9/UsgGbV4d2iN3cGM2ElnpfhYJ3ND7U=; b=AG3CLx6ONkHiw5aPwBVIAwnexwmldJ3OdpsnFYdATtm2s9p6oe2Bprr3IQ5leFhmS1 QxaCnL9h1cMrRQKfsjaPpKZaTkCEwG4HFPOqszZl+Sk2O9RhuHu3bCRvJslbBJDp3EOq rmUX7IzlxeYC7cHlV2k3WXvU4KkHDM8FBxSaQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=nOdvhFqYY0VY8tJiN6Pk910tvX6AyUkYijQPOR5AEtCMl5H4HM3UEnB1bwmUD/F6cM TUVAeaBaqhNtWns46j25lUrevpxHhM6fj1ITazHlgyh0eQV0ryeF9q9y2h/m4LnLeXcq G1rsdsmyRcqB/vMr1sg0kMg2dmo3TCT9Aa6lE= MIME-Version: 1.0 Received: by 10.231.162.70 with HTTP; Thu, 8 Apr 2010 01:39:58 -0700 (PDT) Date: Thu, 8 Apr 2010 16:39:58 +0800 Received: by 10.150.13.20 with SMTP id 20mr10411856ybm.170.1270715998741; Thu, 08 Apr 2010 01:39:58 -0700 (PDT) Message-ID: From: doolin wu To: simple@ietf.org Content-Type: multipart/alternative; boundary=000e0cd76164b728470483b59f36 Subject: [Simple] Hello SIMPLE X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 09 Apr 2010 01:26:16 -0000 --000e0cd76164b728470483b59f36 Content-Type: text/plain; charset=ISO-8859-1 Hello, Just join the mail list. Could someone tell me where can I get the new progress of SIMPLE? -- Steven Wu Teleca Mobile Solution --000e0cd76164b728470483b59f36 Content-Type: text/html; charset=ISO-8859-1 Hello,

Just join the mail list.
Could someone tell me where can I get the new progress of SIMPLE?

--
Steven Wu
Teleca Mobile Solution
--000e0cd76164b728470483b59f36-- From ben@nostrum.com Thu Apr 8 20:02:32 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04A6C3A6AD2 for ; Thu, 8 Apr 2010 20:02:32 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYz4YvV7HROc for ; Thu, 8 Apr 2010 20:02:31 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 9BDA03A6ACF for ; Thu, 8 Apr 2010 20:02:30 -0700 (PDT) Received: from [10.0.1.12] (adsl-68-94-8-111.dsl.rcsntx.swbell.net [68.94.8.111]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o3932JR4007399 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Apr 2010 22:02:19 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: Date: Thu, 8 Apr 2010 22:02:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <25C8A20C-08C1-4FC3-9483-2DEAC8454A50@nostrum.com> References: To: doolin wu X-Mailer: Apple Mail (2.1078) Cc: simple@ietf.org Subject: Re: [Simple] Hello SIMPLE X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 09 Apr 2010 03:02:32 -0000 Hello, and welcome. You can look at the work group charter. Unfortunately, the milestone = dates are well out of date, but the milestones themselves are reasonably = accurate: http://datatracker.ietf.org/wg/simple/charter/ There's a list of RFCs and drafts at: http://datatracker.ietf.org/wg/simple/ ... and mail list archives at: http://www.ietf.org/mail-archive/web/simple/current/maillist.html On Apr 8, 2010, at 3:39 AM, doolin wu wrote: > Hello, >=20 > Just join the mail list. > Could someone tell me where can I get the new progress of SIMPLE? >=20 > --=20 > Steven Wu > Teleca Mobile Solution > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From srikanthv@motorola.com Fri Apr 9 00:08:15 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44DC33A68D9 for ; Fri, 9 Apr 2010 00:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wm5ibyveQfag for ; Fri, 9 Apr 2010 00:08:14 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id 251AB3A6877 for ; Fri, 9 Apr 2010 00:08:14 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: srikanthv@motorola.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1270796889!25503588!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 5838 invoked from network); 9 Apr 2010 07:08:10 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Apr 2010 07:08:10 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o39789Q6011021 for ; Fri, 9 Apr 2010 00:08:09 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id o39789RY018708 for ; Fri, 9 Apr 2010 02:08:09 -0500 (CDT) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id o39787FB018702 for ; Fri, 9 Apr 2010 02:08:08 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Apr 2010 15:07:46 +0800 Message-ID: <608D7BFF0D57794785CBC2C440BC4FA105F226DA@ZMY16EXM67.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Sip-implementors] Question on RFC 4662 - Resource List Subscription thread-index: AcrXrwLi3dVos/nVS7Obkyid+mh1/wABBPyQ References: <608D7BFF0D57794785CBC2C440BC4FA105F22671@ZMY16EXM67.ds.mot.com> From: "Vavilapalli Srikanth-A19563" To: "Pandurangan R S" , X-CFilter-Loop: Reflected Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Simple] [Sip-implementors] Question on RFC 4662 - Resource List Subscription X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 09 Apr 2010 07:08:15 -0000 Forwarding to SIMPLE mailing list...=20 -----Original Message----- From: Pandurangan R S [mailto:pandurangan.r.s@gmail.com]=20 Sent: Friday, April 09, 2010 12:07 PM To: Vavilapalli Srikanth-A19563 Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Question on RFC 4662 - Resource List Subscription RFC 4662 states The third mandatory attribute is "fullState". The "fullState" attribute indicates whether the NOTIFY message contains information for every resource in the list. If it does, the value of the attribute is "true" (or "1"); otherwise, it is "false" (or "0"). The first NOTIFY sent in a subscription MUST contain full state, as must the first NOTIFY sent after receipt of a SUBSCRIBE request for the subscription. Why is it a required that first NOTIFY contains information for every resource in the list? I believe it can have a initial information (which tells the subscriber to get rid of any old info) and then build upon the data using further NOTIFYs. Any interop problems if the "fullState" flag is interpreted as "initialState" flag? On Fri, Apr 9, 2010 at 10:48 AM, Vavilapalli Srikanth-A19563 wrote: > Hi > > I have a question related to first NOTIFY being generated for a=20 > Resource List Subscription assuming where the all the entities support > only unreliable UDP transport and message size is limitied by path MTU > size (because of for ex. No support for UDP fragmentation by the=20 > intermediate routers on that network).. > > As per RFC 4662, The first NOTIFY sent in a subscription MUST contain=20 > full state, as must the first NOTIFY sent after receipt of a SUBSCRIBE > request for the subscription. And the "fullState" attribute indicates=20 > that the NOTIFY message contains information for every resource in the > list.. > > Assuming a user has subscribed to his buddy list of 100 to 150 users=20 > and MTU size is defined as 1500 Bytes, How to fit the "full state" > information (which contains the RLMI with all the the user URIs with=20 > the state of subscription + ZERO or more presence states of each=20 > resource in the list) in the first NOTIFY sent towards subscrier? > > Are there any well defined schemes to split such a BIG NOTIFY in to=20 > multiple NOTIFYs without violating the above RFC 4662 requirement? > > Regards > Srikanth > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > From srikanthv@motorola.com Fri Apr 9 00:22:01 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE8E33A687E for ; Fri, 9 Apr 2010 00:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qI-oC9zNXbAR for ; Fri, 9 Apr 2010 00:21:58 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id E2F7F3A698F for ; Fri, 9 Apr 2010 00:21:53 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: srikanthv@motorola.com X-Msg-Ref: server-2.tower-128.messagelabs.com!1270797709!10349255!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 26737 invoked from network); 9 Apr 2010 07:21:49 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-2.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Apr 2010 07:21:49 -0000 Received: from il27exr04.cig.mot.com ([10.17.196.73]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id o397Ln6k010426 for ; Fri, 9 Apr 2010 00:21:49 -0700 (MST) Received: from il27vts01 (il27vts01.cig.mot.com [10.17.196.85]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id o397Lmhg020065 for ; Fri, 9 Apr 2010 02:21:48 -0500 (CDT) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id o397Lldu020061 for ; Fri, 9 Apr 2010 02:21:48 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Apr 2010 15:21:25 +0800 Message-ID: <608D7BFF0D57794785CBC2C440BC4FA105F226E9@ZMY16EXM67.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Sip-implementors] Question on RFC 4662 - Resource List Subscription thread-index: AcrXrwLi3dVos/nVS7Obkyid+mh1/wABBPyQAACI3oA= References: <608D7BFF0D57794785CBC2C440BC4FA105F22671@ZMY16EXM67.ds.mot.com> From: "Vavilapalli Srikanth-A19563" To: X-CFilter-Loop: Reflected Subject: Re: [Simple] [Sip-implementors] Question on RFC 4662 - Resource List Subscription X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 09 Apr 2010 07:22:01 -0000 Forwarding to SIMPLE mailing list...=20 -----Original Message----- From: Pandurangan R S [mailto:pandurangan.r.s@gmail.com] Sent: Friday, April 09, 2010 12:07 PM To: Vavilapalli Srikanth-A19563 Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Question on RFC 4662 - Resource List Subscription RFC 4662 states The third mandatory attribute is "fullState". The "fullState" attribute indicates whether the NOTIFY message contains information for every resource in the list. If it does, the value of the attribute is "true" (or "1"); otherwise, it is "false" (or "0"). The first NOTIFY sent in a subscription MUST contain full state, as must the first NOTIFY sent after receipt of a SUBSCRIBE request for the subscription. Why is it a required that first NOTIFY contains information for every resource in the list? I believe it can have a initial information (which tells the subscriber to get rid of any old info) and then build upon the data using further NOTIFYs. Any interop problems if the "fullState" flag is interpreted as "initialState" flag? On Fri, Apr 9, 2010 at 10:48 AM, Vavilapalli Srikanth-A19563 wrote: > Hi > > I have a question related to first NOTIFY being generated for a=20 > Resource List Subscription assuming where the all the entities support > only unreliable UDP transport and message size is limitied by path MTU > size (because of for ex. No support for UDP fragmentation by the=20 > intermediate routers on that network).. > > As per RFC 4662, The first NOTIFY sent in a subscription MUST contain=20 > full state, as must the first NOTIFY sent after receipt of a SUBSCRIBE > request for the subscription. And the "fullState" attribute indicates=20 > that the NOTIFY message contains information for every resource in the > list.. > > Assuming a user has subscribed to his buddy list of 100 to 150 users=20 > and MTU size is defined as 1500 Bytes, How to fit the "full state" > information (which contains the RLMI with all the the user URIs with=20 > the state of subscription + ZERO or more presence states of each=20 > resource in the list) in the first NOTIFY sent towards subscrier? > > Are there any well defined schemes to split such a BIG NOTIFY in to=20 > multiple NOTIFYs without violating the above RFC 4662 requirement? > > Regards > Srikanth > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > From srikanthv@motorola.com Fri Apr 9 01:51:31 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82DAB3A67E7 for ; Fri, 9 Apr 2010 01:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfaPw6gGu9QD for ; Fri, 9 Apr 2010 01:51:30 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id BD1B43A697B for ; Fri, 9 Apr 2010 01:51:02 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: srikanthv@motorola.com X-Msg-Ref: server-9.tower-55.messagelabs.com!1270803057!82400799!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 22938 invoked from network); 9 Apr 2010 08:50:58 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Apr 2010 08:50:58 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o398ovsG028270 for ; Fri, 9 Apr 2010 01:50:57 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id o398ov0i000710 for ; Fri, 9 Apr 2010 03:50:57 -0500 (CDT) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id o398ourd000707 for ; Fri, 9 Apr 2010 03:50:56 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Apr 2010 16:50:33 +0800 Message-ID: <608D7BFF0D57794785CBC2C440BC4FA105F2271C@ZMY16EXM67.ds.mot.com> In-Reply-To: <608D7BFF0D57794785CBC2C440BC4FA105F226DA@ZMY16EXM67.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Simple] [Sip-implementors] Question on RFC 4662 - ResourceList Subscription thread-index: AcrXrwLi3dVos/nVS7Obkyid+mh1/wABBPyQAAL67fA= References: <608D7BFF0D57794785CBC2C440BC4FA105F22671@ZMY16EXM67.ds.mot.com> <608D7BFF0D57794785CBC2C440BC4FA105F226DA@ZMY16EXM67.ds.mot.com> From: "Vavilapalli Srikanth-A19563" To: "Pandurangan R S" , X-CFilter-Loop: Reflected Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Simple] [Sip-implementors] Question on RFC 4662 - ResourceList Subscription X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 09 Apr 2010 08:51:31 -0000 There was also an example given in RFC 4662 in Section 6 at Page 20.. 3. As is required by RFC 3265 [2], the RLS sends a NOTIFY immediately upon accepting the subscription. In this example, we are assuming that the local RLS is also an authority for presence information for the users in the "vancouver.example.com" domain. "*********The NOTIFY contains an RLMI document describing the entire buddy list (initial notifies require full state)*********", as well as presence information for the users about which it already knows. Buddy List at COM Liste der Freunde an COM Bob Smith Dave Jones Ed at NET My Friends at ORG Meine Freunde an ORG In the above example List "adam-buddies@pres.vancouver.example.com" contains members as=20 sip:bob@vancouver.example.com,=20 sip:dave@vancouver.example.com,=20 sip:ed@dallas.example.net and=20 sip:adam-friends@stockholm.example.org Not sure why RFC mandates/recommends to keep the entire buddy list info in the first NOTIFY..=20 =20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Vavilapalli Srikanth-A19563 Sent: Friday, April 09, 2010 12:38 PM To: Pandurangan R S; simple@ietf.org Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Simple] [Sip-implementors] Question on RFC 4662 - ResourceList Subscription Forwarding to SIMPLE mailing list...=20 -----Original Message----- From: Pandurangan R S [mailto:pandurangan.r.s@gmail.com] Sent: Friday, April 09, 2010 12:07 PM To: Vavilapalli Srikanth-A19563 Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Question on RFC 4662 - Resource List Subscription RFC 4662 states The third mandatory attribute is "fullState". The "fullState" attribute indicates whether the NOTIFY message contains information for every resource in the list. If it does, the value of the attribute is "true" (or "1"); otherwise, it is "false" (or "0"). The first NOTIFY sent in a subscription MUST contain full state, as must the first NOTIFY sent after receipt of a SUBSCRIBE request for the subscription. Why is it a required that first NOTIFY contains information for every resource in the list? I believe it can have a initial information (which tells the subscriber to get rid of any old info) and then build upon the data using further NOTIFYs. Any interop problems if the "fullState" flag is interpreted as "initialState" flag? On Fri, Apr 9, 2010 at 10:48 AM, Vavilapalli Srikanth-A19563 wrote: > Hi > > I have a question related to first NOTIFY being generated for a=20 > Resource List Subscription assuming where the all the entities support > only unreliable UDP transport and message size is limitied by path MTU > size (because of for ex. No support for UDP fragmentation by the=20 > intermediate routers on that network).. > > As per RFC 4662, The first NOTIFY sent in a subscription MUST contain=20 > full state, as must the first NOTIFY sent after receipt of a SUBSCRIBE > request for the subscription. And the "fullState" attribute indicates=20 > that the NOTIFY message contains information for every resource in the > list.. > > Assuming a user has subscribed to his buddy list of 100 to 150 users=20 > and MTU size is defined as 1500 Bytes, How to fit the "full state" > information (which contains the RLMI with all the the user URIs with=20 > the state of subscription + ZERO or more presence states of each=20 > resource in the list) in the first NOTIFY sent towards subscrier? > > Are there any well defined schemes to split such a BIG NOTIFY in to=20 > multiple NOTIFYs without violating the above RFC 4662 requirement? > > Regards > Srikanth > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From ibc@aliax.net Fri Apr 9 02:39:19 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2313A6A1E for ; Fri, 9 Apr 2010 02:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVykNoPVfIXB for ; Fri, 9 Apr 2010 02:39:19 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id E65723A6A69 for ; Fri, 9 Apr 2010 02:38:16 -0700 (PDT) Received: by pwj2 with SMTP id 2so2657459pwj.31 for ; Fri, 09 Apr 2010 02:38:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.141.3 with HTTP; Fri, 9 Apr 2010 02:38:09 -0700 (PDT) In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A44CD83@ZMY16EXM66.ds.mot.com> References: <608D7BFF0D57794785CBC2C440BC4FA105F22671@ZMY16EXM67.ds.mot.com> <608D7BFF0D57794785CBC2C440BC4FA105F226DA@ZMY16EXM67.ds.mot.com> <608D7BFF0D57794785CBC2C440BC4FA105F2271C@ZMY16EXM67.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A44CD83@ZMY16EXM66.ds.mot.com> Date: Fri, 9 Apr 2010 11:38:09 +0200 Received: by 10.140.55.17 with SMTP id d17mr1659884rva.209.1270805889802; Fri, 09 Apr 2010 02:38:09 -0700 (PDT) Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Avasarala Ranjit-A20990 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org, sip-implementors@lists.cs.columbia.edu Subject: Re: [Simple] [Sip-implementors] Question on RFC 4662 - ResourceListSubscription X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 09 Apr 2010 09:39:19 -0000 2010/4/9 Avasarala Ranjit-A20990 : > > It could be that they did not anticipate the buddy list to very large > one. Or it would be that the whole mechanism to mantain a buddylist with SIMPLE/XCAP is a pain, by handling two different protocols (SIP and HTTP) and a complex relationship between them (even more on the presence and XCAP server, as the communication betweeen them is mostly "undefined"). So, it's supposed that HTTP/XCAP is used to allow SIP UDP as HTTP allows large documents, but later RFC 4662 itself makes mandatory to notify the entire (large) document the first time. Annoying. --=20 I=C3=B1aki Baz Castillo From keith.drage@alcatel-lucent.com Fri Apr 9 03:53:10 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A9B3A688E for ; Fri, 9 Apr 2010 03:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.519 X-Spam-Level: X-Spam-Status: No, score=-3.519 tagged_above=-999 required=5 tests=[AWL=-1.270, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCbsz506Edwg for ; Fri, 9 Apr 2010 03:53:09 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 71AD03A6407 for ; Fri, 9 Apr 2010 03:53:09 -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 o39Aqnpt030767 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 9 Apr 2010 12:53:01 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 9 Apr 2010 12:52:53 +0200 From: "DRAGE, Keith (Keith)" To: Ben Campbell , doolin wu Date: Fri, 9 Apr 2010 12:52:49 +0200 Thread-Topic: [Simple] Hello SIMPLE Thread-Index: AcrXkRpZb6aP9SGOTni2vgFrb6lfQQAQUhXw Message-ID: References: <25C8A20C-08C1-4FC3-9483-2DEAC8454A50@nostrum.com> In-Reply-To: <25C8A20C-08C1-4FC3-9483-2DEAC8454A50@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.64 on 155.132.188.80 Cc: "simple@ietf.org" Subject: Re: [Simple] Hello SIMPLE X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 09 Apr 2010 10:53:10 -0000 The tools page for the WG also gives some information: http://tools.ietf.org/wg/simple/ Much of this is what is in the datatracker charter page, but it does tell y= ou quicker about the dead and expired documents. It is a further search on = datatracker to get you these. regards Keith=20 > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Ben Campbell > Sent: Friday, April 09, 2010 4:02 AM > To: doolin wu > Cc: simple@ietf.org > Subject: Re: [Simple] Hello SIMPLE >=20 > Hello, and welcome. >=20 > You can look at the work group charter. Unfortunately, the=20 > milestone dates are well out of date, but the milestones=20 > themselves are reasonably accurate: >=20 > http://datatracker.ietf.org/wg/simple/charter/ >=20 > There's a list of RFCs and drafts at: >=20 > http://datatracker.ietf.org/wg/simple/ >=20 > ... and mail list archives at: >=20 > http://www.ietf.org/mail-archive/web/simple/current/maillist.html >=20 >=20 >=20 > On Apr 8, 2010, at 3:39 AM, doolin wu wrote: >=20 > > Hello, > >=20 > > Just join the mail list. > > Could someone tell me where can I get the new progress of SIMPLE? > >=20 > > -- > > Steven Wu > > Teleca Mobile Solution > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > = From ibc@aliax.net Fri Apr 9 04:19:18 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 653703A68EB for ; Fri, 9 Apr 2010 04:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.029 X-Spam-Level: ** X-Spam-Status: No, score=2.029 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKoLA0V7S7oU for ; Fri, 9 Apr 2010 04:19:17 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id E98853A688E for ; Fri, 9 Apr 2010 04:19:11 -0700 (PDT) Received: by pvf33 with SMTP id 33so1142582pvf.31 for ; Fri, 09 Apr 2010 04:19:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.141.3 with HTTP; Fri, 9 Apr 2010 04:19:05 -0700 (PDT) In-Reply-To: References: Date: Fri, 9 Apr 2010 13:19:05 +0200 Received: by 10.140.55.17 with SMTP id d17mr1756079rva.209.1270811946027; Fri, 09 Apr 2010 04:19:06 -0700 (PDT) Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: simple@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Simple] Hello SIMPLE X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 09 Apr 2010 11:19:18 -0000 2010/4/8 doolin wu : > Hello, > > Just join the mail list. > Could someone tell me where can I get the new progress of SIMPLE? Do you mean progress about SIMPLE specifications? or about SIMPLE implementations in the real world? For the first question (SIMPLE specifications) there are a lot, but most of them not enough reliable or strict, so other organizations as OMA/RCS take them and add extra layers of specifications to get something usable (but not so usable in fact, as the final RCS specifications provide less features than MSN 8 years ago). For the second question (SIMPLE implementations in the real world) there is no interest at all in implementing most of the SIMPLE specifications, nobody in Internet wants them as there are other protocols (as XMPP) much more reliable, powerful and easy to implement (without mixing two different protocols, SIP and HTTP, in order to mantain a simple buddylist): http://oversip.net/public/XMPP.jpeg For sure just IMS is interested in SIMPLE/XCAP/XDM architecture as they like a lot the complex diagrams and message flows: http://oversip.net/public/SIP_SIMPLE_OMA.jpeg I have no doubt about why Google and Facebook have chosen XMPP. It has been easier for Google to add voice feature to XMPP rather than using SIP (mature voice specs) having to implement SIMPLE stuf for presence/IM. But well, does somebody care that no one innovative provider in Internet (so far from 3GPP operators) is interested in SIMPLE? I'm really worried about it, and IMHO the way is not adding more and more drafts about xcap-diff and such unuseful and complex stuf. The core of SIMPLE/XCAP (in presence terms) is a pain IMHO, and adding more and more drafts over it will fix nothing. Sorry for being so rude in my words, but this is what I think after long time dealing and implementing most of the SIMPLE/XCAP specifications (for presence), so I think I do know what I'm speaking about. Regards. --=20 I=C3=B1aki Baz Castillo From pkyzivat@cisco.com Fri Apr 9 07:43:15 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81DA93A68A0 for ; Fri, 9 Apr 2010 07:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.408 X-Spam-Level: X-Spam-Status: No, score=-10.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jz+fwSOk5Dcu for ; Fri, 9 Apr 2010 07:43:14 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 68BCE3A68C0 for ; Fri, 9 Apr 2010 07:42:44 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABPavktAZnwM/2dsb2JhbACbPHGhcpkyhQkEhis X-IronPort-AV: E=Sophos;i="4.52,177,1270425600"; d="scan'208";a="100393461" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 09 Apr 2010 14:42:40 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o39EgefZ022697; Fri, 9 Apr 2010 14:42:40 GMT Message-ID: <4BBF3CDB.2070602@cisco.com> Date: Fri, 09 Apr 2010 10:42:35 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Avasarala Ranjit-A20990 References: <608D7BFF0D57794785CBC2C440BC4FA105F22671@ZMY16EXM67.ds.mot.com><608D7BFF0D57794785CBC2C440BC4FA105F226DA@ZMY16EXM67.ds.mot.com> <608D7BFF0D57794785CBC2C440BC4FA105F2271C@ZMY16EXM67.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A44CD83@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A44CD83@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pandurangan R S , simple@ietf.org, sip-implementors@lists.cs.columbia.edu Subject: Re: [Simple] [Sip-implementors] Question on RFC 4662 - ResourceListSubscription X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 09 Apr 2010 14:43:15 -0000 Avasarala Ranjit-A20990 wrote: > It could be that they did not anticipate the buddy list to very large > one. Or it could be that they expected that the implementors would support TCP, as 3261 requires them to do. Thanks, Paul > Regards > Ranjit > > -----Original Message----- > From: sip-implementors-bounces@lists.cs.columbia.edu > [mailto:sip-implementors-bounces@lists.cs.columbia.edu] On Behalf Of > Vavilapalli Srikanth-A19563 > Sent: Friday, April 09, 2010 2:21 PM > To: Pandurangan R S; simple@ietf.org > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] [Simple] Question on RFC 4662 - > ResourceListSubscription > > There was also an example given in RFC 4662 in Section 6 at Page 20.. > > 3. As is required by RFC 3265 [2], the RLS sends a NOTIFY immediately > upon accepting the subscription. In this example, we are assuming that > the local RLS is also an authority for presence information for the > users in the "vancouver.example.com" domain. "*********The NOTIFY > contains an RLMI document describing the entire buddy list (initial > notifies require full state)*********", as well as presence information > for the users about which it already knows. > > > uri="sip:adam-friends@pres.vancouver.example.com" > version="1" fullState="true"> > Buddy List at COM > Liste der Freunde an COM > > Bob Smith > cid="bUZBsM@pres.vancouver.example.com"/> > > > Dave Jones > cid="ZvSvkz@pres.vancouver.example.com"/> > > > Ed at NET > > > My Friends at ORG > Meine Freunde an ORG > > > > In the above example List "adam-buddies@pres.vancouver.example.com" > contains members as > sip:bob@vancouver.example.com, > sip:dave@vancouver.example.com, > sip:ed@dallas.example.net and > sip:adam-friends@stockholm.example.org > > > Not sure why RFC mandates/recommends to keep the entire buddy list info > in the first NOTIFY.. > > > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Vavilapalli Srikanth-A19563 > Sent: Friday, April 09, 2010 12:38 PM > To: Pandurangan R S; simple@ietf.org > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Simple] [Sip-implementors] Question on RFC 4662 - > ResourceList Subscription > > Forwarding to SIMPLE mailing list... > > -----Original Message----- > From: Pandurangan R S [mailto:pandurangan.r.s@gmail.com] > Sent: Friday, April 09, 2010 12:07 PM > To: Vavilapalli Srikanth-A19563 > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] Question on RFC 4662 - Resource List > Subscription > > RFC 4662 states > > The third mandatory attribute is "fullState". The "fullState" > attribute indicates whether the NOTIFY message contains information > for every resource in the list. If it does, the value of the > attribute is "true" (or "1"); otherwise, it is "false" (or "0"). The > first NOTIFY sent in a subscription MUST contain full state, as must > the first NOTIFY sent after receipt of a SUBSCRIBE request for the > subscription. > > Why is it a required that first NOTIFY contains information for every > resource in the list? I believe it can have a initial information (which > tells the subscriber to get rid of any old info) and then build upon the > data using further NOTIFYs. > > Any interop problems if the "fullState" flag is interpreted as > "initialState" flag? > > On Fri, Apr 9, 2010 at 10:48 AM, Vavilapalli Srikanth-A19563 > wrote: >> Hi >> >> I have a question related to first NOTIFY being generated for a >> Resource List Subscription assuming where the all the entities support > >> only unreliable UDP transport and message size is limitied by path MTU > >> size (because of for ex. No support for UDP fragmentation by the >> intermediate routers on that network).. >> >> As per RFC 4662, The first NOTIFY sent in a subscription MUST contain >> full state, as must the first NOTIFY sent after receipt of a SUBSCRIBE > >> request for the subscription. And the "fullState" attribute indicates >> that the NOTIFY message contains information for every resource in the > >> list.. >> >> Assuming a user has subscribed to his buddy list of 100 to 150 users >> and MTU size is defined as 1500 Bytes, How to fit the "full state" >> information (which contains the RLMI with all the the user URIs with >> the state of subscription + ZERO or more presence states of each >> resource in the list) in the first NOTIFY sent towards subscrier? >> >> Are there any well defined schemes to split such a BIG NOTIFY in to >> multiple NOTIFYs without violating the above RFC 4662 requirement? >> >> Regards >> Srikanth >> >> _______________________________________________ >> Sip-implementors mailing list >> Sip-implementors@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > From ibc@aliax.net Fri Apr 9 08:09:29 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 090973A6874 for ; Fri, 9 Apr 2010 08:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j91EqaWTVlwG for ; Fri, 9 Apr 2010 08:09:28 -0700 (PDT) Received: from mail-pz0-f194.google.com (mail-pz0-f194.google.com [209.85.222.194]) by core3.amsl.com (Postfix) with ESMTP id 5C9A33A683A for ; Fri, 9 Apr 2010 08:09:28 -0700 (PDT) Received: by pzk32 with SMTP id 32so544978pzk.31 for ; Fri, 09 Apr 2010 08:09:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.141.3 with HTTP; Fri, 9 Apr 2010 08:09:22 -0700 (PDT) In-Reply-To: <4BBF3CDB.2070602@cisco.com> References: <608D7BFF0D57794785CBC2C440BC4FA105F22671@ZMY16EXM67.ds.mot.com> <608D7BFF0D57794785CBC2C440BC4FA105F226DA@ZMY16EXM67.ds.mot.com> <608D7BFF0D57794785CBC2C440BC4FA105F2271C@ZMY16EXM67.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A44CD83@ZMY16EXM66.ds.mot.com> <4BBF3CDB.2070602@cisco.com> Date: Fri, 9 Apr 2010 17:09:22 +0200 Received: by 10.140.55.9 with SMTP id d9mr310193rva.94.1270825762268; Fri, 09 Apr 2010 08:09:22 -0700 (PDT) Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sip-implementors@lists.cs.columbia.edu, Avasarala Ranjit-A20990 , simple@ietf.org Subject: Re: [Simple] [Sip-implementors] Question on RFC 4662 - ResourceListSubscription X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 09 Apr 2010 15:09:29 -0000 2010/4/9 Paul Kyzivat : > Avasarala Ranjit-A20990 wrote: >> It could be that they did not anticipate the buddy list to very large >> one. > > Or it could be that they expected that the implementors would support > TCP, as 3261 requires them to do. Then, the pain of HTTP/XCAP wouldn't be required, just a new SIP method to store info in the presence server permanently. --=20 I=C3=B1aki Baz Castillo From ben@nostrum.com Fri Apr 9 09:19:16 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1936E3A68B3 for ; Fri, 9 Apr 2010 09:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUh65S0tedbe for ; Fri, 9 Apr 2010 09:19:15 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 392373A6938 for ; Fri, 9 Apr 2010 09:19:12 -0700 (PDT) Received: from dn3-174.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o39GJ6pa070534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 9 Apr 2010 11:19:06 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1078) From: Ben Campbell In-Reply-To: Date: Fri, 9 Apr 2010 11:19:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <776E3173-01ED-4C25-81B1-EEEBDF631E38@nostrum.com> References: <608D7BFF0D57794785CBC2C440BC4FA105F22671@ZMY16EXM67.ds.mot.com> <608D7BFF0D57794785CBC2C440BC4FA105F226DA@ZMY16EXM67.ds.mot.com> <608D7BFF0D57794785CBC2C440BC4FA105F2271C@ZMY16EXM67.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A44CD83@ZMY16EXM66.ds.mot.com> <4BBF3CDB.2070602@cisco.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Simple WG X-Mailer: Apple Mail (2.1078) Subject: Re: [Simple] [Sip-implementors] Question on RFC 4662 - ResourceListSubscription X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 09 Apr 2010 16:19:16 -0000 The decision to use XCAP rather than SIP for provisioning this sort of = thing reflects work group consensus after a lot of discussion. People = are certainly welcome to propose new work in SIMPLE, DISPATCH, or = elsewhere. But unless you plan to make a concrete proposal for new work, = please don't use the SIMPLE list to rehash old points of consensus. Thanks! Ben. On Apr 9, 2010, at 10:09 AM, I=F1aki Baz Castillo wrote: > 2010/4/9 Paul Kyzivat : >> Avasarala Ranjit-A20990 wrote: >>> It could be that they did not anticipate the buddy list to very = large >>> one. >>=20 >> Or it could be that they expected that the implementors would support >> TCP, as 3261 requires them to do. >=20 > Then, the pain of HTTP/XCAP wouldn't be required, just a new SIP > method to store info in the presence server permanently. >=20 >=20 >=20 > --=20 > I=F1aki Baz Castillo > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ibc@aliax.net Fri Apr 9 10:33:36 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89B0A3A688E for ; Fri, 9 Apr 2010 10:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.031 X-Spam-Level: X-Spam-Status: No, score=-1.031 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDE4Z3bzVf8U for ; Fri, 9 Apr 2010 10:33:35 -0700 (PDT) Received: from mail-pz0-f191.google.com (mail-pz0-f191.google.com [209.85.222.191]) by core3.amsl.com (Postfix) with ESMTP id 5EE173A68AE for ; Fri, 9 Apr 2010 10:33:31 -0700 (PDT) Received: by pzk29 with SMTP id 29so3049160pzk.29 for ; Fri, 09 Apr 2010 10:33:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.141.3 with HTTP; Fri, 9 Apr 2010 10:33:24 -0700 (PDT) In-Reply-To: <776E3173-01ED-4C25-81B1-EEEBDF631E38@nostrum.com> References: <608D7BFF0D57794785CBC2C440BC4FA105F22671@ZMY16EXM67.ds.mot.com> <608D7BFF0D57794785CBC2C440BC4FA105F226DA@ZMY16EXM67.ds.mot.com> <608D7BFF0D57794785CBC2C440BC4FA105F2271C@ZMY16EXM67.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A44CD83@ZMY16EXM66.ds.mot.com> <4BBF3CDB.2070602@cisco.com> <776E3173-01ED-4C25-81B1-EEEBDF631E38@nostrum.com> Date: Fri, 9 Apr 2010 19:33:24 +0200 Received: by 10.140.180.6 with SMTP id c6mr683529rvf.41.1270834404309; Fri, 09 Apr 2010 10:33:24 -0700 (PDT) Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: Simple WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Simple] [Sip-implementors] Question on RFC 4662 - ResourceListSubscription X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 09 Apr 2010 17:33:36 -0000 2010/4/9 Ben Campbell : > > > The decision to use XCAP rather than SIP for provisioning this sort of th= ing reflects work group consensus after a lot of discussion. People are cer= tainly welcome to propose new work in SIMPLE, DISPATCH, or elsewhere. But u= nless you plan to make a concrete proposal for new work, please don't use t= he SIMPLE list to rehash old points of consensus. SIP is (or should be) IMHO enough powerful to carry information about buddies and permissions without the need of using other protocols which makes the whole specification complex. For sure I'll propose something very different, just based on SIP protocol, in a future :) --=20 I=C3=B1aki Baz Castillo From dworley@avaya.com Fri Apr 9 07:48:24 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7AEF3A6925 for ; Fri, 9 Apr 2010 07:48:24 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5C6rj6XW-j6 for ; Fri, 9 Apr 2010 07:48:24 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 5F7FD3A6903 for ; Fri, 9 Apr 2010 07:48:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,177,1270440000"; d="scan'208";a="212821325" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Apr 2010 10:48:04 -0400 X-IronPort-AV: E=Sophos;i="4.52,177,1270440000"; d="scan'208";a="450253873" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 Apr 2010 10:47:24 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.214]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 9 Apr 2010 10:47:24 -0400 From: "Worley, Dale R (Dale)" To: Vavilapalli Srikanth-A19563 , Pandurangan R S , "simple@ietf.org" Date: Fri, 9 Apr 2010 10:45:39 -0400 Thread-Topic: [Sip-implementors] [Simple] Question on RFC 4662 - ResourceList Subscription Thread-Index: AcrXrwLi3dVos/nVS7Obkyid+mh1/wABBPyQAAL67fAADRP3gQ== Message-ID: References: <608D7BFF0D57794785CBC2C440BC4FA105F22671@ZMY16EXM67.ds.mot.com> <608D7BFF0D57794785CBC2C440BC4FA105F226DA@ZMY16EXM67.ds.mot.com>, <608D7BFF0D57794785CBC2C440BC4FA105F2271C@ZMY16EXM67.ds.mot.com> In-Reply-To: <608D7BFF0D57794785CBC2C440BC4FA105F2271C@ZMY16EXM67.ds.mot.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-Mailman-Approved-At: Fri, 09 Apr 2010 13:57:04 -0700 Cc: "sip-implementors@lists.cs.columbia.edu" Subject: Re: [Simple] [Sip-implementors] Question on RFC 4662 - ResourceList Subscription X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 09 Apr 2010 14:48:24 -0000 ________________________________________ From: sip-implementors-bounces@lists.cs.columbia.edu [sip-implementors-boun= ces@lists.cs.columbia.edu] On Behalf Of Vavilapalli Srikanth-A19563 [srikan= thv@motorola.com] Not sure why RFC mandates/recommends to keep the entire buddy list info in the first NOTIFY.. _______________________________________________ I suspect it is so that the subscriber will know what resources the list co= ntains. If information about the resources could be sent completely increm= entally, then the subscriber might have to wait a long time before it even = knew the number of resources in the list. Dale From ranjit@motorola.com Fri Apr 9 01:54:21 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 442943A69CB for ; Fri, 9 Apr 2010 01:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.369 X-Spam-Level: X-Spam-Status: No, score=-5.369 tagged_above=-999 required=5 tests=[AWL=1.231, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOGN5jka9pKg for ; Fri, 9 Apr 2010 01:54:20 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 1D7213A69C8 for ; Fri, 9 Apr 2010 01:54:04 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-8.tower-55.messagelabs.com!1270803239!102220691!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 21656 invoked from network); 9 Apr 2010 08:53:59 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Apr 2010 08:53:59 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o398rxab028773 for ; Fri, 9 Apr 2010 01:53:59 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id o398rxMB001107 for ; Fri, 9 Apr 2010 03:53:59 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id o398rvk2001104 for ; Fri, 9 Apr 2010 03:53:58 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Apr 2010 16:53:35 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A44CD83@ZMY16EXM66.ds.mot.com> In-Reply-To: <608D7BFF0D57794785CBC2C440BC4FA105F2271C@ZMY16EXM67.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip-implementors] [Simple] Question on RFC 4662 - ResourceListSubscription thread-index: AcrXrwLi3dVos/nVS7Obkyid+mh1/wABBPyQAAL67fAAAMOBYA== References: <608D7BFF0D57794785CBC2C440BC4FA105F22671@ZMY16EXM67.ds.mot.com><608D7BFF0D57794785CBC2C440BC4FA105F226DA@ZMY16EXM67.ds.mot.com> <608D7BFF0D57794785CBC2C440BC4FA105F2271C@ZMY16EXM67.ds.mot.com> From: "Avasarala Ranjit-A20990" To: "Vavilapalli Srikanth-A19563" , "Pandurangan R S" , X-CFilter-Loop: Reflected X-Mailman-Approved-At: Fri, 09 Apr 2010 13:57:17 -0700 Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Simple] [Sip-implementors] Question on RFC 4662 - ResourceListSubscription X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 09 Apr 2010 08:54:21 -0000 It could be that they did not anticipate the buddy list to very large one. =20 Regards Ranjit -----Original Message----- From: sip-implementors-bounces@lists.cs.columbia.edu [mailto:sip-implementors-bounces@lists.cs.columbia.edu] On Behalf Of Vavilapalli Srikanth-A19563 Sent: Friday, April 09, 2010 2:21 PM To: Pandurangan R S; simple@ietf.org Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] [Simple] Question on RFC 4662 - ResourceListSubscription There was also an example given in RFC 4662 in Section 6 at Page 20.. 3. As is required by RFC 3265 [2], the RLS sends a NOTIFY immediately upon accepting the subscription. In this example, we are assuming that the local RLS is also an authority for presence information for the users in the "vancouver.example.com" domain. "*********The NOTIFY contains an RLMI document describing the entire buddy list (initial notifies require full state)*********", as well as presence information for the users about which it already knows. Buddy List at COM Liste der Freunde an COM Bob Smith Dave Jones Ed at NET My Friends at ORG Meine Freunde an ORG In the above example List "adam-buddies@pres.vancouver.example.com" contains members as sip:bob@vancouver.example.com, sip:dave@vancouver.example.com, sip:ed@dallas.example.net and sip:adam-friends@stockholm.example.org Not sure why RFC mandates/recommends to keep the entire buddy list info in the first NOTIFY..=20 =20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Vavilapalli Srikanth-A19563 Sent: Friday, April 09, 2010 12:38 PM To: Pandurangan R S; simple@ietf.org Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Simple] [Sip-implementors] Question on RFC 4662 - ResourceList Subscription Forwarding to SIMPLE mailing list...=20 -----Original Message----- From: Pandurangan R S [mailto:pandurangan.r.s@gmail.com] Sent: Friday, April 09, 2010 12:07 PM To: Vavilapalli Srikanth-A19563 Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Question on RFC 4662 - Resource List Subscription RFC 4662 states The third mandatory attribute is "fullState". The "fullState" attribute indicates whether the NOTIFY message contains information for every resource in the list. If it does, the value of the attribute is "true" (or "1"); otherwise, it is "false" (or "0"). The first NOTIFY sent in a subscription MUST contain full state, as must the first NOTIFY sent after receipt of a SUBSCRIBE request for the subscription. Why is it a required that first NOTIFY contains information for every resource in the list? I believe it can have a initial information (which tells the subscriber to get rid of any old info) and then build upon the data using further NOTIFYs. Any interop problems if the "fullState" flag is interpreted as "initialState" flag? On Fri, Apr 9, 2010 at 10:48 AM, Vavilapalli Srikanth-A19563 wrote: > Hi > > I have a question related to first NOTIFY being generated for a=20 > Resource List Subscription assuming where the all the entities support > only unreliable UDP transport and message size is limitied by path MTU > size (because of for ex. No support for UDP fragmentation by the=20 > intermediate routers on that network).. > > As per RFC 4662, The first NOTIFY sent in a subscription MUST contain=20 > full state, as must the first NOTIFY sent after receipt of a SUBSCRIBE > request for the subscription. And the "fullState" attribute indicates=20 > that the NOTIFY message contains information for every resource in the > list.. > > Assuming a user has subscribed to his buddy list of 100 to 150 users=20 > and MTU size is defined as 1500 Bytes, How to fit the "full state" > information (which contains the RLMI with all the the user URIs with=20 > the state of subscription + ZERO or more presence states of each=20 > resource in the list) in the first NOTIFY sent towards subscrier? > > Are there any well defined schemes to split such a BIG NOTIFY in to=20 > multiple NOTIFYs without violating the above RFC 4662 requirement? > > Regards > Srikanth > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors From christer.holmberg@ericsson.com Sat Apr 10 00:27:44 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 142C43A67E3 for ; Sat, 10 Apr 2010 00:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.096 X-Spam-Level: X-Spam-Status: No, score=-5.096 tagged_above=-999 required=5 tests=[AWL=0.903, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNpbtrB8hpQ5 for ; Sat, 10 Apr 2010 00:27:42 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 056B43A6767 for ; Sat, 10 Apr 2010 00:27:41 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-6a-4bc028684ff7 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id CA.4F.23532.86820CB4; Sat, 10 Apr 2010 09:27:36 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sat, 10 Apr 2010 09:27:35 +0200 From: Christer Holmberg To: Ben Campbell Date: Sat, 10 Apr 2010 09:27:34 +0200 Thread-Topic: [Simple] Draft new versions: ACM and sessmatch Thread-Index: AcrXb3uB73oMF6pnSNqOW2escgjaGgARcR6A Message-ID: <224F5CB1ECAB2C45BC64065AFD0339650406B57B28@ESESSCMS0354.eemea.ericsson.se> References: <3714450D-BC9E-4325-9E7B-551DC670F53F@estacado.net> In-Reply-To: <3714450D-BC9E-4325-9E7B-551DC670F53F@estacado.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "'simple@ietf.org'" Subject: Re: [Simple] Draft new versions: ACM and sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 10 Apr 2010 07:27:44 -0000 Hi,=20 >----------------------------- >Comments on ACM-07: > >-- section 3,=20 > >Last sentence needs some elaboration. I think the important point is that = this should be supported for user agents that might be deployed behind a NA= T where they cannot accept inbound TCP=20 >connections, and therefore could not accept MSRP sessions offered by a pee= r device outside the NAT, right? It does not only apply to user agents that might be deployed behind a NAT. = It also applies to user agents that might not be deployed behind NATs thems= elves, but that communicate with other user agents that might be deployed b= ehind NATs. >-- Sections 4.* > >We need to be a little careful about normative language of the form of "MS= RP UAs MUST..." when that language is really scoped to "MSRP UAs that supp= ort this extension MUST...". I certainly=20 >don't expect you to say "MSRP UAs that support this extension" every singl= e time, but I'm afraid that sections could be quoted out of context. > >I see two reasonable ways to fix this. One would be to make sure each sect= ion has some text that scopes the normative language to MSRP-ACM UAs. Anoth= er, which might be less intrusive, would be=20 >to invent a new term for UAs that support ACM (maybe "MSRP-ACM UA"?), defi= ne the term early in the document (maybe in section 3), then use it consist= ently. Although it wouldn't be a global=20 >replace, as there are some sections (e.g. 4.4) that reasonably apply to al= l MSRP UAs. My understanding is that, since the draft does not update/obsolete RFC 4975= , the procedures only apply to user agents that implement the draft. I think it would be very messy if we, everytime we say something normative,= explicitly need to clarify that it only applies to MSRP-ACM UAs... Section 3 says that the support of the specification is optional. Isn't tha= t enough? If needed, I could modify the text in section 4.1 to: "This section defines how an MSRP UA that supports this specification uses = the COMEDIA SDP attributes defined in [RFC4145]." >-- section 4.2, last bullet point: > >s/"NAT address:port"/"NAT address and port" Ok. >-- section 4.2, first paragraph after bullet list: > >s/determinte/determine Ok. >spurious quote at end. > >I suggest rewording the last sentence to the effect of "If SIP requests cr= osses a SIP proxy before crossing a NAT,=85" Ok. >-- section 4.2, "note" following first paragraph after the bullet list: > >Note is redundant with last sentence in previous paragraph. Ok. >-- section 4.2, 2nd paragraph: > >Can you elaborate on the last sentence? It means that an entity that knows that it is not located behind a NAT can = unsure that the remote UA establishes the connection, in case it would be l= ocated behind a NAT. If you think the text is unclear, would the following be better? "The a=3Dsetup attribute is particularly useful when one MSRP UA (e.g. a ne= twork media server) knows that it is not located behind a NAT. The a=3Dsetu= p attribute allows that MSRP UA to ensure that the remote MSRP UA creates t= he MSRP tranport connection, in case the remote MSRP UA remote is located b= ehind a NAT." And, going back to your comment on section 3, this is why the extension is = also applicable to entities that are not located behind NATs themselves :) >-- section 4.2, 3rd paragraph: > >I'm not aware of anything in 4975 that says a UA always sends it's certifi= cate. If not doing mutual authn, then there's no reason to expect the TLS c= lient to send a client cert. I assume you refer to the 3rd paragraph of section 4.3? After a re-look at RFC 4975, and when it comes to the TLS client it seems y= ou are right. So, I guess we could simply remove the following statement: "In accordance with [RFC4975], if an MSRP UA has a TLS certificate, it alwa= ys sends the certificate to the other endpoint during the TLS establishment= ." =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >--------------------------------- >Comments on sessmatch-04: > >-- section 5, third paragraph, first 2 sentences: > >I think the meaning got a little confused here with all the back-and-forth= . Does the following say what you mean to say?: > >"With this update, MSRP entities no longer use the MSRP URI domain part to= perform session matching. But if intermediaries modify=85" The text was provided by Adam. But, I have no problem with your suggestion,= so if Adam is ok with it I can do that change. So, the section text would be: "With this update, MSRP entities no longer use the MSRP URI domain part to = perform session matching. But if intermediaries modify the "a=3Dpath" attri= bute in the SDP, but do not modify the corresponding information in the ass= ociated MSRP messages, then the endpoints can determine that such modificat= ions have been performed by comparing the domain information in the SDP wit= h the domain information in the MSRP messages." Regards, Christer= From christer.holmberg@ericsson.com Mon Apr 12 01:02:34 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3B663A69FC for ; Mon, 12 Apr 2010 01:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.044 X-Spam-Level: X-Spam-Status: No, score=-5.044 tagged_above=-999 required=5 tests=[AWL=0.955, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKGLUGlEek0v for ; Mon, 12 Apr 2010 01:02:34 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 9426E28C0DC for ; Mon, 12 Apr 2010 01:02:32 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-c1-4bc2d392cba4 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 52.61.23532.293D2CB4; Mon, 12 Apr 2010 10:02:26 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 12 Apr 2010 10:02:25 +0200 From: Christer Holmberg To: "simple@ietf.org" Date: Mon, 12 Apr 2010 10:02:24 +0200 Thread-Topic: MSRP-ACM: Suggestion to allow a=setup:passive in SDP offer Thread-Index: AQHK2XJutFdvvOEIpEm349s7W1ybzw== Message-ID: 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-Brightmail-Tracker: AAAAAA== Subject: [Simple] MSRP-ACM: Suggestion to allow a=setup:passive in SDP offer X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 12 Apr 2010 08:02:34 -0000 Hi, I have received an off-line comment regarding a statement in section 4.2, s= aying that an offerer MUST NOT use "a=3Dsetup:passive". The suggestion is to allow "passive" in cases where the offerer knows that = the answerer is located behind a NAT, and where it won't be possible to est= ablish a session unless the answerer supports acm and becomes "active". The= re are cases where the answerer does not know whether it's behind a NAT, so= if the offer contains "actpass" there is a risk that the answerer uses "pa= ssive". So, the text could be modified to: "The UA SHOULD NOT use the a=3Dsetup "passive" attribute value in an SDP of= fer, unless it knows that the SDP answerer is located behind a NAT and is r= equired to become active in order to be able to establish the TCP connectio= n." So, unless anyone objects, my intention is to do that change. Regards, Christer From christer.holmberg@ericsson.com Mon Apr 12 02:41:49 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 712883A68D4 for ; Mon, 12 Apr 2010 02:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[AWL=-0.761, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+6eNRm8G66x for ; Mon, 12 Apr 2010 02:41:48 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 7FBC73A6885 for ; Mon, 12 Apr 2010 02:41:45 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-03-4bc2ead39e2c Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 59.6F.23740.3DAE2CB4; Mon, 12 Apr 2010 11:41:39 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Mon, 12 Apr 2010 11:41:39 +0200 From: Christer Holmberg To: Christer Holmberg , Ben Campbell Date: Mon, 12 Apr 2010 11:41:38 +0200 Thread-Topic: [Simple] Draft new versions: ACM and sessmatch Thread-Index: AcrXb3uB73oMF6pnSNqOW2escgjaGgARcR6AAJuiENA= Message-ID: References: <3714450D-BC9E-4325-9E7B-551DC670F53F@estacado.net> <224F5CB1ECAB2C45BC64065AFD0339650406B57B28@ESESSCMS0354.eemea.ericsson.se> In-Reply-To: <224F5CB1ECAB2C45BC64065AFD0339650406B57B28@ESESSCMS0354.eemea.ericsson.se> 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-Brightmail-Tracker: AAAAAA== Cc: "'simple@ietf.org'" Subject: Re: [Simple] Draft new versions: ACM and sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 12 Apr 2010 09:41:49 -0000 Hi,=20 >>-- section 4.2, first paragraph after bullet list: >> >>s/determinte/determine >=20 >Ok. >=20 >=20 >>spurious quote at end. >> >>I suggest rewording the last sentence to the effect of "If SIP requests c= rosses a SIP proxy before crossing a NAT,..." >=20 >Ok. I took a second look at this. I don't think it matters whether there is a proxy between the UA and the NA= T - the Via check will still work. Regards, Christer From christer.holmberg@ericsson.com Mon Apr 12 04:52:08 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 660103A6A0F for ; Mon, 12 Apr 2010 04:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[AWL=-1.048, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4+c8L2s1s+G for ; Mon, 12 Apr 2010 04:52:07 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 3AB423A6991 for ; Mon, 12 Apr 2010 04:52:06 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-5c-4bc3095faf38 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 22.72.23740.F5903CB4; Mon, 12 Apr 2010 13:51:59 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Mon, 12 Apr 2010 13:51:59 +0200 From: Christer Holmberg To: "simple@ietf.org" Date: Mon, 12 Apr 2010 13:51:57 +0200 Thread-Topic: MSRP-ACM: Suggestion to allow a=setup:passive in SDP offer Thread-Index: AQHK2XJutFdvvOEIpEm349s7W1ybz5IeufDA 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-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] MSRP-ACM: Suggestion to allow a=setup:passive in SDP offer X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 12 Apr 2010 11:52:08 -0000 Hi, I had missunderstood the comment that was given to me, so I don't think we = need to change anything. The existing text is fine. Sorry for the mess. Regards, Christer > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 12. huhtikuuta 2010 11:02 > To: simple@ietf.org > Subject: [Simple] MSRP-ACM: Suggestion to allow=20 > a=3Dsetup:passive in SDP offer >=20 >=20 > Hi, >=20 > I have received an off-line comment regarding a statement in=20 > section 4.2, saying that an offerer MUST NOT use "a=3Dsetup:passive". >=20 > The suggestion is to allow "passive" in cases where the=20 > offerer knows that the answerer is located behind a NAT, and=20 > where it won't be possible to establish a session unless the=20 > answerer supports acm and becomes "active". There are cases=20 > where the answerer does not know whether it's behind a NAT,=20 > so if the offer contains "actpass" there is a risk that the=20 > answerer uses "passive". >=20 > So, the text could be modified to: >=20 > "The UA SHOULD NOT use the a=3Dsetup "passive" attribute value=20 > in an SDP offer, unless it knows that the SDP answerer is=20 > located behind a NAT and is required to become active in=20 > order to be able to establish the TCP connection." >=20 > So, unless anyone objects, my intention is to do that change. >=20 > Regards, >=20 > Christer >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > = From doolinwu@gmail.com Tue Apr 13 07:05:48 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E904D3A6969 for ; Tue, 13 Apr 2010 07:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.537 X-Spam-Level: X-Spam-Status: No, score=-1.537 tagged_above=-999 required=5 tests=[AWL=-0.728, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQQbpAuX3tAf for ; Tue, 13 Apr 2010 07:05:44 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 8E09D3A67E2 for ; Tue, 13 Apr 2010 07:05:44 -0700 (PDT) Received: by iwn27 with SMTP id 27so5495062iwn.5 for ; Tue, 13 Apr 2010 07:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=UP8Tc4cKO47WhYsDMx1CfOTeutARTSeiiz5bibyX6bM=; b=bbtIPo+tHkxfLE9MmR4BfBQAwFu3cXaa3pupBmsVZ1t+/LyB0SlbSO+N008JiSTcPy xPmk59EbEUy3/7BFPX6pDHitqySwqg1ROjbf/H41e+nzkIifQBK4xTSenTaVpCbpNrUu 0hcZBSBY3hLi/fhONUC/6zl0dFLg+SpcfPCx8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Pz18BjO7B0xC7fH9rZSMC1jN1tVAw3PXKJnFhguIZh1NBARnPLr6eJ6OJXqmVzPY/k Mh8gUGLBmU8O2B50AKDlrihFiE7fwKO0d5aCONSQ1+qIJ9JW3yDVkH1yB9x++jarqKr6 HlUB5BJXKpCE3UMEiy9+GZA+wogeDA+EX4W+w= MIME-Version: 1.0 Received: by 10.231.157.74 with HTTP; Tue, 13 Apr 2010 07:05:36 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Apr 2010 22:05:36 +0800 Received: by 10.231.156.65 with SMTP id v1mr2659010ibw.67.1271167536182; Tue, 13 Apr 2010 07:05:36 -0700 (PDT) Message-ID: From: doolin wu To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001636c933da71b4ae04841ec1b9 Cc: simple@ietf.org Subject: Re: [Simple] Hello SIMPLE X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 13 Apr 2010 14:05:49 -0000 --001636c933da71b4ae04841ec1b9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for your experiences! If just for IM maybe people does like use SIMPLE because there is XMPP. But think about the software arch, our system has implemented voice and video over IP based on SIP. We are going to add IM for our system based the lower layer SIP stack. In this case, I think SIMPLE is a good choice then XMPP. Do you think so? -Steven On Fri, Apr 9, 2010 at 7:19 PM, I=F1aki Baz Castillo wrote: > 2010/4/8 doolin wu : > > Hello, > > > > Just join the mail list. > > Could someone tell me where can I get the new progress of SIMPLE? > > Do you mean progress about SIMPLE specifications? or about SIMPLE > implementations in the real world? > > For the first question (SIMPLE specifications) there are a lot, but > most of them not enough reliable or strict, so other organizations as > OMA/RCS take them and add extra layers of specifications to get > something usable (but not so usable in fact, as the final RCS > specifications provide less features than MSN 8 years ago). > > For the second question (SIMPLE implementations in the real world) > there is no interest at all in implementing most of the SIMPLE > specifications, nobody in Internet wants them as there are other > protocols (as XMPP) much more reliable, powerful and easy to implement > (without mixing two different protocols, SIP and HTTP, in order to > mantain a simple buddylist): > http://oversip.net/public/XMPP.jpeg > > For sure just IMS is interested in SIMPLE/XCAP/XDM architecture as > they like a lot the complex diagrams and message flows: > http://oversip.net/public/SIP_SIMPLE_OMA.jpeg > > I have no doubt about why Google and Facebook have chosen XMPP. It has > been easier for Google to add voice feature to XMPP rather than using > SIP (mature voice specs) having to implement SIMPLE stuf for > presence/IM. > > But well, does somebody care that no one innovative provider in > Internet (so far from 3GPP operators) is interested in SIMPLE? I'm > really worried about it, and IMHO the way is not adding more and more > drafts about xcap-diff and such unuseful and complex stuf. The core of > SIMPLE/XCAP (in presence terms) is a pain IMHO, and adding more and > more drafts over it will fix nothing. > > Sorry for being so rude in my words, but this is what I think after > long time dealing and implementing most of the SIMPLE/XCAP > specifications (for presence), so I think I do know what I'm speaking > about. > > Regards. > > > -- > I=F1aki Baz Castillo > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > --=20 Steven Wu Teleca Mobile Solution --001636c933da71b4ae04841ec1b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for your experiences!
If just for IM maybe people does like use SIMPLE because there is XMPP= .
But think about the software arch, our system has implemented voice an= d video over IP based on SIP. We are going to add IM for our system based t= he lower layer SIP stack.
In this case, I think SIMPLE is a good choice then XMPP. Do you think = so?
=A0
-Steven

On Fri, Apr 9, 2010 at 7:19 PM, I=F1aki Baz Cast= illo <ibc@aliax.net> wrote:
2010/4/8 doolin wu <doolinwu@gmail.com>:
> Hello,
>
> Just join the mail list.
&= gt; Could someone tell me where can I get the new progress of SIMPLE?
Do you mean progress about SIMPLE specifications? or about SIMPLE implementations in the real world?

For the first question (SIMPLE sp= ecifications) there are a lot, but
most of them not enough reliable or s= trict, so other organizations as
OMA/RCS take them and add extra layers = of specifications to get
something usable (but not so usable in fact, as the final RCS
specificat= ions provide less features than MSN 8 years ago).

For the second que= stion (SIMPLE implementations in the real world)
there is no interest at= all in implementing most of the SIMPLE
specifications, nobody in Internet wants them as there are other
protoco= ls (as XMPP) much more reliable, powerful and easy to implement
(without= mixing two different protocols, SIP and HTTP, in order to
mantain a sim= ple buddylist):
=A0http:/= /oversip.net/public/XMPP.jpeg

For sure just IMS is interested in= SIMPLE/XCAP/XDM architecture as
they like a lot the complex diagrams an= d message flows:
=A0http://oversip.net/public/SIP_SIMPLE_OMA.jpeg

I have no doub= t about why Google and Facebook have chosen XMPP. It has
been easier for= Google to add voice feature to XMPP rather than using
SIP (mature voice specs) having to implement SIMPLE stuf for
presence/IM= .

But well, does somebody care that no one innovative provider inInternet (so far from 3GPP operators) is interested in SIMPLE? I'm
really worried about it, and IMHO the way is not adding more and more
dr= afts about xcap-diff and such unuseful and complex stuf. The core of
SIM= PLE/XCAP (in presence terms) is a pain IMHO, and adding more and
more dr= afts over it will fix nothing.

Sorry for being so rude in my words, but this is what I think after
= long time dealing and implementing most of the SIMPLE/XCAP
specification= s (for presence), so I think I do know what I'm speaking
about.

Regards.


--
I=F1aki Baz Castillo<= br><ibc@aliax.net>
_______________________________________________
Simple= mailing list
Simple@ietf.org
= = https://www.ietf.org/mailman/listinfo/simple



--
Steven WuTeleca Mobile Solution
--001636c933da71b4ae04841ec1b9-- From ibc@aliax.net Tue Apr 13 07:12:33 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FD603A6A35 for ; Tue, 13 Apr 2010 07:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.176 X-Spam-Level: X-Spam-Status: No, score=0.176 tagged_above=-999 required=5 tests=[AWL=1.853, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfKcXnh51SXl for ; Tue, 13 Apr 2010 07:12:32 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 19FAF3A6903 for ; Tue, 13 Apr 2010 07:12:31 -0700 (PDT) Received: by pvf33 with SMTP id 33so3118967pvf.31 for ; Tue, 13 Apr 2010 07:12:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.141.3 with HTTP; Tue, 13 Apr 2010 07:12:22 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Apr 2010 16:12:22 +0200 Received: by 10.140.247.17 with SMTP id u17mr5477542rvh.151.1271167942747; Tue, 13 Apr 2010 07:12:22 -0700 (PDT) Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: doolin wu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org Subject: Re: [Simple] Hello SIMPLE X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 13 Apr 2010 14:12:33 -0000 2010/4/13 doolin wu : > Thanks for your experiences! > If just for IM maybe people does like use SIMPLE because there is XMPP. > But think about the software arch, our system has implemented voice and > video over IP based on SIP. We are going to add IM for our system based t= he > lower layer SIP stack. > In this case, I think SIMPLE is a good choice then XMPP. Do you think so? Advanced IM in SIP is MSRP and IM conference specifications. I think it's suitable, yes. --=20 I=C3=B1aki Baz Castillo From doolinwu@gmail.com Tue Apr 13 07:23:13 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F6983A6A35 for ; Tue, 13 Apr 2010 07:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+370CySVALy for ; Tue, 13 Apr 2010 07:23:12 -0700 (PDT) Received: from mail-pz0-f191.google.com (mail-pz0-f191.google.com [209.85.222.191]) by core3.amsl.com (Postfix) with ESMTP id EC8FF28C1E7 for ; Tue, 13 Apr 2010 07:22:17 -0700 (PDT) Received: by pzk29 with SMTP id 29so5752319pzk.29 for ; Tue, 13 Apr 2010 07:22:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=um4WvbgX8SDx7OjdPgR27AwxTd7hUVKX4m9PqOLPrQU=; b=hkODUpoxwL5DwELyCT0ft3EyZGqiqTW945nrROHShT8EhLCiHqcjDXsM62AeFsqcws +tdlxFpgPDNkgpx3AeLWc+3sezYhwCPE6IgvfvH+IUdtOBEP+9qefCmyqduDexbnQfjE ETva5AXF5pCi0gtPDVb9aFhOvhtjLLPpKFcJM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RARJr4cwB7guvm9EJUvFoX06lclXPFooyfV5mgnx9V2x9wS0uzMO/Za7bF5JLXZQY0 V8PWDIMNM17fckAgu1jmznk9L/UObnBX0ldJ+EVFIXwNUOiSJw9EBZNMpYCqUR2C89ab TNygAGGZedqIjOZw2GEpU55uFYKa1oG0My92k= MIME-Version: 1.0 Received: by 10.231.157.74 with HTTP; Tue, 13 Apr 2010 07:22:00 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Apr 2010 22:22:00 +0800 Received: by 10.115.115.39 with SMTP id s39mr5324947wam.119.1271168520260; Tue, 13 Apr 2010 07:22:00 -0700 (PDT) Message-ID: From: doolin wu To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=0016e648d808199b4a04841efce9 Cc: simple@ietf.org Subject: Re: [Simple] Hello SIMPLE X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 13 Apr 2010 14:23:13 -0000 --0016e648d808199b4a04841efce9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Is there any SIP based IM application in real world? -Steven On Tue, Apr 13, 2010 at 10:12 PM, I=F1aki Baz Castillo wrot= e: > 2010/4/13 doolin wu : > > Thanks for your experiences! > > If just for IM maybe people does like use SIMPLE because there is XMPP. > > But think about the software arch, our system has implemented voice and > > video over IP based on SIP. We are going to add IM for our system based > the > > lower layer SIP stack. > > In this case, I think SIMPLE is a good choice then XMPP. Do you think s= o? > > Advanced IM in SIP is MSRP and IM conference specifications. I think > it's suitable, yes. > > > -- > I=F1aki Baz Castillo > > --=20 Steven Wu Teleca Mobile Solution --0016e648d808199b4a04841efce9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Is there any SIP based IM application in real world?
=A0
-Steven

On Tue, Apr 13, 2010 at 10:12 PM, I=F1aki Baz Ca= stillo <ibc@aliax.net= > wrote:
2010/4/13 doolin wu <doolinwu@gmail.com>:
> Thanks for your experiences!
> If just for IM = maybe people does like use SIMPLE because there is XMPP.
> But think = about the software arch, our system has implemented voice and
> video= over IP based on SIP. We are going to add IM for our system based the
> lower layer SIP stack.
> In this case, I think SIMPLE is a good = choice then XMPP. Do you think so?

Advanced IM in SIP is MSRP = and IM conference specifications. I think
it's suitable, yes.


--
I=F1aki Baz Castillo
<ibc@aliax.net>



--
Steven Wu
Teleca Mobile Solution
--0016e648d808199b4a04841efce9-- From ibc@aliax.net Tue Apr 13 07:25:20 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215663A6B20 for ; Tue, 13 Apr 2010 07:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.462 X-Spam-Level: X-Spam-Status: No, score=-1.462 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyTBRnzNd6In for ; Tue, 13 Apr 2010 07:25:19 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 4A9B428C201 for ; Tue, 13 Apr 2010 07:24:08 -0700 (PDT) Received: by pwj2 with SMTP id 2so5429479pwj.31 for ; Tue, 13 Apr 2010 07:24:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.141.3 with HTTP; Tue, 13 Apr 2010 07:23:59 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Apr 2010 16:23:59 +0200 Received: by 10.141.91.4 with SMTP id t4mr5196376rvl.78.1271168640047; Tue, 13 Apr 2010 07:24:00 -0700 (PDT) Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: doolin wu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org Subject: Re: [Simple] Hello SIMPLE X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 13 Apr 2010 14:25:20 -0000 2010/4/13 doolin wu : > Is there any SIP based IM application in real world? Now there are some SIP devices (mostly softphones) starting with MSRP. Until now just the old legacy "MESSAGE" was implemented. --=20 I=C3=B1aki Baz Castillo From ag@ag-projects.com Tue Apr 13 07:26:22 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 487BF28C1F5 for ; Tue, 13 Apr 2010 07:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWvnVSz1ebfW for ; Tue, 13 Apr 2010 07:26:16 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by core3.amsl.com (Postfix) with ESMTP id D0E9B3A6A3F for ; Tue, 13 Apr 2010 07:25:40 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 58F32B01B9; Tue, 13 Apr 2010 16:25:34 +0200 (CEST) Received: from [192.168.1.6] (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 767B8B01B1; Tue, 13 Apr 2010 16:25:33 +0200 (CEST) Message-Id: From: Adrian Georgescu To: doolin wu In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-5-803757102 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Apr 2010 16:25:33 +0200 References: X-Mailer: Apple Mail (2.936) Cc: Simple WG Subject: Re: [Simple] Hello SIMPLE X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 13 Apr 2010 14:26:22 -0000 --Apple-Mail-5-803757102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Try Blink http://icanblink.com It has IM, File Transfer and Desktop Sharing using MSRP and its relay =20= extension. Adrian On Apr 13, 2010, at 4:22 PM, doolin wu wrote: > Is there any SIP based IM application in real world? > > -Steven > > On Tue, Apr 13, 2010 at 10:12 PM, I=F1aki Baz Castillo = =20 > wrote: > 2010/4/13 doolin wu : > > Thanks for your experiences! > > If just for IM maybe people does like use SIMPLE because there is =20= > XMPP. > > But think about the software arch, our system has implemented =20 > voice and > > video over IP based on SIP. We are going to add IM for our system =20= > based the > > lower layer SIP stack. > > In this case, I think SIMPLE is a good choice then XMPP. Do you =20 > think so? > > Advanced IM in SIP is MSRP and IM conference specifications. I think > it's suitable, yes. > > > -- > I=F1aki Baz Castillo > > > > > --=20 > Steven Wu > Teleca Mobile Solution > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail-5-803757102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Try Blink


It has IM, File Transfer and Desktop Sharing using MSRP and its = relay = extension.

Adrian

<= div>On Apr 13, 2010, at 4:22 PM, doolin wu wrote:

Is = there any SIP based IM application in real world?
=
 
-Steven

On= Tue, Apr 13, 2010 at 10:12 PM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
=
2010/4/13 = doolin wu <doolinwu@gmail.com>:
> Thanks for your experiences!
> If just for IM = maybe people does like use SIMPLE because there is XMPP.
> But = think about the software arch, our system has implemented voice = and
> video over IP based on SIP. We are going to add IM for our = system based the
> lower layer SIP stack.
> In this case, I = think SIMPLE is a good choice then XMPP. Do you think = so?

Advanced IM in SIP is MSRP and IM conference = specifications. I think
it's suitable, yes.


--
I=F1aki Baz Castillo
<ibc@aliax.net>



--
Steven Wu
Teleca Mobile = Solution
_______________________________________________
Simple = mailing list
Simple@ietf.org
https://www.ietf.org= /mailman/listinfo/simple

= --Apple-Mail-5-803757102-- From victor.pascual.avila@gmail.com Tue Apr 13 10:45:28 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51973A6A6A for ; Tue, 13 Apr 2010 10:45:28 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pR8aCNGXpIMm for ; Tue, 13 Apr 2010 10:45:28 -0700 (PDT) Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by core3.amsl.com (Postfix) with ESMTP id 2FFD73A6A62 for ; Tue, 13 Apr 2010 10:45:25 -0700 (PDT) Received: by bwz9 with SMTP id 9so6079530bwz.29 for ; Tue, 13 Apr 2010 10:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DtRqZ78/gZ7IY5lXy1dzT6/ce1pztP200zVRMyibBCs=; b=p7uM0yb6FuHT8gNAN7jZD8NNurFnWF527MExWw1h8s6kzTBaEGlldP1a6X12O67WWQ AoPOFZWCktRjSaBK3DaBbwV9fh4q9wshhwJ0WPP05qJCorqsKSk+5KJ2oCY0jux5kv3Q TpcpyXBOEm6i8RsShQh1/46XvkZOplw65nihA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=p20GNEufzlyMUJGhplkUAu3jawhlHWqR+9DfnwqTGKyZvL12XeOysHgxh6YF3RZFyy 8Of59g8am2keDu+TjD5m2pCREVaA13wFuFZPFJOITFXRuOJapa9ckMwEWjqsDjDetRsg EEVpdyekoavkXHBjqK45IAr37X51hTjgf9oAw= MIME-Version: 1.0 Received: by 10.204.66.73 with HTTP; Tue, 13 Apr 2010 10:45:16 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Apr 2010 19:45:16 +0200 Received: by 10.204.150.77 with SMTP id x13mr7124821bkv.19.1271180716235; Tue, 13 Apr 2010 10:45:16 -0700 (PDT) Message-ID: From: Victor Pascual Avila To: doolin wu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org Subject: Re: [Simple] Hello SIMPLE X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 13 Apr 2010 17:45:29 -0000 On Tue, Apr 13, 2010 at 4:22 PM, doolin wu wrote: > Is there any SIP based IM application in real world? Blink[1] is a nice piece of software [1] http://www.ag-projects.com/content/view/587/283/ Cheers, --=20 Victor Pascual =C3=81vila From ben@estacado.net Tue Apr 13 18:08:47 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC5A3A6AEB for ; Tue, 13 Apr 2010 18:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGujlt6l+k9R for ; Tue, 13 Apr 2010 18:08:46 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 063793A6AD3 for ; Tue, 13 Apr 2010 18:08:45 -0700 (PDT) Received: from [10.0.1.12] (adsl-68-94-8-111.dsl.rcsntx.swbell.net [68.94.8.111]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o3E18SIu082565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Apr 2010 20:08:32 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=windows-1252 From: Ben Campbell In-Reply-To: <224F5CB1ECAB2C45BC64065AFD0339650406B57B28@ESESSCMS0354.eemea.ericsson.se> Date: Tue, 13 Apr 2010 20:08:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8294DB05-9568-4886-A2DB-2F8EC522B9E7@estacado.net> References: <3714450D-BC9E-4325-9E7B-551DC670F53F@estacado.net> <224F5CB1ECAB2C45BC64065AFD0339650406B57B28@ESESSCMS0354.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1078) Cc: "'simple@ietf.org'" Subject: Re: [Simple] Draft new versions: ACM and sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 14 Apr 2010 01:08:47 -0000 On Apr 10, 2010, at 2:27 AM, Christer Holmberg wrote: >=20 > Hi,=20 >=20 >> ----------------------------- >> Comments on ACM-07: >>=20 >> -- section 3,=20 >>=20 >> Last sentence needs some elaboration. I think the important point is = that this should be supported for user agents that might be deployed = behind a NAT where they cannot accept inbound TCP=20 >> connections, and therefore could not accept MSRP sessions offered by = a peer device outside the NAT, right? >=20 > It does not only apply to user agents that might be deployed behind a = NAT. It also applies to user agents that might not be deployed behind = NATs themselves, but that communicate with other user agents that might = be deployed behind NATs. Okay, I buy that. But I have trouble getting the essence of that from = "User Agents that are likely to be deployed in networks where User = Agents need to establish the TCP connections in order to traverse = NATs..." is clear. By user agents that "need to _establish_ the TCP = connection" , are you talking about those that must be the active party? = Or is the important point that the TCP connections are peer to peer = (i.e. no relay)? >=20 >> -- Sections 4.* >>=20 >> We need to be a little careful about normative language of the form = of "MSRP UAs MUST..." when that language is really scoped to "MSRP UAs = that support this extension MUST...". I certainly=20 >> don't expect you to say "MSRP UAs that support this extension" every = single time, but I'm afraid that sections could be quoted out of = context. >>=20 >> I see two reasonable ways to fix this. One would be to make sure each = section has some text that scopes the normative language to MSRP-ACM = UAs. Another, which might be less intrusive, would be=20 >> to invent a new term for UAs that support ACM (maybe "MSRP-ACM UA"?), = define the term early in the document (maybe in section 3), then use it = consistently. Although it wouldn't be a global=20 >> replace, as there are some sections (e.g. 4.4) that reasonably apply = to all MSRP UAs. >=20 > My understanding is that, since the draft does not update/obsolete RFC = 4975, the procedures only apply to user agents that implement the draft. >=20 > I think it would be very messy if we, everytime we say something = normative, explicitly need to clarify that it only applies to MSRP-ACM = UAs... >=20 > Section 3 says that the support of the specification is optional. = Isn't that enough? I agree that it's ugly to restate the scope every time. I'm trying to = think about how people (sometimes willfully) misread drafts. My concern = is that text is often taken out of context. I think it helps to have the = occasional reminder, instead of assuming everyone will infer the meaning = from the scope of the draft.=20 >=20 > If needed, I could modify the text in section 4.1 to: >=20 > "This section defines how an MSRP UA that supports this specification = uses the COMEDIA SDP attributes defined in [RFC4145]." I think that helps. It might be better to move that text to be under the = Section 4 heading instead of a 4.1, and say "This section and its = subsections..." since those willful misreaders could otherwise argue = that the "this section" refers to 4.1. [ ... ] >=20 >=20 >> -- section 4.2, 2nd paragraph: >>=20 >> Can you elaborate on the last sentence? >=20 > It means that an entity that knows that it is not located behind a NAT = can unsure that the remote UA establishes the connection, in case it = would be located behind a NAT. >=20 > If you think the text is unclear, would the following be better? >=20 > "The a=3Dsetup attribute is particularly useful when one MSRP UA (e.g. = a network media server) knows that it is not located behind a NAT. The = a=3Dsetup attribute allows that MSRP UA to ensure that the remote MSRP = UA creates the MSRP tranport connection, in case the remote MSRP UA = remote is located behind a NAT." >=20 > And, going back to your comment on section 3, this is why the = extension is also applicable to entities that are not located behind = NATs themselves :) Oops, that sections fine. I meant section 4.3. (And I would not have = figured out what I was originally commenting on had you not so = graciously pointed out my 4.2 vs 4.3 confusion in the next comment ;-) = ) >=20 >=20 >> -- section 4.2, 3rd paragraph: >>=20 >> I'm not aware of anything in 4975 that says a UA always sends it's = certificate. If not doing mutual authn, then there's no reason to expect = the TLS client to send a client cert. >=20 > I assume you refer to the 3rd paragraph of section 4.3? Yes, sorry. >=20 > After a re-look at RFC 4975, and when it comes to the TLS client it = seems you are right. So, I guess we could simply remove the following = statement: >=20 > "In accordance with [RFC4975], if an MSRP UA has a TLS certificate, it = always sends the certificate to the other endpoint during the TLS = establishment." I think that's the best solution. >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >> --------------------------------- >> Comments on sessmatch-04: >>=20 >> -- section 5, third paragraph, first 2 sentences: >>=20 >> I think the meaning got a little confused here with all the = back-and-forth. Does the following say what you mean to say?: >>=20 >> "With this update, MSRP entities no longer use the MSRP URI domain = part to perform session matching. But if intermediaries modify=85" >=20 > The text was provided by Adam. But, I have no problem with your = suggestion, so if Adam is ok with it I can do that change. >=20 > So, the section text would be: >=20 > "With this update, MSRP entities no longer use the MSRP URI domain = part to perform session matching. But if intermediaries modify the = "a=3Dpath" attribute in the SDP, but do not modify the corresponding = information in the associated MSRP messages, then the endpoints can = determine that such modifications have been performed by comparing the = domain information in the SDP with the domain information in the MSRP = messages." >=20 Works for me. Thanks! Ben.= From ben@estacado.net Tue Apr 13 19:13:52 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5800128C210 for ; Tue, 13 Apr 2010 19:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7JE-7qIwcOe for ; Tue, 13 Apr 2010 19:13:38 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id BF2B628C20C for ; Tue, 13 Apr 2010 19:13:33 -0700 (PDT) Received: from [10.0.1.12] (adsl-68-94-8-111.dsl.rcsntx.swbell.net [68.94.8.111]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o3E2DIMH092801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Apr 2010 21:13:23 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: Date: Tue, 13 Apr 2010 21:13:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <41490A3A-86F0-4E8F-A063-498488014758@estacado.net> References: <3714450D-BC9E-4325-9E7B-551DC670F53F@estacado.net> <224F5CB1ECAB2C45BC64065AFD0339650406B57B28@ESESSCMS0354.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1078) Cc: "'simple@ietf.org'" Subject: Re: [Simple] Draft new versions: ACM and sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 14 Apr 2010 02:13:53 -0000 On Apr 12, 2010, at 4:41 AM, Christer Holmberg wrote: >=20 > Hi,=20 >=20 >>> -- section 4.2, first paragraph after bullet list: >>>=20 >>> s/determinte/determine >>=20 >> Ok. >>=20 >>=20 >>> spurious quote at end. >>>=20 >>> I suggest rewording the last sentence to the effect of "If SIP = requests crosses a SIP proxy before crossing a NAT,..." >>=20 >> Ok. >=20 > I took a second look at this. >=20 > I don't think it matters whether there is a proxy between the UA and = the NAT - the Via check will still work. How? I assume you are talking about inspecting the "received" parameter = in the Via, right? But by the time a response gets back to the UAC, only = the initial Via will be left. The UAC cannot infer anything from = downstream Via headers, since they won't be in the response. Am I = missing something? >=20 > Regards, >=20 > Christer From christer.holmberg@ericsson.com Tue Apr 13 22:59:22 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 421263A6850 for ; Tue, 13 Apr 2010 22:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.027 X-Spam-Level: X-Spam-Status: No, score=-5.027 tagged_above=-999 required=5 tests=[AWL=0.972, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1-dR8dDY9R6 for ; Tue, 13 Apr 2010 22:59:20 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 604B728C186 for ; Tue, 13 Apr 2010 22:59:20 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-ea-4bc559b03e1b Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id A8.F7.23532.0B955CB4; Wed, 14 Apr 2010 07:59:12 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 14 Apr 2010 07:59:12 +0200 From: Christer Holmberg To: Ben Campbell Date: Wed, 14 Apr 2010 07:59:11 +0200 Thread-Topic: [Simple] Draft new versions: ACM and sessmatch Thread-Index: AcrbbwRSaxerUdDZTbG8MeNpsEQL/AAJDnWg Message-ID: References: <3714450D-BC9E-4325-9E7B-551DC670F53F@estacado.net> <224F5CB1ECAB2C45BC64065AFD0339650406B57B28@ESESSCMS0354.eemea.ericsson.se> <8294DB05-9568-4886-A2DB-2F8EC522B9E7@estacado.net> In-Reply-To: <8294DB05-9568-4886-A2DB-2F8EC522B9E7@estacado.net> 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-Brightmail-Tracker: AAAAAA== Cc: "'simple@ietf.org'" Subject: Re: [Simple] Draft new versions: ACM and sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 14 Apr 2010 05:59:22 -0000 =20 Hi, >>>----------------------------- >>> Comments on ACM-07: >>>=20 >>> -- section 3, >>>=20 >>>Last sentence needs some elaboration. I think the=20 >>>important point is that this should be supported for user agents that mi= ght=20 >>>be deployed behind a NAT where they cannot accept inbound TCP=20 >>>connections, and therefore could not accept MSRP sessions=20 >>>offered by a peer device outside the NAT, right? >>=20 >>It does not only apply to user agents that might be=20 >>deployed behind a NAT. It also applies to user agents that=20 >>might not be deployed behind NATs themselves, but that=20 >>communicate with other user agents that might be deployed behind NATs. >=20 >Okay, I buy that. But I have trouble getting the essence of=20 >that from "User Agents that are likely to be deployed in=20 >networks where User Agents need to establish the TCP=20 >connections in order to traverse NATs..." is clear. By user=20 >agents that "need to _establish_ the TCP connection" , are=20 >you talking about those that must be the active party? Or is=20 >the important point that the TCP connections are peer to peer=20 >(i.e. no relay)? I am talking about cases where the SDP answerer is behind the NAT, and need= s to become active. In RFC 4975 the answerer is always passive. I don't think it apply to terminals behind relays, because they will anyway= always establish a connection with the relay - no matter if they are activ= e or passive. So, would the following be more clear: "Support of this specification is optional for MSRP user agents in general. User agents that are located behind NATs, do not use MSRP relays for=20 NAT traversal, and need to establish the TCP connections in order to traver= se NATs,=20 and other user agents communicating with those user agents, SHOULD support= =20 this specification in order to improve the odds of being able to communicat= e acress NATs." ------------ >>>-- Sections 4.* >>>=20 >>>We need to be a little careful about normative language of=20 >>>the form of "MSRP UAs MUST..." when that language is really scoped=20 >>>to "MSRP UAs that support this extension MUST...". I=20 >>>certainly don't expect you to say "MSRP UAs that support this=20 >>>extension" every single time, but I'm afraid that sections=20 >>>could be quoted out of context. >>>=20 >>>I see two reasonable ways to fix this. One would be to=20 >>>make sure each section has some text that scopes the normative language= =20 >>>to MSRP-ACM UAs. Another, which might be less intrusive, would be to=20 >>>invent a new term for UAs that support ACM (maybe "MSRP-ACM=20 >>>UA"?), define the term early in the document (maybe in=20 >>>section 3), then use it consistently. Although it wouldn't be=20 >>>a global replace, as there are some sections (e.g. 4.4) that=20 >>>reasonably apply to all MSRP UAs. >>=20 >>My understanding is that, since the draft does not=20 >>update/obsolete RFC 4975, the procedures only apply to user=20 >>agents that implement the draft. >>=20 >>I think it would be very messy if we, everytime we say=20 >>something normative, explicitly need to clarify that it only=20 >>applies to MSRP-ACM UAs... >>=20 >>Section 3 says that the support of the specification is=20 >>Optional. Isn't that enough? >=20 >I agree that it's ugly to restate the scope every time. I'm=20 >trying to think about how people (sometimes willfully)=20 >misread drafts. My concern is that text is often taken out of=20 >context. I think it helps to have the occasional reminder,=20 >instead of assuming everyone will infer the meaning from the=20 >scope of the draft.=20 >=20 >>=20 >>If needed, I could modify the text in section 4.1 to: >>=20 >>"This section defines how an MSRP UA that supports this=20 >>specification uses the COMEDIA SDP attributes defined in [RFC4145]." >=20 >I think that helps. It might be better to move that text to=20 >be under the Section 4 heading instead of a 4.1, and say=20 >"This section and its subsections..." since those willful=20 >misreaders could otherwise argue that the "this section"=20 >refers to 4.1. Keith has spent a number of years teachin me that you can't do it that way = (it's called hanging paragraph, or something),=20 and that the correct way is to have a "General" subsection where you descri= be things which=20 apply to all subsections :) That is also how we've done in many other specifications. ------------ =20 >>>-- section 4.2, 2nd paragraph: >>>=20 >>> Can you elaborate on the last sentence? >>=20 >>It means that an entity that knows that it is not located=20 >>behind a NAT can unsure that the remote UA establishes the=20 >>connection, in case it would be located behind a NAT. >>=20 >>If you think the text is unclear, would the following be better? >>=20 >>"The a=3Dsetup attribute is particularly useful when one MSRP=20 >>UA (e.g. a network media server) knows that it is not located=20 >>behind a NAT. The a=3Dsetup attribute allows that MSRP UA to=20 >>ensure that the remote MSRP UA creates the MSRP tranport=20 >>connection, in case the remote MSRP UA remote is located=20 >>behind a NAT." >>=20 >>And, going back to your comment on section 3, this is why the=20 >>extension is also applicable to entities that are not=20 >>located behind NATs themselves :) >=20 >Oops, that sections fine. I meant section 4.3. (And I would=20 >not have figured out what I was originally commenting on had=20 >you not so graciously pointed out my 4.2 vs 4.3 confusion in=20 >the next comment ;-) ) So, your issue is related to section 4.3, 2nd paragraph? The sentence says: "From TLS authentication point of view it is thus irrelevant whether an endpoint takes the active or passive role." The text simply intends to show that the TLS authentication is not affected= by the active/passive role. ------------ >>>-- section 4.2, 3rd paragraph: >>>=20 >>>I'm not aware of anything in 4975 that says a UA always=20 >>>sends it's certificate. If not doing mutual authn, then=20 >>>there's no reason to expect the TLS client to send a client cert. >>=20 >>I assume you refer to the 3rd paragraph of section 4.3? >=20 >Yes, sorry. >=20 >>=20 >>After a re-look at RFC 4975, and when it comes to the TLS=20 >>client it seems you are right. So, I guess we could simply=20 >>remove the following statement: >>=20 >>"In accordance with [RFC4975], if an MSRP UA has a TLS=20 >>certificate, it always sends the certificate to the other=20 >>endpoint during the TLS establishment." >=20 >I think that's the best solution. Gone it is :) ------------ >>>>I suggest rewording the last sentence to the effect of "If SIP requests= crosses a SIP proxy before crossing a NAT,..." >>>=20 >>>Ok. >>=20 >>I took a second look at this. >>=20 >>I don't think it matters whether there is a proxy between the UA and the = NAT - the Via check will still work. > >How? I assume you are talking about inspecting the "received" parameter in= the Via, right?=20 >But by the time a response gets back to the UAC, only the initial Via will= be left. =20 >The UAC cannot infer anything from downstream Via headers, since they won'= t be in the response.=20 >Am I missing something? No, you are correct. I was thinking about how an edge proxy could determine= whether it's a NAT between itself and the UA. So, the text could be: "If SIP requests crosses a SIP proxy before crossing a NAT, the UA will not= be able to detect the NAT by comparing the IP addresses." >>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>>--------------------------------- >>>Comments on sessmatch-04: >>>=20 >>>-- section 5, third paragraph, first 2 sentences: >>>=20 >>>I think the meaning got a little confused here with all=20 >>>the back-and-forth. Does the following say what you mean to say?: >>>=20 >>>"With this update, MSRP entities no longer use the MSRP=20 >>>URI domain part to perform session matching. But if=20 >>>intermediaries modify..." >>=20 >>The text was provided by Adam. But, I have no problem with=20 >>your suggestion, so if Adam is ok with it I can do that change. >>=20 >>So, the section text would be: >>=20 >> "With this update, MSRP entities no longer use the MSRP URI=20 >domain part to perform session matching. But if=20 >intermediaries modify the "a=3Dpath" attribute in the SDP, but=20 >do not modify the corresponding information in the associated=20 >MSRP messages, then the endpoints can determine that such=20 >modifications have been performed by comparing the domain=20 >information in the SDP with the domain information in the=20 >MSRP messages." >>=20 >=20 >Works for me. Changed it is. Regards, Christer From christer.holmberg@ericsson.com Mon Apr 19 03:30:27 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464853A69BA for ; Mon, 19 Apr 2010 03:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.944 X-Spam-Level: X-Spam-Status: No, score=-2.944 tagged_above=-999 required=5 tests=[AWL=-0.946, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5R2OOmrlw2i for ; Mon, 19 Apr 2010 03:30:26 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 25FA83A699A for ; Mon, 19 Apr 2010 03:30:25 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-9e-4bcc30b8c068 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 0F.DE.23740.8B03CCB4; Mon, 19 Apr 2010 12:30:16 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 19 Apr 2010 12:30:15 +0200 From: Christer Holmberg To: "'simple@ietf.org'" Date: Mon, 19 Apr 2010 12:30:14 +0200 Thread-Topic: WGLC comment on MSRP-ACM Thread-Index: Acrfq0xXUEDaLmk5QgugYOCK+oP/XQ== Message-ID: 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_FF84A09F50A6DC48ACB6714F4666CC745E21D7DE2FESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Simple] WGLC comment on MSRP-ACM X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 10:30:27 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC745E21D7DE2FESESSCMS0354e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've received an off-line comment regarding the usage of port=3D9 when a UA= is active. The text in section 4.2 of the draft says: "If the a=3Dsetup attribute value is "active", the port number value MUST either be the actual port number that the MSRP UA will use for the TCP endpoint, or the port value 9." Since RFC 4145 uses "SHOULD use port 9", it has been suggested to modify th= e text to: "In accordance with RFC 4145, if the a=3Dsetup attribute value is "active",= the port number value SHOULD be 9." If nobody objects, I will do this change in the next version of the draft. Regards, Christer --_000_FF84A09F50A6DC48ACB6714F4666CC745E21D7DE2FESESSCMS0354e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
I've received an off-line comment regarding the usage= of port=3D9 when a UA is active.
 
The text in section 4.2 of the draft says:
 
"If the a=3Dsetup attribute value is "activ= e", the port number value
MUST either be the actual port number that the MSRP U= A will use for
the TCP endpoint, or the port value 9."
 
Since RFC 4145 uses "SHOULD use port 9", it= has been suggested to modify the text to:
 
"In accordance with RFC 4145, if the a=3Dsetup a= ttribute value is "active", the port number value SHOULD be 9.&qu= ot;
 
If nobody objects, I will do this change in the next = version of the draft.
 
Regards,
 
Christer
 
 
 
 
 --_000_FF84A09F50A6DC48ACB6714F4666CC745E21D7DE2FESESSCMS0354e_-- From cryingzgz@gmail.com Mon Apr 19 01:29:27 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1A73A67AB for ; Mon, 19 Apr 2010 01:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZ8GH6kgC-Jb for ; Mon, 19 Apr 2010 01:29:26 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 826913A6864 for ; Mon, 19 Apr 2010 01:29:26 -0700 (PDT) Received: by wwi18 with SMTP id 18so433015wwi.31 for ; Mon, 19 Apr 2010 01:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=9CQCWtj1hPsJ9tBzLU4T+kmqwYyGHnYlIh6w2y5cJvI=; b=aHQR/9tJgng6cHMwqe3MKrGrdeP72Kqq7iHEG3YZrR7V+lDMm0etAqkT6EXQUv4GbQ WdeF3vVaxyd346q6pPPqVPc+G8nBj4HSIXG4Ys49eD7Wnaxm6IJrUysOv8oAw8KZHt+6 g0tlsA/LXUSKkHJzFyPbeY1TkMt1GnVyQEaNA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=rrPl0qT7tX8mdrqOEnWNEw9M5+gqtd6YPC0CosmiqZkte4+kSO4hYGVwP8y63WEI2I 2ZNGvgU+KqFnG7PHiPcmha4EQSH3CbOZbGTa8s3+padTcZcWR45Tu3evxEDitFp0iCBo se9GlD82Ch/z3EtG5EHNlrecRxayCRxCXrgNo= MIME-Version: 1.0 Received: by 10.216.87.133 with HTTP; Mon, 19 Apr 2010 01:29:13 -0700 (PDT) Date: Mon, 19 Apr 2010 09:29:13 +0100 Received: by 10.216.86.71 with SMTP id v49mr4325623wee.14.1271665753922; Mon, 19 Apr 2010 01:29:13 -0700 (PDT) Message-ID: From: Guangzuo Zheng To: simple@ietf.org Content-Type: multipart/alternative; boundary=0016e6d56669891c09048492c15c X-Mailman-Approved-At: Mon, 19 Apr 2010 13:23:25 -0700 Subject: [Simple] Hi, can you give me some help X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 08:34:10 -0000 --0016e6d56669891c09048492c15c Content-Type: text/plain; charset=ISO-8859-1 Hi: Now I am working on an IM, it should handle multiple protocols, including XMPP and SIMPLE. By now we have searched for months to find an open source product based on SIMPLE, but got nothing. Would you give me some advices? Can you tell me any open source product based on SIMPLE and if you know some java libs for SIMPLE is better. Many thanks, Best Regards Zara --0016e6d56669891c09048492c15c Content-Type: text/html; charset=ISO-8859-1 Hi:

Now I am working on an IM, it should handle multiple protocols, including XMPP and SIMPLE. By now we have searched for months to find an open source product based on SIMPLE, but got nothing.
Would you give me some advices? Can you tell me any open source product based on SIMPLE and if you know some java libs for SIMPLE is better.

Many thanks,
Best Regards
Zara --0016e6d56669891c09048492c15c-- From hisham.khartabil@gmail.com Mon Apr 19 20:54:39 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05E413A6982 for ; Mon, 19 Apr 2010 20:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6OULs8YkXeo for ; Mon, 19 Apr 2010 20:54:38 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id DB3133A694F for ; Mon, 19 Apr 2010 20:54:37 -0700 (PDT) Received: by gwj20 with SMTP id 20so772560gwj.31 for ; Mon, 19 Apr 2010 20:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=MXhxhvbutacnB7NQlC34Vi3f4Ysu9JhCwsAtvW7vTdo=; b=WYVARsAYQI6qPeuDAbWPu/GaHaNCwHAp8btqCGNpH8gasjObPx4g5q0/kiatXIK68J 6OyLEy+6i0JP5dUH67kViB94811suy4KlwyQGJFiZsGW1yQl6UQK7Xz/ee+VkNiB7xLO OyTyYclZreDvIJSWxMNwsl4xga/JekbHhgeDE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Tpp/jCMoi94sgJPL2nVa+ki3StTeHwNYmahX2DPgOsiMdxeICApKN/H5UVVHIPo7mg lRbdak7hYc1bvnpGpnCIJbjNSsjrWgm0FvDEDk8ZpGcI2hA1rdX0E/qfhPrQzmoagBoH 5C+qz7LXKmoTP4VA2nOcxuLskeabbdhXMbbjw= MIME-Version: 1.0 Received: by 10.100.202.7 with HTTP; Mon, 19 Apr 2010 20:54:18 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 Apr 2010 13:54:18 +1000 Received: by 10.100.56.9 with SMTP id e9mr14339747ana.138.1271735658647; Mon, 19 Apr 2010 20:54:18 -0700 (PDT) Message-ID: From: Hisham Khartabil To: Guangzuo Zheng Content-Type: multipart/alternative; boundary=001485f882982ec2960484a30864 Cc: simple@ietf.org Subject: Re: [Simple] Hi, can you give me some help X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 03:54:39 -0000 --001485f882982ec2960484a30864 Content-Type: text/plain; charset=ISO-8859-1 http://www.ag-projects.com/content/blogcategory/31/96/ Regards, Hisham On 19 April 2010 18:29, Guangzuo Zheng wrote: > Hi: > > Now I am working on an IM, it should handle multiple protocols, including > XMPP and SIMPLE. By now we have searched for months to find an open source > product based on SIMPLE, but got nothing. > Would you give me some advices? Can you tell me any open source product > based on SIMPLE and if you know some java libs for SIMPLE is better. > > Many thanks, > Best Regards > Zara > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > > --001485f882982ec2960484a30864 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable http://w= ww.ag-projects.com/content/blogcategory/31/96/

Regards,
Hisha= m

On 19 April 2010 18:29, Guangzuo Zheng = <cryingzgz@gmai= l.com> wrote:
Hi:

Now I = am working on an IM, it should handle multiple=20 protocols, including XMPP and SIMPLE. By now we have searched for months to find an open source product based on SIMPLE, but got nothing.
Would you give me some advices? Can you tell me any open source product based on SIMPLE and if you know some java libs for SIMPLE is better.

Many thanks,
Best Regards
Zara
_______________________________________________
Simple mailing list
Simple@ietf.org
= https://www.ietf.org/mailman/listinfo/simple


--001485f882982ec2960484a30864-- From emcho@sip-communicator.org Tue Apr 20 00:30:44 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A7B13A6A18 for ; Tue, 20 Apr 2010 00:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCA02DgFywiK for ; Tue, 20 Apr 2010 00:30:38 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 717C33A6407 for ; Tue, 20 Apr 2010 00:30:37 -0700 (PDT) Received: by wwi18 with SMTP id 18so1176923wwi.31 for ; Tue, 20 Apr 2010 00:30:24 -0700 (PDT) Received: by 10.216.162.202 with SMTP id y52mr424524wek.76.1271748624647; Tue, 20 Apr 2010 00:30:24 -0700 (PDT) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id r29sm22378277wbv.3.2010.04.20.00.30.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Apr 2010 00:30:23 -0700 (PDT) Message-ID: <4BCD580E.8010806@sip-communicator.org> Date: Tue, 20 Apr 2010 09:30:22 +0200 From: Emil Ivov Organization: SIP Communicator User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Guangzuo Zheng References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org Subject: Re: [Simple] Hi, can you give me some help X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 07:30:44 -0000 Hey Guangzuo, =D0=9D=D0=B0 19.04.10 10:29, Guangzuo Zheng =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0: > Now I am working on an IM, it should handle multiple protocols, > including XMPP and SIMPLE. By now we have searched for months to find a= n > open source product based on SIMPLE, but got nothing. You may want to try SIP Communicator: http://sip-communicator.org. It is multi-platform (including Windows, Mac OS X, and Windows) and multiprotocol (including SIP/SIMPLE and XMPP among many others). It's also written in Java which seems to be of interest to you. > Would you give me some advices? Can you tell me any open source product= > based on SIMPLE and if you know some java libs for SIMPLE is better. SIP Communicator uses JAIN SIP: http://jain-sip.dev.java.net Hope this helps! Emil > Many thanks, > Best Regards > Zara >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --=20 Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France SIP Communicator emcho@sip-communicator.org PHONE: +33.1.77.62.43.30 http://sip-communicator.org FAX: +33.1.77.62.47.31 From ag@ag-projects.com Tue Apr 20 00:40:33 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7786D3A6A67 for ; Tue, 20 Apr 2010 00:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfWi9BJY5XCW for ; Tue, 20 Apr 2010 00:40:32 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by core3.amsl.com (Postfix) with ESMTP id 287AD3A6358 for ; Tue, 20 Apr 2010 00:40:27 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 1AAA2B01B3; Tue, 20 Apr 2010 09:40:18 +0200 (CEST) Received: from [192.168.1.124] (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 4BE89B0193; Tue, 20 Apr 2010 09:40:17 +0200 (CEST) Message-Id: <7851CA4B-957E-4A78-80BE-99109504ECB7@ag-projects.com> From: Adrian Georgescu To: Guangzuo Zheng In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 20 Apr 2010 09:40:17 +0200 References: X-Mailer: Apple Mail (2.936) Cc: simple@ietf.org Subject: Re: [Simple] Hi, can you give me some help X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 07:40:33 -0000 If you want to program in Python try SIP SIMPLE client SDK from: http://sipsimpleclient.com/ If you like Java, try SIP communicator from http://sip- communicator.org it also supports XMPP Adrian On Apr 19, 2010, at 10:29 AM, Guangzuo Zheng wrote: > Hi: > > Now I am working on an IM, it should handle multiple protocols, > including XMPP and SIMPLE. By now we have searched for months to > find an open source product based on SIMPLE, but got nothing. > Would you give me some advices? Can you tell me any open source > product based on SIMPLE and if you know some java libs for SIMPLE is > better. > > Many thanks, > Best Regards > Zara _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Wed Apr 21 02:58:33 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E9553A6B1F for ; Wed, 21 Apr 2010 02:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.626, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvVNqMymbIHD for ; Wed, 21 Apr 2010 02:58:32 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id AC8C33A6B1B for ; Wed, 21 Apr 2010 02:58:31 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-06-4bcecc3c3e58 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 05.EC.23740.C3CCECB4; Wed, 21 Apr 2010 11:58:20 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 21 Apr 2010 11:58:20 +0200 From: Christer Holmberg To: "'simple@ietf.org'" Date: Wed, 21 Apr 2010 11:58:19 +0200 Thread-Topic: Draft new versions: ACM & SESSMATCH Thread-Index: AcrhOSvWmO+DxRaJT6Kh2mzZwk6Pkg== Message-ID: 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_FF84A09F50A6DC48ACB6714F4666CC745E21DB8474ESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Simple] Draft new versions: ACM & SESSMATCH X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 09:58:33 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC745E21DB8474ESESSCMS0354e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the latest WGLC comments, I've submitted new versions of ACM (-08)= and SESSMATCH (-05). They can also be found at: http://users.piuha.net/cholmber/drafts/draft-ietf-simple-msrp-acm-08.txt http://users.piuha.net/cholmber/drafts/draft-ietf-simple-msrp-sessmatch-05.= txt Regards, Christer --_000_FF84A09F50A6DC48ACB6714F4666CC745E21DB8474ESESSCMS0354e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
Based on the latest WGLC comments, I've submitted new= versions of ACM (-08) and SESSMATCH (-05).
 
They can also be found at:
 
 
Regards,
 
Christer
 
 --_000_FF84A09F50A6DC48ACB6714F4666CC745E21DB8474ESESSCMS0354e_-- From root@core3.amsl.com Wed Apr 21 03:00:01 2010 Return-Path: X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E2C4C28C0F2; Wed, 21 Apr 2010 03:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100421100001.E2C4C28C0F2@core3.amsl.com> Date: Wed, 21 Apr 2010 03:00:01 -0700 (PDT) Cc: simple@ietf.org Subject: [Simple] I-D Action:draft-ietf-simple-msrp-acm-08.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 10:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : An Alternative Connection Model for the Message Session Relay Protocol (MSRP) Author(s) : C. Holmberg, S. Blau Filename : draft-ietf-simple-msrp-acm-08.txt Pages : 9 Date : 2010-04-21 This document defines an alternative connection model for Message Session Relay Protocol (MSRP) User Agents (UAs), which uses the connection-oriented media (COMEDIA) mechanism in order to create the MSRP transport connection. The model allows MSRP UAs behind Network Address Translators (NATs) to negotiate which endpoint initiates the establishment of the TCP connection, in order for MSRP messages to traverse the NAT. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-acm-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-simple-msrp-acm-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-21025704.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Apr 21 03:00:02 2010 Return-Path: X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EFA8C28C0F7; Wed, 21 Apr 2010 03:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100421100001.EFA8C28C0F7@core3.amsl.com> Date: Wed, 21 Apr 2010 03:00:01 -0700 (PDT) Cc: simple@ietf.org Subject: [Simple] I-D Action:draft-ietf-simple-msrp-sessmatch-05.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 10:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Session Matching Update for the Message Session Relay Protocol (MSRP) Author(s) : C. Holmberg, S. Blau Filename : draft-ietf-simple-msrp-sessmatch-05.txt Pages : 6 Date : 2010-04-21 This document updates the session matching procedure defined in sections 5.4 and 7.3 of RFC 4975, so that an Message Session Relay Protocol (MSRP) User Agent (UA) only uses the session-id part of the MSRP URI in order to perform the consistency checks. The update allows intermediaries, Application Layer Gateways (ALGs), to modify the address information in the MSRP URI of the Session Description Protocol (SDP) a=path attribute, without the need for the intermediaries to terminate and do the correlating modifications in the associated MSRP messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-sessmatch-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-simple-msrp-sessmatch-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-21025820.I-D@ietf.org> --NextPart-- From cryingzgz@gmail.com Tue Apr 20 10:32:23 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9E9028C127 for ; Tue, 20 Apr 2010 10:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqkcFHIbd1WA for ; Tue, 20 Apr 2010 10:32:23 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 327AE3A6B36 for ; Tue, 20 Apr 2010 10:32:18 -0700 (PDT) Received: by wwi18 with SMTP id 18so1583782wwi.31 for ; Tue, 20 Apr 2010 10:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=Q+qkZKUiCjxII1BnN2T4I7/9SY3h3rDPOgA4iEkJiSE=; b=cl8YHNRtJJQ5soQNeGbYNHritJPlva7ULX92QvRW9nrrIC2V8qC3nOlIZnbHFzXZ4s AJ0rUUE4Mn1X9AGpSQ1JOd4mH6r4kAlPSVXAKrF0m/6z8rtJfSC7vxN925d21yL/cvF+ rx0MLcZL9NCCQQ5QQS3fEm9yumCsjEPWo+7hM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=r/nBCR9fut3549ls5LjU1AUcsliZoH37c/+YjYHXv3TdrMZQ3vbVVpLA4E62xCrHIM aXtwdsTYH7STLsYecNzY72P4SZA9BS9WbVOwNl0hTtT5xlFCcTuEDnhVM9TMgNQFZ4In 7EoeKB+t/bhvMLBX1YKFFrK+P0ASXh+h9W3qU= MIME-Version: 1.0 Received: by 10.216.87.133 with HTTP; Tue, 20 Apr 2010 10:32:05 -0700 (PDT) In-Reply-To: <7851CA4B-957E-4A78-80BE-99109504ECB7@ag-projects.com> References: <7851CA4B-957E-4A78-80BE-99109504ECB7@ag-projects.com> Date: Tue, 20 Apr 2010 18:32:05 +0100 Received: by 10.216.184.83 with SMTP id r61mr3748826wem.34.1271784725302; Tue, 20 Apr 2010 10:32:05 -0700 (PDT) Message-ID: From: Guangzuo Zheng To: Adrian Georgescu Content-Type: multipart/alternative; boundary=001485f1dcb8c84d6c0484ae74eb X-Mailman-Approved-At: Wed, 21 Apr 2010 08:11:17 -0700 Cc: simple@ietf.org Subject: Re: [Simple] Hi, can you give me some help X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 17:32:23 -0000 --001485f1dcb8c84d6c0484ae74eb Content-Type: text/plain; charset=ISO-8859-1 Thanks very much, these are what I am searching for! Best Regards Zara --001485f1dcb8c84d6c0484ae74eb Content-Type: text/html; charset=ISO-8859-1 Thanks very much, these are what I am searching for!

Best Regards
Zara
--001485f1dcb8c84d6c0484ae74eb-- From nancy.greene@ericsson.com Fri Apr 23 08:25:51 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D56183A69D9 for ; Fri, 23 Apr 2010 08:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3tnEUY5pqTj for ; Fri, 23 Apr 2010 08:25:50 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 2DCA43A69AC for ; Fri, 23 Apr 2010 08:25:29 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o3NFPIh8030749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Apr 2010 10:25:19 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 23 Apr 2010 11:25:18 -0400 From: Nancy Greene To: "geir.sandbakken@tandberg.com" , Miguel Garcia A , "aki.niemi@nokia.com" , "simple@ietf.org" Date: Fri, 23 Apr 2010 11:25:16 -0400 Thread-Topic: [Simple] Multi-party Chat version 06 submitted - CPIM To issue Thread-Index: AcrXTsq2+LQrdusiQkOPBGCsnIy4QgDEpwPwAQML+0A= Message-ID: 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 Subject: Re: [Simple] Multi-party Chat version 06 submitted - CPIM To issue X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 23 Apr 2010 15:25:52 -0000 I have a comment on the mandating of including CPIM To header in MSRP SENDs= . =20 We have seen SBGs hide the Contact header value from clients. The client ge= ts the chat room URI from the Contact header. This is not a problem for the= SIP signalling associated with the chat room, since the SBG will map it ba= ck when required.=20 However, mandating clients to include the chat room URI in the CPIM To head= er in MSRP SENDs for multi-party chat is not a good idea: the chat room foc= us, nor the other participants will not find the chat room URI they expect = in the CPIM TO header, since it will receive the Contact URI given to the c= lient by the SBG.=20 One way around this is to just say that a client includes the CPIM To heade= r *only* when it wants to send a private message. When a chat message is me= ant to go to all participants, the client would not include a CPIM To heade= r in the MSRP SEND at all. What do you think? Nancy -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= Geir Arne Sandbakken Sent: April-08-10 3:08 PM To: Simple Subject: [Simple] Multi-party Chat version 06 submitted A new version of "Multi-party Chat Using the Message Session Relay Protocol= (MSRP)" has been submitted. The new version can be found here: http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-06.txt Changes from version -05 from on the WGLC summary: - Changed Anonymous URI allocation and usage - Simplified Nickname examples only to utilize alice and bob as user part o= f SIP URIs - Various spelling and wording errors Geir Arne _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From geir.sandbakken@tandberg.com Fri Apr 23 09:23:02 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E9863A6872 for ; Fri, 23 Apr 2010 09:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HliO8LyryARS for ; Fri, 23 Apr 2010 09:22:58 -0700 (PDT) Received: from mail179.messagelabs.com (mail179.messagelabs.com [85.158.139.35]) by core3.amsl.com (Postfix) with SMTP id 55A4C3A6978 for ; Fri, 23 Apr 2010 09:22:18 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: geir.sandbakken@tandberg.com X-Msg-Ref: server-9.tower-179.messagelabs.com!1272039726!35453788!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 27170 invoked from network); 23 Apr 2010 16:22:07 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-9.tower-179.messagelabs.com with SMTP; 23 Apr 2010 16:22:07 -0000 Received: from oslexcp1.eu.tandberg.int ([10.47.136.29]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Apr 2010 18:22:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Apr 2010 18:22:05 +0200 Message-ID: <9F6ACAE02B6DD040A1E259977622CFDB081B6CD3@oslexcp1.eu.tandberg.int> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Multi-party Chat version 06 submitted - CPIM To issue Thread-Index: AcrXTsq2+LQrdusiQkOPBGCsnIy4QgDEpwPwAQML+0ABJGNfMA== References: From: "Geir Arne Sandbakken" To: "Nancy Greene" , "Miguel Garcia A" , , X-OriginalArrivalTime: 23 Apr 2010 16:22:06.0775 (UTC) FILETIME=[1DCA4C70:01CAE301] Subject: Re: [Simple] Multi-party Chat version 06 submitted - CPIM To issue X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 23 Apr 2010 16:23:02 -0000 Nancy, I do understand your concern, but I don't think removing the CPIM wrapper is the solution. If you remove the wrapper, you remove the Sender header that identifies who's sending a specific message that is fanned out by the MSRP switch. This would break requirement number 2. I haven't thought this thru, but what if we required the chat room URI to be something specific instead of the conference URI? This will break if we allow for a single MSRP session cope with several conference instances. Thanks, Geir Arne > -----Original Message----- > From: Nancy Greene [mailto:nancy.greene@ericsson.com] > Sent: 23. april 2010 17:25 > To: Geir Arne Sandbakken; Miguel Garcia A; aki.niemi@nokia.com; > simple@ietf.org > Cc: Nadia Bishai > Subject: RE: [Simple] Multi-party Chat version 06 submitted - CPIM To > issue >=20 > I have a comment on the mandating of including CPIM To header in MSRP > SENDs. >=20 > We have seen SBGs hide the Contact header value from clients. The > client gets the chat room URI from the Contact header. This is not a > problem for the SIP signalling associated with the chat room, since the > SBG will map it back when required. >=20 > However, mandating clients to include the chat room URI in the CPIM To > header in MSRP SENDs for multi-party chat is not a good idea: the chat > room focus, nor the other participants will not find the chat room URI > they expect in the CPIM TO header, since it will receive the Contact > URI given to the client by the SBG. >=20 > One way around this is to just say that a client includes the CPIM To > header *only* when it wants to send a private message. When a chat > message is meant to go to all participants, the client would not > include a CPIM To header in the MSRP SEND at all. What do you think? >=20 > Nancy >=20 > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On > Behalf Of Geir Arne Sandbakken > Sent: April-08-10 3:08 PM > To: Simple > Subject: [Simple] Multi-party Chat version 06 submitted >=20 > A new version of "Multi-party Chat Using the Message Session Relay > Protocol (MSRP)" has been submitted. >=20 > The new version can be found here: > http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-06.txt >=20 > Changes from version -05 from on the WGLC summary: > - Changed Anonymous URI allocation and usage > - Simplified Nickname examples only to utilize alice and bob as user > part of SIP URIs > - Various spelling and wording errors >=20 > Geir Arne >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From nancy.greene@ericsson.com Fri Apr 23 09:38:11 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A2093A6978 for ; Fri, 23 Apr 2010 09:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeanpG84u1Zr for ; Fri, 23 Apr 2010 09:38:10 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 4D5BE3A6959 for ; Fri, 23 Apr 2010 09:38:10 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o3NGbx18007325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Apr 2010 11:37:59 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 23 Apr 2010 12:37:58 -0400 From: Nancy Greene To: Geir Arne Sandbakken , Miguel Garcia A , "aki.niemi@nokia.com" , "simple@ietf.org" Date: Fri, 23 Apr 2010 12:37:57 -0400 Thread-Topic: [Simple] Multi-party Chat version 06 submitted - CPIM To issue Thread-Index: AcrXTsq2+LQrdusiQkOPBGCsnIy4QgDEpwPwAQML+0ABJGNfMAAA+9dw Message-ID: References: <9F6ACAE02B6DD040A1E259977622CFDB081B6CD3@oslexcp1.eu.tandberg.int> In-Reply-To: <9F6ACAE02B6DD040A1E259977622CFDB081B6CD3@oslexcp1.eu.tandberg.int> 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 Subject: Re: [Simple] Multi-party Chat version 06 submitted - CPIM To issue X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 23 Apr 2010 16:38:11 -0000 Just to clarify, I am not saying remove the CPIM wrapper - the CPIM From is= required for sure. I just want to remove the CPIM To when a message is not= a private one. Nancy=20 -----Original Message----- From: Geir Arne Sandbakken [mailto:geir.sandbakken@tandberg.com]=20 Sent: April-23-10 12:22 PM To: Nancy Greene; Miguel Garcia A; aki.niemi@nokia.com; simple@ietf.org Cc: Nadia Bishai Subject: RE: [Simple] Multi-party Chat version 06 submitted - CPIM To issue Nancy, I do understand your concern, but I don't think removing the CPIM wrapper i= s the solution. If you remove the wrapper, you remove the Sender header th= at identifies who's sending a specific message that is fanned out by the MS= RP switch. This would break requirement number 2. I haven't thought this thru, but what if we required the chat room URI to b= e something specific instead of the conference URI? This will break if we = allow for a single MSRP session cope with several conference instances. Thanks, Geir Arne > -----Original Message----- > From: Nancy Greene [mailto:nancy.greene@ericsson.com] > Sent: 23. april 2010 17:25 > To: Geir Arne Sandbakken; Miguel Garcia A; aki.niemi@nokia.com;=20 > simple@ietf.org > Cc: Nadia Bishai > Subject: RE: [Simple] Multi-party Chat version 06 submitted - CPIM To=20 > issue >=20 > I have a comment on the mandating of including CPIM To header in MSRP=20 > SENDs. >=20 > We have seen SBGs hide the Contact header value from clients. The=20 > client gets the chat room URI from the Contact header. This is not a=20 > problem for the SIP signalling associated with the chat room, since the > SBG will map it back when required. >=20 > However, mandating clients to include the chat room URI in the CPIM To=20 > header in MSRP SENDs for multi-party chat is not a good idea: the chat=20 > room focus, nor the other participants will not find the chat room URI=20 > they expect in the CPIM TO header, since it will receive the Contact=20 > URI given to the client by the SBG. >=20 > One way around this is to just say that a client includes the CPIM To=20 > header *only* when it wants to send a private message. When a chat=20 > message is meant to go to all participants, the client would not=20 > include a CPIM To header in the MSRP SEND at all. What do you think? >=20 > Nancy >=20 > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20 > Behalf Of Geir Arne Sandbakken > Sent: April-08-10 3:08 PM > To: Simple > Subject: [Simple] Multi-party Chat version 06 submitted >=20 > A new version of "Multi-party Chat Using the Message Session Relay=20 > Protocol (MSRP)" has been submitted. >=20 > The new version can be found here: > http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-06.txt >=20 > Changes from version -05 from on the WGLC summary: > - Changed Anonymous URI allocation and usage > - Simplified Nickname examples only to utilize alice and bob as user=20 > part of SIP URIs > - Various spelling and wording errors >=20 > Geir Arne >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From miguel.a.garcia@ericsson.com Mon Apr 26 00:19:50 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50C4D3A6894 for ; Mon, 26 Apr 2010 00:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[AWL=-1.696, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXkp1J5Ou2Xj for ; Mon, 26 Apr 2010 00:19:48 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 0D7713A68AB for ; Mon, 26 Apr 2010 00:19:11 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-e6-4bd53e63c600 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 70.0A.23740.36E35DB4; Mon, 26 Apr 2010 09:18:59 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Apr 2010 09:18:58 +0200 Received: from [159.107.25.8] ([159.107.25.8]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Apr 2010 09:18:58 +0200 Message-ID: <4BD53E61.9050904@ericsson.com> Date: Mon, 26 Apr 2010 09:18:57 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: Nancy Greene References: <9F6ACAE02B6DD040A1E259977622CFDB081B6CD3@oslexcp1.eu.tandberg.int> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2010 07:18:58.0472 (UTC) FILETIME=[BCE32280:01CAE510] X-Brightmail-Tracker: AAAAAA== Cc: Geir Arne Sandbakken , "aki.niemi@nokia.com" , "simple@ietf.org" Subject: Re: [Simple] Multi-party Chat version 06 submitted - CPIM To issue X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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 Apr 2010 07:19:50 -0000 Hi Nancy: I believe the idea behind the To header in CPIM is to provide an aid to the MSRP switch on how to route the message, whether it is private or it is addressed to a chat room. This allows a client to have a single transport connection to an MSRP switch, and MSRP sessions to multiple chat rooms, besides making the MSRP message self routable. If we do not include the To header in CPIM, I think the MSRP switch can still route the message by making some strange deductions (If CPIM To header not present, then use MSRP session to route it to the default chat room), but we loose the property of making the message selfcontained. I don't understand the behavior of the SBC you mention. Perhaps this behavior is due to the fact that the SBC is not able to understand MSRP chat... but we said that the major drawback of an SBC is that it needs to understand every single extension made to the protocol. So, I wonder if that behavior in the SBC can be fixed (by supporting MSRP chat), and we can model our protocol without an SBC walk around. /Miguel On 23/04/2010 18:37, Nancy Greene wrote: > Just to clarify, I am not saying remove the CPIM wrapper - the CPIM From is required for sure. I just want to remove the CPIM To when a message is not a private one. > > > Nancy > > -----Original Message----- > From: Geir Arne Sandbakken [mailto:geir.sandbakken@tandberg.com] > Sent: April-23-10 12:22 PM > To: Nancy Greene; Miguel Garcia A; aki.niemi@nokia.com; simple@ietf.org > Cc: Nadia Bishai > Subject: RE: [Simple] Multi-party Chat version 06 submitted - CPIM To issue > > Nancy, > > I do understand your concern, but I don't think removing the CPIM wrapper is the solution. If you remove the wrapper, you remove the Sender header that identifies who's sending a specific message that is fanned out by the MSRP switch. This would break requirement number 2. > > I haven't thought this thru, but what if we required the chat room URI to be something specific instead of the conference URI? This will break if we allow for a single MSRP session cope with several conference instances. > > Thanks, > Geir Arne > >> -----Original Message----- >> From: Nancy Greene [mailto:nancy.greene@ericsson.com] >> Sent: 23. april 2010 17:25 >> To: Geir Arne Sandbakken; Miguel Garcia A; aki.niemi@nokia.com; >> simple@ietf.org >> Cc: Nadia Bishai >> Subject: RE: [Simple] Multi-party Chat version 06 submitted - CPIM To >> issue >> >> I have a comment on the mandating of including CPIM To header in MSRP >> SENDs. >> >> We have seen SBGs hide the Contact header value from clients. The >> client gets the chat room URI from the Contact header. This is not a >> problem for the SIP signalling associated with the chat room, since > the >> SBG will map it back when required. >> >> However, mandating clients to include the chat room URI in the CPIM To >> header in MSRP SENDs for multi-party chat is not a good idea: the chat >> room focus, nor the other participants will not find the chat room URI >> they expect in the CPIM TO header, since it will receive the Contact >> URI given to the client by the SBG. >> >> One way around this is to just say that a client includes the CPIM To >> header *only* when it wants to send a private message. When a chat >> message is meant to go to all participants, the client would not >> include a CPIM To header in the MSRP SEND at all. What do you think? >> >> Nancy >> >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >> Behalf Of Geir Arne Sandbakken >> Sent: April-08-10 3:08 PM >> To: Simple >> Subject: [Simple] Multi-party Chat version 06 submitted >> >> A new version of "Multi-party Chat Using the Message Session Relay >> Protocol (MSRP)" has been submitted. >> >> The new version can be found here: >> http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-06.txt >> >> Changes from version -05 from on the WGLC summary: >> - Changed Anonymous URI allocation and usage >> - Simplified Nickname examples only to utilize alice and bob as user >> part of SIP URIs >> - Various spelling and wording errors >> >> Geir Arne >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From hisham.khartabil@gmail.com Wed Apr 28 15:22:28 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C34E3A6860 for ; Wed, 28 Apr 2010 15:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YWlklu6VbSY for ; Wed, 28 Apr 2010 15:22:25 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id EA5C33A6839 for ; Wed, 28 Apr 2010 15:22:10 -0700 (PDT) Received: by gyh4 with SMTP id 4so7707381gyh.31 for ; Wed, 28 Apr 2010 15:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=Qw1gnQArr/cg9KgoRR7IrgcmrPyoyzrclJo1JSWSDsg=; b=d/Y0mk2kRNWfyE6EfdHNx+9fPvuKYGzpg8Mo7zOLiOwtwfQsWFWUfPyTReCwopF6VK WWuOcrfo5YnloVJXOjudeA5bz3RlkV1GEaRE7lJAsToTdJ86ipSWmcrdYASwRRSWmS6/ K+7nhYnf2fOd4rA0Jie+hGGCHGt6n11vCyugc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=aCRDJDLx6eGLUZ0dO4NSAysxCW1Zky3c9e57iqWeK5RXnCB8FnyAsU4hNqLLKaJi4C edw2bu1MLQZfAZ7phCKEHWiv4E+KByD4/dNt9dvpYZGXbNN0zYQRcvwasRRXg9vGjzOZ tDSb/30rNDsVBcqV40sUVW29it48gq/stfaOk= MIME-Version: 1.0 Received: by 10.101.188.12 with SMTP id q12mr3519004anp.97.1272493315055; Wed, 28 Apr 2010 15:21:55 -0700 (PDT) Received: by 10.100.197.19 with HTTP; Wed, 28 Apr 2010 15:21:55 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Apr 2010 08:21:55 +1000 Message-ID: From: Hisham Khartabil To: Simple WG Content-Type: multipart/alternative; boundary=001636ed6e3705e8e50485537017 Subject: [Simple] Fwd: Publication Request for draft-ietf-simple-msrp-acm-08 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 28 Apr 2010 22:22:28 -0000 --001636ed6e3705e8e50485537017 Content-Type: text/plain; charset=ISO-8859-1 FYI. Regards, Hisham ---------- Forwarded message ---------- From: Hisham Khartabil Date: 29 April 2010 08:17 Subject: Publication Request for draft-ietf-simple-msrp-acm-08 To: iesg-secretary@ietf.org, Gonzalo Camarillo < gonzalo.camarillo@ericsson.com> Cc: Robert Sparks , Ben Campbell This is a publication request for draft-ietf-simple-msrp-acm-08. The proto write-up is below. Thanks, Hisham The Proto writeup for this document is as follows: PROTO writeup for *http://www.ietf.org/id/draft-ietf-simple-msrp-acm-08.txt*: "An Alternative Connection Model for the Message Session Relay Protocol (MSRP)" (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document shepherd for this document is Hisham Khartabil. The document has been reviewed and is ready for forwarding to IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? WGLC comments have been received by: Ben Campbell, Hadriel Kaplan, Adam Roach, Salvatore Loreto, Shida Schubert, Krisztian Kiss and Adrian Georgescu. Other people have commented during the work on the document. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? The document has received review from a number of people whose interests lie in this particular field, in addition to the normal WG responses. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. The document shepherd has no concerns with this document. There have been no IPR disclosures on this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Among the people currently active in the WG there is a wide concensus behind the document. No objections have been raised. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) Nobody has threatened an appeal or otherwise indicated extreme discontent. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See *http://www.ietf.org/ID-Checklist.html*and *http://tools.ietf.org/tools/idnits/*.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. For ID-NITS the checks against idnits version 2.12.2 did not report any NITS. It is considered that the document contains all needed information. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The draft contains both normative and informative references. All references have reached RFC status. There are no downward references. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The document has no actions for IANA. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document does not contain any material written in a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. The document defines an alternative connection model for Message Session Relay Protocol (MSRP) User Agents (UAs), which uses the connection-oriended media (COMEDIA) mechanism in order to create the MSRP transport connection. The model allows MSRP UAs behind Network Address Translators (NATs) to negotiate which UA will initiate the establishment of the TCP connection, in order for MSRP messages to traverse the NAT. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was consensus in the working group to publish this document. There were no controversy points about this document. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? The document has received review by members of the SIMPLE working group, and by other experts. The document has been adopted by other standardization bodies. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' The document shepherd for this document is Hisham Khartabil. The responsible Area Director is Gonzalo Camarillo. The IANA Expert(s) for the registries in this document are . --001636ed6e3705e8e50485537017 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FYI.

Regards,
Hisham

----------= Forwarded message ----------
From: Hisham= Khartabil <hisham.khartabil@gmail.com>
Date: 29 April 2010 08:17
Subject: Publication Request for draft-ietf-si= mple-msrp-acm-08
To: iesg-sec= retary@ietf.org, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Cc: Robert Sparks <rjsparks@nost= rum.com>, Ben Campbell <ben@no= strum.com>


This is a publication request for draft-ietf-simple-msrp-acm-08. The proto write-up is below.

Thanks,
Hisham

The Proto writeup for this document is as follows:
=A0
PROTO writeup for http://www.ietf.org/id/draft-ietf-simpl= e-msrp-acm-08.txt: "An Alternative Connection Model for the Message Session Relay Protocol (MSRP)"
=A0
=A0
=A0=A0 (1.a)=A0 Who i= s the=20 Document Shepherd for this document?=A0 Has the
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Document=20 Shepherd personally reviewed this version of the
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 document=20 and, in particular, does he or she believe this
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 version is=20 ready for forwarding to the IESG for publication?
=A0
The document shepherd= =20 for this document is Hisham Khartabil.
=A0
The document has been= =20 reviewed and is ready for forwarding to IESG for publication.
=A0
=A0
=A0=A0 (1.b)=A0 Has t= he=20 document had adequate review both from key WG members
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 and from key non-WG members?=A0 Does the Document Shepherd have
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 any concerns about the depth or breadth of the reviews that
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 have been=20 performed?
=A0
WGLC comments have=20 been received by: Ben Campbell, Hadriel Kaplan, Adam Roach, Salvatore=20 Loreto, Shida Schubert, Krisztian Kiss and Adrian Georgescu. Other=20 people have commented during the work on the document.
=A0
=A0
=A0=A0 (1.c)=A0 Does = the=20 Document Shepherd have concerns that the document
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 needs more=20 review from a particular or broader perspective,
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 e.g.,=20 security, operational complexity, someone familiar with
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 AAA,=20 internationalization, or XML?
=A0
The document has=20 received review from a number of people whose interests lie in this=20 particular field, in addition to the normal WG responses.
=A0
=A0
=A0
=A0=A0 (1.d)=A0 Does = the=20 Document Shepherd have any specific concerns or
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 issues with=20 this document that the Responsible Area Director
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 and/or the=20 IESG should be aware of?=A0 For example, perhaps he
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 or she is=20 uncomfortable with certain parts of the document, or
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 has concerns whether there really is a need for it.=A0 In any
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 event, if=20 the WG has discussed those issues and has indicated
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 that it=20 still wishes to advance the document, detail those
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 concerns=20 here.=A0 Has an IPR disclosure related to this document
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 been filed?=A0 If so, please include a reference to the
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 disclosure=20 and summarize the WG discussion and conclusion on
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 this issue.
=A0
=A0
The document shepherd= =20 has no concerns with this document.
=A0
There have been no IP= R disclosures on this document.
=A0
=A0
=A0
=A0=A0 (1.e)=A0 How s= olid is the WG consensus behind this document?=A0 Does it
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 represent=20 the strong concurrence of a few individuals, with
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 others being silent, or does the WG as a whole understand and
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 agree with=20 it?
=A0
Among the people=20 currently active in the WG there is a wide concensus behind the=20 document. No objections have been raised.
=A0
=A0
=A0
=A0=A0 (1.f)=A0 Has a= nyone=20 threatened an appeal or otherwise indicated extreme
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 discontent?=A0 If so, please summarize the areas of conflict in
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 separate=20 email messages to the Responsible Area Director.=A0 (It
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 should be in a separate email because this questionnaire is
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 entered into the ID Tracker.)
=A0
Nobody has threatened= =20 an appeal or otherwise indicated extreme discontent.
=A0
=A0
=A0=A0 (1.g)=A0 Has t= he=20 Document Shepherd personally verified that the
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 document=20 satisfies all ID nits?=A0 (See
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 = http://www.ietf.org/ID-Checklist.html= and
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 http://tools.ietf.org/tools/idnits/= .)=A0 Boilerplate checks are
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 not enough;=20 this check needs to be thorough.=A0 Has the document
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 met all=20 formal review criteria it needs to, such as the MIB
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Doctor,=20 media type, and URI type reviews?=A0 If the document
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 does not=20 already indicate its intended status at the top of
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 the first=20 page, please indicate the intended status here.
=A0
For ID-NITS the check= s against idnits version 2.12.2 did not report any NITS.
=A0
It is considered that= =20 the document contains all needed information.
=A0
=A0
=A0=A0 (1.h)=A0 Has t= he=20 document split its references into normative and
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=20 informative?=A0 Are there normative references to documents that
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 are not=20 ready for advancement or are otherwise in an unclear
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 state?=A0 If=20 such normative references exist, what is the
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 strategy for their completion?=A0 Are there normative references
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 that are=20 downward references, as described in [RFC3967]?=A0 If
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 so, list=20 these downward references to support the Area
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Director in=20 the Last Call procedure for them [RFC3967].
=A0
The draft contains=20 both normative and informative references.
=A0
All references have= =20 reached RFC status.
=A0
There are no downward= =20 references.
=A0
=A0
=A0=A0 (1.i)=A0 Has t= he=20 Document Shepherd verified that the document's IANA
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=20 Considerations section exists and is consistent with the body
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 of the=20 document?=A0 If the document specifies protocol
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 extensions,=20 are reservations requested in appropriate IANA
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 registries?=A0 Are the IANA registries clearly identified?=A0 If
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 the document creates a new registry, does it define the
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 proposed=20 initial contents of the registry and an allocation
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 procedure=20 for future registrations?=A0 Does it suggest a
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 reasonable=20 name for the new registry?=A0 See [RFC2434].=A0 If the
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 document=20 describes an Expert Review process, has the Document
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Shepherd=20 conferred with the Responsible Area Director so that
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 the IESG can appoint the needed Expert during IESG Evaluation?
=A0
The document has no= =20 actions for IANA.
=A0
=A0
=A0=A0 (1.j)=A0 Has t= he=20 Document Shepherd verified that sections of the
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 document=20 that are written in a formal language, such as XML
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 code, BNF=20 rules, MIB definitions, etc., validate correctly in
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 an automated checker?
=A0
The document does not= =20 contain any material written in a formal language.
=A0
=A0
=A0
=A0=A0 (1.k)=A0 The I= ESG=20 approval announcement includes a Document
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Announcement Write-Up.=A0 Please provide such a Document
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Announcement Write-Up.=A0 Recent examples can be found in the
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 "Action"=20 announcements for approved documents.=A0 The approval
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 announcement contains the following sections:
=A0
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Technical=20 Summary
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Relevant=20 content can frequently be found in the abstract
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 and/or=20 introduction of the document.=A0 If not, this may be
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 an=20 indication that there are deficiencies in the abstract
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 or=20 introduction.
=A0
The document defines= =20 an alternative connection model for Message Session Relay Protocol=20 (MSRP) User Agents (UAs), which uses the connection-oriended media=20 (COMEDIA) mechanism in order to create the MSRP transport connection.=A0 The model allows MSRP UAs behind Network Address=20 Translators (NATs) to negotiate which UA will initiate the establishment of the TCP connection, in order for MSRP messages to traverse the NAT.
=A0
=A0
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Working=20 Group Summary
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Was there anything in the WG process that is worth noting?
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 For=20 example, was there controversy about particular points
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 or were=20 there decisions where the consensus was
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=20 particularly rough?
=A0
There was consensus i= n the working group to publish this document.
=A0
There were no=20 controversy points about this document.
=A0
=A0
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Document=20 Quality
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Are there existing implementations of the protocol?=A0 Have a
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=20 significant number of vendors indicated their plan to
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 implement the specification?=A0 Are there any reviewers that
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 merit=20 special mention as having done a thorough review,
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 e.g., one that resulted in important changes or a
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=20 conclusion that the document had no substantive issues?=A0 If
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 there was a MIB Doctor, Media Type, or other Expert Review,
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 what was=20 its course (briefly)?=A0 In the case of a Media Type
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Review,=20 on what date was the request posted?
=A0
The document has=20 received review by members of the SIMPLE working group, and by other=20 experts.
=A0
The document has been= =20 adopted by other standardization bodies.
=A0
=A0
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Personnel
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Who is=20 the Document Shepherd for this document?=A0 Who is the
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=20 Responsible Area Director?=A0 If the document requires IANA
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=20 experts(s), insert 'The IANA Expert(s) for the registries
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 in this=20 document are <TO BE ADDED BY THE AD>.'
=A0
The document shepherd= =20 for this document is Hisham Khartabil.
=A0
The responsible Area= =20 Director is Gonzalo Camarillo.
=A0
The IANA Expert(s) fo= r the registries in this document are <TO BE ADDED BY THE AD>.<= /div>

--001636ed6e3705e8e50485537017-- From hisham.khartabil@gmail.com Wed Apr 28 15:23:02 2010 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 332393A6948 for ; Wed, 28 Apr 2010 15:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.765 X-Spam-Level: X-Spam-Status: No, score=-1.765 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DI3tDqXi9zdG for ; Wed, 28 Apr 2010 15:22:55 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 54DD528C139 for ; Wed, 28 Apr 2010 15:22:38 -0700 (PDT) Received: by mail-gy0-f172.google.com with SMTP id 4so7707381gyh.31 for ; Wed, 28 Apr 2010 15:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=xF6A7Z3ttDKEoVI0R1+SzGlKnWEyk6sR41UsAi3gNv0=; b=PP4j2Gv+LKoQFxurdPKDSy0D2z5eqaNb/rLhetH3nbsrZubIlZLbfCPTLfbZW9ByqG IAPvnULnh7wWpghBLQLoc2U3tDQQ0HFmNDXJD6GuSgfibeRxjW8t4oewhicJKxgay47o dJv6vhKTef7Wl9UjQCuIai4XOXM13zyhZkaYc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=v/hRFTTCHfH1gud3X35ckxrlZCE3Xl541cyBa4zkF921SJs9h0NRs98PgDSjtnjaFu liJ72N8Hf5s/0yYsMyN6OD0OOr2KllGAuDve7yPqquSUHKEIICZa7tu/cD13VL/x6h6o 1XbReaK067YS/aJ3/QccPUqx61No+I193ag5Y= MIME-Version: 1.0 Received: by 10.101.163.35 with SMTP id q35mr3902912ano.133.1272493345188; Wed, 28 Apr 2010 15:22:25 -0700 (PDT) Received: by 10.100.197.19 with HTTP; Wed, 28 Apr 2010 15:22:24 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Apr 2010 08:22:24 +1000 Message-ID: From: Hisham Khartabil To: Simple WG Content-Type: multipart/alternative; boundary=0016e68ba1b7d1add40485537196 Subject: [Simple] Fwd: Publication Request for draft-ietf-simple-msrp-sessmatch-05 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 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, 28 Apr 2010 22:23:02 -0000 --0016e68ba1b7d1add40485537196 Content-Type: text/plain; charset=ISO-8859-1 FYI. Regards, Hisham ---------- Forwarded message ---------- From: Hisham Khartabil Date: 29 April 2010 08:21 Subject: Publication Request for draft-ietf-simple-msrp-sessmatch-05 To: iesg-secretary@ietf.org, Gonzalo Camarillo < gonzalo.camarillo@ericsson.com> Cc: Robert Sparks , Ben Campbell This is a publication request for draft-ietf-simple-msrp-sessmatch-05. The proto write up is below. Thanks, Hisham PROTO writeup for * http://www.ietf.org/id/draft-ietf-simple-msrp-sessmatch-05.txt*: "Session Matching Update for the Message Session Relay Protocol (MSRP)" (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document shepherd for this document is Hisham Khartabil. The document has been reviewed and is ready for forwarding to IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? WGLC comments have been received by: Ben Campbell, Hadriel Kaplan, Adam Roach, Salvatore Loreto, Shida Schubert, Krisztian Kiss and Adrian Georgescu. Other people have commented during the work on the document. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? The document has received review from a number of people whose interests lie in this particular field, in addition to the normal WG responses. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. The document shepherd has no concerns with this document. There have been no IPR disclosures on this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Among the people currently active in the WG there is a wide concensus behind the document. No objections have been raised. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) Nobody has threatened an appeal or otherwise indicated extreme discontent. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See *http://www.ietf.org/ID-Checklist.html*and *http://tools.ietf.org/tools/idnits/*.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. For ID-NITS the checks against idnits version 2.12.2 did not report any NITS. It is considered that the document contains all needed information. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The draft contains both normative and informative references. All IETF references have reached RFC status. There are no normative downward references. There is an informative reference to a 3GPP specification. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The document updates section 7.3 of RFC 4975. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document does not contain any material written in a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. The document updates the session matching procedure defined in sections 5.4 and 7.3 of RFC 4975, so that an Message Session Relay Protocol (MSRP) User Agent (UA) only uses the session-id part of the MSRP URI in order to perform the consistency checks. The update allows intermediaries, Application Layer Gateways (ALGs), to modify the address information in the MSRP URI of the Session Description Protocol (SDP) a=path attribute, without the need for the intermediaries to terminate and do the correlating modifications in the associated MSRP messages. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was consensus in the working group to publish this document. There were discussions regarding the usage of the SDP c/m parameters for routing of MSRP messages, rather than using the a=path attribute. It was agreed to use the a=path attribute. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? The document has received review by members of the SIMPLE working group, and by other experts. The document has been adopted by other standardization bodies. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' The document shepherd for this document is Hisham Khartabil. The responsible Area Director is Gonzalo Camarillo. The IANA Expert(s) for the registries in this document are . --0016e68ba1b7d1add40485537196 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FYI.

Regards,
Hisham

----------= Forwarded message ----------
From: Hisham= Khartabil <hisham.khartabil@gmail.com>
Date: 29 April 2010 08:21
Subject: Publication Request for draft-ietf-si= mple-msrp-sessmatch-05
To: ie= sg-secretary@ietf.org, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Cc: Robert Sparks <rjsparks@nost= rum.com>, Ben Campbell <ben@no= strum.com>


This is a publication request for draft-ietf-s= imple-msrp-sessmatch-05. The proto write up is below.

Thanks,
Hisham

PROTO=20 writeup for http://www.ietf.or= g/id/draft-ietf-simple-msrp-sessmatch-05.txt: "Session Matching Update for the Message Session Relay Protocol (MSRP)"
=A0
=A0
=A0=A0 (1.a)=A0 Who is the Document Shepherd for this= =20 document?=A0 Has the
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Document Shepherd persona= lly reviewed this version of the
=A0=A0=A0=A0=A0=A0=A0=A0=A0 document and, in particul= ar, does he or=20 she believe this
=A0=A0=A0=A0=A0=A0=A0=A0=A0 version is ready for forw= arding to the=20 IESG for publication?
=A0
The document shepherd for this document is Hisham=20 Khartabil.
=A0
The document has been reviewed and is ready for=20 forwarding to IESG for publication.
=A0
=A0
=A0=A0 (1.b)=A0 Has the document had adequate review = both=20 from key WG members
=A0=A0=A0=A0=A0=A0=A0=A0=A0 and from key non-WG membe= rs?=A0 Does the=20 Document Shepherd have
=A0=A0=A0=A0=A0=A0=A0=A0=A0 any concerns about the de= pth or breadth of the reviews that
=A0=A0=A0=A0=A0=A0=A0=A0=A0 have been performed?
=A0
WGLC comments have been received by: Ben Campbell,=20 Hadriel Kaplan, Adam Roach, Salvatore Loreto, Shida Schubert, Krisztian=20 Kiss and Adrian Georgescu. Other people have commented during the work=20 on the document.
=A0
=A0
=A0=A0 (1.c)=A0 Does the Document Shepherd have conce= rns=20 that the document
=A0=A0=A0=A0=A0=A0=A0=A0=A0 needs more review from a = particular or=20 broader perspective,
=A0=A0=A0=A0=A0=A0=A0=A0=A0 e.g., security, operation= al complexity,=20 someone familiar with
=A0=A0=A0=A0=A0=A0=A0=A0=A0 AAA, internationalization= , or XML?
=A0
The document has received review from a number of=20 people whose interests lie in this particular field, in addition to the=20 normal WG responses.
=A0
=A0
=A0
=A0=A0 (1.d)=A0 Does the Document Shepherd have any= =20 specific concerns or
=A0=A0=A0=A0=A0=A0=A0=A0=A0 issues with this document= that the=20 Responsible Area Director
=A0=A0=A0=A0=A0=A0=A0=A0=A0 and/or the IESG should be= aware of?=A0 For=20 example, perhaps he
=A0=A0=A0=A0=A0=A0=A0=A0=A0 or she is uncomfortable w= ith certain parts of the document, or
=A0=A0=A0=A0=A0=A0=A0=A0=A0 has concerns whether ther= e really is a=20 need for it.=A0 In any
=A0=A0=A0=A0=A0=A0=A0=A0=A0 event, if the WG has disc= ussed those=20 issues and has indicated
=A0=A0=A0=A0=A0=A0=A0=A0=A0 that it still wishes to a= dvance the=20 document, detail those
=A0=A0=A0=A0=A0=A0=A0=A0=A0 concerns here.=A0 Has an = IPR disclosure=20 related to this document
=A0=A0=A0=A0=A0=A0=A0=A0=A0 been filed?=A0 If so, ple= ase include a=20 reference to the
=A0=A0=A0=A0=A0=A0=A0=A0=A0 disclosure and summarize = the WG discussion and conclusion on
=A0=A0=A0=A0=A0=A0=A0=A0=A0 this issue.
=A0
=A0
The document shepherd has no concerns with this=20 document.
=A0
There have been no IPR disclosures on this document.<= /font>
=A0
=A0
=A0
=A0=A0 (1.e)=A0 How solid is the WG consensus behind = this=20 document?=A0 Does it
=A0=A0=A0=A0=A0=A0=A0=A0=A0 represent the strong conc= urrence of a few=20 individuals, with
=A0=A0=A0=A0=A0=A0=A0=A0=A0 others being silent, or d= oes the WG as a=20 whole understand and
=A0=A0=A0=A0=A0=A0=A0=A0=A0 agree with it?
=A0
Among the people currently active in the WG there is a wide concensus behind the document. No objections have been raised.
=A0
=A0
=A0
=A0=A0 (1.f)=A0 Has anyone threatened an appeal or=20 otherwise indicated extreme
=A0=A0=A0=A0=A0=A0=A0=A0=A0 discontent?=A0 If so, ple= ase summarize the=20 areas of conflict in
=A0=A0=A0=A0=A0=A0=A0=A0=A0 separate email messages t= o the Responsible Area Director.=A0 (It
=A0=A0=A0=A0=A0=A0=A0=A0=A0 should be in a separate e= mail because this questionnaire is
=A0=A0=A0=A0=A0=A0=A0=A0=A0 entered into the ID Track= er.)
=A0
Nobody has threatened an appeal or otherwise=20 indicated extreme discontent.
=A0
=A0
=A0=A0 (1.g)=A0 Has the Document Shepherd personally= =20 verified that the
=A0=A0=A0=A0=A0=A0=A0=A0=A0 document satisfies all ID= nits?=A0 (See
=A0=A0=A0=A0=A0=A0=A0=A0=A0 http:= //www.ietf.org/ID-Checklist.html and
=A0=A0=A0=A0=A0=A0=A0=A0=A0 http://= tools.ietf.org/tools/idnits/.)=A0 Boilerplate checks are
=A0=A0=A0=A0=A0=A0=A0=A0=A0 not enough; this check ne= eds to be=20 thorough.=A0 Has the document
=A0=A0=A0=A0=A0=A0=A0=A0=A0 met all formal review cri= teria it needs=20 to, such as the MIB
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Doctor, media type, and U= RI type reviews?=A0 If the document
=A0=A0=A0=A0=A0=A0=A0=A0=A0 does not already indicate= its intended=20 status at the top of
=A0=A0=A0=A0=A0=A0=A0=A0=A0 the first page, please in= dicate the=20 intended status here.
=A0
For ID-NITS the checks against idnits version 2.12.2 did not report any NITS.
=A0
It is considered that the document contains all=20 needed information.
=A0
=A0
=A0=A0 (1.h)=A0 Has the document split its references= into normative and
=A0=A0=A0=A0=A0=A0=A0=A0=A0 informative?=A0 Are there= normative=20 references to documents that
=A0=A0=A0=A0=A0=A0=A0=A0=A0 are not ready for advance= ment or are=20 otherwise in an unclear
=A0=A0=A0=A0=A0=A0=A0=A0=A0 state?=A0 If such normati= ve references=20 exist, what is the
=A0=A0=A0=A0=A0=A0=A0=A0=A0 strategy for their comple= tion?=A0 Are there=20 normative references
=A0=A0=A0=A0=A0=A0=A0=A0=A0 that are downward referen= ces, as described in [RFC3967]?=A0 If
=A0=A0=A0=A0=A0=A0=A0=A0=A0 so, list these downward r= eferences to=20 support the Area
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Director in the Last Call= procedure for=20 them [RFC3967].
=A0
The draft contains both normative and informative=20 references.
=A0
All IETF references have reached RFC status.
=A0
There are no normative downward references. There is an informative reference to a 3GPP specification.
=A0
=A0
=A0=A0 (1.i)=A0 Has the Document Shepherd verified th= at=20 the document's IANA
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Considerations section ex= ists and is=20 consistent with the body
=A0=A0=A0=A0=A0=A0=A0=A0=A0 of the document?=A0 If th= e document=20 specifies protocol
=A0=A0=A0=A0=A0=A0=A0=A0=A0 extensions, are reservati= ons requested in=20 appropriate IANA
=A0=A0=A0=A0=A0=A0=A0=A0=A0 registries?=A0 Are the IA= NA registries=20 clearly identified?=A0 If
=A0=A0=A0=A0=A0=A0=A0=A0=A0 the document creates a ne= w registry, does=20 it define the
=A0=A0=A0=A0=A0=A0=A0=A0=A0 proposed initial contents= of the registry=20 and an allocation
=A0=A0=A0=A0=A0=A0=A0=A0=A0 procedure for future regi= strations?=A0 Does=20 it suggest a
=A0=A0=A0=A0=A0=A0=A0=A0=A0 reasonable name for the n= ew registry?=A0 See [RFC2434].=A0 If the
=A0=A0=A0=A0=A0=A0=A0=A0=A0 document describes an Exp= ert Review=20 process, has the Document
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Shepherd conferred with t= he Responsible=20 Area Director so that
=A0=A0=A0=A0=A0=A0=A0=A0=A0 the IESG can appoint the = needed Expert=20 during IESG Evaluation?
=A0
The document updates section 7.3 of RFC 4975.<= /div>
=A0
=A0
=A0=A0 (1.j)=A0 Has the Document Shepherd verified th= at=20 sections of the
=A0=A0=A0=A0=A0=A0=A0=A0=A0 document that are written= in a formal=20 language, such as XML
=A0=A0=A0=A0=A0=A0=A0=A0=A0 code, BNF rules, MIB defi= nitions, etc.,=20 validate correctly in
=A0=A0=A0=A0=A0=A0=A0=A0=A0 an automated checker?
=A0
The document does not contain any material written=20 in a formal language.
=A0
=A0
=A0
=A0=A0 (1.k)=A0 The IESG approval announcement includ= es a=20 Document
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Announcement Write-Up.=A0= Please provide=20 such a Document
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Announcement Write-Up.=A0= Recent examples=20 can be found in the
=A0=A0=A0=A0=A0=A0=A0=A0=A0 "Action" announ= cements for approved=20 documents.=A0 The approval
=A0=A0=A0=A0=A0=A0=A0=A0=A0 announcement contains the= following=20 sections:
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Technical Summary<= /div>
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Relevant content can freq= uently be found=20 in the abstract
=A0=A0=A0=A0=A0=A0=A0=A0=A0 and/or introduction of th= e document.=A0 If=20 not, this may be
=A0=A0=A0=A0=A0=A0=A0=A0=A0 an indication that there = are deficiencies=20 in the abstract
=A0=A0=A0=A0=A0=A0=A0=A0=A0 or introduction.
=A0
The document updates the session matching procedure= =20 defined in
sections 5.4 and 7.3 of RFC 4975, so that an Message Session Relay
Protocol (MSRP) User Agent (UA) only uses the=20 session-id part of the
MSRP URI in order to perform the consistency=20 checks.=A0 The update
allows intermediaries, Application Layer Gateways=20 (ALGs), to modify
the address information in the MSRP URI of the=20 Session Description
Protocol (SDP) a=3Dpath attribute, without the need= =20 for the
intermediaries to terminate and do the correlating=20 modifications in
the associated MSRP messages.
=A0
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Working Group Summary
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Was there anything in the= WG process that=20 is worth noting?
=A0=A0=A0=A0=A0=A0=A0=A0=A0 For example, was there co= ntroversy about=20 particular points
=A0=A0=A0=A0=A0=A0=A0=A0=A0 or were there decisions w= here the=20 consensus was
=A0=A0=A0=A0=A0=A0=A0=A0=A0 particularly rough?
=A0
There was consensus in the working group to publish= =20 this document.
=A0
There were discussions regarding the usage of the=20 SDP c/m parameters for routing of MSRP messages, rather than using the=20 a=3Dpath attribute. It was agreed to use the a=3Dpath attribute.
=A0
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Document Quality
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Are there existing implem= entations of the=20 protocol?=A0 Have a
=A0=A0=A0=A0=A0=A0=A0=A0=A0 significant number of ven= dors indicated=20 their plan to
=A0=A0=A0=A0=A0=A0=A0=A0=A0 implement the specificati= on?=A0 Are there=20 any reviewers that
=A0=A0=A0=A0=A0=A0=A0=A0=A0 merit special mention as = having done a=20 thorough review,
=A0=A0=A0=A0=A0=A0=A0=A0=A0 e.g., one that resulted i= n important=20 changes or a
=A0=A0=A0=A0=A0=A0=A0=A0=A0 conclusion that the docum= ent had no=20 substantive issues?=A0 If
=A0=A0=A0=A0=A0=A0=A0=A0=A0 there was a MIB Doctor, M= edia Type, or=20 other Expert Review,
=A0=A0=A0=A0=A0=A0=A0=A0=A0 what was its course (brie= fly)?=A0 In the=20 case of a Media Type
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Review, on what date was = the request=20 posted?
=A0
The document has received review by members of the=20 SIMPLE working group, and by other experts.
=A0
The document has been adopted by other=20 standardization bodies.
=A0
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Personnel
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Who is the Document Sheph= erd for this=20 document?=A0 Who is the
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Responsible Area Director= ?=A0 If the=20 document requires IANA
=A0=A0=A0=A0=A0=A0=A0=A0=A0 experts(s), insert 'T= he IANA Expert(s) for the registries
=A0=A0=A0=A0=A0=A0=A0=A0=A0 in this document are <= TO BE ADDED BY=20 THE AD>.'
=A0
The document shepherd for this document is Hisham=20 Khartabil.
=A0
The responsible Area Director is Gonzalo Camarillo. <= /font>
=A0
The IANA Expert(s) for the registries in this=20 document are <TO BE ADDED BY THE AD>.
=A0
=A0


--0016e68ba1b7d1add40485537196--