From ben@nostrum.com Tue Apr 5 14:21:31 2011 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 89BC23A67D7 for ; Tue, 5 Apr 2011 14:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 dXIL96n-RebV for ; Tue, 5 Apr 2011 14:21:30 -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 41C8F3A67C1 for ; Tue, 5 Apr 2011 14:21:30 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p35LN1vw003411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Apr 2011 16:23:02 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Apr 2011 16:23:01 -0500 Message-Id: <1EA75631-ECF8-4CDF-A90D-951CC1B6B841@nostrum.com> To: Simple WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism) Cc: Cullen Jennings , Adam Roach , John Mattsson Subject: [Simple] draft-ietf-simple-msrp-sessmatch-10 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: Tue, 05 Apr 2011 21:21:31 -0000 Hi, A small group (Christer, Cullen, Adam, Hadriel, John, and myself) held a = face-to-face discussion of issues related to = draft-ietf-simple-msrp-sessmatch-10. The discussion highlighted a = backwards compatibility issue. Specifically, an MSRP user agent implementing the sessmatch description = that is behind an SBC or ALG that operates as the draft envisions cannot = interoperate with a peer that uses an MSRP Relay as defined in RFC 4976. = The issue is not caused by the sessmatch extension per se, but by the = SBC/ALG. However, the sole purpose of this extension is to allow such = behavior. We agreed that this was a backwards compatibility issue, and as such = would not be acceptable without some negotiation mechanism. We discussed the following options. Note that no one option was favored = by all present--I will let people speak individually as to their = preferences. 1) Treat MSRP over ALGs using the sessmatch extension as a fundamentally = different protocol from base MSRP 2) Create a SIP option tag that indicates that a UA both supports = sessmatch, and does not use an MSRP relay. 3) Give up on sessmatch, and assert that for an ALG or SBC to relay = MSRP, it must rewrite the MSRP header fields in a manner similar to an = MSRP Relay. The chairs would appreciate a quick resolution to this issue, and = request anyone who cares please make their opinions known on the SIMPLE = list as soon as possible. Thanks! Ben.= From hisham.khartabil@gmail.com Tue Apr 5 19:05:30 2011 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 DECE13A6839 for ; Tue, 5 Apr 2011 19:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYEIlJWS21rS for ; Tue, 5 Apr 2011 19:05:30 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id AB5DF3A6833 for ; Tue, 5 Apr 2011 19:05:29 -0700 (PDT) Received: by eye13 with SMTP id 13so350400eye.31 for ; Tue, 05 Apr 2011 19:07:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5nBE2U2YshbfkjhFefNyuztiQDR/XVnXjePIFb0ZbAg=; b=Y5u1PWdt0pdhUZLkGSMe+V+htZOqTvYhscZPWG0RWsL2+Xi7+nMhnYHumh4Fmct0r+ Gx6bAdct29ye45pFzaWcbYxASo7bwtiNXT9frfoINWGFLjn4zpYC6kJ+egVNC8DZiA03 FbRoazvhjvMb1DBjrD5tRfEMBXVDs4mciBlW8= 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=LALRI9HXJah3Hswr+0hZ6zMgThvzOUxm+jLI7mGO5YpODE5CFRD4KTYsK5q/gY2Lgv s8LLD70XrUhDcwJM/tfpqlJOK9zral/oESNjci5nT1vj86VjqAfwUUJwNAVzmrDXLKDk dp62GN3HM+uL2hjRv3LSusKP5IQbPstVFJVzg= MIME-Version: 1.0 Received: by 10.14.119.205 with SMTP id n53mr131241eeh.153.1302055632329; Tue, 05 Apr 2011 19:07:12 -0700 (PDT) Received: by 10.14.45.16 with HTTP; Tue, 5 Apr 2011 19:07:12 -0700 (PDT) In-Reply-To: <1EA75631-ECF8-4CDF-A90D-951CC1B6B841@nostrum.com> References: <1EA75631-ECF8-4CDF-A90D-951CC1B6B841@nostrum.com> Date: Wed, 6 Apr 2011 12:07:12 +1000 Message-ID: From: Hisham Khartabil To: Ben Campbell Content-Type: multipart/alternative; boundary=90e6ba539e52715b1404a03673b3 Cc: Cullen Jennings , Adam Roach , Simple WG , John Mattsson Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 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: Wed, 06 Apr 2011 02:05:31 -0000 --90e6ba539e52715b1404a03673b3 Content-Type: text/plain; charset=ISO-8859-1 It sounds like options 1 and 2 will not allow interoperability between the 2 UAs. I least hate option 3, but do we need to document that? Hisham On 6 April 2011 07:23, Ben Campbell wrote: > Hi, > > A small group (Christer, Cullen, Adam, Hadriel, John, and myself) held a > face-to-face discussion of issues related to > draft-ietf-simple-msrp-sessmatch-10. The discussion highlighted a backwards > compatibility issue. > > Specifically, an MSRP user agent implementing the sessmatch description > that is behind an SBC or ALG that operates as the draft envisions cannot > interoperate with a peer that uses an MSRP Relay as defined in RFC 4976. The > issue is not caused by the sessmatch extension per se, but by the SBC/ALG. > However, the sole purpose of this extension is to allow such behavior. > > We agreed that this was a backwards compatibility issue, and as such would > not be acceptable without some negotiation mechanism. > > We discussed the following options. Note that no one option was favored by > all present--I will let people speak individually as to their preferences. > > 1) Treat MSRP over ALGs using the sessmatch extension as a fundamentally > different protocol from base MSRP > > 2) Create a SIP option tag that indicates that a UA both supports > sessmatch, and does not use an MSRP relay. > > 3) Give up on sessmatch, and assert that for an ALG or SBC to relay MSRP, > it must rewrite the MSRP header fields in a manner similar to an MSRP Relay. > > The chairs would appreciate a quick resolution to this issue, and request > anyone who cares please make their opinions known on the SIMPLE list as soon > as possible. > > Thanks! > > Ben. --90e6ba539e52715b1404a03673b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It sounds like options 1 and 2 will not allow interoperability between the = 2 UAs. I least hate option 3, but do we need to document that?

Hisha= m

On 6 April 2011 07:23, Ben Campbell <ben@nostrum.com&g= t; wrote:
Hi,

A small group (Christer, Cullen, Adam, Hadriel, John, and myself) held a fa= ce-to-face discussion of issues related to draft-ietf-simple-msrp-sessmatch= -10. The discussion highlighted a backwards compatibility issue.

Specifically, an MSRP user agent implementing the sessmatch description tha= t is behind an SBC or ALG that operates as the draft envisions cannot inter= operate with a peer that uses an MSRP Relay as defined in RFC 4976. The iss= ue is not caused by the sessmatch extension per se, but by the SBC/ALG. How= ever, the sole purpose of this extension is to allow such behavior.

We agreed that this was a backwards compatibility issue, and as such would = not be acceptable without some negotiation mechanism.

We discussed the following options. Note that no one option was favored by = all present--I will let people speak individually as to their preferences.<= br>
1) Treat MSRP over ALGs using the sessmatch extension as a fundamentally di= fferent protocol from base MSRP

2) Create a SIP option tag that indicates that a UA both supports sessmatch= , and does not use an MSRP relay.

3) Give up on sessmatch, and assert that for an ALG or SBC to relay MSRP, i= t must rewrite the MSRP header fields in a manner similar to an MSRP Relay.=

The chairs would appreciate a quick resolution to this issue, and request a= nyone who cares please make their opinions known on the SIMPLE list as soon= as possible.

Thanks!

Ben.

--90e6ba539e52715b1404a03673b3-- From ben@nostrum.com Tue Apr 5 19:16:49 2011 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 CDFC33A683B for ; Tue, 5 Apr 2011 19:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 wW+00AKQu3KC for ; Tue, 5 Apr 2011 19:16:48 -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 49A0C3A6839 for ; Tue, 5 Apr 2011 19:16:48 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p362IIMS027208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Apr 2011 21:18:19 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2--520931372 From: Ben Campbell In-Reply-To: Date: Tue, 5 Apr 2011 21:18:19 -0500 Message-Id: References: <1EA75631-ECF8-4CDF-A90D-951CC1B6B841@nostrum.com> To: Hisham Khartabil X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism) Cc: Cullen Jennings , Adam Roach , Simple WG , John Mattsson Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 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: Wed, 06 Apr 2011 02:16:49 -0000 --Apple-Mail-2--520931372 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 5, 2011, at 9:07 PM, Hisham Khartabil wrote: > It sounds like options 1 and 2 will not allow interoperability between = the 2 UAs. Option 2 could conceivably allow the UA behind the SBC to fall back to = standard behavior. We all know a provider using an SBC is unlikely to = allow the UA to do that-but that's a policy problem rather than a = technical one. But in the most likely case, you at least get an explicit = signaling error, which is marginally better than an inexplicable media = failure.=20 > I least hate option 3, but do we need to document that? You are probably right on the documentation bit--we don't need to = specify how SBCs work with or without sessmatch. >=20 > Hisham >=20 > On 6 April 2011 07:23, Ben Campbell wrote: > Hi, >=20 > A small group (Christer, Cullen, Adam, Hadriel, John, and myself) held = a face-to-face discussion of issues related to = draft-ietf-simple-msrp-sessmatch-10. The discussion highlighted a = backwards compatibility issue. >=20 > Specifically, an MSRP user agent implementing the sessmatch = description that is behind an SBC or ALG that operates as the draft = envisions cannot interoperate with a peer that uses an MSRP Relay as = defined in RFC 4976. The issue is not caused by the sessmatch extension = per se, but by the SBC/ALG. However, the sole purpose of this extension = is to allow such behavior. >=20 > We agreed that this was a backwards compatibility issue, and as such = would not be acceptable without some negotiation mechanism. >=20 > We discussed the following options. Note that no one option was = favored by all present--I will let people speak individually as to their = preferences. >=20 > 1) Treat MSRP over ALGs using the sessmatch extension as a = fundamentally different protocol from base MSRP >=20 > 2) Create a SIP option tag that indicates that a UA both supports = sessmatch, and does not use an MSRP relay. >=20 > 3) Give up on sessmatch, and assert that for an ALG or SBC to relay = MSRP, it must rewrite the MSRP header fields in a manner similar to an = MSRP Relay. >=20 > The chairs would appreciate a quick resolution to this issue, and = request anyone who cares please make their opinions known on the SIMPLE = list as soon as possible. >=20 > Thanks! >=20 > Ben. >=20 --Apple-Mail-2--520931372 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
It sounds like options 1 and 2 will not allow = interoperability between the 2 UAs. =

Option 2 could conceivably allow the UA = behind the SBC to fall back to standard behavior. We all know a provider = using an SBC is unlikely to allow the UA to do that-but that's a policy = problem rather than a technical one. But in the most likely case, you at = least get an explicit signaling error, which is marginally better than = an inexplicable media failure. 

I least hate option 3, but do we need to document = that?

You are probably right on the = documentation bit--we don't need to specify how SBCs work with or = without sessmatch.


Hisham

On 6 April = 2011 07:23, Ben Campbell <ben@nostrum.com> = wrote:
Hi,

A small group (Christer, Cullen, Adam, Hadriel, John, and myself) held a = face-to-face discussion of issues related to = draft-ietf-simple-msrp-sessmatch-10. The discussion highlighted a = backwards compatibility issue.

Specifically, an MSRP user agent implementing the sessmatch description = that is behind an SBC or ALG that operates as the draft envisions cannot = interoperate with a peer that uses an MSRP Relay as defined in RFC 4976. = The issue is not caused by the sessmatch extension per se, but by the = SBC/ALG. However, the sole purpose of this extension is to allow such = behavior.

We agreed that this was a backwards compatibility issue, and as such = would not be acceptable without some negotiation mechanism.

We discussed the following options. Note that no one option was favored = by all present--I will let people speak individually as to their = preferences.

1) Treat MSRP over ALGs using the sessmatch extension as a fundamentally = different protocol from base MSRP

2) Create a SIP option tag that indicates that a UA both supports = sessmatch, and does not use an MSRP relay.

3) Give up on sessmatch, and assert that for an ALG or SBC to relay = MSRP, it must rewrite the MSRP header fields in a manner similar to an = MSRP Relay.

The chairs would appreciate a quick resolution to this issue, and = request anyone who cares please make their opinions known on the SIMPLE = list as soon as possible.

Thanks!

Ben.


= --Apple-Mail-2--520931372-- From ben@nostrum.com Tue Apr 5 19:29:57 2011 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 E82B03A683B for ; Tue, 5 Apr 2011 19:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 wdemQ2jWRgpw for ; Tue, 5 Apr 2011 19:29:57 -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 B4FDF3A6839 for ; Tue, 5 Apr 2011 19:29:56 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p362VXji028309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Apr 2011 21:31:35 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Apr 2011 21:31:33 -0500 Message-Id: <42C57E6F-B75F-4D12-991F-246E3FF31192@nostrum.com> To: Simple WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism) Cc: Cullen Jennings , Adam Roach , John Mattsson Subject: [Simple] draft-ietf-simple-msrp-sessmatch-10 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: Wed, 06 Apr 2011 02:29:58 -0000 (oops, managed to miss Christer in the CC list. Sorry for the repeat) Hi, A small group (Christer, Cullen, Adam, Hadriel, John, and myself) held a = face-to-face discussion of issues related to = draft-ietf-simple-msrp-sessmatch-10. The discussion highlighted a = backwards compatibility issue. Specifically, an MSRP user agent implementing the sessmatch description = that is behind an SBC or ALG that operates as the draft envisions cannot = interoperate with a peer that uses an MSRP Relay as defined in RFC 4976. = The issue is not caused by the sessmatch extension per se, but by the = SBC/ALG. However, the sole purpose of this extension is to allow such = behavior. We agreed that this was a backwards compatibility issue, and as such = would not be acceptable without some negotiation mechanism. We discussed the following options. Note that no one option was favored = by all present--I will let people speak individually as to their = preferences. 1) Treat MSRP over ALGs using the sessmatch extension as a fundamentally = different protocol from base MSRP 2) Create a SIP option tag that indicates that a UA both supports = sessmatch, and does not use an MSRP relay. 3) Give up on sessmatch, and assert that for an ALG or SBC to relay = MSRP, it must rewrite the MSRP header fields in a manner similar to an = MSRP Relay. The chairs would appreciate a quick resolution to this issue, and = request anyone who cares please make their opinions known on the SIMPLE = list as soon as possible. Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Tue Apr 5 23:18:33 2011 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 DEEEA28C0D8 for ; Tue, 5 Apr 2011 23:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 kGej7tD7+iB3 for ; Tue, 5 Apr 2011 23:18:33 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A044C3A68AC for ; Tue, 5 Apr 2011 23:18:32 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-32-4d9c061f52ba Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D2.FF.09202.F160C9D4; Wed, 6 Apr 2011 08:20:15 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.30]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 6 Apr 2011 08:20:15 +0200 From: Christer Holmberg To: Ben Campbell , Simple WG Date: Wed, 6 Apr 2011 08:20:14 +0200 Thread-Topic: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue Thread-Index: Acv0AsIaPO5UfsKTRK2sQYFjYIzHYAAHv2lT Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851948D7E0B8@ESESSCMS0356.eemea.ericsson.se> References: <42C57E6F-B75F-4D12-991F-246E3FF31192@nostrum.com> In-Reply-To: <42C57E6F-B75F-4D12-991F-246E3FF31192@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: Cullen Jennings , John, Adam Roach , Mattsson Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 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: Wed, 06 Apr 2011 06:18:34 -0000 Hi, I vote for option 2). I provides a mechanism to negotiate the usage of sess= match, and the possibility for an SBC to perform fallback. Whether it does = so, as Ben said, is an implementation/policy issue, but I can inform that t= here is at least one vendor considering such fallback support. Option 3) is very bad, considering that there are already at least two othe= r SDOs (OMA and 3GPP) refering to sessmatch (and have been doing so for qui= te a while already). Option 1) is also bad, as it will cause confusing and additional work in ot= her SDOs, and in the market in genral. And, option 2) provides the same out= come as option 1). Regards, Christer ________________________________________ From: Ben Campbell [ben@nostrum.com] Sent: Wednesday, April 06, 2011 5:31 AM To: Simple WG Cc: Cullen Jennings; Adam Roach; John Mattsson; Christer Holmberg Subject: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue (oops, managed to miss Christer in the CC list. Sorry for the repeat) Hi, A small group (Christer, Cullen, Adam, Hadriel, John, and myself) held a fa= ce-to-face discussion of issues related to draft-ietf-simple-msrp-sessmatch= -10. The discussion highlighted a backwards compatibility issue. Specifically, an MSRP user agent implementing the sessmatch description tha= t is behind an SBC or ALG that operates as the draft envisions cannot inter= operate with a peer that uses an MSRP Relay as defined in RFC 4976. The iss= ue is not caused by the sessmatch extension per se, but by the SBC/ALG. How= ever, the sole purpose of this extension is to allow such behavior. We agreed that this was a backwards compatibility issue, and as such would = not be acceptable without some negotiation mechanism. We discussed the following options. Note that no one option was favored by = all present--I will let people speak individually as to their preferences. 1) Treat MSRP over ALGs using the sessmatch extension as a fundamentally di= fferent protocol from base MSRP 2) Create a SIP option tag that indicates that a UA both supports sessmatch= , and does not use an MSRP relay. 3) Give up on sessmatch, and assert that for an ALG or SBC to relay MSRP, i= t must rewrite the MSRP header fields in a manner similar to an MSRP Relay. The chairs would appreciate a quick resolution to this issue, and request a= nyone who cares please make their opinions known on the SIMPLE list as soon= as possible. Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple= From R.Jesske@telekom.de Wed Apr 6 00:38:00 2011 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 5FE0E3A68B5 for ; Wed, 6 Apr 2011 00:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 Iou0VArE-6kM for ; Wed, 6 Apr 2011 00:37:59 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 1623B3A68CB for ; Wed, 6 Apr 2011 00:37:58 -0700 (PDT) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 06 Apr 2011 09:39:35 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.34]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 6 Apr 2011 09:39:33 +0200 From: To: Date: Wed, 6 Apr 2011 09:39:31 +0200 Thread-Topic: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue Thread-Index: Acv0AsIaPO5UfsKTRK2sQYFjYIzHYAAI9eziAAGtceA= Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D018583580A@HE111648.emea1.cds.t-internal.com> References: <42C57E6F-B75F-4D12-991F-246E3FF31192@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851948D7E0C1@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851948D7E0C1@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 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: Wed, 06 Apr 2011 07:38:00 -0000 I support Option 2) Thanks Roland > ________________________________________ > From: Ben Campbell [ben@nostrum.com] > Sent: Wednesday, April 06, 2011 5:31 AM > To: Simple WG > Cc: Cullen Jennings; Adam Roach; John Mattsson; Christer Holmberg > Subject: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue > > (oops, managed to miss Christer in the CC list. Sorry for the repeat) > > Hi, > > A small group (Christer, Cullen, Adam, Hadriel, John, and > myself) held a face-to-face discussion of issues related to > draft-ietf-simple-msrp-sessmatch-10. The discussion > highlighted a backwards compatibility issue. > > Specifically, an MSRP user agent implementing the sessmatch > description that is behind an SBC or ALG that operates as the > draft envisions cannot interoperate with a peer that uses an > MSRP Relay as defined in RFC 4976. The issue is not caused by > the sessmatch extension per se, but by the SBC/ALG. However, > the sole purpose of this extension is to allow such behavior. > > We agreed that this was a backwards compatibility issue, and > as such would not be acceptable without some negotiation mechanism. > > We discussed the following options. Note that no one option > was favored by all present--I will let people speak > individually as to their preferences. > > 1) Treat MSRP over ALGs using the sessmatch extension as a > fundamentally different protocol from base MSRP > > 2) Create a SIP option tag that indicates that a UA both > supports sessmatch, and does not use an MSRP relay. > > 3) Give up on sessmatch, and assert that for an ALG or SBC to > relay MSRP, it must rewrite the MSRP header fields in a > manner similar to an MSRP Relay. > > The chairs would appreciate a quick resolution to this issue, > and request anyone who cares please make their opinions known > on the SIMPLE list as soon as possible. > > Thanks! > > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From atle.monrad@ericsson.com Wed Apr 6 01:47:32 2011 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 043F928C0E7 for ; Wed, 6 Apr 2011 01:47:32 -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 n8wSOL7a9Gjy for ; Wed, 6 Apr 2011 01:47:31 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id B7CDC3A681D for ; Wed, 6 Apr 2011 01:47:30 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-c4-4d9c290912fc Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 13.76.11171.9092C9D4; Wed, 6 Apr 2011 10:49:14 +0200 (CEST) Received: from ESESSCMS0352.eemea.ericsson.se ([169.254.1.98]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 6 Apr 2011 10:49:13 +0200 From: Atle Monrad To: Ben Campbell , Simple WG Date: Wed, 6 Apr 2011 10:49:12 +0200 Thread-Topic: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue Thread-Index: Acv0AsIaPO5UfsKTRK2sQYFjYIzHYAAHv2lTAAVS0OA= Message-ID: <7A051DFAA46D0246A82293C7CEF621E90554F04881@ESESSCMS0352.eemea.ericsson.se> References: <42C57E6F-B75F-4D12-991F-246E3FF31192@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851948D7E0B8@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851948D7E0B8@ESESSCMS0356.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: Cullen Jennings , "John@core3.amsl.com" , Adam Roach , John Mattsson Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 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: Wed, 06 Apr 2011 08:47:32 -0000 Folks As the new 3GPP / IETF coordinator, i can confirme that there is a 3GPP dep= endency on sessmatch since a quite long time. I hope that we can solve the issue soon. Please don't drop or completely re= start the topic. I would also like to support option 2) for the reasons outlined by Christer= below. /atle=20 ________________________________=20 Atle Monrad 3GPP CT1 Chairman Standardization and Regulation, Group Function Technology and Portfolio Management=20 Ericsson =20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: 6. april 2011 08:20 To: Ben Campbell; Simple WG Cc: Cullen Jennings; John@core3.amsl.com; Adam Roach; John Mattsson Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue Hi, I vote for option 2). I provides a mechanism to negotiate the usage of sess= match, and the possibility for an SBC to perform fallback. Whether it does = so, as Ben said, is an implementation/policy issue, but I can inform that t= here is at least one vendor considering such fallback support. Option 3) is very bad, considering that there are already at least two othe= r SDOs (OMA and 3GPP) refering to sessmatch (and have been doing so for qui= te a while already). Option 1) is also bad, as it will cause confusing and additional work in ot= her SDOs, and in the market in genral. And, option 2) provides the same out= come as option 1). Regards, Christer ________________________________________ From: Ben Campbell [ben@nostrum.com] Sent: Wednesday, April 06, 2011 5:31 AM To: Simple WG Cc: Cullen Jennings; Adam Roach; John Mattsson; Christer Holmberg Subject: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue (oops, managed to miss Christer in the CC list. Sorry for the repeat) Hi, A small group (Christer, Cullen, Adam, Hadriel, John, and myself) held a fa= ce-to-face discussion of issues related to draft-ietf-simple-msrp-sessmatch= -10. The discussion highlighted a backwards compatibility issue. Specifically, an MSRP user agent implementing the sessmatch description tha= t is behind an SBC or ALG that operates as the draft envisions cannot inter= operate with a peer that uses an MSRP Relay as defined in RFC 4976. The iss= ue is not caused by the sessmatch extension per se, but by the SBC/ALG. How= ever, the sole purpose of this extension is to allow such behavior. We agreed that this was a backwards compatibility issue, and as such would = not be acceptable without some negotiation mechanism. We discussed the following options. Note that no one option was favored by = all present--I will let people speak individually as to their preferences. 1) Treat MSRP over ALGs using the sessmatch extension as a fundamentally di= fferent protocol from base MSRP 2) Create a SIP option tag that indicates that a UA both supports sessmatch= , and does not use an MSRP relay. 3) Give up on sessmatch, and assert that for an ALG or SBC to relay MSRP, i= t must rewrite the MSRP header fields in a manner similar to an MSRP Relay. The chairs would appreciate a quick resolution to this issue, and request a= nyone who cares please make their opinions known on the SIMPLE list as soon= as possible. Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From christian.1.schmidt@nsn.com Wed Apr 6 03:57:20 2011 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 EBA243A68C8 for ; Wed, 6 Apr 2011 03:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.452 X-Spam-Level: X-Spam-Status: No, score=-5.452 tagged_above=-999 required=5 tests=[AWL=1.147, 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 jvHIxTrTQ9dC for ; Wed, 6 Apr 2011 03:57:18 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id EE7603A68C4 for ; Wed, 6 Apr 2011 03:57:17 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p36AwrKf004524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Apr 2011 12:58:53 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p36Awlru020622; Wed, 6 Apr 2011 12:58:52 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 12:58:51 +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: Wed, 6 Apr 2011 12:58:47 +0200 Message-ID: In-Reply-To: <7A051DFAA46D0246A82293C7CEF621E90554F04881@ESESSCMS0352.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue Thread-Index: Acv0AsIaPO5UfsKTRK2sQYFjYIzHYAAHv2lTAAVS0OAABJS+QA== References: <42C57E6F-B75F-4D12-991F-246E3FF31192@nostrum.com><7F2072F1E0DE894DA4B517B93C6A05851948D7E0B8@ESESSCMS0356.eemea.ericsson.se> <7A051DFAA46D0246A82293C7CEF621E90554F04881@ESESSCMS0352.eemea.ericsson.se> From: "Schmidt, Christian 1. (NSN - DE/Munich)" To: "ext Atle Monrad" , "Ben Campbell" , "Simple WG" X-OriginalArrivalTime: 06 Apr 2011 10:58:51.0215 (UTC) FILETIME=[9CE3B5F0:01CBF449] Cc: Cullen Jennings , John@core3.amsl.com, Adam Roach , John Mattsson Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 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: Wed, 06 Apr 2011 10:57:20 -0000 Hi, option 2 seems to be the right choice. /Christian -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of ext Atle Monrad Sent: Wednesday, April 06, 2011 10:49 AM To: Ben Campbell; Simple WG Cc: Cullen Jennings; John@core3.amsl.com; Adam Roach; John Mattsson Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue Folks As the new 3GPP / IETF coordinator, i can confirme that there is a 3GPP dependency on sessmatch since a quite long time. I hope that we can solve the issue soon. Please don't drop or completely restart the topic. I would also like to support option 2) for the reasons outlined by Christer below. /atle=20 ________________________________=20 Atle Monrad 3GPP CT1 Chairman Standardization and Regulation, Group Function Technology and Portfolio Management=20 Ericsson =20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 6. april 2011 08:20 To: Ben Campbell; Simple WG Cc: Cullen Jennings; John@core3.amsl.com; Adam Roach; John Mattsson Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue Hi, I vote for option 2). I provides a mechanism to negotiate the usage of sessmatch, and the possibility for an SBC to perform fallback. Whether it does so, as Ben said, is an implementation/policy issue, but I can inform that there is at least one vendor considering such fallback support. Option 3) is very bad, considering that there are already at least two other SDOs (OMA and 3GPP) refering to sessmatch (and have been doing so for quite a while already). Option 1) is also bad, as it will cause confusing and additional work in other SDOs, and in the market in genral. And, option 2) provides the same outcome as option 1). Regards, Christer ________________________________________ From: Ben Campbell [ben@nostrum.com] Sent: Wednesday, April 06, 2011 5:31 AM To: Simple WG Cc: Cullen Jennings; Adam Roach; John Mattsson; Christer Holmberg Subject: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue (oops, managed to miss Christer in the CC list. Sorry for the repeat) Hi, A small group (Christer, Cullen, Adam, Hadriel, John, and myself) held a face-to-face discussion of issues related to draft-ietf-simple-msrp-sessmatch-10. The discussion highlighted a backwards compatibility issue. Specifically, an MSRP user agent implementing the sessmatch description that is behind an SBC or ALG that operates as the draft envisions cannot interoperate with a peer that uses an MSRP Relay as defined in RFC 4976. The issue is not caused by the sessmatch extension per se, but by the SBC/ALG. However, the sole purpose of this extension is to allow such behavior. We agreed that this was a backwards compatibility issue, and as such would not be acceptable without some negotiation mechanism. We discussed the following options. Note that no one option was favored by all present--I will let people speak individually as to their preferences. 1) Treat MSRP over ALGs using the sessmatch extension as a fundamentally different protocol from base MSRP 2) Create a SIP option tag that indicates that a UA both supports sessmatch, and does not use an MSRP relay. 3) Give up on sessmatch, and assert that for an ALG or SBC to relay MSRP, it must rewrite the MSRP header fields in a manner similar to an MSRP Relay. The chairs would appreciate a quick resolution to this issue, and request anyone who cares please make their opinions known on the SIMPLE list as soon as possible. Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From nancy.greene@ericsson.com Wed Apr 6 07:57:35 2011 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 0EF263A69BB for ; Wed, 6 Apr 2011 07:57:35 -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 EmlBpry1pJ7I for ; Wed, 6 Apr 2011 07:57:34 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id D07ED3A693C for ; Wed, 6 Apr 2011 07:57:33 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p36ExBL4002990; Wed, 6 Apr 2011 09:59:16 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.203]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 6 Apr 2011 10:59:11 -0400 From: Nancy Greene To: Ben Campbell , Simple WG Date: Wed, 6 Apr 2011 10:59:09 -0400 Thread-Topic: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue Thread-Index: Acvz17N6Yb8buA2kSj297Kr+xvhU/AAk1VMg Message-ID: References: <1EA75631-ECF8-4CDF-A90D-951CC1B6B841@nostrum.com> In-Reply-To: <1EA75631-ECF8-4CDF-A90D-951CC1B6B841@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 Cc: Cullen Jennings , John, Adam Roach , Mattsson Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 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: Wed, 06 Apr 2011 14:57:35 -0000 I support option 2.=20 Nancy=20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= Ben Campbell Sent: April-05-11 5:23 PM To: Simple WG Cc: Cullen Jennings; Adam Roach; John Mattsson Subject: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue Hi, A small group (Christer, Cullen, Adam, Hadriel, John, and myself) held a fa= ce-to-face discussion of issues related to draft-ietf-simple-msrp-sessmatch= -10. The discussion highlighted a backwards compatibility issue. Specifically, an MSRP user agent implementing the sessmatch description tha= t is behind an SBC or ALG that operates as the draft envisions cannot inter= operate with a peer that uses an MSRP Relay as defined in RFC 4976. The iss= ue is not caused by the sessmatch extension per se, but by the SBC/ALG. How= ever, the sole purpose of this extension is to allow such behavior. We agreed that this was a backwards compatibility issue, and as such would = not be acceptable without some negotiation mechanism. We discussed the following options. Note that no one option was favored by = all present--I will let people speak individually as to their preferences. 1) Treat MSRP over ALGs using the sessmatch extension as a fundamentally di= fferent protocol from base MSRP 2) Create a SIP option tag that indicates that a UA both supports sessmatch= , and does not use an MSRP relay. 3) Give up on sessmatch, and assert that for an ALG or SBC to relay MSRP, i= t must rewrite the MSRP header fields in a manner similar to an MSRP Relay. The chairs would appreciate a quick resolution to this issue, and request a= nyone who cares please make their opinions known on the SIMPLE list as soon= as possible. Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From bvnkumar@gmail.com Thu Apr 7 10:20:24 2011 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 30D303A694F for ; Thu, 7 Apr 2011 10:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] 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 2pRrg1JwBF7a for ; Thu, 7 Apr 2011 10:20:23 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id B8CCC3A68BD for ; Thu, 7 Apr 2011 10:20:20 -0700 (PDT) Received: by iye19 with SMTP id 19so3314696iye.31 for ; Thu, 07 Apr 2011 10:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=1VH26EHEiV9YsW5y4dTPHuR0LNzXBzyJwdWSkXzzi08=; b=mut5zfc1LurXvY/g/NDzlN9ta8YvAHXV6i1QPufxR4e/C02ZmU5Zdz0gPBgemr9Miw 3dwCDWe1iP29j6DapYUFczB24eAGAHiQarzZzgoPNa6bEcbdQcyqIA56W5gx2gLbkoA6 Dh3shk3PL9UE/V/HvkRAW62C8ixQTeWXfTlWU= 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=HGhrx633PoA08Sc94z7ovxjzHt0bmAr9kAhrQxfUJ0WlpPMF6cLy2TSS/Dauzkujwy Ses2MZ91jMuoRggBvn11fbTQh1ehCKzI83akqyUlXFPZFRFqSiQv3ZOYU2B8lgSyDGQU IgqYy0iyBx05jH/iY4aGRblrOFDtu0uVAvGCY= MIME-Version: 1.0 Received: by 10.231.30.73 with SMTP id t9mr1130038ibc.51.1302196925306; Thu, 07 Apr 2011 10:22:05 -0700 (PDT) Received: by 10.231.150.131 with HTTP; Thu, 7 Apr 2011 10:22:05 -0700 (PDT) In-Reply-To: References: <1EA75631-ECF8-4CDF-A90D-951CC1B6B841@nostrum.com> Date: Thu, 7 Apr 2011 22:52:05 +0530 Message-ID: From: nagesh kumar To: Simple WG Content-Type: multipart/alternative; boundary=0022152d607d291a0304a05759dd Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 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: Thu, 07 Apr 2011 17:20:24 -0000 --0022152d607d291a0304a05759dd Content-Type: text/plain; charset=ISO-8859-1 copied the maling list... Regards Nagesh On Wed, Apr 6, 2011 at 8:40 PM, nagesh kumar wrote: > Experts, > > Are we essentially ruling out a deployment which has SBCs and MSRP Relays? > (I didn't come across such a deployment till now - just making sure that it > indeed is the case). > > If that is case, can we not take the presence of a=setup attribute to > support ACM model itself as a declaration of sess-match capabilitiy? If UA > is using MSRP relay, there is no need to use ACM. > > Regards > Nagesh > > On Wed, Apr 6, 2011 at 8:29 PM, Nancy Greene wrote: > >> I support option 2. >> >> Nancy >> >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf >> Of Ben Campbell >> Sent: April-05-11 5:23 PM >> To: Simple WG >> Cc: Cullen Jennings; Adam Roach; John Mattsson >> Subject: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue >> >> Hi, >> >> A small group (Christer, Cullen, Adam, Hadriel, John, and myself) held a >> face-to-face discussion of issues related to >> draft-ietf-simple-msrp-sessmatch-10. The discussion highlighted a backwards >> compatibility issue. >> >> Specifically, an MSRP user agent implementing the sessmatch description >> that is behind an SBC or ALG that operates as the draft envisions cannot >> interoperate with a peer that uses an MSRP Relay as defined in RFC 4976. The >> issue is not caused by the sessmatch extension per se, but by the SBC/ALG. >> However, the sole purpose of this extension is to allow such behavior. >> >> We agreed that this was a backwards compatibility issue, and as such would >> not be acceptable without some negotiation mechanism. >> >> We discussed the following options. Note that no one option was favored by >> all present--I will let people speak individually as to their preferences. >> >> 1) Treat MSRP over ALGs using the sessmatch extension as a fundamentally >> different protocol from base MSRP >> >> 2) Create a SIP option tag that indicates that a UA both supports >> sessmatch, and does not use an MSRP relay. >> >> 3) Give up on sessmatch, and assert that for an ALG or SBC to relay MSRP, >> it must rewrite the MSRP header fields in a manner similar to an MSRP Relay. >> >> The chairs would appreciate a quick resolution to this issue, and request >> anyone who cares please make their opinions known on the SIMPLE list as soon >> as possible. >> >> Thanks! >> >> Ben. >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >> > > --0022152d607d291a0304a05759dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
copied the maling list...
=A0
Regards
Nagesh
On Wed, Apr 6, 2011 at 8:40 PM, nagesh kumar <bvnkumar@gmail.com= > wrote:
Experts,
=A0
Are we essentially ruling out a deployment which has SBCs and MSRP Rel= ays? (I didn't come across such a deployment till now - just making sur= e that it indeed is the case).
=A0
If that is case, can we not take the presence of a=3Dsetup attribute t= o support ACM model itself as a declaration of sess-match capabilitiy? If U= A is using MSRP relay, there is no need to use ACM.
=A0
Regards
Nagesh

On Wed, Apr 6, 2011 at 8:29 PM, Nancy Greene <nancy.greene@ericsson.com> wrote:
I support option 2.

Nancy

-----Original Message-----
From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.o= rg] On Behalf Of Ben Campbell
Sent: April-05-11 5:23 PM
To: Simple WG
Cc: Cullen Jennings; Adam Roa= ch; John Mattsson
Subject: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue

Hi,=

A small group (Christer, Cullen, Adam, Hadriel, John, and myself) h= eld a face-to-face discussion of issues related to draft-ietf-simple-msrp-s= essmatch-10. The discussion highlighted a backwards compatibility issue.
Specifically, an MSRP user agent implementing the sessmatch description= that is behind an SBC or ALG that operates as the draft envisions cannot i= nteroperate with a peer that uses an MSRP Relay as defined in RFC 4976. The= issue is not caused by the sessmatch extension per se, but by the SBC/ALG.= However, the sole purpose of this extension is to allow such behavior.

We agreed that this was a backwards compatibility issue, and as such wo= uld not be acceptable without some negotiation mechanism.

We discuss= ed the following options. Note that no one option was favored by all presen= t--I will let people speak individually as to their preferences.

1) Treat MSRP over ALGs using the sessmatch extension as a fundamentall= y different protocol from base MSRP

2) Create a SIP option tag that = indicates that a UA both supports sessmatch, and does not use an MSRP relay= .

3) Give up on sessmatch, and assert that for an ALG or SBC to relay MSR= P, it must rewrite the MSRP header fields in a manner similar to an MSRP Re= lay.

The chairs would appreciate a quick resolution to this issue, a= nd request anyone who cares please make their opinions known on the SIMPLE = list as soon as possible.

Thanks!

Ben.
_______________________________________________<= br>Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple=
_______________________________________________
Simple mailing list
<= a href=3D"mailto:Simple@ietf.org" target=3D"_blank">Simple@ietf.org
= = https://www.ietf.org/mailman/listinfo/simple


--0022152d607d291a0304a05759dd-- From ben@nostrum.com Thu Apr 7 10:26:16 2011 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 D0B623A69CC for ; Thu, 7 Apr 2011 10:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.218 X-Spam-Level: X-Spam-Status: No, score=-102.218 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 wF0dXe2LGM+G for ; Thu, 7 Apr 2011 10:26:16 -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 DFBB63A6954 for ; Thu, 7 Apr 2011 10:26:15 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p37HRurL038319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Apr 2011 12:27:57 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-3--379955847 From: Ben Campbell In-Reply-To: Date: Thu, 7 Apr 2011 12:27:54 -0500 Message-Id: <55541AF2-1688-410C-8C73-9E0CAC2AAD06@nostrum.com> References: <1EA75631-ECF8-4CDF-A90D-951CC1B6B841@nostrum.com> To: nagesh kumar X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 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: Thu, 07 Apr 2011 17:26:16 -0000 --Apple-Mail-3--379955847 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (as individual) On Apr 7, 2011, at 12:22 PM, nagesh kumar wrote: > copied the maling list... > =20 > Regards > Nagesh > On Wed, Apr 6, 2011 at 8:40 PM, nagesh kumar = wrote: > Experts, > =20 > Are we essentially ruling out a deployment which has SBCs and MSRP = Relays? (I didn't come across such a deployment till now - just making = sure that it indeed is the case). > =20 > If that is case, can we not take the presence of a=3Dsetup attribute = to support ACM model itself as a declaration of sess-match capabilitiy? = If UA is using MSRP relay, there is no need to use ACM. I don't think the use of ACM implies the use of sessmatch, and there are = a subset of ACM scenarios that should be able to work with relays. = Also, while sessmatch may not be commonly used without ACM, it's still = certainly possible. So I don't think the setup attribute is sufficient. = It is worth discussing whether signaling sessmatch support belongs in a = SIP option tag vs SDP. [...] Thanks! Ben.= --Apple-Mail-3--379955847 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
(as individual)

On Apr 7, 2011, at 12:22 PM, nagesh kumar wrote:

copied the maling list...
 
Regards
Nagesh
On Wed, Apr 6, 2011 at 8:40 PM, nagesh kumar <bvnkumar@gmail.com> wrote:
Experts,
 
Are we essentially ruling out a deployment which has SBCs and MSRP Relays? (I didn't come across such a deployment till now - just making sure that it indeed is the case).
 
If that is case, can we not take the presence of a=setup attribute to support ACM model itself as a declaration of sess-match capabilitiy? If UA is using MSRP relay, there is no need to use ACM.

I don't think the use of ACM implies the use of sessmatch, and there are a subset of ACM scenarios that should be able to work with relays.  Also, while sessmatch may not be commonly used without ACM, it's still certainly possible. So I don't think the setup attribute is sufficient. It is worth discussing whether signaling sessmatch support belongs in a SIP option tag vs SDP.


[...]

Thanks!

Ben.
--Apple-Mail-3--379955847-- From christer.holmberg@ericsson.com Thu Apr 7 12:54:56 2011 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 5FC8E3A672F for ; Thu, 7 Apr 2011 12:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.269 X-Spam-Level: X-Spam-Status: No, score=-6.269 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 vd+H04gU0nrd for ; Thu, 7 Apr 2011 12:54:55 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 32A0D3A6405 for ; Thu, 7 Apr 2011 12:54:55 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-e1-4d9e16f51825 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 03.5B.11171.5F61E9D4; Thu, 7 Apr 2011 21:56:37 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.30]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 7 Apr 2011 21:56:36 +0200 From: Christer Holmberg To: 'Ben Campbell' , 'nagesh kumar' Date: Thu, 7 Apr 2011 21:56:35 +0200 Thread-Topic: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue Thread-Index: Acv1SSjr24kUMKIET46v92kLnMV6YgAELmkg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851948F0B34F@ESESSCMS0356.eemea.ericsson.se> References: <1EA75631-ECF8-4CDF-A90D-951CC1B6B841@nostrum.com> <55541AF2-1688-410C-8C73-9E0CAC2AAD06@nostrum.com> In-Reply-To: <55541AF2-1688-410C-8C73-9E0CAC2AAD06@nostrum.com> 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_7F2072F1E0DE894DA4B517B93C6A05851948F0B34FESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: 'Simple WG' Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 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: Thu, 07 Apr 2011 19:54:56 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05851948F0B34FESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, ACM and sessmatch are two separate functions - and that's one of the reason= s we at one point decided to describe them in separate drafts. ACM can be useful when a UA is behind a NAT - no matter whether there is an= SBC or not. Regards, Christer ________________________________ From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= Ben Campbell Sent: 7. huhtikuuta 2011 20:28 To: nagesh kumar Cc: Simple WG Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue (as individual) On Apr 7, 2011, at 12:22 PM, nagesh kumar wrote: copied the maling list... Regards Nagesh On Wed, Apr 6, 2011 at 8:40 PM, nagesh kumar > wrote: Experts, Are we essentially ruling out a deployment which has SBCs and MSRP Relays? = (I didn't come across such a deployment till now - just making sure that it= indeed is the case). If that is case, can we not take the presence of a=3Dsetup attribute to sup= port ACM model itself as a declaration of sess-match capabilitiy? If UA is = using MSRP relay, there is no need to use ACM. I don't think the use of ACM implies the use of sessmatch, and there are a = subset of ACM scenarios that should be able to work with relays. Also, whi= le sessmatch may not be commonly used without ACM, it's still certainly pos= sible. So I don't think the setup attribute is sufficient. It is worth disc= ussing whether signaling sessmatch support belongs in a SIP option tag vs S= DP. [...] Thanks! Ben. --_000_7F2072F1E0DE894DA4B517B93C6A05851948F0B34FESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
ACM and sessmatch are two separate functions - and= that's=20 one of the reasons we at one point decided to describe them in separate=20 drafts.
 
ACM can be useful when a UA is behind a = NAT - no=20 matter whether there is an SBC or not.
 
Regards,
 
Christer

From: simple-bounces@ietf.org=20 [mailto:simple-bounces@ietf.org] On Behalf Of Ben=20 Campbell
Sent: 7. huhtikuuta 2011 20:28
To: nagesh=20 kumar
Cc: Simple WG
Subject: Re: [Simple]=20 draft-ietf-simple-msrp-sessmatch-10 Issue

(as individual)

On Apr 7, 2011, at 12:22 PM, nagesh kumar wrote:
copied the maling list...
 
Regards
Nagesh
On Wed, Apr 6, 2011 at 8:40 PM, nagesh kumar <bvnkumar@gmail.com> wrot= e:
Experts,
 
Are we essentially ruling out a deployment which has SBCs and MSRP= =20 Relays? (I didn't come across such a deployment till now - just making = sure=20 that it indeed is the case).
 
If that is case, can we not take the presence of a=3Dsetup attribu= te to=20 support ACM model itself as a declaration of sess-match capabilitiy? If= UA=20 is using MSRP relay, there is no need to use=20 ACM.

I don't think the use of ACM implies the use of sessmatch, and there a= re a=20 subset of ACM scenarios that should be able to work with relays.  Also= ,=20 while sessmatch may not be commonly used without ACM, it's still certainly= =20 possible. So I don't think the setup attribute is sufficient. It is worth=20 discussing whether signaling sessmatch support belongs in a SIP option tag = vs=20 SDP.


[...]

Thanks!

Ben.
--_000_7F2072F1E0DE894DA4B517B93C6A05851948F0B34FESESSCMS0356e_-- From victor.pascual.avila@gmail.com Sun Apr 10 12:21:35 2011 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 BE89D3A68EC for ; Sun, 10 Apr 2011 12:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 PdxNgtoZCwBG for ; Sun, 10 Apr 2011 12:21:34 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 864633A6876 for ; Sun, 10 Apr 2011 12:21:34 -0700 (PDT) Received: by yic13 with SMTP id 13so2379129yic.31 for ; Sun, 10 Apr 2011 12:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=95Mdv+bbfK3pPhDZQ4GepztC4LdjdS4RONh2kXTsggk=; b=rrV+Clf2aHsdP5YvVGS8QhoN3hVnAEuckh/10MxmnhQbQMzC9n7uvEc5VfnO2jrFCu Zdel9GYZZnK99knF5B8kiRDEoxd7HdhcCUs6qQJCK67vA/39jzAur/aYuBN72jUWMlFZ p/F+3DyCbdOmJWhZIFWosAWm79+CBnWtwruek= 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=radmHmFYzc4jz7ShOss/H6DyFirINHWB6W5MakALVpTVPK6U2Bz1N2cZ2JzhXLK6ns QWglgOJl6fFysbrlZXP9ghJNE7eQ3+Vby/c8ZF0rRN5fNMRkMEFaTGZ5J8hJP031xKum 63/kHMwAuhiaLGtul52ZLMDUeg9iw1K/nA7u0= MIME-Version: 1.0 Received: by 10.91.8.3 with SMTP id l3mr3918593agi.2.1302463293735; Sun, 10 Apr 2011 12:21:33 -0700 (PDT) Received: by 10.90.118.14 with HTTP; Sun, 10 Apr 2011 12:21:33 -0700 (PDT) In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D018583580A@HE111648.emea1.cds.t-internal.com> References: <42C57E6F-B75F-4D12-991F-246E3FF31192@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851948D7E0C1@ESESSCMS0356.eemea.ericsson.se> <580BEA5E3B99744AB1F5BFF5E9A3C67D018583580A@HE111648.emea1.cds.t-internal.com> Date: Sun, 10 Apr 2011 21:21:33 +0200 Message-ID: From: Victor Pascual Avila To: R.Jesske@telekom.de Content-Type: multipart/alternative; boundary=0016364ecd04f4c63004a0955d23 Cc: simple@ietf.org Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 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: Sun, 10 Apr 2011 19:21:35 -0000 --0016364ecd04f4c63004a0955d23 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 On Wed, Apr 6, 2011 at 9:39 AM, wrote: > I support Option 2) > > Thanks > > Roland > > > > > > ________________________________________ > > From: Ben Campbell [ben@nostrum.com] > > Sent: Wednesday, April 06, 2011 5:31 AM > > To: Simple WG > > Cc: Cullen Jennings; Adam Roach; John Mattsson; Christer Holmberg > > Subject: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue > > > > (oops, managed to miss Christer in the CC list. Sorry for the repeat) > > > > Hi, > > > > A small group (Christer, Cullen, Adam, Hadriel, John, and > > myself) held a face-to-face discussion of issues related to > > draft-ietf-simple-msrp-sessmatch-10. The discussion > > highlighted a backwards compatibility issue. > > > > Specifically, an MSRP user agent implementing the sessmatch > > description that is behind an SBC or ALG that operates as the > > draft envisions cannot interoperate with a peer that uses an > > MSRP Relay as defined in RFC 4976. The issue is not caused by > > the sessmatch extension per se, but by the SBC/ALG. However, > > the sole purpose of this extension is to allow such behavior. > > > > We agreed that this was a backwards compatibility issue, and > > as such would not be acceptable without some negotiation mechanism. > > > > We discussed the following options. Note that no one option > > was favored by all present--I will let people speak > > individually as to their preferences. > > > > 1) Treat MSRP over ALGs using the sessmatch extension as a > > fundamentally different protocol from base MSRP > > > > 2) Create a SIP option tag that indicates that a UA both > > supports sessmatch, and does not use an MSRP relay. > > > > 3) Give up on sessmatch, and assert that for an ALG or SBC to > > relay MSRP, it must rewrite the MSRP header fields in a > > manner similar to an MSRP Relay. > > > > The chairs would appreciate a quick resolution to this issue, > > and request anyone who cares please make their opinions known > > on the SIMPLE list as soon as possible. > > > > Thanks! > > > > Ben. > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > --=20 Victor Pascual =C3=81vila --0016364ecd04f4c63004a0955d23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1

On Wed, Apr 6, 2011 at 9:39 AM, <R.Jesske@telekom.de> wrote:
I support Option 2)

Thank= s

Roland




> ____________________________________= ____
> From: Ben Campbell [ben@nos= trum.com]
> Sent: Wednesday, April 06, 2011 5:31 AM
> To: S= imple WG
> Cc: Cullen Jennings; Adam Roach; John Mattsson; Christer Holmberg
<= /div>> Subject: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue
>
> (oops, managed to miss Christer in the CC li= st. Sorry for the repeat)
>
> Hi,
>
> A small group= (Christer, Cullen, Adam, Hadriel, John, and
> myself) held a face-to= -face discussion of issues related to
> draft-ietf-simple-msrp-sessmatch-10. The discussion
> highlighte= d a backwards compatibility issue.
>
> Specifically, an MSRP us= er agent implementing the sessmatch
> description that is behind an S= BC or ALG that operates as the
> draft envisions cannot interoperate with a peer that uses an
> M= SRP Relay as defined in RFC 4976. The issue is not caused by
> the se= ssmatch extension per se, but by the SBC/ALG. However,
> the sole pur= pose of this extension is to allow such behavior.
>
> We agreed that this was a backwards compatibility issue, and> as such would not be acceptable without some negotiation mechanism.<= br>>
> We discussed the following options. Note that no one option=
> was favored by all present--I will let people speak
> individual= ly as to their preferences.
>
> 1) Treat MSRP over ALGs using t= he sessmatch extension as a
> fundamentally different protocol from b= ase MSRP
>
> 2) Create a SIP option tag that indicates that a UA both
&g= t; supports sessmatch, and does not use an MSRP relay.
>
> 3) G= ive up on sessmatch, and assert that for an ALG or SBC to
> relay MSR= P, it must rewrite the MSRP header fields in a
> manner similar to an MSRP Relay.
>
> The chairs would appr= eciate a quick resolution to this issue,
> and request anyone who car= es please make their opinions known
> on the SIMPLE list as soon as p= ossible.
>
> Thanks!
>
> Ben.
> _________________________= ______________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman= /listinfo/simple
>
_______________________________________________
Simple mailing l= ist
Simple@ietf.org
https://ww= w.ietf.org/mailman/listinfo/simple



--
Victor Pasc= ual =C3=81vila
--0016364ecd04f4c63004a0955d23-- From saghul@gmail.com Tue Apr 12 01:23:16 2011 Return-Path: X-Original-To: simple@ietfc.amsl.com Delivered-To: simple@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1914EE0676 for ; Tue, 12 Apr 2011 01:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMaT7bk1v0At for ; Tue, 12 Apr 2011 01:23:14 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfc.amsl.com (Postfix) with ESMTP id 95B23E0663 for ; Tue, 12 Apr 2011 01:23:14 -0700 (PDT) Received: by qyk7 with SMTP id 7so4122283qyk.10 for ; Tue, 12 Apr 2011 01:23:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=WjDcLIl+ayz/nMJQFNWfC28g8ta68A7GJEa5lTOjAmo=; b=R7kdAjwMAE1Q4CRDtsyeJzJLSG/59t8iCNxvqjP/iWmLPWpeH8UaY6Gkus1arnu32A C/5E/d5LidW6uN/+RR+UbjEu1k+d24UywwzOxg+5D0WCrbdi1mSYwpQAK8rLBfEne4k7 4LSpoF0II8+ifY44844Ui3SGJ5Qk5Cm7TRfvw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=bNGezx5gfCYSJEMkyoFE6QV0yvZjbVugq/H7+mvJ7cU34vQPoRmIEzcM1JkSAcXImQ FQtgEK3lyWBoFoXzIFkGHeJ863R/5UvAqYeb8uZ5UaLb43jSyvHk4m6qB43oVIju/8oF w4M1TgGHGQXKpMdaEoGSRHMu9gD/Gq2fc6Xj0= Received: by 10.229.129.139 with SMTP id o11mr4948708qcs.17.1302596594081; Tue, 12 Apr 2011 01:23:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.40.209 with HTTP; Tue, 12 Apr 2011 01:22:53 -0700 (PDT) In-Reply-To: <1EA75631-ECF8-4CDF-A90D-951CC1B6B841@nostrum.com> References: <1EA75631-ECF8-4CDF-A90D-951CC1B6B841@nostrum.com> From: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Date: Tue, 12 Apr 2011 10:22:53 +0200 Message-ID: To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , Adam Roach , Simple WG , John Mattsson Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 08:23:16 -0000 On Tue, Apr 5, 2011 at 11:23 PM, Ben Campbell wrote: > Hi, > > A small group (Christer, Cullen, Adam, Hadriel, John, and myself) held a = face-to-face discussion of issues related to draft-ietf-simple-msrp-sessmat= ch-10. The discussion highlighted a backwards compatibility issue. > > Specifically, an MSRP user agent implementing the sessmatch description t= hat is behind an SBC or ALG that operates as the draft envisions cannot int= eroperate with a peer that uses an MSRP Relay as defined in RFC 4976. The i= ssue is not caused by the sessmatch extension per se, but by the SBC/ALG. H= owever, the sole purpose of this extension is to allow such behavior. > > We agreed that this was a backwards compatibility issue, and as such woul= d not be acceptable without some negotiation mechanism. > > We discussed the following options. Note that no one option was favored b= y all present--I will let people speak individually as to their preferences= . > > 1) Treat MSRP over ALGs using the sessmatch extension as a fundamentally = different protocol from base MSRP > > 2) Create a SIP option tag that indicates that a UA both supports sessmat= ch, and does not use an MSRP relay. > > 3) Give up on sessmatch, and assert that for an ALG or SBC to relay MSRP,= it must rewrite the MSRP header fields in a manner similar to an MSRP Rela= y. > > The chairs would appreciate a quick resolution to this issue, and request= anyone who cares please make their opinions known on the SIMPLE list as so= on as possible. > Correct me if I'm wrong, but we need sessmatch in order to allow interoperability between 2 UAs that are not using TLS name based auth and have a SBC/ALG between them, right? If this is the case, how is this scenario envisioned to grow in deployment? Option 2 would be my choice if the sessmatch spec is wanted/needed, though as someone pointed out, there would be issues if SBC/ALG manufacturers don't implement a fallback mechanism. I agree with Hisham in that option 3 is the one I less hate. How disruptive would it be to give up on sessmatch given that 3GPP/OMA already refer to it? If answer to this is "well, not that much" then I'd go option 3, else I'd go for option 2. That's my 2 cents, --=20 /Sa=C3=BAl http://saghul.net | http://sipdoc.net From HKaplan@acmepacket.com Thu Apr 14 10:15:26 2011 Return-Path: X-Original-To: simple@ietfc.amsl.com Delivered-To: simple@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BB707E0782 for ; Thu, 14 Apr 2011 10:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrVruFcVZM8B for ; Thu, 14 Apr 2011 10:15:26 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfc.amsl.com (Postfix) with ESMTP id 0E2FFE0753 for ; Thu, 14 Apr 2011 10:15:25 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 14 Apr 2011 13:15:24 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Thu, 14 Apr 2011 13:15:24 -0400 From: Hadriel Kaplan To: Ben Campbell Date: Thu, 14 Apr 2011 13:15:23 -0400 Thread-Topic: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue Thread-Index: Acv6x4rzMbmS5SP7QpSAlwv0CVZXhQ== Message-ID: <1D5727A3-FE7F-444E-BA60-9C8720DAF580@acmepacket.com> References: <42C57E6F-B75F-4D12-991F-246E3FF31192@nostrum.com> In-Reply-To: <42C57E6F-B75F-4D12-991F-246E3FF31192@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: AAAAAQAAAUA= Cc: Cullen Jennings , Adam Roach , Simple WG , John Mattsson Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 17:15:27 -0000 I support option 2. -hadriel On Apr 5, 2011, at 10:31 PM, Ben Campbell wrote: > (oops, managed to miss Christer in the CC list. Sorry for the repeat) >=20 > Hi, >=20 > A small group (Christer, Cullen, Adam, Hadriel, John, and myself) held a = face-to-face discussion of issues related to draft-ietf-simple-msrp-sessmat= ch-10. The discussion highlighted a backwards compatibility issue. >=20 > Specifically, an MSRP user agent implementing the sessmatch description t= hat is behind an SBC or ALG that operates as the draft envisions cannot int= eroperate with a peer that uses an MSRP Relay as defined in RFC 4976. The i= ssue is not caused by the sessmatch extension per se, but by the SBC/ALG. H= owever, the sole purpose of this extension is to allow such behavior. >=20 > We agreed that this was a backwards compatibility issue, and as such woul= d not be acceptable without some negotiation mechanism. >=20 > We discussed the following options. Note that no one option was favored b= y all present--I will let people speak individually as to their preferences= . >=20 > 1) Treat MSRP over ALGs using the sessmatch extension as a fundamentally = different protocol from base MSRP >=20 > 2) Create a SIP option tag that indicates that a UA both supports sessmat= ch, and does not use an MSRP relay. >=20 > 3) Give up on sessmatch, and assert that for an ALG or SBC to relay MSRP,= it must rewrite the MSRP header fields in a manner similar to an MSRP Rela= y. >=20 > The chairs would appreciate a quick resolution to this issue, and request= anyone who cares please make their opinions known on the SIMPLE list as so= on as possible. >=20 > Thanks! >=20 > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@nostrum.com Thu Apr 14 10:36:33 2011 Return-Path: X-Original-To: simple@ietfc.amsl.com Delivered-To: simple@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 030EDE087E for ; Thu, 14 Apr 2011 10:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.251 X-Spam-Level: X-Spam-Status: No, score=-102.251 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdKMZWbHQYx9 for ; Thu, 14 Apr 2011 10:36:32 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfc.amsl.com (Postfix) with ESMTP id EF7F7E080D for ; Thu, 14 Apr 2011 10:36:31 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p3EHaLsW040880 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Apr 2011 12:36:22 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <42C57E6F-B75F-4D12-991F-246E3FF31192@nostrum.com> Date: Thu, 14 Apr 2011 12:36:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <42C57E6F-B75F-4D12-991F-246E3FF31192@nostrum.com> To: Simple WG X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism) Cc: Cullen Jennings , Adam Roach , John Mattsson Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 17:36:33 -0000 (as chair) The responses so far seem to show a rough consensus in favor of option = 2. I think it's time to move on to a technical discussion on how such = an option tag will work.=20 Thanks! Ben. On Apr 5, 2011, at 9:31 PM, Ben Campbell wrote: > (oops, managed to miss Christer in the CC list. Sorry for the repeat) >=20 > Hi, >=20 > A small group (Christer, Cullen, Adam, Hadriel, John, and myself) held = a face-to-face discussion of issues related to = draft-ietf-simple-msrp-sessmatch-10. The discussion highlighted a = backwards compatibility issue. >=20 > Specifically, an MSRP user agent implementing the sessmatch = description that is behind an SBC or ALG that operates as the draft = envisions cannot interoperate with a peer that uses an MSRP Relay as = defined in RFC 4976. The issue is not caused by the sessmatch extension = per se, but by the SBC/ALG. However, the sole purpose of this extension = is to allow such behavior. >=20 > We agreed that this was a backwards compatibility issue, and as such = would not be acceptable without some negotiation mechanism. >=20 > We discussed the following options. Note that no one option was = favored by all present--I will let people speak individually as to their = preferences. >=20 > 1) Treat MSRP over ALGs using the sessmatch extension as a = fundamentally different protocol from base MSRP >=20 > 2) Create a SIP option tag that indicates that a UA both supports = sessmatch, and does not use an MSRP relay. >=20 > 3) Give up on sessmatch, and assert that for an ALG or SBC to relay = MSRP, it must rewrite the MSRP header fields in a manner similar to an = MSRP Relay. >=20 > The chairs would appreciate a quick resolution to this issue, and = request anyone who cares please make their opinions known on the SIMPLE = list as soon as possible. >=20 > Thanks! >=20 > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Thu Apr 14 12:19:15 2011 Return-Path: X-Original-To: simple@ietfc.amsl.com Delivered-To: simple@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 93F93E07D5 for ; Thu, 14 Apr 2011 12:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3DnntxYDwAK for ; Thu, 14 Apr 2011 12:19:14 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfc.amsl.com (Postfix) with ESMTP id 62846E07A8 for ; Thu, 14 Apr 2011 12:19:14 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-e4-4da748b08059 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 18.C1.09202.0B847AD4; Thu, 14 Apr 2011 21:19:12 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.30]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 14 Apr 2011 21:19:11 +0200 From: Christer Holmberg To: 'Ben Campbell' , Simple WG Date: Thu, 14 Apr 2011 21:19:11 +0200 Thread-Topic: Sessmatch: Proposed option-tag text [was: draft-ietf-simple-msrp-sessmatch-10 Issue] Thread-Index: Acv6yn2hsmOUmyTeQJyu4pbx8QWkFQADNZYg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851948F0B38A@ESESSCMS0356.eemea.ericsson.se> References: <42C57E6F-B75F-4D12-991F-246E3FF31192@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Simple] Sessmatch: Proposed option-tag text [was: draft-ietf-simple-msrp-sessmatch-10 Issue] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 19:19:15 -0000 Hi, I've drafted some text regarding the usage of an option-tag for sessmatch. Comments are welcome. ----- An MSRP entity that supports the sessmatch extension, and is not=20 located behind an MSRP relay, MUST insert the 'sessmatch' option-tag=20 in the Supported header field of the initial INVITE request for a session= =20 that contains MSRP media. =20 An MSRP entity that supports the sessmatch extension, and is not=20 located behind an MSRP relay, MUST insert the 'sessmatch' option-tag=20 in at least one reliably sent successful response to the intial INVITE=20 request for a session that contains MSRP media. =20 In addition to inserting the 'sessmatch' option-tag in the Supported=20 header field of the INVITE request, if the MSRP entity is performing=20 MSRP related procedures that require the remote MSRP entity to support=20 the sessmatch extension in order to enable MSRP meddia, it MUST also=20 insert the 'sessmatch' option-tag in the Require header field ofthe reques= t. =20 NOTE: An example of a scenarios where an MSRP entity needs to insert=20 the 'sessmatch' option-tag in the Require header field, is when it=20 acts as an intermediary MSRP entity that modifies the SDP a=3Dpath=20 attribute address information, in order to anchor and forward MSRP=20 traffic, but does not perform the corresponding address information=20 changes in the associated MSRP messages. The actions taken by such=20 MSRP entity in case the remote MSRP entity does not support the sessmatch= =20 extension, and therfore sends a 420 (Not Supported) response to the=20 INVITE request, is outside the scope of this specification. =20 An MSRP entity that are deployed in environment where all MSRP=20 entities that it will communicate with are mandated to support the=20 sessmatch extension MAY omit the 'sessmatch' option tag. =20 NOTE: The reason for omitting the 'sessmatch' option-tag is to provide=20 backward compability in networks where the MSRP entities are based on=20 an earlier version of the sessmatch specification, in which usage of=20 the option-tag was not defined. =20 ----- Regards, Christer =20 -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: 14. huhtikuuta 2011 20:36 To: Simple WG Cc: Cullen Jennings; Adam Roach; John Mattsson; Christer Holmberg Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue (as chair) The responses so far seem to show a rough consensus in favor of option 2. = I think it's time to move on to a technical discussion on how such an optio= n tag will work.=20 Thanks! Ben. On Apr 5, 2011, at 9:31 PM, Ben Campbell wrote: > (oops, managed to miss Christer in the CC list. Sorry for the repeat) >=20 > Hi, >=20 > A small group (Christer, Cullen, Adam, Hadriel, John, and myself) held a = face-to-face discussion of issues related to draft-ietf-simple-msrp-sessmat= ch-10. The discussion highlighted a backwards compatibility issue. >=20 > Specifically, an MSRP user agent implementing the sessmatch description t= hat is behind an SBC or ALG that operates as the draft envisions cannot int= eroperate with a peer that uses an MSRP Relay as defined in RFC 4976. The i= ssue is not caused by the sessmatch extension per se, but by the SBC/ALG. H= owever, the sole purpose of this extension is to allow such behavior. >=20 > We agreed that this was a backwards compatibility issue, and as such woul= d not be acceptable without some negotiation mechanism. >=20 > We discussed the following options. Note that no one option was favored b= y all present--I will let people speak individually as to their preferences= . >=20 > 1) Treat MSRP over ALGs using the sessmatch extension as a=20 > fundamentally different protocol from base MSRP >=20 > 2) Create a SIP option tag that indicates that a UA both supports sessmat= ch, and does not use an MSRP relay. >=20 > 3) Give up on sessmatch, and assert that for an ALG or SBC to relay MSRP,= it must rewrite the MSRP header fields in a manner similar to an MSRP Rela= y. >=20 > The chairs would appreciate a quick resolution to this issue, and request= anyone who cares please make their opinions known on the SIMPLE list as so= on as possible. >=20 > Thanks! >=20 > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@nostrum.com Thu Apr 14 12:24:17 2011 Return-Path: X-Original-To: simple@ietfc.amsl.com Delivered-To: simple@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 163A5E08DF for ; Thu, 14 Apr 2011 12:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.021 X-Spam-Level: X-Spam-Status: No, score=-102.021 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnzA4QSnG-6o for ; Thu, 14 Apr 2011 12:24:16 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfc.amsl.com (Postfix) with ESMTP id B1730E074B for ; Thu, 14 Apr 2011 12:24:15 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p3EJOD6x050493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 14 Apr 2011 14:24:14 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851948F0B38A@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 14 Apr 2011 14:24:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7A491F66-6E6C-477B-99DE-45700C5A7369@nostrum.com> References: <42C57E6F-B75F-4D12-991F-246E3FF31192@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851948F0B38A@ESESSCMS0356.eemea.ericsson.se> To: Simple WG X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism) Subject: Re: [Simple] Sessmatch: Proposed option-tag text [was: draft-ietf-simple-msrp-sessmatch-10 Issue] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 19:24:17 -0000 (as chair) By the way, Gonzalo confirmed that we can in fact define an option tag = in SIMPLE. Thanks! Ben. On Apr 14, 2011, at 2:19 PM, Christer Holmberg wrote: >=20 > Hi, >=20 > I've drafted some text regarding the usage of an option-tag for = sessmatch. >=20 > Comments are welcome. >=20 > ----- >=20 > An MSRP entity that supports the sessmatch extension, and is not=20 > located behind an MSRP relay, MUST insert the 'sessmatch' option-tag=20= > in the Supported header field of the initial INVITE request for a = session=20 > that contains MSRP media. >=20 > An MSRP entity that supports the sessmatch extension, and is not=20 > located behind an MSRP relay, MUST insert the 'sessmatch' option-tag=20= > in at least one reliably sent successful response to the intial INVITE=20= > request for a session that contains MSRP media. >=20 > In addition to inserting the 'sessmatch' option-tag in the Supported=20= > header field of the INVITE request, if the MSRP entity is performing=20= > MSRP related procedures that require the remote MSRP entity to support=20= > the sessmatch extension in order to enable MSRP meddia, it MUST also=20= > insert the 'sessmatch' option-tag in the Require header field ofthe = request. >=20 > NOTE: An example of a scenarios where an MSRP entity needs to insert=20= > the 'sessmatch' option-tag in the Require header field, is when it=20 > acts as an intermediary MSRP entity that modifies the SDP a=3Dpath=20 > attribute address information, in order to anchor and forward MSRP=20 > traffic, but does not perform the corresponding address information=20 > changes in the associated MSRP messages. The actions taken by such=20 > MSRP entity in case the remote MSRP entity does not support the = sessmatch=20 > extension, and therfore sends a 420 (Not Supported) response to the=20 > INVITE request, is outside the scope of this specification. >=20 > An MSRP entity that are deployed in environment where all MSRP=20 > entities that it will communicate with are mandated to support the=20 > sessmatch extension MAY omit the 'sessmatch' option tag. >=20 > NOTE: The reason for omitting the 'sessmatch' option-tag is to provide=20= > backward compability in networks where the MSRP entities are based on=20= > an earlier version of the sessmatch specification, in which usage of=20= > the option-tag was not defined. >=20 > ----- >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com]=20 > Sent: 14. huhtikuuta 2011 20:36 > To: Simple WG > Cc: Cullen Jennings; Adam Roach; John Mattsson; Christer Holmberg > Subject: Re: [Simple] draft-ietf-simple-msrp-sessmatch-10 Issue >=20 > (as chair) >=20 > The responses so far seem to show a rough consensus in favor of option = 2. I think it's time to move on to a technical discussion on how such = an option tag will work.=20 >=20 > Thanks! >=20 > Ben. >=20 > On Apr 5, 2011, at 9:31 PM, Ben Campbell wrote: >=20 >> (oops, managed to miss Christer in the CC list. Sorry for the repeat) >>=20 >> Hi, >>=20 >> A small group (Christer, Cullen, Adam, Hadriel, John, and myself) = held a face-to-face discussion of issues related to = draft-ietf-simple-msrp-sessmatch-10. The discussion highlighted a = backwards compatibility issue. >>=20 >> Specifically, an MSRP user agent implementing the sessmatch = description that is behind an SBC or ALG that operates as the draft = envisions cannot interoperate with a peer that uses an MSRP Relay as = defined in RFC 4976. The issue is not caused by the sessmatch extension = per se, but by the SBC/ALG. However, the sole purpose of this extension = is to allow such behavior. >>=20 >> We agreed that this was a backwards compatibility issue, and as such = would not be acceptable without some negotiation mechanism. >>=20 >> We discussed the following options. Note that no one option was = favored by all present--I will let people speak individually as to their = preferences. >>=20 >> 1) Treat MSRP over ALGs using the sessmatch extension as a=20 >> fundamentally different protocol from base MSRP >>=20 >> 2) Create a SIP option tag that indicates that a UA both supports = sessmatch, and does not use an MSRP relay. >>=20 >> 3) Give up on sessmatch, and assert that for an ALG or SBC to relay = MSRP, it must rewrite the MSRP header fields in a manner similar to an = MSRP Relay. >>=20 >> The chairs would appreciate a quick resolution to this issue, and = request anyone who cares please make their opinions known on the SIMPLE = list as soon as possible. >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >=20 From saghul@gmail.com Mon Apr 18 01:32:40 2011 Return-Path: X-Original-To: simple@ietfc.amsl.com Delivered-To: simple@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 515CFE06CB for ; Mon, 18 Apr 2011 01:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1cy+2zEUKzm for ; Mon, 18 Apr 2011 01:32:35 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfc.amsl.com (Postfix) with ESMTP id 62D1AE074B for ; Mon, 18 Apr 2011 01:32:27 -0700 (PDT) Received: by gxk19 with SMTP id 19so2046961gxk.31 for ; Mon, 18 Apr 2011 01:32:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=F4iOIw725j92QOT3dRCklU/LZQjnx4LtKW8CSBf8HgM=; b=kcS5I/itzEvmBXMIsAhDTeNuz0oio/GVOz+Tg3K9T+ncoQ6iDRZ16UqwgqGeGR74wr Z4FhUY5jk6Hf6GE3ImlNkjYop12EVNnwOVTy6JzsW67qWgjjVn2VHDO5UtCzPaN5fYxo LzYLnpk+kcnWChD2Sv40rOpdUkZKZTYnei7gE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=pHNaykb5nCJRRPfGXogALcOvj3yRkjfrFjx0AosNmXIdiJufmthy/CKDTTMP7mq9zp fLa6Bpu2YWiH2tkmlRd1V2hFnLUBJTCrw5oPxxdX6jUif0zs8iPTD+RZAp6DmGpDWltl 2tKqejwLJZ72uylVxNQUerhp2NSiBUenUAYT4= Received: by 10.236.149.41 with SMTP id w29mr2988020yhj.361.1303115547091; Mon, 18 Apr 2011 01:32:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.109.39 with HTTP; Mon, 18 Apr 2011 01:32:07 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851948F0B38A@ESESSCMS0356.eemea.ericsson.se> References: <42C57E6F-B75F-4D12-991F-246E3FF31192@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851948F0B38A@ESESSCMS0356.eemea.ericsson.se> From: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Date: Mon, 18 Apr 2011 10:32:07 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] Sessmatch: Proposed option-tag text [was: draft-ietf-simple-msrp-sessmatch-10 Issue] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 08:32:40 -0000 Hi, On Thu, Apr 14, 2011 at 9:19 PM, Christer Holmberg wrote: > =C2=A0An MSRP entity that are deployed in environment where all MSRP > =C2=A0entities that it will communicate with are mandated to support the > =C2=A0sessmatch extension MAY omit the 'sessmatch' option tag. > > =C2=A0NOTE: The reason for omitting the 'sessmatch' option-tag is to prov= ide > =C2=A0backward compability in networks where the MSRP entities are based = on > =C2=A0an earlier version of the sessmatch specification, in which usage o= f > =C2=A0the option-tag was not defined. The text sounds good to me, but those 2 last paragraphs may break everything stated above. Do we need to maintain backwards compatibility taking into account that sessmatch is still a draft (which could change, as its doing now)? Also, the use case for that feels a bit narrow to me, how can I be sure I'll *only* communicate with sessmatch enabled devices? As long as its not a walled garden :-) My 2 cents. Regards, --=20 /Sa=C3=BAl http://saghul.net | http://sipdoc.net From ibc@aliax.net Mon Apr 18 01:38:46 2011 Return-Path: X-Original-To: simple@ietfc.amsl.com Delivered-To: simple@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1C66AE0682 for ; Mon, 18 Apr 2011 01:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AT9b2+R45qkn for ; Mon, 18 Apr 2011 01:38:45 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfc.amsl.com (Postfix) with ESMTP id 7487BE065C for ; Mon, 18 Apr 2011 01:38:45 -0700 (PDT) Received: by yxk30 with SMTP id 30so2049083yxk.31 for ; Mon, 18 Apr 2011 01:38:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.195.98 with SMTP id o62mr910685yhn.178.1303115925130; Mon, 18 Apr 2011 01:38:45 -0700 (PDT) Received: by 10.147.33.10 with HTTP; Mon, 18 Apr 2011 01:38:45 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851948F0B38A@ESESSCMS0356.eemea.ericsson.se> References: <42C57E6F-B75F-4D12-991F-246E3FF31192@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851948F0B38A@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 18 Apr 2011 10:38:45 +0200 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] Sessmatch: Proposed option-tag text [was: draft-ietf-simple-msrp-sessmatch-10 Issue] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 08:38:46 -0000 2011/4/14 Christer Holmberg : > =C2=A0NOTE: The reason for omitting the 'sessmatch' option-tag is to prov= ide > =C2=A0backward compability in networks where the MSRP entities are based = on > =C2=A0an earlier version of the sessmatch specification, in which usage o= f > =C2=A0the option-tag was not defined. Hi, let me a question: is such earlier version of sessmatch specification a draft or a RFC? Thanks. --=20 I=C3=B1aki Baz Castillo From ben@nostrum.com Mon Apr 18 08:28:35 2011 Return-Path: X-Original-To: simple@ietfc.amsl.com Delivered-To: simple@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2F28EE06DD for ; Mon, 18 Apr 2011 08:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s91O2LTFNO-9 for ; Mon, 18 Apr 2011 08:28:34 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfc.amsl.com (Postfix) with ESMTP id 455B8E068E for ; Mon, 18 Apr 2011 08:28:33 -0700 (PDT) Received: from dn3-227.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 p3IFSFFM013667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Apr 2011 10:28:25 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Ben Campbell In-Reply-To: Date: Mon, 18 Apr 2011 10:28:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <42C57E6F-B75F-4D12-991F-246E3FF31192@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851948F0B38A@ESESSCMS0356.eemea.ericsson.se> To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] Sessmatch: Proposed option-tag text [was: draft-ietf-simple-msrp-sessmatch-10 Issue] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 15:28:35 -0000 (as individual) On Apr 18, 2011, at 3:32 AM, Sa=FAl Ibarra Corretg=E9 wrote: > Hi, >=20 > On Thu, Apr 14, 2011 at 9:19 PM, Christer Holmberg > wrote: >> An MSRP entity that are deployed in environment where all MSRP >> entities that it will communicate with are mandated to support the >> sessmatch extension MAY omit the 'sessmatch' option tag. >>=20 >> NOTE: The reason for omitting the 'sessmatch' option-tag is to = provide >> backward compability in networks where the MSRP entities are based = on >> an earlier version of the sessmatch specification, in which usage of >> the option-tag was not defined. >=20 > The text sounds good to me, but those 2 last paragraphs may break > everything stated above. >=20 > Do we need to maintain backwards compatibility taking into account > that sessmatch is still a draft (which could change, as its doing > now)? Also, the use case for that feels a bit narrow to me, how can I > be sure I'll *only* communicate with sessmatch enabled devices? As > long as its not a walled garden :-) >=20 I concur. The whole point of the option tag is to avoid balkanizing the = protocol. If you allow for scenarios where people think they don't need = to interop can ignore the backward compatibility feature, then there's = little point for the feature in the first place.=20 The idea of an environment where all entities are mandated to support = sessmatch contemplates entities being prohibited from communication with = endpoints outside their walled garden. I don't think we want to = encourage that. It's one thing to forbid this by policy--it's entirely = different to prevent it via technology. If a carrier decides to open up = at some point in the future, it would be ill-served to find its = endpoints were unable to communicate because the implementor assumed = they would never be used outside a walled garden. From christer.holmberg@ericsson.com Mon Apr 18 09:01:38 2011 Return-Path: X-Original-To: simple@ietfc.amsl.com Delivered-To: simple@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B8BC3E06DD for ; Mon, 18 Apr 2011 09:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8VwLbDt0iVb for ; Mon, 18 Apr 2011 09:01:37 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfc.amsl.com (Postfix) with ESMTP id AFFD7E068E for ; Mon, 18 Apr 2011 09:01:37 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-4e-4dac60606f71 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C0.D3.09202.0606CAD4; Mon, 18 Apr 2011 18:01:37 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.251]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Mon, 18 Apr 2011 18:01:36 +0200 From: Christer Holmberg To: Ben Campbell , =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Mon, 18 Apr 2011 18:00:43 +0200 Thread-Topic: [Simple] Sessmatch: Proposed option-tag text [was: draft-ietf-simple-msrp-sessmatch-10 Issue] Thread-Index: Acv93UU5z0QYNm+oRJ2oz/BEsUwpOAABIAkc Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194C9CC8CF@ESESSCMS0356.eemea.ericsson.se> References: <42C57E6F-B75F-4D12-991F-246E3FF31192@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851948F0B38A@ESESSCMS0356.eemea.ericsson.se> , 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] Sessmatch: Proposed option-tag text [was: draft-ietf-simple-msrp-sessmatch-10 Issue] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 16:01:38 -0000 Hi, I'm ok to remove the text paragraph and the note. Regards, Christer ________________________________________ From: Ben Campbell [ben@nostrum.com] Sent: Monday, April 18, 2011 6:28 PM To: Sa=FAl Ibarra Corretg=E9 Cc: Christer Holmberg; Simple WG Subject: Re: [Simple] Sessmatch: Proposed option-tag text [was: draft-ietf-= simple-msrp-sessmatch-10 Issue] (as individual) On Apr 18, 2011, at 3:32 AM, Sa=FAl Ibarra Corretg=E9 wrote: > Hi, > > On Thu, Apr 14, 2011 at 9:19 PM, Christer Holmberg > wrote: >> An MSRP entity that are deployed in environment where all MSRP >> entities that it will communicate with are mandated to support the >> sessmatch extension MAY omit the 'sessmatch' option tag. >> >> NOTE: The reason for omitting the 'sessmatch' option-tag is to provide >> backward compability in networks where the MSRP entities are based on >> an earlier version of the sessmatch specification, in which usage of >> the option-tag was not defined. > > The text sounds good to me, but those 2 last paragraphs may break > everything stated above. > > Do we need to maintain backwards compatibility taking into account > that sessmatch is still a draft (which could change, as its doing > now)? Also, the use case for that feels a bit narrow to me, how can I > be sure I'll *only* communicate with sessmatch enabled devices? As > long as its not a walled garden :-) > I concur. The whole point of the option tag is to avoid balkanizing the pro= tocol. If you allow for scenarios where people think they don't need to int= erop can ignore the backward compatibility feature, then there's little poi= nt for the feature in the first place. The idea of an environment where all entities are mandated to support sessm= atch contemplates entities being prohibited from communication with endpoin= ts outside their walled garden. I don't think we want to encourage that. It= 's one thing to forbid this by policy--it's entirely different to prevent i= t via technology. If a carrier decides to open up at some point in the futu= re, it would be ill-served to find its endpoints were unable to communicate= because the implementor assumed they would never be used outside a walled = garden.= From saghul@gmail.com Mon Apr 18 09:13:53 2011 Return-Path: X-Original-To: simple@ietfc.amsl.com Delivered-To: simple@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B14A5E0776 for ; Mon, 18 Apr 2011 09:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbiOFR1vdZLy for ; Mon, 18 Apr 2011 09:13:52 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfc.amsl.com (Postfix) with ESMTP id AEB57E06D9 for ; Mon, 18 Apr 2011 09:13:52 -0700 (PDT) Received: by qwc23 with SMTP id 23so3376176qwc.31 for ; Mon, 18 Apr 2011 09:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Ofoul5eqcbx/BNxGCWUXU2gpWQu0m3Yd5aeOmPFB1Xg=; b=VcahLLTb2kOiEaqrsMTGfDbZ8vYcP12EVoHAapGkUEOBqx4RwB2aGY+4Xe4pl2aJmI L2DZPBga5752oO+tlmUI+WUZCxmUcL04yIGldYqxo0sfSyB3YdZuPrx5dnxtWLzMGPnS Zc3ubKzY39G9PC2Dy6Dbbf8MaisUciI287+Lo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=g7HGxRQAxO0MTD9EMDO9KHh4iWRX6ctJFG383V8xdp7NHAH6+gwaawsYaSjepG1+gr cG+WJVzQjSb7swn/p9npM4PBDH17t38DLn646VPdDGSxUk7tiUwm4D41qr9Rf1frXzl+ OZ6ffENogDRJUjghlPlJcivPjvhXpWifF66+8= Received: by 10.229.48.84 with SMTP id q20mr3624509qcf.131.1303143232169; Mon, 18 Apr 2011 09:13:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.40.209 with HTTP; Mon, 18 Apr 2011 09:13:32 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194C9CC8CF@ESESSCMS0356.eemea.ericsson.se> References: <42C57E6F-B75F-4D12-991F-246E3FF31192@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851948F0B38A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194C9CC8CF@ESESSCMS0356.eemea.ericsson.se> From: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Date: Mon, 18 Apr 2011 18:13:32 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] Sessmatch: Proposed option-tag text [was: draft-ietf-simple-msrp-sessmatch-10 Issue] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 16:13:53 -0000 On Mon, Apr 18, 2011 at 6:00 PM, Christer Holmberg wrote: > Hi, > > I'm ok to remove the text paragraph and the note. > > Regards, > > Christer > That's great, thanks! Regards, --=20 /Sa=C3=BAl http://saghul.net | http://sipdoc.net From christer.holmberg@ericsson.com Mon Apr 18 11:46:36 2011 Return-Path: X-Original-To: simple@ietfc.amsl.com Delivered-To: simple@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9DC0BE086E for ; Mon, 18 Apr 2011 11:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.104 X-Spam-Level: X-Spam-Status: No, score=-6.104 tagged_above=-999 required=5 tests=[AWL=-0.405, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSNOO94Lcsjv for ; Mon, 18 Apr 2011 11:46:36 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfc.amsl.com (Postfix) with ESMTP id B4DBEE0870 for ; Mon, 18 Apr 2011 11:46:35 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-a9-4dac870a28b3 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id ED.EE.09202.A078CAD4; Mon, 18 Apr 2011 20:46:34 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.251]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 18 Apr 2011 20:46:34 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?=27Sa=FAl_Ibarra_Corretg=E9=27?= Date: Mon, 18 Apr 2011 20:46:33 +0200 Thread-Topic: [Simple] Sessmatch: Proposed option-tag text [was: draft-ietf-simple-msrp-sessmatch-10 Issue] - Version 2 Thread-Index: Acv945wUWjhSEntGTAaL662iWM+KRAAFNbXg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194CA56CDA@ESESSCMS0356.eemea.ericsson.se> References: <42C57E6F-B75F-4D12-991F-246E3FF31192@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851948F0B38A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194C9CC8CF@ESESSCMS0356.eemea.ericsson.se> 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] Sessmatch: Proposed option-tag text [was: draft-ietf-simple-msrp-sessmatch-10 Issue] - Version 2 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 18:46:36 -0000 Hi, An uppdated version of the proposed option-tag text below. The only difference is that I removed the last paragraph and note from the = previous text proposal. ----- An MSRP entity that supports the sessmatch extension, and is not located b= ehind an MSRP relay, MUST insert=20 the 'sessmatch' option-tag in the Supported header field of the initial I= NVITE request for a session that=20 contains MSRP media. =20 An MSRP entity that supports the sessmatch extension, and is not located b= ehind an MSRP relay, MUST insert=20 the 'sessmatch' option-tag in at least one reliably sent successful respon= se to the intial INVITE request=20 for a session that contains MSRP media. =20 In addition to inserting the 'sessmatch' option-tag in the Supported heade= r field of the INVITE request,=20 if the MSRP entity is performing MSRP related procedures that require the= remote MSRP entity to support=20 the sessmatch extension in order to enable MSRP meddia, it MUST also inser= t the 'sessmatch' option-tag=20 in the Require header field ofthe request. =20 NOTE: An example of a scenarios where an MSRP entity needs to insert the '= sessmatch' option-tag in the=20 Require header field, is when it acts as an intermediary MSRP entity that= modifies the SDP a=3Dpath attribute address information, in order to anchor and forward MSRP traffic, but does= not perform the corresponding=20 address information changes in the associated MSRP messages. The actions = taken by such MSRP entity in=20 case the remote MSRP entity does not support the sessmatch extension, and = therfore sends a 420 (Not Supported)=20 response to the INVITE request, is outside the scope of this specificatio= n. =20 ----- Regards, Christer=20 -----Original Message----- From: Sa=FAl Ibarra Corretg=E9 [mailto:saghul@gmail.com]=20 Sent: 18. huhtikuuta 2011 19:14 To: Christer Holmberg Cc: Ben Campbell; Simple WG Subject: Re: [Simple] Sessmatch: Proposed option-tag text [was: draft-ietf-= simple-msrp-sessmatch-10 Issue] On Mon, Apr 18, 2011 at 6:00 PM, Christer Holmberg wrote: > Hi, > > I'm ok to remove the text paragraph and the note. > > Regards, > > Christer > That's great, thanks! Regards, -- /Sa=FAl http://saghul.net | http://sipdoc.net From keith.drage@alcatel-lucent.com Tue Apr 19 03:08:54 2011 Return-Path: X-Original-To: simple@ietfc.amsl.com Delivered-To: simple@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4DA3AE06DA for ; Tue, 19 Apr 2011 03:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.402 X-Spam-Level: X-Spam-Status: No, score=-105.402 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unW2aWmR1cFU for ; Tue, 19 Apr 2011 03:08:53 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfc.amsl.com (Postfix) with ESMTP id 4FCA3E0665 for ; Tue, 19 Apr 2011 03:08:53 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3JA8dxG001199 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Apr 2011 12:08:50 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 19 Apr 2011 12:08:46 +0200 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , =?iso-8859-1?Q?=27Sa=FAl_Ibarra_Corretg=E9=27?= Date: Tue, 19 Apr 2011 12:08:45 +0200 Thread-Topic: [Simple] Sessmatch: Proposed option-tag text [was: draft-ietf-simple-msrp-sessmatch-10 Issue] - Version 2 Thread-Index: Acv945wUWjhSEntGTAaL662iWM+KRAAFNbXgACA5uRA= Message-ID: References: <42C57E6F-B75F-4D12-991F-246E3FF31192@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851948F0B38A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194C9CC8CF@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194CA56CDA@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194CA56CDA@ESESSCMS0356.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: Simple WG Subject: Re: [Simple] Sessmatch: Proposed option-tag text [was: draft-ietf-simple-msrp-sessmatch-10 Issue] - Version 2 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 10:08:54 -0000 The second paragraph does not state which header field is used. I assume fr= om the third paragraph "In addition", that it is the Supported header field= . Nowhere do you appear to state what the recipient understands when it recei= ves such an option tag, and therefore what it can safely do as a result, no= r what it should assume if it does not receive it.=20 Keith > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Christer Holmberg > Sent: 18 April 2011 19:47 > To: 'Sa=FAl Ibarra Corretg=E9' > Cc: Simple WG > Subject: Re: [Simple] Sessmatch: Proposed option-tag text [was: draft- > ietf-simple-msrp-sessmatch-10 Issue] - Version 2 >=20 >=20 > Hi, >=20 > An uppdated version of the proposed option-tag text below. >=20 > The only difference is that I removed the last paragraph and note from th= e > previous text proposal. >=20 > ----- >=20 > An MSRP entity that supports the sessmatch extension, and is not located > behind an MSRP relay, MUST insert > the 'sessmatch' option-tag in the Supported header field of the initial > INVITE request for a session that > contains MSRP media. >=20 > An MSRP entity that supports the sessmatch extension, and is not located > behind an MSRP relay, MUST insert > the 'sessmatch' option-tag in at least one reliably sent successful > response to the intial INVITE request > for a session that contains MSRP media. >=20 > In addition to inserting the 'sessmatch' option-tag in the Supported > header field of the INVITE request, > if the MSRP entity is performing MSRP related procedures that require > the remote MSRP entity to support > the sessmatch extension in order to enable MSRP meddia, it MUST also > insert the 'sessmatch' option-tag > in the Require header field ofthe request. >=20 > NOTE: An example of a scenarios where an MSRP entity needs to insert the > 'sessmatch' option-tag in the > Require header field, is when it acts as an intermediary MSRP entity > that modifies the SDP a=3Dpath attribute > address information, in order to anchor and forward MSRP traffic, but > does not perform the corresponding > address information changes in the associated MSRP messages. The action= s > taken by such MSRP entity in > case the remote MSRP entity does not support the sessmatch extension, an= d > therfore sends a 420 (Not Supported) > response to the INVITE request, is outside the scope of this > specification. >=20 > ----- >=20 >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: Sa=FAl Ibarra Corretg=E9 [mailto:saghul@gmail.com] > Sent: 18. huhtikuuta 2011 19:14 > To: Christer Holmberg > Cc: Ben Campbell; Simple WG > Subject: Re: [Simple] Sessmatch: Proposed option-tag text [was: draft- > ietf-simple-msrp-sessmatch-10 Issue] >=20 > On Mon, Apr 18, 2011 at 6:00 PM, Christer Holmberg > wrote: > > Hi, > > > > I'm ok to remove the text paragraph and the note. > > > > Regards, > > > > Christer > > >=20 > That's great, thanks! >=20 > Regards, >=20 > -- > /Sa=FAl > http://saghul.net | http://sipdoc.net > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Tue Apr 19 03:38:58 2011 Return-Path: X-Original-To: simple@ietfc.amsl.com Delivered-To: simple@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A7785E0694 for ; Tue, 19 Apr 2011 03:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.07 X-Spam-Level: X-Spam-Status: No, score=-6.07 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T23ljFPIuvDC for ; Tue, 19 Apr 2011 03:38:57 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfc.amsl.com (Postfix) with ESMTP id 5727CE0680 for ; Tue, 19 Apr 2011 03:38:57 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-df-4dad6640ecf3 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6C.5E.11171.0466DAD4; Tue, 19 Apr 2011 12:38:56 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.251]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 19 Apr 2011 12:38:56 +0200 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , =?iso-8859-1?Q?=27Sa=FAl_Ibarra_Corretg=E9=27?= Date: Tue, 19 Apr 2011 12:38:55 +0200 Thread-Topic: [Simple] Sessmatch: Proposed option-tag text [was: draft-ietf-simple-msrp-sessmatch-10 Issue] - Version 2 Thread-Index: Acv945wUWjhSEntGTAaL662iWM+KRAAFNbXgACA5uRAAADSMQA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194C8A29AE@ESESSCMS0356.eemea.ericsson.se> References: <42C57E6F-B75F-4D12-991F-246E3FF31192@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851948F0B38A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194C9CC8CF@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194CA56CDA@ESESSCMS0356.eemea.ericsson.se> 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] Sessmatch: Proposed option-tag text [was: draft-ietf-simple-msrp-sessmatch-10 Issue] - Version 2 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 10:38:58 -0000 Hi Keith,=20 >The second paragraph does not state which header field is=20 >used. I assume from the third paragraph "In addition", that=20 >it is the Supported header field. Correct. "An MSRP entity that supports the sessmatch extension, and is not=20 located behind an MSRP relay, MUST insert the 'sessmatch'=20 option-tag in the Supported header field of at least one reliably=20 sent successful response to the intial INVITE request for a=20 session that contains MSRP media." >Nowhere do you appear to state what the recipient understands=20 >when it receives such an option tag, and therefore what it=20 >can safely do as a result, nor what it should assume if it=20 >does not receive it.=20 Good point. I suggest to re-write the paragraph mentioned above: "If an MSRP entity that supports the sessmatch extension receives an=20 initial INVITE request that contains the 'sessmatch' option-tag in=20 the Supported or Require header field of the request, and if it is not=20 located behind an MSRP relay, it MUST insert the 'sessmatch' option-tag=20 in the Supported header field of at least one reliably sent successful=20 response to the intial INVITE request, and it MUST use the session matching procedures defined in this specification during the session. Otherwise the MSRP entity MUST NOT insert the 'sessmatch' option-tag in a successful response to the initial INVITE request, and it MUST use=20 the session matching procedures defined in [RFC4975]." In addition, I suggest to re-write the first paragraph: "An MSRP entity that supports the sessmatch extension, and is not=20 located behind an MSRP relay, MUST insert the 'sessmatch' option-tag =20 in the Supported header field of the initial INVITE request for a session= =20 that contains MSRP media. If at least one reliably sent successful=20 response to the intial INVITE request contains the 'sessmatch' option-tag in the Supported header field of the response, the MSRP entity MUST=20 use the session matching procedures defined in this specification during=20 the session. Otherwise the MSRP entity MUST use the procedures defined=20 in [RFC4975]." Regards, Christer > > -----Original Message----- > > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20 > > Behalf Of Christer Holmberg > > Sent: 18 April 2011 19:47 > > To: 'Sa=FAl Ibarra Corretg=E9' > > Cc: Simple WG > > Subject: Re: [Simple] Sessmatch: Proposed option-tag text=20 > [was: draft-=20 > > ietf-simple-msrp-sessmatch-10 Issue] - Version 2 > >=20 > >=20 > > Hi, > >=20 > > An uppdated version of the proposed option-tag text below. > >=20 > > The only difference is that I removed the last paragraph=20 > and note from=20 > > the previous text proposal. > >=20 > > ----- > >=20 > > An MSRP entity that supports the sessmatch extension, and is not=20 > > located behind an MSRP relay, MUST insert the 'sessmatch'=20 > option-tag =20 > > in the Supported header field of the initial INVITE request for a=20 > > session that contains MSRP media. > >=20 > > An MSRP entity that supports the sessmatch extension, and is not=20 > > located behind an MSRP relay, MUST insert the 'sessmatch'=20 > option-tag=20 > > in at least one reliably sent successful response to the=20 > intial INVITE=20 > > request for a session that contains MSRP media. > >=20 > > In addition to inserting the 'sessmatch' option-tag in the=20 > Supported=20 > > header field of the INVITE request, if the MSRP entity is=20 > performing =20 > > MSRP related procedures that require the remote MSRP entity=20 > to support =20 > > the sessmatch extension in order to enable MSRP meddia, it=20 > MUST also=20 > > insert the 'sessmatch' option-tag in the Require header=20 > field ofthe=20 > > request. > >=20 > > NOTE: An example of a scenarios where an MSRP entity needs=20 > to insert=20 > > the 'sessmatch' option-tag in the Require header field, is=20 > when it =20 > > acts as an intermediary MSRP entity that modifies the SDP a=3Dpath=20 > > attribute address information, in order to anchor and forward MSRP=20 > > traffic, but does not perform the corresponding address=20 > information =20 > > changes in the associated MSRP messages. The actions taken by such =20 > > MSRP entity in case the remote MSRP entity does not support the=20 > > sessmatch extension, and therfore sends a 420 (Not Supported) =20 > > response to the INVITE request, is outside the scope of this=20 > > specification. > >=20 > > ----- > >=20 > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > > -----Original Message----- > > From: Sa=FAl Ibarra Corretg=E9 [mailto:saghul@gmail.com] > > Sent: 18. huhtikuuta 2011 19:14 > > To: Christer Holmberg > > Cc: Ben Campbell; Simple WG > > Subject: Re: [Simple] Sessmatch: Proposed option-tag text=20 > [was: draft-=20 > > ietf-simple-msrp-sessmatch-10 Issue] > >=20 > > On Mon, Apr 18, 2011 at 6:00 PM, Christer Holmberg=20 > > wrote: > > > Hi, > > > > > > I'm ok to remove the text paragraph and the note. > > > > > > Regards, > > > > > > Christer > > > > >=20 > > That's great, thanks! > >=20 > > Regards, > >=20 > > -- > > /Sa=FAl > > http://saghul.net | http://sipdoc.net > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple > = From wwwrun@ietfc.amsl.com Tue Apr 19 12:19:22 2011 Return-Path: X-Original-To: Simple Delivered-To: Simple@ietfc.amsl.com Received: by ietfc.amsl.com (Postfix, from userid 30) id 84B18E07E1; Tue, 19 Apr 2011 12:19:22 -0700 (PDT) From: The IESG To: isms-chairs@tools.ietf.org, Transport@ietfc.amsl.com, Subsystem@ietfc.amsl.com, for@ietfc.amsl.com, the@ietfc.amsl.com, Simple@ietfc.amsl.com, Network@ietfc.amsl.com, Management@ietfc.amsl.com, Protocol@tools.ietf.org (SNMP) (Expired) Message-Id: <20110419191922.84B18E07E1@ietfc.amsl.com> Date: Tue, 19 Apr 2011 12:19:22 -0700 (PDT) Subject: [Simple] ID Tracker State Update Notice: RFC 5590 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf-secretariat-reply@ietf.org 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, 19 Apr 2011 19:19:22 -0000 'State Changes to Last Call Requested from Publication Requested by Sean Turner' ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=5590&rfc_flag=1 From wwwrun@ietfc.amsl.com Tue Apr 19 12:40:32 2011 Return-Path: X-Original-To: Simple Delivered-To: Simple@ietfc.amsl.com Received: by ietfc.amsl.com (Postfix, from userid 30) id 7AD9DE0715; Tue, 19 Apr 2011 12:40:32 -0700 (PDT) From: The IESG To: isms-chairs@tools.ietf.org, Transport@ietfc.amsl.com, Subsystem@ietfc.amsl.com, for@ietfc.amsl.com, the@ietfc.amsl.com, Simple@ietfc.amsl.com, Network@ietfc.amsl.com, Management@ietfc.amsl.com, Protocol@tools.ietf.org (SNMP) (Expired) Message-Id: <20110419194032.7AD9DE0715@ietfc.amsl.com> Date: Tue, 19 Apr 2011 12:40:32 -0700 (PDT) Subject: [Simple] ID Tracker State Update Notice: RFC 5590 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf-secretariat-reply@ietf.org 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, 19 Apr 2011 19:40:32 -0000 'State Changes to Publication Requested from Last Call Requested by Sean Turner' ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=5590&rfc_flag=1 From wwwrun@ietfc.amsl.com Tue Apr 19 12:41:21 2011 Return-Path: X-Original-To: Simple Delivered-To: Simple@ietfc.amsl.com Received: by ietfc.amsl.com (Postfix, from userid 30) id 317B2E0689; Tue, 19 Apr 2011 12:41:21 -0700 (PDT) From: The IESG To: isms-chairs@tools.ietf.org, Transport@ietfc.amsl.com, Subsystem@ietfc.amsl.com, for@ietfc.amsl.com, the@ietfc.amsl.com, Simple@ietfc.amsl.com, Network@ietfc.amsl.com, Management@ietfc.amsl.com, Protocol@tools.ietf.org (SNMP) (Expired) Message-Id: <20110419194121.317B2E0689@ietfc.amsl.com> Date: Tue, 19 Apr 2011 12:41:21 -0700 (PDT) Subject: [Simple] ID Tracker State Update Notice: RFC 5590 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf-secretariat-reply@ietf.org 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, 19 Apr 2011 19:41:21 -0000 'State Changes to Last Call Requested from Publication Requested by Sean Turner' ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=5590&rfc_flag=1 From wwwrun@ietfc.amsl.com Tue Apr 19 14:18:59 2011 Return-Path: X-Original-To: Simple Delivered-To: Simple@ietfc.amsl.com Received: by ietfc.amsl.com (Postfix, from userid 30) id 4887DE0837; Tue, 19 Apr 2011 14:18:59 -0700 (PDT) From: The IESG To: isms-chairs@tools.ietf.org, Transport@ietfc.amsl.com, Subsystem@ietfc.amsl.com, for@ietfc.amsl.com, the@ietfc.amsl.com, Simple@ietfc.amsl.com, Network@ietfc.amsl.com, Management@ietfc.amsl.com, Protocol@tools.ietf.org (SNMP) (Expired) Message-Id: <20110419211859.4887DE0837@ietfc.amsl.com> Date: Tue, 19 Apr 2011 14:18:59 -0700 (PDT) Subject: [Simple] ID Tracker State Update Notice: RFC 5590 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf-secretariat-reply@ietf.org 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, 19 Apr 2011 21:18:59 -0000 'State Changes to In Last Call from Last Call Requested by Amy Vezza' ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=5590&rfc_flag=1 From wwwrun@ietfc.amsl.com Tue Apr 19 14:30:58 2011 Return-Path: X-Original-To: Simple Delivered-To: Simple@ietfc.amsl.com Received: by ietfc.amsl.com (Postfix, from userid 30) id 4C365E0781; Tue, 19 Apr 2011 14:30:58 -0700 (PDT) From: The IESG To: opsawg-chairs@tools.ietf.org, Simple@ietfc.amsl.com, Network@ietfc.amsl.com, Management@ietfc.amsl.com, Protocol@ietfc.amsl.com, Context@ietfc.amsl.com (SNMP), EngineID@ietfc.amsl.com, Discovery@tools.ietf.org (Expired) Message-Id: <20110419213058.4C365E0781@ietfc.amsl.com> Date: Tue, 19 Apr 2011 14:30:58 -0700 (PDT) Subject: [Simple] ID Tracker State Update Notice: RFC 5343 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf-secretariat-reply@ietf.org 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, 19 Apr 2011 21:30:58 -0000 'State Changes to Last Call Requested from Publication Requested by Amy Vezza' ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=5343&rfc_flag=1 From wwwrun@ietfc.amsl.com Tue Apr 19 14:39:36 2011 Return-Path: X-Original-To: Simple Delivered-To: Simple@ietfc.amsl.com Received: by ietfc.amsl.com (Postfix, from userid 30) id C64D2E07A4; Tue, 19 Apr 2011 14:39:36 -0700 (PDT) From: The IESG To: opsawg-chairs@tools.ietf.org, Simple@ietfc.amsl.com, Network@ietfc.amsl.com, Management@ietfc.amsl.com, Protocol@ietfc.amsl.com, Context@ietfc.amsl.com (SNMP), EngineID@ietfc.amsl.com, Discovery@tools.ietf.org (Expired) Message-Id: <20110419213936.C64D2E07A4@ietfc.amsl.com> Date: Tue, 19 Apr 2011 14:39:36 -0700 (PDT) Subject: [Simple] ID Tracker State Update Notice: RFC 5343 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf-secretariat-reply@ietf.org 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, 19 Apr 2011 21:39:37 -0000 'State Changes to In Last Call from Last Call Requested by Amy Vezza' ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=5343&rfc_flag=1