From hisham.khartabil@gmail.com Sun Mar 1 18:38:44 2009 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 AC80028C1BE for ; Sun, 1 Mar 2009 18:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCYBNOM5ka9o for ; Sun, 1 Mar 2009 18:38:43 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id AF46828C1BC for ; Sun, 1 Mar 2009 18:38:43 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1875971rvb.49 for ; Sun, 01 Mar 2009 18:39:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bbmNtvf+8uNjhDOzEljrVFtvhuxzxkdK23GiojB6lOk=; b=uoWGOv8OefhsygxZuFNfFEERGscoCoiiHnYY85Qq0+kzIQZrX9M0ScMWn7z9TMVcVq niaEemOBHUSwMZMBt9FnWalG9R/XhhouoCxXoYIddqk/NYdmw6TxGvXtg4AKjJt2xTHo wDPIVChc0hha6SS5LjPtq2Z22ZtFW3zUB2Y0I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mqBegw7ZN6usR3jbsD07+Spo6bQbVThyhs54rRYvK8JHa4jH8MmCIGscU12LPGcZVG izAUx5nk1NAblX93cyLdoPD2Pv5QrYKQz4S92qYWMEK9ctP81fsd/X7pVwjShc3QsOOH CBkJVBLbSp6rXrd4ZrgyEgNicT0BmP7sYHiOs= MIME-Version: 1.0 Received: by 10.143.162.8 with SMTP id p8mr2749317wfo.34.1235961548989; Sun, 01 Mar 2009 18:39:08 -0800 (PST) In-Reply-To: References: <1B48F5CF-A504-423B-8DDD-6E8667A3B887@estacado.net> <5036B2F7-3C21-4296-B92B-9D3F2B5E8601@estacado.net> <76CDAA7F-C8D5-4D1B-89F7-AF5FB2916799@estacado.net> Date: Mon, 2 Mar 2009 13:39:08 +1100 Message-ID: <66cd252f0903011839g6b51f93ahb09f0ad7a95cceea@mail.gmail.com> From: Hisham Khartabil To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] msrp-acm: Using MSRP with SBCs/ALGs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 02:38:44 -0000 I don't agree with that. We cannot have two MSRP clients using SIP and SDP as signalling protocols not be able to communicate, just like we cannot have two G.711 clients using SIP and SDP as signalling protocols not be able to communicate. To me, the requirement seems strong that we need to have communicability between an msrp-acm client and msrp-relay client. I suggest Hadriel and Christer start working on use cases and call flows to that effect. Regards, Hisham 2009/2/25 Hadriel Kaplan : > > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@estacado.net] >> Sent: Tuesday, February 24, 2009 9:35 AM >> >> This quickly returns to the "if we go down this path, we have >> effectively deprecated MSRP relays." situation. =A0If the community >> wants to do that, so be it. But I really don't want to split the >> standard so that we have two implementation choices that can't >> interoperate. > > I don't think that's what we're saying. =A0We have a session-creating ren= dezvous protocol (SIP) with address advertisement and capability negotiatio= n (SDP) which allows us to offer different media-layer connection schemes a= nd attributes. =A0So we're saying let SIP and SDP do their job - let them a= dvertise what each side supports. =A0That's what they do for codecs, srtp, = audio/video, etc. =A0If the two sides each support incompatible choices, th= en sure it won't work - just like it won't if we don't have common media ca= pabilities. > > -hadriel > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From HKaplan@acmepacket.com Sun Mar 1 19:10:40 2009 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 EE21A28C1C2 for ; Sun, 1 Mar 2009 19:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2emAMKTY2M8P for ; Sun, 1 Mar 2009 19:10:40 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id DED8028C195 for ; Sun, 1 Mar 2009 19:10:39 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sun, 1 Mar 2009 22:11:04 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 1 Mar 2009 22:11:04 -0500 From: Hadriel Kaplan To: Hisham Khartabil Date: Sun, 1 Mar 2009 22:11:02 -0500 Thread-Topic: [Simple] msrp-acm: Using MSRP with SBCs/ALGs Thread-Index: Acma4BnsblY8WXpmQs68fVwUSHRlDQAAW3Jg Message-ID: References: <1B48F5CF-A504-423B-8DDD-6E8667A3B887@estacado.net> <5036B2F7-3C21-4296-B92B-9D3F2B5E8601@estacado.net> <76CDAA7F-C8D5-4D1B-89F7-AF5FB2916799@estacado.net> <66cd252f0903011839g6b51f93ahb09f0ad7a95cceea@mail.gmail.com> In-Reply-To: <66cd252f0903011839g6b51f93ahb09f0ad7a95cceea@mail.gmail.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: Simple WG Subject: Re: [Simple] msrp-acm: Using MSRP with SBCs/ALGs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 03:10:41 -0000 > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > Sent: Sunday, March 01, 2009 9:39 PM > > I don't agree with that. We cannot have two MSRP clients using SIP and > SDP as signalling protocols not be able to communicate, just like we > cannot have two G.711 clients using SIP and SDP as signalling > protocols not be able to communicate. But you do have that situation for two "G.711" clients, right now, all over= the place. First, "G.711" is actually PCMU vs. PCMA as you know, and thos= e two don't talk to each other. Even if you do both, you can indicate RTP/= AVP, RTP/SAVP, RTP/AVPF, RTP/SAVPF - and none of them talk to each other. = And there are at least 3 different forms of SRTP key exchange, which don't = interoperate. But more to the point my analogy is that this isn't G.711 vs= G.711 - this is more like RTP vs. SRTP, or UDP vs. RUDP. The two modes ar= e inexorably non-interoperable. > To me, the requirement seems strong that we need to have > communicability between an msrp-acm client and msrp-relay client. I > suggest Hadriel and Christer start working on use cases and call flows > to that effect. Why does the requirement seem strong to you? -hadriel From hisham.khartabil@gmail.com Sun Mar 1 20:20:05 2009 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 BA03D28C1EC for ; Sun, 1 Mar 2009 20:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQ23JN+h2XMG for ; Sun, 1 Mar 2009 20:20:04 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id B530228C1CC for ; Sun, 1 Mar 2009 20:20:04 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1906367rvb.49 for ; Sun, 01 Mar 2009 20:20:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/nqsGGgqLjii5peY3nPWioEgi+pxx6PGHYyLcNRycZw=; b=bjJcEZ2nFVOVZ9gVyLkaz7bGWKyw5mtBZ/9B9H0rA3QUmZpEVyYtBX7ykRcV7a+RnD ndsCs7+q1HGZKDT7OyoAR8HpZ94rytsKqfZILIRmMH6e4GHygUs88hmPQS0EHlzdh20c UH7sz9UamzV+PIxlS7DQmXVxOEJBOcaqm2FtM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RNJsKq9TPeE9DbaV8fDqeKTlOfT303iqFWVzFoZ3uu+YjG5SfHmHL2SgZet8esE3vB ReA2IOyjEoRTFD923m9juNihjW33kG4Q8JIfSBXRKfSNmFfyS3vZxFaF7o6RUjzfOgfd 11qVypQVrEYbRE7LRzZDo92wyxh8s+KHzBMt4= MIME-Version: 1.0 Received: by 10.142.221.11 with SMTP id t11mr2780314wfg.238.1235967629967; Sun, 01 Mar 2009 20:20:29 -0800 (PST) In-Reply-To: References: <1B48F5CF-A504-423B-8DDD-6E8667A3B887@estacado.net> <5036B2F7-3C21-4296-B92B-9D3F2B5E8601@estacado.net> <76CDAA7F-C8D5-4D1B-89F7-AF5FB2916799@estacado.net> <66cd252f0903011839g6b51f93ahb09f0ad7a95cceea@mail.gmail.com> Date: Mon, 2 Mar 2009 15:20:29 +1100 Message-ID: <66cd252f0903012020n4958fab0wa6b5d85f47d59fea@mail.gmail.com> From: Hisham Khartabil To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] msrp-acm: Using MSRP with SBCs/ALGs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 04:20:05 -0000 The requirement is strong because 90% of the people I talked to off-line agree with it. We can take a poll on the mailing to see how strong this requirement and satisfy those who don't believe it is. Hisham 2009/3/2 Hadriel Kaplan : > > >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] >> Sent: Sunday, March 01, 2009 9:39 PM >> >> I don't agree with that. We cannot have two MSRP clients using SIP and >> SDP as signalling protocols not be able to communicate, just like we >> cannot have two G.711 clients using SIP and SDP as signalling >> protocols not be able to communicate. > > But you do have that situation for two "G.711" clients, right now, all ov= er the place. =A0First, "G.711" is actually PCMU vs. PCMA as you know, and = those two don't talk to each other. =A0Even if you do both, you can indicat= e RTP/AVP, RTP/SAVP, RTP/AVPF, RTP/SAVPF - and none of them talk to each ot= her. =A0And there are at least 3 different forms of SRTP key exchange, whic= h don't interoperate. =A0But more to the point my analogy is that this isn'= t G.711 vs G.711 - this is more like RTP vs. SRTP, or UDP vs. RUDP. =A0The = two modes are inexorably non-interoperable. > > >> To me, the requirement seems strong that we need to have >> communicability between an msrp-acm client and msrp-relay client. I >> suggest Hadriel and Christer start working on use cases and call flows >> to that effect. > > Why does the requirement seem strong to you? > > -hadriel > From hisham.khartabil@gmail.com Sun Mar 1 20:23:47 2009 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 1F3CF28C1F7 for ; Sun, 1 Mar 2009 20:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JnbzPqOJLmb for ; Sun, 1 Mar 2009 20:23:46 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 40ACE28C1FB for ; Sun, 1 Mar 2009 20:23:46 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2395116wfd.31 for ; Sun, 01 Mar 2009 20:24:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=zEe9fJ8TOKYOlbkKbfPfYWFHFmUdPutS5/2siKnkWho=; b=k+d1MUCFWPlXpxDvrevUW06XtNVICgCuXyfD0SwF2jdj+F2SQqq3jLRPTaOAKp8wj/ +8cC4CXvcJHXfR78wFokz3fPh4lJnxCZZsaX1vlzzAfTdX2CaYkaUxPmakSSLFa5Nd/N /wGt50OxK1MyytHaNgE2fDZgMYBFOE383zr6M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=kabEoMQJ4SwlZoth1O4ZRROwRxpBUj52yWhU5mFMvQkVNoK4iXFTgOmB32Ab7eBV90 4CS9q2OwNcyjNNsCCK14giIVUMuGXaDUnXjZe6iEFM4XPvYsidE9XSiMJ1nk2NWK5hJh PvPQQQ3WqJ7TphawmG1lX7VLjjx4v764FPkoE= MIME-Version: 1.0 Received: by 10.142.214.5 with SMTP id m5mr2781779wfg.266.1235967851626; Sun, 01 Mar 2009 20:24:11 -0800 (PST) Date: Mon, 2 Mar 2009 15:24:11 +1100 Message-ID: <66cd252f0903012024v6550c6edv83234fe2bd07fd34@mail.gmail.com> From: Hisham Khartabil To: Simple WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Simple] msrp-acm and msrp-relay client interworking X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 04:23:47 -0000 Hi All, There seems to be an online debate on how strong a requirement is that an msrp-acm client must be able to communicate with an msrp-relay client using an MSRP session set up using SIP/SDP as signalling protocols. This is a poll requesting input to see if this is indeed a requirement. Please reply directly tot he mailing list. Thanks, Hisham From hisham.khartabil@gmail.com Sun Mar 1 20:29:58 2009 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 C76B728C1FA for ; Sun, 1 Mar 2009 20:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpIsDBkGjJAL for ; Sun, 1 Mar 2009 20:29:58 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id EF2A528C1F7 for ; Sun, 1 Mar 2009 20:29:57 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1909415rvb.49 for ; Sun, 01 Mar 2009 20:30:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7oN1dsi9FhyhP/ljRxvNspdthdIhWQyrKKHM5PWq9SQ=; b=fX9LvL7Pbt3uJ62xR7Ch9KFMGxJRVjbgEv5w2EBySotqxbBEedhCtO4+1SfwmNeJf1 +xQm1ISbTL/emlnwhzZUFTo5TXZXdHnE+ySVHF7sw/r+uwduxjleMnuYyEZiZJ4pYO6A CiCFKu5UJo7LWf4Mx0NHtMOYa/tscegDgq7Uc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HKxHaUNfsvzvbJWNFOARKUlhsOuTSLcVusn8wH9832444Wwv5nM4QW2SyXwkEFFPgk sDa0Z5PfvL34RfWpfPwD0F0Orvqsk2B9FyPYn622/w8jyhKiIFa206auSFJ5wk4ENTBZ Zl4eqEWdYrmuKCf1WA3AFqMDoN3K8TFEtHBQg= MIME-Version: 1.0 Received: by 10.142.125.9 with SMTP id x9mr2778983wfc.331.1235968223317; Sun, 01 Mar 2009 20:30:23 -0800 (PST) In-Reply-To: References: <1B48F5CF-A504-423B-8DDD-6E8667A3B887@estacado.net> <5036B2F7-3C21-4296-B92B-9D3F2B5E8601@estacado.net> <76CDAA7F-C8D5-4D1B-89F7-AF5FB2916799@estacado.net> <66cd252f0903011839g6b51f93ahb09f0ad7a95cceea@mail.gmail.com> Date: Mon, 2 Mar 2009 15:30:23 +1100 Message-ID: <66cd252f0903012030h2d001aa4j4dd4e5ec6f0c0994@mail.gmail.com> From: Hisham Khartabil To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] msrp-acm: Using MSRP with SBCs/ALGs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 04:29:58 -0000 2009/3/2 Hadriel Kaplan : > > >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] >> Sent: Sunday, March 01, 2009 9:39 PM >> >> I don't agree with that. We cannot have two MSRP clients using SIP and >> SDP as signalling protocols not be able to communicate, just like we >> cannot have two G.711 clients using SIP and SDP as signalling >> protocols not be able to communicate. > > But you do have that situation for two "G.711" clients, right now, all ov= er the place. =A0First, "G.711" is actually PCMU vs. PCMA as you know, and = those two don't talk to each other. =A0Even if you do both, > you can indic= ate RTP/AVP, RTP/SAVP, RTP/AVPF, RTP/SAVPF - and none of them talk to each = other. =A0And there are at least 3 different forms of SRTP key exchange, wh= ich don't interoperate. =A0But > more to the point my analogy is that this isn't G.711 vs G.711 - this is = more like RTP vs. SRTP, or UDP vs. RUDP. =A0The two modes are inexorably no= n-interoperable. > Sorry, I meant to compare RTP with MSRP. PCMU and PCMA are really different codecs and is like comparing text/plain with image/jpeg. What are talking about here is 2 ways to signal an initiation of a session that uses the same MSRP protocol to carry media. Hisham > >> To me, the requirement seems strong that we need to have >> communicability between an msrp-acm client and msrp-relay client. I >> suggest Hadriel and Christer start working on use cases and call flows >> to that effect. > > Why does the requirement seem strong to you? > > -hadriel > From HKaplan@acmepacket.com Sun Mar 1 20:45:49 2009 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 95D5828C1CC for ; Sun, 1 Mar 2009 20:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMv60PoStqLs for ; Sun, 1 Mar 2009 20:45:49 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 218E828C141 for ; Sun, 1 Mar 2009 20:45:48 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sun, 1 Mar 2009 23:46:12 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 1 Mar 2009 23:46:12 -0500 From: Hadriel Kaplan To: Hisham Khartabil Date: Sun, 1 Mar 2009 23:46:10 -0500 Thread-Topic: [Simple] msrp-acm: Using MSRP with SBCs/ALGs Thread-Index: Acma75tWp27aQHADSNOy53fBuhy6VQAAJmmA Message-ID: References: <1B48F5CF-A504-423B-8DDD-6E8667A3B887@estacado.net> <5036B2F7-3C21-4296-B92B-9D3F2B5E8601@estacado.net> <76CDAA7F-C8D5-4D1B-89F7-AF5FB2916799@estacado.net> <66cd252f0903011839g6b51f93ahb09f0ad7a95cceea@mail.gmail.com> <66cd252f0903012030h2d001aa4j4dd4e5ec6f0c0994@mail.gmail.com> In-Reply-To: <66cd252f0903012030h2d001aa4j4dd4e5ec6f0c0994@mail.gmail.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: Simple WG Subject: Re: [Simple] msrp-acm: Using MSRP with SBCs/ALGs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 04:45:49 -0000 > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > Sent: Sunday, March 01, 2009 11:30 PM > > Sorry, I meant to compare RTP with MSRP. > > PCMU and PCMA are really different codecs and is like comparing > text/plain with image/jpeg. > > What are talking about here is 2 ways to signal an initiation of a > session that uses the same MSRP protocol to carry media. Not as I read it. The MSRP protocol itself would be changed/different on t= he client. The msrp-acm client is receiving MSRP messages with a from-path= url not matching the remote ip:port it's receiving from, and sending them = out to a remote ip:port not matching it's to-path url. No? It's effectively a different "codec". It's a small difference, somewhat li= ke u-law/a-law companding, but non-interoperable. -hadriel From HKaplan@acmepacket.com Sun Mar 1 21:00:47 2009 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 4ED8228C216 for ; Sun, 1 Mar 2009 21:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awz+srqUIYD2 for ; Sun, 1 Mar 2009 21:00:46 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5717628C215 for ; Sun, 1 Mar 2009 21:00:46 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 2 Mar 2009 00:01:11 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 2 Mar 2009 00:01:11 -0500 From: Hadriel Kaplan To: Hisham Khartabil Date: Mon, 2 Mar 2009 00:01:10 -0500 Thread-Topic: [Simple] msrp-acm: Using MSRP with SBCs/ALGs Thread-Index: Acma7kYlJuCewpgtQz2WvM7daqLD7AAA+VJw Message-ID: References: <1B48F5CF-A504-423B-8DDD-6E8667A3B887@estacado.net> <5036B2F7-3C21-4296-B92B-9D3F2B5E8601@estacado.net> <76CDAA7F-C8D5-4D1B-89F7-AF5FB2916799@estacado.net> <66cd252f0903011839g6b51f93ahb09f0ad7a95cceea@mail.gmail.com> <66cd252f0903012020n4958fab0wa6b5d85f47d59fea@mail.gmail.com> In-Reply-To: <66cd252f0903012020n4958fab0wa6b5d85f47d59fea@mail.gmail.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: Simple WG Subject: Re: [Simple] msrp-acm: Using MSRP with SBCs/ALGs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 05:00:47 -0000 > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > Sent: Sunday, March 01, 2009 11:20 PM > > The requirement is strong because 90% of the people I talked to > off-line agree with it. We can take a poll on the mailing to see how > strong this requirement and satisfy those who don't believe it is. To date I have not seen a proposal for how the mechanism can interwork with= current rfc4976 MSRP Relays. I'm all in favor of making it work with such= , but I don't know how to do the impossible. -hadriel From christer.holmberg@ericsson.com Sun Mar 1 22:03:10 2009 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 9F7383A68F6 for ; Sun, 1 Mar 2009 22:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.776 X-Spam-Level: X-Spam-Status: No, score=-5.776 tagged_above=-999 required=5 tests=[AWL=0.473, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 z6ufmgBXFC2k for ; Sun, 1 Mar 2009 22:03:09 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 76E833A6901 for ; Sun, 1 Mar 2009 22:03:05 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 728E020E73; Mon, 2 Mar 2009 07:03:29 +0100 (CET) X-AuditID: c1b4fb3c-aa804bb000001b43-b3-49ab76b13911 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4519620E6A; Mon, 2 Mar 2009 07:03:29 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Mar 2009 07:03:28 +0100 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: Mon, 2 Mar 2009 07:03:28 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] msrp-acm: Using MSRP with SBCs/ALGs Thread-Index: Acma7kYlJuCewpgtQz2WvM7daqLD7AAA+VJwAAKAzeA= References: <1B48F5CF-A504-423B-8DDD-6E8667A3B887@estacado.net> <5036B2F7-3C21-4296-B92B-9D3F2B5E8601@estacado.net> <76CDAA7F-C8D5-4D1B-89F7-AF5FB2916799@estacado.net> <66cd252f0903011839g6b51f93ahb09f0ad7a95cceea@mail.gmail.com> <66cd252f0903012020n4958fab0wa6b5d85f47d59fea@mail.gmail.com> From: "Christer Holmberg" To: "Hadriel Kaplan" , "Hisham Khartabil" X-OriginalArrivalTime: 02 Mar 2009 06:03:28.0721 (UTC) FILETIME=[9B72FC10:01C99AFC] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] msrp-acm: Using MSRP with SBCs/ALGs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 06:03:10 -0000 Hi, One way of making it work is to use a B2BUA which does interworking between msrp-acm and msrp-relay. I think that would be a satisfying solution, considerering the relay deployment situation. Regards, Christer=20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: 2. maaliskuuta 2009 7:01 > To: Hisham Khartabil > Cc: Ben Campbell; Christer Holmberg; Simple WG > Subject: RE: [Simple] msrp-acm: Using MSRP with SBCs/ALGs >=20 >=20 >=20 > > -----Original Message----- > > From: Hisham Khartabil [mailto:hisham.khartabil@gmail.com] > > Sent: Sunday, March 01, 2009 11:20 PM > > > > The requirement is strong because 90% of the people I talked to=20 > > off-line agree with it. We can take a poll on the mailing=20 > to see how=20 > > strong this requirement and satisfy those who don't believe it is. >=20 > To date I have not seen a proposal for how the mechanism can=20 > interwork with current rfc4976 MSRP Relays. I'm all in favor=20 > of making it work with such, but I don't know how to do the=20 > impossible. >=20 > -hadriel >=20 From christer.holmberg@ericsson.com Sun Mar 1 22:03:58 2009 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 D01383A68F6 for ; Sun, 1 Mar 2009 22:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.785 X-Spam-Level: X-Spam-Status: No, score=-5.785 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 6sUhE4oo0bqt for ; Sun, 1 Mar 2009 22:03:58 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 025003A6822 for ; Sun, 1 Mar 2009 22:03:58 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 425F121285; Mon, 2 Mar 2009 07:04:22 +0100 (CET) X-AuditID: c1b4fb3e-af8a1bb0000023da-ba-49ab76e60407 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3043C203BD; Mon, 2 Mar 2009 07:04:22 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Mar 2009 07:04:22 +0100 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: Mon, 2 Mar 2009 07:04:21 +0100 Message-ID: In-Reply-To: <66cd252f0903012024v6550c6edv83234fe2bd07fd34@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] msrp-acm and msrp-relay client interworking Thread-Index: Acma7sB6ldIpCgzfTdWw280jB13NGQADePHw References: <66cd252f0903012024v6550c6edv83234fe2bd07fd34@mail.gmail.com> From: "Christer Holmberg" To: "Hisham Khartabil" , "Simple WG" X-OriginalArrivalTime: 02 Mar 2009 06:04:22.0051 (UTC) FILETIME=[BB3C7F30:01C99AFC] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] msrp-acm and msrp-relay client interworking X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 06:03:58 -0000 Hi, It can be done with an interworking B2BUA. Regards, Christer > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Hisham Khartabil > Sent: 2. maaliskuuta 2009 6:24 > To: Simple WG > Subject: [Simple] msrp-acm and msrp-relay client interworking >=20 > Hi All, >=20 > There seems to be an online debate on how strong a=20 > requirement is that an msrp-acm client must be able to=20 > communicate with an msrp-relay client using an MSRP session=20 > set up using SIP/SDP as signalling protocols. This is a poll=20 > requesting input to see if this is indeed a requirement.=20 > Please reply directly tot he mailing list. >=20 > Thanks, > Hisham > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From HKaplan@acmepacket.com Sun Mar 1 22:05:18 2009 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 92A8128C0F1 for ; Sun, 1 Mar 2009 22:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbr0wGBCATkA for ; Sun, 1 Mar 2009 22:05:17 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 03BD83A68F6 for ; Sun, 1 Mar 2009 22:05:17 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 2 Mar 2009 01:05:41 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 2 Mar 2009 01:05:41 -0500 From: Hadriel Kaplan To: Hisham Khartabil , Simple WG Date: Mon, 2 Mar 2009 01:05:40 -0500 Thread-Topic: [Simple] msrp-acm and msrp-relay client interworking Thread-Index: Acma7r9UUG8yLvo5Q/+V5/jCJVBvAAABUDUQ Message-ID: References: <66cd252f0903012024v6550c6edv83234fe2bd07fd34@mail.gmail.com> In-Reply-To: <66cd252f0903012024v6550c6edv83234fe2bd07fd34@mail.gmail.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 Subject: Re: [Simple] msrp-acm and msrp-relay client interworking X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 06:05:18 -0000 Well if you're going to ask for a vote on that, I suppose it's only fair th= at I actually argue *why* I don't think it's a requirement. First, I vote = "no" it's not a requirement. And here's my rationale: 1) The MSRP Relay idea was actually a bad idea. Think about it. You're cr= eating a protocol to not only send instant-messages now and then in an IM s= ession, but to in fact transfer files - possibly really BIG files. There a= re a bunch of folks that want to do that with MSRP. Some of them are even = delay-sensitive, like white-boarding and remote GUI control. Would you per= form bulk file transfer through application-layer relays? Note this isn't = a socket relay - but actual signaling relays that terminate TLS/TCP, parse = text messages, and route each chunk/message using what effectively amounts = to a SIP Via/Route list inside the message. You might as well have just se= nt hundreds of SIP MESSAGE requests with binary MIME attached payloads of t= he chunks. It's a really bad protocol idea. 2) The main driver for MSRP Relays, as far as I can tell, is to cross NATs.= Even if you don't like how SBC's do that, it doesn't take a super-genius = to figure out TURN at least is a better protocol for this than MSRP Relays.= If you're using TURN, you don't need MSRP Relays. 3) One of the reasons (in fact the only reason, IMHO) to support MSRP Relay= s is because of the installed base. I appreciate that, a lot. Interworkin= g with an installed base is something I like, because it means more people = using it, which means wider and faster adoption, which is more money for me= in the end (I hope). But there isn't an installed base. I don't know how= to say this without sounding like a jerk, but if the msrprelay.org site on= ly has 50,000 users, then it's basically a field trial in east-Latvia for s= ome of us. Compare it to the 50 *Million* Jabber/XMPP users. And as far a= s I've heard that MSRP-Relay project is the big one. If their goal is to h= elp NAT traversal of MSRP, a TURN server project would do it - and would be= usable for things other than MSRP. 4) What msrp-acm is proposing is NOT to deprecate RFC 4976. If people want= to use Relays, that's cool. Clients can continue to support it as well. = All msrp-acm is doing is offering a different relay model, for those who wi= sh to use it. And the market can decide if one is more useful, or both can= be used. That is *actually* the IETF way. RFC 4976 is a Proposed Standar= d, nothing more. It's not gospel. We don't have to have one and only one = way to use MSRP, and we're not constrained from making changes to it. And = luckily we actually have a capability advertisement protocol (SDP) at our d= isposal to negotiate which mode. It would be one thing if we were talking = about HTTP or SIP - something with a very large installed base, and a long = history of use. But with MSRP Relays we're not. Not by a long shot. -hadriel > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Hisham Khartabil > > There seems to be an online debate on how strong a requirement is that > an msrp-acm client must be able to communicate with an msrp-relay > client using an MSRP session set up using SIP/SDP as signalling > protocols. This is a poll requesting input to see if this is indeed a > requirement. Please reply directly tot he mailing list. > > Thanks, > Hisham > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From HKaplan@acmepacket.com Sun Mar 1 22:09:46 2009 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 E7C233A6901 for ; Sun, 1 Mar 2009 22:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZrvmWJYVc75 for ; Sun, 1 Mar 2009 22:09:45 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A1FBC3A68D1 for ; Sun, 1 Mar 2009 22:09:45 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 2 Mar 2009 01:10:10 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 2 Mar 2009 01:10:10 -0500 From: Hadriel Kaplan To: Christer Holmberg , Hisham Khartabil Date: Mon, 2 Mar 2009 01:10:09 -0500 Thread-Topic: [Simple] msrp-acm: Using MSRP with SBCs/ALGs Thread-Index: Acma7kYlJuCewpgtQz2WvM7daqLD7AAA+VJwAAKAzeAAAEw9wA== Message-ID: References: <1B48F5CF-A504-423B-8DDD-6E8667A3B887@estacado.net> <5036B2F7-3C21-4296-B92B-9D3F2B5E8601@estacado.net> <76CDAA7F-C8D5-4D1B-89F7-AF5FB2916799@estacado.net> <66cd252f0903011839g6b51f93ahb09f0ad7a95cceea@mail.gmail.com> <66cd252f0903012020n4958fab0wa6b5d85f47d59fea@mail.gmail.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 Cc: Simple WG Subject: Re: [Simple] msrp-acm: Using MSRP with SBCs/ALGs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 06:09:47 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, March 02, 2009 1:03 AM > > One way of making it work is to use a B2BUA which does interworking > between msrp-acm and msrp-relay. > > I think that would be a satisfying solution, considerering the relay > deployment situation. Sure, I'm cool with that if it will move us forward. -hadriel From Remi.Denis-Courmont@nokia.com Mon Mar 2 00:37:08 2009 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 3579A3A6BD7 for ; Mon, 2 Mar 2009 00:37:08 -0800 (PST) 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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqYmKfBo9140 for ; Mon, 2 Mar 2009 00:37:07 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id E0DFE3A6BE5 for ; Mon, 2 Mar 2009 00:37:06 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n228b3r1025889 for ; Mon, 2 Mar 2009 10:37:29 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Mar 2009 10:37:29 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Mar 2009 10:37:29 +0200 Received: from leon.remlab.net (esdhcp041160.research.nokia.com [172.21.41.160]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n228bR6q031712 for ; Mon, 2 Mar 2009 10:37:28 +0200 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Software - Nokia Devices R&D To: simple@ietf.org Date: Mon, 2 Mar 2009 10:37:44 +0200 User-Agent: KMail/1.11.0 (Linux/2.6.28.7; KDE/4.2.0; i686; ; ) References: <66cd252f0903012024v6550c6edv83234fe2bd07fd34@mail.gmail.com> In-Reply-To: <66cd252f0903012024v6550c6edv83234fe2bd07fd34@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903021037.44690.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 02 Mar 2009 08:37:29.0369 (UTC) FILETIME=[1F4DF890:01C99B12] X-Nokia-AV: Clean Subject: Re: [Simple] msrp-acm and msrp-relay client interworking X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 08:37:08 -0000 On Monday 02 March 2009 06:24:11 ext Hisham Khartabil wrote: > Hi All, > > There seems to be an online debate on how strong a requirement is that > an msrp-acm client must be able to communicate with an msrp-relay > client using an MSRP session set up using SIP/SDP as signalling > protocols. This is a poll requesting input to see if this is indeed a > requirement. Please reply directly tot he mailing list. As Hadriel said, and as I mentioned on this mailing list and on BEHAVE on=20 several occasions, multiplexing independent bulk transfers over hop-by-hop = TCP=20 is a *BAD* idea. To me, MSRP relays are broken -beyond repair- by design. I would not mind i= f=20 MSRP-ACM does not interwork with those. A fortiori, I would really not care= if=20 those two can be made interwork albeit with some non-IETF architecture=20 components. I anyway believe MSRP relays don't exist except as spec and prototypes. =2D-=20 R=E9mi Denis-Courmont Maemo Software, Nokia Devices R&D From miguel.a.garcia@ericsson.com Mon Mar 2 06:43:05 2009 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 AAFF23A689C for ; Mon, 2 Mar 2009 06:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qg3QI6u1USf3 for ; Mon, 2 Mar 2009 06:43:04 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 741473A6818 for ; Mon, 2 Mar 2009 06:43:04 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1254E2157B; Mon, 2 Mar 2009 15:43:29 +0100 (CET) X-AuditID: c1b4fb3e-ae89fbb0000023da-bf-49abf0907944 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A546721541; Mon, 2 Mar 2009 15:43:28 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Mar 2009 15:43:28 +0100 Received: from [159.107.26.155] ([159.107.26.155]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Mar 2009 15:43:28 +0100 Message-ID: <49ABF08F.9040001@ericsson.com> Date: Mon, 02 Mar 2009 15:43:27 +0100 From: "Miguel A. Garcia" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Hadriel Kaplan References: <1B48F5CF-A504-423B-8DDD-6E8667A3B887@estacado.net> <5036B2F7-3C21-4296-B92B-9D3F2B5E8601@estacado.net> <76CDAA7F-C8D5-4D1B-89F7-AF5FB2916799@estacado.net> <66cd252f0903011839g6b51f93ahb09f0ad7a95cceea@mail.gmail.com> <66cd252f0903012020n4958fab0wa6b5d85f47d59fea@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Mar 2009 14:43:28.0226 (UTC) FILETIME=[3FCDA420:01C99B45] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] msrp-acm: Using MSRP with SBCs/ALGs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 14:43:05 -0000 I am leaning towards the solution pointed below by Christer. Facts: - While we have indications that MSRP relays will not ever take, there is one weak signal of it (msrprelay.org) which deserves our respect. - Those architectures who could have embraced MSRP relays decided to do something else (a la MSRP ACM). - The industry in general is reluctant to use special mechanisms for NAT traversal with MSRP, and is willing to use existing general mechanisms. So, I think MSRP ACM has to move forward, and it has to provide a mechanism to interoperate with MSRP relays. This is going to be an update to the MSRP relay spec., similarly to what many RFCs do with their canonical specifications. /Miguel Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Monday, March 02, 2009 1:03 AM >> >> One way of making it work is to use a B2BUA which does interworking >> between msrp-acm and msrp-relay. >> >> I think that would be a satisfying solution, considerering the relay >> deployment situation. > > Sure, I'm cool with that if it will move us forward. > > -hadriel > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ag@ag-projects.com Mon Mar 2 11:10:05 2009 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 AE33A3A688C for ; Mon, 2 Mar 2009 11:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hvlhq9-4XT2m for ; Mon, 2 Mar 2009 11:09:58 -0800 (PST) Received: from node05.dns-hosting.info (node05.dns-hosting.info [85.17.186.5]) by core3.amsl.com (Postfix) with ESMTP id 74DAB3A6804 for ; Mon, 2 Mar 2009 11:09:56 -0800 (PST) Received: from mit.xs4all.nl ([80.101.96.20] helo=[192.168.1.6]) by node05.dns-hosting.info with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.68) (envelope-from ) id 1LeDQx-00030b-BZ for simple@ietf.org; Mon, 02 Mar 2009 20:04:14 +0100 Message-Id: From: Adrian Georgescu To: simple@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-2-15773112 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 2 Mar 2009 20:10:10 +0100 X-Mailer: Apple Mail (2.930.3) X-SA-Exim-Connect-IP: 80.101.96.20 X-SA-Exim-Mail-From: ag@ag-projects.com X-SA-Exim-Version: 4.2.1 (built Tue, 21 Aug 2007 23:39:36 +0000) X-SA-Exim-Scanned: Yes (on node05.dns-hosting.info) Subject: [Simple] Launch of SIP MSRP chatserver X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 19:10:05 -0000 --Apple-Mail-2-15773112 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hello, There is new SIP server software available for multi-party IM chat. =20 SIP chatserver is an open source conference bridge that supports MSRP =20= chat sessions. It can be used for ad-hoc conferencing by SIP end-=20 points. The software is provided under the GPL LICENSE. Features The server implements relevant features from the following standards: =95 MSRP protocol RFC4975 =95 MSRP ad-hoc multi-party chat sessions = draft-ietf-simple-chat-03 =95 Common Presence and Instant Messaging (CPIM): Message Format = RFC3862 =95 Framework for Conferencing with the Session Initiation = Protocol =20 (SIP) RFC4353 =95 Framework for Centralized Conferencing = draft-ietf-xcon-framework-11 =95 Conference event package RFC4575 Support The project is developed and supported by AG Projects. The support is =20= provided on a best-effort basis. "best-effort" means that we try to =20 solve the bugs you report or help fix your problems as soon as we can, =20= subject to available resources. To request support you must use the =20 mailing list available at = http://lists.ag-projects.com/mailman/listinfo/sipchatserver=20 . Patches and bug reports must be submitted by opening a ticket at = http://chatserver.ag-projects.com/newticket Installation instructions are available at: http://chatserver.ag-projects.com/wiki/Installation Credits The development of SIP chatserver has been sponsored by NLNet =20 foundation http://nlnet.nl Kind regards, Adrian Georgescu --Apple-Mail-2-15773112 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hello,

There is new SIP = server software available for multi-party IM chat. SIP chatserver is an = open source conference bridge that supports MSRP chat sessions. It can = be used for ad-hoc conferencing by SIP end-points. The software is = provided under the GPL LICENSE.

Features

The server = implements relevant features from the following standards:

=95 MSRP = protocol RFC4975
=95 MSRP ad-hoc multi-party chat = sessions draft-ietf-simple-chat-03
=95 Common Presence and Instant = Messaging (CPIM): Message Format RFC3862
=95 Framework for Conferencing = with the Session Initiation Protocol (SIP) RFC4353
=95 = Framework for Centralized Conferencing = draft-ietf-xcon-framework-11
=95 Conference event package = RFC4575

Support

The project is developed and supported by = AG Projects. The support is provided on a best-effort basis. = "best-effort" means that we try to solve the bugs you report or help fix = your problems as soon as we can, subject to available resources. To = request support you must use the mailing list available at http:= //lists.ag-projects.com/mailman/listinfo/sipchatserver. Patches and = bug reports must be submitted by opening a ticket at http://chatserver.ag-= projects.com/newticket

Installation instructions are = available at:

http://chatse= rver.ag-projects.com/wiki/Installation

Credits

The = development of SIP chatserver has been sponsored by NLNet foundation http://nlnet.nl


Kind = regards,

Adrian Georgescu


= --Apple-Mail-2-15773112-- From wwwrun@core3.amsl.com Mon Mar 2 10:08:44 2009 Return-Path: X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 30D5528C2AD; Mon, 2 Mar 2009 10:08:44 -0800 (PST) To: eburger@standardstrack.com,hisham.khartabil@gmail.com From: IETF Secretariat Message-Id: <20090302180844.30D5528C2AD@core3.amsl.com> Date: Mon, 2 Mar 2009 10:08:44 -0800 (PST) X-Mailman-Approved-At: Mon, 02 Mar 2009 12:42:53 -0800 Cc: fluffy@cisco.com, jon.peterson@neustar.biz, simple@ietf.org, ipr-announce@ietf.org Subject: [Simple] Posting of IPR Disclosure X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 18:08:44 -0000 Dear Eric Burger, Hisham Khartabil: An IPR disclosure that pertains to your RFC entitled "Instant Message Disposition Notification (IMDN)" (RFC5438) was submitted to the IETF Secretariat on 2009-03-01 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/public/ipr_list.cgi). The title of the IPR disclosure is "Nokia Corporation's Statement about IPR related to RFC 5438." The IETF Secretariat From rjsparks@nostrum.com Tue Mar 3 08:51:11 2009 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 CC50C3A69FC for ; Tue, 3 Mar 2009 08:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jc7ItOVF1IYR for ; Tue, 3 Mar 2009 08:51:06 -0800 (PST) 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 347043A6911 for ; Tue, 3 Mar 2009 08:51:05 -0800 (PST) Received: from dn3-232.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 n23GpScT084204 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 3 Mar 2009 10:51:31 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-Id: <7139249E-A044-4349-9AB0-B25DE497899C@nostrum.com> From: Robert Sparks To: simple mailing list Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Mar 2009 10:51:28 -0600 X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9065/Tue Mar 3 04:43:41 2009 on shaman.nostrum.com X-Virus-Status: Clean Subject: [Simple] Registration for SIPit 24 is open 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, 03 Mar 2009 16:51:11 -0000 Registration for SIPit 24 is open! SIPit 24 will be held May 18-22, 2009 in Akihabara, Tokyo, Japan hosted by JPNIC and NICT. Additional information is available at http://www.sipit.net and http://www.nic.ad.jp/en/sipit24/ From ben@estacado.net Tue Mar 3 12:46:06 2009 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 1C0413A684A for ; Tue, 3 Mar 2009 12:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkCO-hjOEOrT for ; Tue, 3 Mar 2009 12:46:05 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id C0DB83A69CE for ; Tue, 3 Mar 2009 12:46:04 -0800 (PST) Received: from [10.0.1.197] (adsl-68-94-20-58.dsl.rcsntx.swbell.net [68.94.20.58]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n23KkNNR058929 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Mar 2009 14:46:28 -0600 (CST) (envelope-from ben@estacado.net) Message-Id: <76B54C3F-103E-4A95-B1C3-5E460E24A93F@estacado.net> From: Ben Campbell To: Hisham Khartabil In-Reply-To: <66cd252f0903012024v6550c6edv83234fe2bd07fd34@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Mar 2009 14:46:23 -0600 References: <66cd252f0903012024v6550c6edv83234fe2bd07fd34@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: Simple WG Subject: Re: [Simple] msrp-acm and msrp-relay client interworking 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, 03 Mar 2009 20:46:06 -0000 Registering my vote, before responding to other entries on the thread: I vote yes. I don't want to encourage people to deploy islands of non- interoperable endpoints. If they want that for policy reasons, fine, but it should not happen due to technological reasons. If we go down the path of the current ACM draft, we will almost certainly get the scenario where my provider forces me to use a relay, and your provider forces you to use an SBC, and we therefore can't talk. On Mar 1, 2009, at 10:24 PM, Hisham Khartabil wrote: > Hi All, > > There seems to be an online debate on how strong a requirement is that > an msrp-acm client must be able to communicate with an msrp-relay > client using an MSRP session set up using SIP/SDP as signalling > protocols. This is a poll requesting input to see if this is indeed a > requirement. Please reply directly tot he mailing list. > > Thanks, > Hisham > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@estacado.net Tue Mar 3 12:58:49 2009 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 DB2863A69C4 for ; Tue, 3 Mar 2009 12:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfJVJbk3VXjA for ; Tue, 3 Mar 2009 12:58:49 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 8E6223A69A0 for ; Tue, 3 Mar 2009 12:58:48 -0800 (PST) Received: from [10.0.1.197] (adsl-68-94-20-58.dsl.rcsntx.swbell.net [68.94.20.58]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n23Kx1ic061038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Mar 2009 14:59:06 -0600 (CST) (envelope-from ben@estacado.net) Message-Id: <8B79F05E-4706-4F69-B518-70410FF0FC4B@estacado.net> From: Ben Campbell To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Mar 2009 14:59:01 -0600 References: <66cd252f0903012024v6550c6edv83234fe2bd07fd34@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: Simple WG Subject: Re: [Simple] msrp-acm and msrp-relay client interworking 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, 03 Mar 2009 20:58:49 -0000 On Mar 2, 2009, at 12:04 AM, Christer Holmberg wrote: > > Hi, > > It can be done with an interworking B2BUA. > I think it can also be done with a minor modification to the way MSRP endpoint map incoming messages to sessions. I'm not sure this works, but it's worth exploring. I've mentioned this in other threads, but to recap: The endpoint currently maps a message to sessions by matching the URI in the To-Path of an inbound message to the URI that endpoint published in SDP. This prevents an ALG/SBC from modifying the addressing info in the SDP. I think we could modify this so that the endpoint ignores the "address" part of the URI and just matches the "session-ID" part and have little to no affect on the security properties of the URI. This has the advantage than an intermediary could rewrite the URI in the same way the ACM draft encourages rewriting of the C-line, but also working with a peer that uses an msrp relay. As far as I can tell, it has two disadvantages. The first is, existing SBC code doesn't do this now, so implementers would have to touch code. I think it is worth this if it allows MSRP relay compatibility without requiring a b2bua. (I'll leave the argument about the difficulty of guarantying backwards-compatibility with non- standardized devices to the imagination of the reader.) The second issue is that this sort of rewrite can interfere with TLS certificate matching. However, I think this will also be true if we follow the ACM draft, and an SBC rewrites the C-line. This part needs further study. > Regards, > > Christer > > >> -----Original Message----- >> From: simple-bounces@ietf.org >> [mailto:simple-bounces@ietf.org] On Behalf Of Hisham Khartabil >> Sent: 2. maaliskuuta 2009 6:24 >> To: Simple WG >> Subject: [Simple] msrp-acm and msrp-relay client interworking >> >> Hi All, >> >> There seems to be an online debate on how strong a >> requirement is that an msrp-acm client must be able to >> communicate with an msrp-relay client using an MSRP session >> set up using SIP/SDP as signalling protocols. This is a poll >> requesting input to see if this is indeed a requirement. >> Please reply directly tot he mailing list. >> >> Thanks, >> Hisham >> _______________________________________________ >> 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@estacado.net Tue Mar 3 13:18:41 2009 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 4E5373A695A for ; Tue, 3 Mar 2009 13:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jf7THb3Vf4Gf for ; Tue, 3 Mar 2009 13:18:40 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 881E23A6991 for ; Tue, 3 Mar 2009 13:18:39 -0800 (PST) Received: from [10.0.1.197] (adsl-68-94-20-58.dsl.rcsntx.swbell.net [68.94.20.58]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n23LIutG064312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Mar 2009 15:19:00 -0600 (CST) (envelope-from ben@estacado.net) Message-Id: <0B88CBFF-C635-4904-89D1-13C85636D378@estacado.net> From: Ben Campbell To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Mar 2009 15:18:56 -0600 References: <66cd252f0903012024v6550c6edv83234fe2bd07fd34@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: Simple WG Subject: Re: [Simple] msrp-acm and msrp-relay client interworking 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, 03 Mar 2009 21:18:41 -0000 On Mar 2, 2009, at 12:05 AM, Hadriel Kaplan wrote: > > Well if you're going to ask for a vote on that, I suppose it's only > fair that I actually argue *why* I don't think it's a requirement. > First, I vote "no" it's not a requirement. > > And here's my rationale: > 1) The MSRP Relay idea was actually a bad idea. Think about it. > You're creating a protocol to not only send instant-messages now and > then in an IM session, but to in fact transfer files - possibly > really BIG files. There are a bunch of folks that want to do that > with MSRP. Some of them are even delay-sensitive, like white- > boarding and remote GUI control. Would you perform bulk file > transfer through application-layer relays? Note this isn't a socket > relay - but actual signaling relays that terminate TLS/TCP, parse > text messages, and route each chunk/message using what effectively > amounts to a SIP Via/Route list inside the message. You might as > well have just sent hundreds of SIP MESSAGE requests with binary > MIME attached payloads of the chunks. It's a really bad protocol > idea. Lots of this comes from the requirement for connection sharing. There was work group consensus that this was a requirement. That consensus was tested over and over. We also had consensus that MSRP relays needed to be able to act as policy enforcement points and/or message loggers. This was for things like trading-floor applications that are heavily regulated. I'm not saying everyone needs those things. But if we don't require interoperability, then anyone who really needs relays is effectively prevented from deploying them. (I assume communicating with other MSRP users is a pretty big requirement for MSRP deployments.) > > > 2) The main driver for MSRP Relays, as far as I can tell, is to > cross NATs. Even if you don't like how SBC's do that, it doesn't > take a super-genius to figure out TURN at least is a better protocol > for this than MSRP Relays. If you're using TURN, you don't need > MSRP Relays. I think TURN-TCP is a fine choice if you don't need any of the other features of MSRP relays. Furthermore, it should be able to interop with 4975 relays. Furthermore, I don't think it requires the ACM draft to work (although the comedia parts would make it cleaner.) I suspect this is true of other relay protocols such as SOCKS. > > > 3) One of the reasons (in fact the only reason, IMHO) to support > MSRP Relays is because of the installed base. I appreciate that, a > lot. Interworking with an installed base is something I like, > because it means more people using it, which means wider and faster > adoption, which is more money for me in the end (I hope). But there > isn't an installed base. I don't know how to say this without > sounding like a jerk, but if the msrprelay.org site only has 50,000 > users, then it's basically a field trial in east-Latvia for some of > us. Compare it to the 50 *Million* Jabber/XMPP users. And as far > as I've heard that MSRP-Relay project is the big one. If their goal > is to help NAT traversal of MSRP, a TURN server project would do it > - and would be usable for things other than MSRP. As MSRP goes right now, 50K is a big number. It's a fairly new protocol. The number of jabber users is really a non-sequitur here, unless we want to argue about whether one should use MSRP _at_all_. A more fair comparison would be the number of MSRP capable UAs that sit behind SBCs. Or even users behind SBCs that would actually use MSRP in the near future if it worked over the SBC. > > > 4) What msrp-acm is proposing is NOT to deprecate RFC 4976. If > people want to use Relays, that's cool. Clients can continue to > support it as well. All msrp-acm is doing is offering a different > relay model, for those who wish to use it. And the market can > decide if one is more useful, or both can be used. That is > *actually* the IETF way. RFC 4976 is a Proposed Standard, nothing > more. It's not gospel. We don't have to have one and only one way > to use MSRP, and we're not constrained from making changes to it. > And luckily we actually have a capability advertisement protocol > (SDP) at our disposal to negotiate which mode. It would be one > thing if we were talking about HTTP or SIP - something with a very > large installed base, and a long history of use. But with MSRP > Relays we're not. Not by a long shot. We keep saying that no one is advocating we deprecate RFC 4976. Is it better to consign it to a technology ghetto? The effect is pretty much the same--an implicit deprecation is still a deprecation, even if we pretend it's not. > > > -hadriel > >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >> Behalf >> Of Hisham Khartabil >> >> There seems to be an online debate on how strong a requirement is >> that >> an msrp-acm client must be able to communicate with an msrp-relay >> client using an MSRP session set up using SIP/SDP as signalling >> protocols. This is a poll requesting input to see if this is indeed a >> requirement. Please reply directly tot he mailing list. >> >> Thanks, >> Hisham >> _______________________________________________ >> 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 HKaplan@acmepacket.com Tue Mar 3 19:08:09 2009 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 36FC83A6B57 for ; Tue, 3 Mar 2009 19:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCa7xfKfbl3m for ; Tue, 3 Mar 2009 19:08:08 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 2A4853A6B54 for ; Tue, 3 Mar 2009 19:07:54 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 3 Mar 2009 22:08:20 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 3 Mar 2009 22:08:20 -0500 From: Hadriel Kaplan To: Ben Campbell Date: Tue, 3 Mar 2009 22:08:11 -0500 Thread-Topic: [Simple] msrp-acm and msrp-relay client interworking Thread-Index: AcmcRbp9ufKHblfqT1S4K33bCxQFRwAKIUeA Message-ID: References: <66cd252f0903012024v6550c6edv83234fe2bd07fd34@mail.gmail.com> <0B88CBFF-C635-4904-89D1-13C85636D378@estacado.net> In-Reply-To: <0B88CBFF-C635-4904-89D1-13C85636D378@estacado.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simple WG Subject: Re: [Simple] msrp-acm and msrp-relay client interworking 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, 04 Mar 2009 03:08:09 -0000 > -----Original Message----- > From: Ben Campbell [mailto:ben@estacado.net] > Sent: Tuesday, March 03, 2009 4:19 PM > > Lots of this comes from the requirement for connection sharing. There > was work group consensus that this was a requirement. That consensus > was tested over and over. I'm not sure I understand what you mean by that. Who needs connection shar= ing? The MSRP UA? It's only sharing the TCP socket, but each MSRP session= is still unique within it, no? People were worried about the number of TC= P connections for IM on a UA?? Compared with what AJAX and normal web brow= sing uses at any given time?? Maybe you mean for the MSRP Relay's benefit? But that's a circular argumen= t. > We also had consensus that MSRP relays > needed to be able to act as policy enforcement points and/or message > loggers. This was for things like trading-floor applications that are > heavily regulated. You don't need a Relay for that, either. And in fact I seriously doubt an = MSRP Relay is even sufficient for their needs. The trading floor folks I'v= e talked to refuse to allow trading partners learn the IP Addresses of the = trading consoles or PCs of other traders. You can probably imagine why tha= t would be. So they won't be letting the URL's identify the UA's, as is do= ne in the RFC. More importantly, they also need to monitor the SIP signali= ng associated with the session, and bind the two together in the logs, so a= t the end of the day what they really need is an MSRP B2BUA, controlled by = the SIP signaling. Now maybe its just paranoid folks I talk to, but my poi= nt is if you're in a type of situation that requires that level of control,= you're probably not going to just use a simple Relay model anyway. (that'= s in fact why draft-macdonald-simple-msrp-opaque-path-00 was written, to le= t the UA get privacy by anonymizing the MSRP URL's) > As MSRP goes right now, 50K is a big number. It's a fairly new protocol. > The number of jabber users is really a non-sequitur here, unless we > want to argue about whether one should use MSRP _at_all_. A more > fair comparison would be the number of MSRP capable UAs that sit > behind SBCs. Or even users behind SBCs that would actually use MSRP in > the near future if it worked over the SBC. Well I can't speak for how many are MSRP-capable today, because I don't mak= e endpoints. I do know of one softclient vendor that is deployed behind SB= C's that has MSRP in a recent software release, but I don't know how many o= f that release they've shipped, or how many of them are behind SBCs. I als= o know of at least one mobile handset vendor that wants to add MSRP, and th= ey're behind SBCs. And I know of at least two operators that want to use M= SRP, but can't do so without ACM. Each one of them represents far more tha= n 50k users (orders of magnitude more users, but I don't know how many will= do MSRP). But as for total SIP UA endpoints behind SBC's, it's orders of = magnitudes greater than 50k today. Even just softclients it's at least one= order of magnitude greater, maybe more. On the Service Provider side, acc= ess-side SBC's typically range anywhere from 10k-200k SIP UA's per system (= and some a lot more than that now). I only work for one of many SBC vendor= s, but even we've sold several thousands of SBC's, and the rate is increasi= ng. -hadriel From HKaplan@acmepacket.com Tue Mar 3 19:41:05 2009 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 F29993A6867 for ; Tue, 3 Mar 2009 19:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Go-jzclzubQk for ; Tue, 3 Mar 2009 19:41:04 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 0CB3A3A684C for ; Tue, 3 Mar 2009 19:41:04 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 3 Mar 2009 22:41:30 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 3 Mar 2009 22:41:28 -0500 From: Hadriel Kaplan To: Ben Campbell , Christer Holmberg Date: Tue, 3 Mar 2009 22:41:26 -0500 Thread-Topic: [Simple] msrp-acm and msrp-relay client interworking Thread-Index: AcmcQuxSXA/gETdkRbmVPvykG1ua+gAM71Lw Message-ID: References: <66cd252f0903012024v6550c6edv83234fe2bd07fd34@mail.gmail.com> <8B79F05E-4706-4F69-B518-70410FF0FC4B@estacado.net> In-Reply-To: <8B79F05E-4706-4F69-B518-70410FF0FC4B@estacado.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simple WG Subject: Re: [Simple] msrp-acm and msrp-relay client interworking 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, 04 Mar 2009 03:41:05 -0000 > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Ben Campbell > Sent: Tuesday, March 03, 2009 3:59 PM > > I think it can also be done with a minor modification to the way MSRP > endpoint map incoming messages to sessions. I'm not sure this works, > but it's worth exploring. I've mentioned this in other threads, but to > recap: > The endpoint currently maps a message to sessions by matching the URI > in the To-Path of an inbound message to the URI that endpoint > published in SDP. This prevents an ALG/SBC from modifying the > addressing info in the SDP. I think we could modify this so that the > endpoint ignores the "address" part of the URI and just matches the > "session-ID" part and have little to no affect on the security > properties of the URI. > This has the advantage than an intermediary could rewrite the URI in > the same way the ACM draft encourages rewriting of the C-line, but > also working with a peer that uses an msrp relay. This still requires the MSRP UA *and* the MSRP Relay to change from current= behavior, no? The MSRP Relay will be getting a from-path URL in the MSRP = Message of the remote UA that does not match the remote IP/port info for th= e socket, because the remote IP/port of the socket would be the SBC's. If changing current Relay behavior is in-scope, then this would be easy I t= hink. As would privacy-anonymization, for that matter. > As far as I can tell, it has two disadvantages. The first is, existing > SBC code doesn't do this now, so implementers would have to touch > code. I think it is worth this if it allows MSRP relay compatibility > without requiring a b2bua. That's not a problem for my particular company's SBCs (you can just configu= re us to do that, with no code changes). It's not as good as the current A= CM because that didn't even need configuration changes for current deployme= nts, but that's life. But I can't speak for the other vendors. Many of th= em don't even seem to monitor the IETF lists. :( > The second issue is that this sort of rewrite can interfere with TLS > certificate matching. However, I think this will also be true if we > follow the ACM draft, and an SBC rewrites the C-line. This part needs > further study. I know we're successfully supporting Comedia-TLS in deployments, letting th= e TLS go end-end being relayed by the SBC. But those are undoubtedly witho= ut SAN verification, since they rarely even have SAN's. I thought MSRP als= o ultimately ignored the SAN and used the SDP fingerprint instead, no? -hadriel From ben@estacado.net Tue Mar 3 19:46:56 2009 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 74E8D3A6891 for ; Tue, 3 Mar 2009 19:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iitOQFFOcik9 for ; Tue, 3 Mar 2009 19:46:55 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 007EC3A684C for ; Tue, 3 Mar 2009 19:46:54 -0800 (PST) Received: from [10.0.1.197] (adsl-68-94-20-58.dsl.rcsntx.swbell.net [68.94.20.58]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n243l9KN062104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Mar 2009 21:47:14 -0600 (CST) (envelope-from ben@estacado.net) Message-Id: <88AEFA00-124B-48E8-8810-A45C865E715A@estacado.net> From: Ben Campbell To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Mar 2009 21:47:09 -0600 References: <66cd252f0903012024v6550c6edv83234fe2bd07fd34@mail.gmail.com> <0B88CBFF-C635-4904-89D1-13C85636D378@estacado.net> X-Mailer: Apple Mail (2.930.3) Cc: Simple WG Subject: Re: [Simple] msrp-acm and msrp-relay client interworking 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, 04 Mar 2009 03:46:56 -0000 On Mar 3, 2009, at 9:08 PM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@estacado.net] >> Sent: Tuesday, March 03, 2009 4:19 PM >> >> Lots of this comes from the requirement for connection sharing. There >> was work group consensus that this was a requirement. That consensus >> was tested over and over. > > I'm not sure I understand what you mean by that. Who needs > connection sharing? The MSRP UA? It's only sharing the TCP socket, > but each MSRP session is still unique within it, no? People were > worried about the number of TCP connections for IM on a UA?? > Compared with what AJAX and normal web browsing uses at any given > time?? > > Maybe you mean for the MSRP Relay's benefit? But that's a circular > argument. People we worried about the number of connections between a pair of relays. If you use TURN-TCP at both ends, for example, you have 3 TCP connections per session at each TURN server. Same for a pair of TCP aware SBCs, or MSRP B2BUAs, etc. Is this a problem? It depends on how a given platform scales to massive numbers of TCP connections. Also, at least at the time, a large number of parallel TCP connections was considered to have poorer congestion properties than a smaller number. (Alas, my TCP-fu is not advanced enough for me to have an opinion on the congestion issue--I am merely restating the arguments we had then.) > > > >> We also had consensus that MSRP relays >> needed to be able to act as policy enforcement points and/or message >> loggers. This was for things like trading-floor applications that are >> heavily regulated. > > You don't need a Relay for that, either. And in fact I seriously > doubt an MSRP Relay is even sufficient for their needs. The trading > floor folks I've talked to refuse to allow trading partners learn > the IP Addresses of the trading consoles or PCs of other traders. > You can probably imagine why that would be. So they won't be > letting the URL's identify the UA's, as is done in the RFC. More > importantly, they also need to monitor the SIP signaling associated > with the session, and bind the two together in the logs, so at the > end of the day what they really need is an MSRP B2BUA, controlled by > the SIP signaling. Now maybe its just paranoid folks I talk to, but > my point is if you're in a type of situation that requires that > level of control, you're probably not going to just use a simple > Relay model anyway. (that's in fact why draft-macdonald-simple-msrp- > opaque-path-00 was written, to let the UA get privacy by anonymizing > the MSRP URL's) I'm not saying that MSRP relays necessarily support all the features that a particular market needs--I expect there to be many extensions to both RFCs before the dust settles. My point was that the features we considered at the time required it to operate at the application layer. That is, it had to know how to parse MSRP rather than merely shuffle bytes. But to restate my earlier point: If all a deployment needs is relay- assisted NAT traversal, and TCP connection scaling is not a concern, then I think TURN-TCP is an excellent solution. But that's not what the ACM draft is about. > > > >> As MSRP goes right now, 50K is a big number. It's a fairly new >> protocol. >> The number of jabber users is really a non-sequitur here, unless we >> want to argue about whether one should use MSRP _at_all_. A more >> fair comparison would be the number of MSRP capable UAs that sit >> behind SBCs. Or even users behind SBCs that would actually use MSRP >> in >> the near future if it worked over the SBC. > > Well I can't speak for how many are MSRP-capable today, because I > don't make endpoints. I do know of one softclient vendor that is > deployed behind SBC's that has MSRP in a recent software release, > but I don't know how many of that release they've shipped, or how > many of them are behind SBCs. I also know of at least one mobile > handset vendor that wants to add MSRP, and they're behind SBCs. And > I know of at least two operators that want to use MSRP, but can't do > so without ACM. Each one of them represents far more than 50k users > (orders of magnitude more users, but I don't know how many will do > MSRP). But as for total SIP UA endpoints behind SBC's, it's orders > of magnitudes greater than 50k today. Even just softclients it's at > least one order of magnitude greater, maybe more. On the Service > Provider side, access-side SBC's typically range anywhere from > 10k-200k SIP UA's per system (and some a lot more than that now). I > only work for one of many SBC vendors, but even we've sold several > thousands of SBC's, and the rate is increasing. > > -hadriel From ben@estacado.net Tue Mar 3 20:03:58 2009 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 A4FE33A6985 for ; Tue, 3 Mar 2009 20:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIXEaArq0uxw for ; Tue, 3 Mar 2009 20:03:57 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 3F3B03A6968 for ; Tue, 3 Mar 2009 20:03:57 -0800 (PST) Received: from [10.0.1.197] (adsl-68-94-20-58.dsl.rcsntx.swbell.net [68.94.20.58]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n2444DB7064831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Mar 2009 22:04:18 -0600 (CST) (envelope-from ben@estacado.net) Message-Id: <27A11C2B-4606-4E0D-A8EF-7B0DABD89BFF@estacado.net> From: Ben Campbell To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Mar 2009 22:04:13 -0600 References: <66cd252f0903012024v6550c6edv83234fe2bd07fd34@mail.gmail.com> <8B79F05E-4706-4F69-B518-70410FF0FC4B@estacado.net> X-Mailer: Apple Mail (2.930.3) Cc: Simple WG Subject: Re: [Simple] msrp-acm and msrp-relay client interworking 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, 04 Mar 2009 04:03:58 -0000 On Mar 3, 2009, at 9:41 PM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >> Behalf >> Of Ben Campbell >> Sent: Tuesday, March 03, 2009 3:59 PM >> >> I think it can also be done with a minor modification to the way MSRP >> endpoint map incoming messages to sessions. I'm not sure this works, >> but it's worth exploring. I've mentioned this in other threads, but >> to >> recap: >> The endpoint currently maps a message to sessions by matching the URI >> in the To-Path of an inbound message to the URI that endpoint >> published in SDP. This prevents an ALG/SBC from modifying the >> addressing info in the SDP. I think we could modify this so that the >> endpoint ignores the "address" part of the URI and just matches the >> "session-ID" part and have little to no affect on the security >> properties of the URI. >> This has the advantage than an intermediary could rewrite the URI in >> the same way the ACM draft encourages rewriting of the C-line, but >> also working with a peer that uses an msrp relay. > > This still requires the MSRP UA *and* the MSRP Relay to change from > current behavior, no? The MSRP Relay will be getting a from-path > URL in the MSRP Message of the remote UA that does not match the > remote IP/port info for the socket, because the remote IP/port of > the socket would be the SBC's. > On reflection, I guess it would require rewriting relay URIs as well, so probably yes. > If changing current Relay behavior is in-scope, then this would be > easy I think. As would privacy-anonymization, for that matter. > Revisions for these two purposes seems reasonable to me on the surface, assuming that once we work through the implications, we don't discover that they either just don't work, or cause more harm than good. I am certainly not the final arbiter of what we are allowed to change. > >> As far as I can tell, it has two disadvantages. The first is, >> existing >> SBC code doesn't do this now, so implementers would have to touch >> code. I think it is worth this if it allows MSRP relay compatibility >> without requiring a b2bua. > > That's not a problem for my particular company's SBCs (you can just > configure us to do that, with no code changes). It's not as good as > the current ACM because that didn't even need configuration changes > for current deployments, but that's life. But I can't speak for the > other vendors. Many of them don't even seem to monitor the IETF > lists. :( > > >> The second issue is that this sort of rewrite can interfere with TLS >> certificate matching. However, I think this will also be true if we >> follow the ACM draft, and an SBC rewrites the C-line. This part needs >> further study. > > I know we're successfully supporting Comedia-TLS in deployments, > letting the TLS go end-end being relayed by the SBC. But those are > undoubtedly without SAN verification, since they rarely even have > SAN's. I thought MSRP also ultimately ignored the SAN and used the > SDP fingerprint instead, no? I assume SAN == subjectAltName? 4975 allows self-signed UA certs with the fingerprint (from Comedia- TLS.) It also allows client certs with user identities in the subjectAltName. Either of those should work with either approach. It might be harder for TLS between a client and a relay, though. The relay is expected to have a cert that has a match for its URI in the subjectAltName. I can see that working if the SBC and relay are in the same administrative domain, but it falls down otherwise. That may be a show stopper, or at least needs more thought. > > > -hadriel > From christer.holmberg@ericsson.com Tue Mar 3 22:26:15 2009 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 9A4AA3A6963 for ; Tue, 3 Mar 2009 22:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 OBKtRwptU6KK for ; Tue, 3 Mar 2009 22:26:14 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 705543A6804 for ; Tue, 3 Mar 2009 22:26:14 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E477921076; Wed, 4 Mar 2009 07:26:40 +0100 (CET) X-AuditID: c1b4fb3e-ad09cbb0000023da-00-49ae1f2062d5 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B5916200EC; Wed, 4 Mar 2009 07:26:40 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Mar 2009 07:26:40 +0100 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, 4 Mar 2009 07:26:39 +0100 Message-ID: In-Reply-To: <8B79F05E-4706-4F69-B518-70410FF0FC4B@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] msrp-acm and msrp-relay client interworking Thread-Index: AcmcQubE3YxoaH79Tv+ilCDM4ot64QATlzXA References: <66cd252f0903012024v6550c6edv83234fe2bd07fd34@mail.gmail.com> <8B79F05E-4706-4F69-B518-70410FF0FC4B@estacado.net> From: "Christer Holmberg" To: "Ben Campbell" X-OriginalArrivalTime: 04 Mar 2009 06:26:40.0644 (UTC) FILETIME=[2DED1440:01C99C92] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] msrp-acm and msrp-relay client interworking 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, 04 Mar 2009 06:26:15 -0000 =20 Hi Ben, >>It can be done with an interworking B2BUA. >> >=20 >I think it can also be done with a minor modification to the=20 >way MSRP endpoint map incoming messages to sessions. I'm not=20 >sure this works, but it's worth exploring. I've mentioned=20 >this in other threads, but to >recap: >=20 >The endpoint currently maps a message to sessions by matching=20 >the URI in the To-Path of an inbound message to the URI that=20 >endpoint published in SDP. This prevents an ALG/SBC from=20 >modifying the addressing info in the SDP. I think we could=20 >modify this so that the endpoint ignores the "address" part=20 >of the URI and just matches the "session-ID" part and have=20 >little to no affect on the security properties of the URI. >=20 >This has the advantage than an intermediary could rewrite the=20 >URI in the same way the ACM draft encourages rewriting of the=20 >C-line, but also working with a peer that uses an msrp relay. >=20 >As far as I can tell, it has two disadvantages. The first is,=20 >existing SBC code doesn't do this now, so implementers would=20 >have to touch code. I think it is worth this if it allows=20 >MSRP relay compatibility without requiring a b2bua. (I'll=20 >leave the argument about the difficulty of guarantying=20 >backwards-compatibility with non- standardized devices to the=20 >imagination of the reader.) >=20 >The second issue is that this sort of rewrite can interfere=20 >with TLS certificate matching. However, I think this will=20 >also be true if we follow the ACM draft, and an SBC rewrites=20 >the C-line. This part needs further study. So, just for my clarification: this modified way of mapping incoming messages would be an correction to legacy MSRP endpoints, right? Also, I assume that would be described in a separate draft, since it's not ACM specific? Regards, Christer > >> -----Original Message----- > >> From: simple-bounces@ietf.org > >> [mailto:simple-bounces@ietf.org] On Behalf Of Hisham Khartabil > >> Sent: 2. maaliskuuta 2009 6:24 > >> To: Simple WG > >> Subject: [Simple] msrp-acm and msrp-relay client interworking > >> > >> Hi All, > >> > >> There seems to be an online debate on how strong a requirement is=20 > >> that an msrp-acm client must be able to communicate with an=20 > >> msrp-relay client using an MSRP session set up using SIP/SDP as=20 > >> signalling protocols. This is a poll requesting input to=20 > see if this=20 > >> is indeed a requirement. > >> Please reply directly tot he mailing list. > >> > >> Thanks, > >> Hisham > >> _______________________________________________ > >> 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 >=20 From christer.holmberg@ericsson.com Wed Mar 4 03:15:01 2009 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 9349B3A6B4F for ; Wed, 4 Mar 2009 03:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.743 X-Spam-Level: X-Spam-Status: No, score=-5.743 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 MGGEp12oG58S for ; Wed, 4 Mar 2009 03:15:00 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 5599B3A69F9 for ; Wed, 4 Mar 2009 03:15:00 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3455320BD0; Wed, 4 Mar 2009 12:15:27 +0100 (CET) X-AuditID: c1b4fb3c-aa804bb000001b43-a8-49ae62ce62c8 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DB6682139E; Wed, 4 Mar 2009 12:15:26 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Mar 2009 12:15:25 +0100 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, 4 Mar 2009 12:15:24 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] msrp-acm and msrp-relay client interworking Thread-Index: AcmcQubE3YxoaH79Tv+ilCDM4ot64QATlzXAAApEYvA= References: <66cd252f0903012024v6550c6edv83234fe2bd07fd34@mail.gmail.com><8B79F05E-4706-4F69-B518-70410FF0FC4B@estacado.net> From: "Christer Holmberg" To: "Ben Campbell" X-OriginalArrivalTime: 04 Mar 2009 11:15:25.0599 (UTC) FILETIME=[84676AF0:01C99CBA] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] msrp-acm and msrp-relay client interworking 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, 04 Mar 2009 11:15:01 -0000 Hi, Also, IF we do the message session mapping change, I assume it would be documented as an essential change? Ie we document which parts of the RFC needs to be fixed. Regards, Christer =20 > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 4. maaliskuuta 2009 8:27 > To: Ben Campbell > Cc: Simple WG > Subject: Re: [Simple] msrp-acm and msrp-relay client interworking >=20 > =20 > Hi Ben, >=20 > >>It can be done with an interworking B2BUA. > >> > >=20 > >I think it can also be done with a minor modification to the=20 > way MSRP=20 > >endpoint map incoming messages to sessions. I'm not sure this works,=20 > >but it's worth exploring. I've mentioned this in other=20 > threads, but to > >recap: > >=20 > >The endpoint currently maps a message to sessions by=20 > matching the URI=20 > >in the To-Path of an inbound message to the URI that=20 > endpoint published=20 > >in SDP. This prevents an ALG/SBC from modifying the=20 > addressing info in=20 > >the SDP. I think we could modify this so that the endpoint=20 > ignores the=20 > >"address" part of the URI and just matches the "session-ID" part and=20 > >have little to no affect on the security properties of the URI. > >=20 > >This has the advantage than an intermediary could rewrite the URI in=20 > >the same way the ACM draft encourages rewriting of the=20 > C-line, but also=20 > >working with a peer that uses an msrp relay. > >=20 > >As far as I can tell, it has two disadvantages. The first=20 > is, existing=20 > >SBC code doesn't do this now, so implementers would have to=20 > touch code.=20 > >I think it is worth this if it allows MSRP relay=20 > compatibility without=20 > >requiring a b2bua. (I'll leave the argument about the difficulty of=20 > >guarantying backwards-compatibility with non- standardized=20 > devices to=20 > >the imagination of the reader.) > >=20 > >The second issue is that this sort of rewrite can interfere with TLS=20 > >certificate matching. However, I think this will also be true if we=20 > >follow the ACM draft, and an SBC rewrites the C-line. This=20 > part needs=20 > >further study. >=20 > So, just for my clarification: this modified way of mapping=20 > incoming messages would be an correction to legacy MSRP=20 > endpoints, right? >=20 > Also, I assume that would be described in a separate draft,=20 > since it's not ACM specific? >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 > > >> -----Original Message----- > > >> From: simple-bounces@ietf.org > > >> [mailto:simple-bounces@ietf.org] On Behalf Of Hisham Khartabil > > >> Sent: 2. maaliskuuta 2009 6:24 > > >> To: Simple WG > > >> Subject: [Simple] msrp-acm and msrp-relay client interworking > > >> > > >> Hi All, > > >> > > >> There seems to be an online debate on how strong a=20 > requirement is=20 > > >> that an msrp-acm client must be able to communicate with an=20 > > >> msrp-relay client using an MSRP session set up using SIP/SDP as=20 > > >> signalling protocols. This is a poll requesting input to > > see if this > > >> is indeed a requirement. > > >> Please reply directly tot he mailing list. > > >> > > >> Thanks, > > >> Hisham > > >> _______________________________________________ > > >> 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 > >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From ben@estacado.net Wed Mar 4 07:38:49 2009 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 3944F3A6CD2 for ; Wed, 4 Mar 2009 07:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxgpGIerceyE for ; Wed, 4 Mar 2009 07:38:48 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id AFC1B3A6CC3 for ; Wed, 4 Mar 2009 07:38:47 -0800 (PST) Received: from [10.0.1.197] (adsl-68-94-20-58.dsl.rcsntx.swbell.net [68.94.20.58]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n24Fd3nf079830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Mar 2009 09:39:07 -0600 (CST) (envelope-from ben@estacado.net) Message-Id: <266041AA-3BC3-4754-8632-9B1849B29942@estacado.net> From: Ben Campbell To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Mar 2009 09:39:02 -0600 References: <66cd252f0903012024v6550c6edv83234fe2bd07fd34@mail.gmail.com> <8B79F05E-4706-4F69-B518-70410FF0FC4B@estacado.net> X-Mailer: Apple Mail (2.930.3) Cc: Simple WG Subject: Re: [Simple] msrp-acm and msrp-relay client interworking 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, 04 Mar 2009 15:38:49 -0000 On Mar 4, 2009, at 12:26 AM, Christer Holmberg wrote: > > Hi Ben, > >>> It can be done with an interworking B2BUA. >>> >> >> I think it can also be done with a minor modification to the >> way MSRP endpoint map incoming messages to sessions. I'm not >> sure this works, but it's worth exploring. I've mentioned >> this in other threads, but to >> recap: >> >> The endpoint currently maps a message to sessions by matching >> the URI in the To-Path of an inbound message to the URI that >> endpoint published in SDP. This prevents an ALG/SBC from >> modifying the addressing info in the SDP. I think we could >> modify this so that the endpoint ignores the "address" part >> of the URI and just matches the "session-ID" part and have >> little to no affect on the security properties of the URI. >> >> This has the advantage than an intermediary could rewrite the >> URI in the same way the ACM draft encourages rewriting of the >> C-line, but also working with a peer that uses an msrp relay. >> >> As far as I can tell, it has two disadvantages. The first is, >> existing SBC code doesn't do this now, so implementers would >> have to touch code. I think it is worth this if it allows >> MSRP relay compatibility without requiring a b2bua. (I'll >> leave the argument about the difficulty of guarantying >> backwards-compatibility with non- standardized devices to the >> imagination of the reader.) >> >> The second issue is that this sort of rewrite can interfere >> with TLS certificate matching. However, I think this will >> also be true if we follow the ACM draft, and an SBC rewrites >> the C-line. This part needs further study. > > So, just for my clarification: this modified way of mapping incoming > messages would be an correction to legacy MSRP endpoints, right? > > Also, I assume that would be described in a separate draft, since it's > not ACM specific? Assuming it proves to be worth doing, that's how I would expect things to go. > > > Regards, > > Christer > > > > > > >>>> -----Original Message----- >>>> From: simple-bounces@ietf.org >>>> [mailto:simple-bounces@ietf.org] On Behalf Of Hisham Khartabil >>>> Sent: 2. maaliskuuta 2009 6:24 >>>> To: Simple WG >>>> Subject: [Simple] msrp-acm and msrp-relay client interworking >>>> >>>> Hi All, >>>> >>>> There seems to be an online debate on how strong a requirement is >>>> that an msrp-acm client must be able to communicate with an >>>> msrp-relay client using an MSRP session set up using SIP/SDP as >>>> signalling protocols. This is a poll requesting input to >> see if this >>>> is indeed a requirement. >>>> Please reply directly tot he mailing list. >>>> >>>> Thanks, >>>> Hisham >>>> _______________________________________________ >>>> 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@estacado.net Wed Mar 4 07:40:01 2009 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 CC9953A6CD2 for ; Wed, 4 Mar 2009 07:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDP62KIgtuwI for ; Wed, 4 Mar 2009 07:40:00 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id B8FD93A6CD5 for ; Wed, 4 Mar 2009 07:39:59 -0800 (PST) Received: from [10.0.1.197] (adsl-68-94-20-58.dsl.rcsntx.swbell.net [68.94.20.58]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n24FeJQN080101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Mar 2009 09:40:24 -0600 (CST) (envelope-from ben@estacado.net) Message-Id: From: Ben Campbell To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Mar 2009 09:40:19 -0600 References: <66cd252f0903012024v6550c6edv83234fe2bd07fd34@mail.gmail.com><8B79F05E-4706-4F69-B518-70410FF0FC4B@estacado.net> X-Mailer: Apple Mail (2.930.3) Cc: Simple WG Subject: Re: [Simple] msrp-acm and msrp-relay client interworking 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, 04 Mar 2009 15:40:01 -0000 On Mar 4, 2009, at 5:15 AM, Christer Holmberg wrote: > > Hi, > > Also, IF we do the message session mapping change, I assume it would > be > documented as an essential change? Ie we document which parts of the > RFC > needs to be fixed. Again assuming we decide this approach is worth pursuing, that is what I had in mind. > > > Regards, > > Christer > > > > >> -----Original Message----- >> From: simple-bounces@ietf.org >> [mailto:simple-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: 4. maaliskuuta 2009 8:27 >> To: Ben Campbell >> Cc: Simple WG >> Subject: Re: [Simple] msrp-acm and msrp-relay client interworking >> >> >> Hi Ben, >> >>>> It can be done with an interworking B2BUA. >>>> >>> >>> I think it can also be done with a minor modification to the >> way MSRP >>> endpoint map incoming messages to sessions. I'm not sure this works, >>> but it's worth exploring. I've mentioned this in other >> threads, but to >>> recap: >>> >>> The endpoint currently maps a message to sessions by >> matching the URI >>> in the To-Path of an inbound message to the URI that >> endpoint published >>> in SDP. This prevents an ALG/SBC from modifying the >> addressing info in >>> the SDP. I think we could modify this so that the endpoint >> ignores the >>> "address" part of the URI and just matches the "session-ID" part and >>> have little to no affect on the security properties of the URI. >>> >>> This has the advantage than an intermediary could rewrite the URI in >>> the same way the ACM draft encourages rewriting of the >> C-line, but also >>> working with a peer that uses an msrp relay. >>> >>> As far as I can tell, it has two disadvantages. The first >> is, existing >>> SBC code doesn't do this now, so implementers would have to >> touch code. >>> I think it is worth this if it allows MSRP relay >> compatibility without >>> requiring a b2bua. (I'll leave the argument about the difficulty of >>> guarantying backwards-compatibility with non- standardized >> devices to >>> the imagination of the reader.) >>> >>> The second issue is that this sort of rewrite can interfere with TLS >>> certificate matching. However, I think this will also be true if we >>> follow the ACM draft, and an SBC rewrites the C-line. This >> part needs >>> further study. >> >> So, just for my clarification: this modified way of mapping >> incoming messages would be an correction to legacy MSRP >> endpoints, right? >> >> Also, I assume that would be described in a separate draft, >> since it's not ACM specific? >> >> Regards, >> >> Christer >> >> >> >> >> >> >>>>> -----Original Message----- >>>>> From: simple-bounces@ietf.org >>>>> [mailto:simple-bounces@ietf.org] On Behalf Of Hisham Khartabil >>>>> Sent: 2. maaliskuuta 2009 6:24 >>>>> To: Simple WG >>>>> Subject: [Simple] msrp-acm and msrp-relay client interworking >>>>> >>>>> Hi All, >>>>> >>>>> There seems to be an online debate on how strong a >> requirement is >>>>> that an msrp-acm client must be able to communicate with an >>>>> msrp-relay client using an MSRP session set up using SIP/SDP as >>>>> signalling protocols. This is a poll requesting input to >>> see if this >>>>> is indeed a requirement. >>>>> Please reply directly tot he mailing list. >>>>> >>>>> Thanks, >>>>> Hisham >>>>> _______________________________________________ >>>>> 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 christer.holmberg@ericsson.com Wed Mar 4 11:13:46 2009 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 9D36D3A68EF for ; Wed, 4 Mar 2009 11:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.714 X-Spam-Level: X-Spam-Status: No, score=-5.714 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 IJ6-AGmYGvCw for ; Wed, 4 Mar 2009 11:13:45 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 5112D3A6819 for ; Wed, 4 Mar 2009 11:13:45 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 649F020731; Wed, 4 Mar 2009 20:14:12 +0100 (CET) X-AuditID: c1b4fb3c-ae80cbb000001b43-8f-49aed3044d8a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3B4062045B; Wed, 4 Mar 2009 20:14:12 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Mar 2009 20:14:11 +0100 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, 4 Mar 2009 20:14:11 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] msrp-acm and msrp-relay client interworking Thread-Index: Acmc34vcpn5akHgkSy6cpcFBiUKWXwAHba3w References: <66cd252f0903012024v6550c6edv83234fe2bd07fd34@mail.gmail.com><8B79F05E-4706-4F69-B518-70410FF0FC4B@estacado.net> From: "Christer Holmberg" To: "Ben Campbell" X-OriginalArrivalTime: 04 Mar 2009 19:14:11.0972 (UTC) FILETIME=[66A81440:01C99CFD] X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] msrp-acm and msrp-relay client interworking 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, 04 Mar 2009 19:13:46 -0000 Ok, Due to the cutoff date I guess it's too late to submit an essential correction draft for this meeting, but nothing prevents us from putting some slides toghether which would show the changes which are needed. Regards, Christer -----Original Message----- From: Ben Campbell [mailto:ben@estacado.net]=20 Sent: Wednesday, March 04, 2009 5:40 PM To: Christer Holmberg Cc: Simple WG Subject: Re: [Simple] msrp-acm and msrp-relay client interworking On Mar 4, 2009, at 5:15 AM, Christer Holmberg wrote: > > Hi, > > Also, IF we do the message session mapping change, I assume it would=20 > be documented as an essential change? Ie we document which parts of=20 > the RFC needs to be fixed. Again assuming we decide this approach is worth pursuing, that is what I had in mind. > > > Regards, > > Christer > > > > >> -----Original Message----- >> From: simple-bounces@ietf.org >> [mailto:simple-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: 4. maaliskuuta 2009 8:27 >> To: Ben Campbell >> Cc: Simple WG >> Subject: Re: [Simple] msrp-acm and msrp-relay client interworking >> >> >> Hi Ben, >> >>>> It can be done with an interworking B2BUA. >>>> >>> >>> I think it can also be done with a minor modification to the >> way MSRP >>> endpoint map incoming messages to sessions. I'm not sure this works, >>> but it's worth exploring. I've mentioned this in other >> threads, but to >>> recap: >>> >>> The endpoint currently maps a message to sessions by >> matching the URI >>> in the To-Path of an inbound message to the URI that >> endpoint published >>> in SDP. This prevents an ALG/SBC from modifying the >> addressing info in >>> the SDP. I think we could modify this so that the endpoint >> ignores the >>> "address" part of the URI and just matches the "session-ID" part and >>> have little to no affect on the security properties of the URI. >>> >>> This has the advantage than an intermediary could rewrite the URI in >>> the same way the ACM draft encourages rewriting of the >> C-line, but also >>> working with a peer that uses an msrp relay. >>> >>> As far as I can tell, it has two disadvantages. The first >> is, existing >>> SBC code doesn't do this now, so implementers would have to >> touch code. >>> I think it is worth this if it allows MSRP relay >> compatibility without >>> requiring a b2bua. (I'll leave the argument about the difficulty of >>> guarantying backwards-compatibility with non- standardized >> devices to >>> the imagination of the reader.) >>> >>> The second issue is that this sort of rewrite can interfere with TLS >>> certificate matching. However, I think this will also be true if we >>> follow the ACM draft, and an SBC rewrites the C-line. This >> part needs >>> further study. >> >> So, just for my clarification: this modified way of mapping >> incoming messages would be an correction to legacy MSRP >> endpoints, right? >> >> Also, I assume that would be described in a separate draft, >> since it's not ACM specific? >> >> Regards, >> >> Christer >> >> >> >> >> >> >>>>> -----Original Message----- >>>>> From: simple-bounces@ietf.org >>>>> [mailto:simple-bounces@ietf.org] On Behalf Of Hisham Khartabil >>>>> Sent: 2. maaliskuuta 2009 6:24 >>>>> To: Simple WG >>>>> Subject: [Simple] msrp-acm and msrp-relay client interworking >>>>> >>>>> Hi All, >>>>> >>>>> There seems to be an online debate on how strong a >> requirement is >>>>> that an msrp-acm client must be able to communicate with an >>>>> msrp-relay client using an MSRP session set up using SIP/SDP as >>>>> signalling protocols. This is a poll requesting input to >>> see if this >>>>> is indeed a requirement. >>>>> Please reply directly tot he mailing list. >>>>> >>>>> Thanks, >>>>> Hisham >>>>> _______________________________________________ >>>>> 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 ben@estacado.net Wed Mar 4 11:39:36 2009 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 6438928C339 for ; Wed, 4 Mar 2009 11:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lXxsklnEUb3 for ; Wed, 4 Mar 2009 11:39:35 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id E58A128C3C1 for ; Wed, 4 Mar 2009 11:39:34 -0800 (PST) Received: from [10.0.1.197] (adsl-68-94-20-58.dsl.rcsntx.swbell.net [68.94.20.58]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n24Jdrc3018968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Mar 2009 13:39:58 -0600 (CST) (envelope-from ben@estacado.net) Message-Id: <8BE2330A-7077-4DD8-818F-98475BB542F3@estacado.net> From: Ben Campbell To: "Christer Holmberg" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Mar 2009 13:39:53 -0600 References: <66cd252f0903012024v6550c6edv83234fe2bd07fd34@mail.gmail.com><8B79F05E-4706-4F69-B518-70410FF0FC4B@estacado.net> X-Mailer: Apple Mail (2.930.3) Cc: Simple WG Subject: Re: [Simple] msrp-acm and msrp-relay client interworking 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, 04 Mar 2009 19:39:36 -0000 On Mar 4, 2009, at 1:14 PM, Christer Holmberg wrote: > > Ok, > > Due to the cutoff date I guess it's too late to submit an essential > correction draft for this meeting, but nothing prevents us from > putting > some slides toghether which would show the changes which are needed. > Agreed. I had hopes to get a draft together by the cutoff, but my schedule got whacked by a badly timed cold virus over the weekend. It might be worth trying to get a f2f meeting of interested parties together in SF prior to the SIMPLE meeting to talk this through. > Regards, > > Christer > > -----Original Message----- > From: Ben Campbell [mailto:ben@estacado.net] > Sent: Wednesday, March 04, 2009 5:40 PM > To: Christer Holmberg > Cc: Simple WG > Subject: Re: [Simple] msrp-acm and msrp-relay client interworking > > > On Mar 4, 2009, at 5:15 AM, Christer Holmberg wrote: > >> >> Hi, >> >> Also, IF we do the message session mapping change, I assume it would >> be documented as an essential change? Ie we document which parts of >> the RFC needs to be fixed. > > Again assuming we decide this approach is worth pursuing, that is > what I > had in mind. > >> >> >> Regards, >> >> Christer >> >> >> >> >>> -----Original Message----- >>> From: simple-bounces@ietf.org >>> [mailto:simple-bounces@ietf.org] On Behalf Of Christer Holmberg >>> Sent: 4. maaliskuuta 2009 8:27 >>> To: Ben Campbell >>> Cc: Simple WG >>> Subject: Re: [Simple] msrp-acm and msrp-relay client interworking >>> >>> >>> Hi Ben, >>> >>>>> It can be done with an interworking B2BUA. >>>>> >>>> >>>> I think it can also be done with a minor modification to the >>> way MSRP >>>> endpoint map incoming messages to sessions. I'm not sure this >>>> works, >>>> but it's worth exploring. I've mentioned this in other >>> threads, but to >>>> recap: >>>> >>>> The endpoint currently maps a message to sessions by >>> matching the URI >>>> in the To-Path of an inbound message to the URI that >>> endpoint published >>>> in SDP. This prevents an ALG/SBC from modifying the >>> addressing info in >>>> the SDP. I think we could modify this so that the endpoint >>> ignores the >>>> "address" part of the URI and just matches the "session-ID" part >>>> and >>>> have little to no affect on the security properties of the URI. >>>> >>>> This has the advantage than an intermediary could rewrite the URI >>>> in >>>> the same way the ACM draft encourages rewriting of the >>> C-line, but also >>>> working with a peer that uses an msrp relay. >>>> >>>> As far as I can tell, it has two disadvantages. The first >>> is, existing >>>> SBC code doesn't do this now, so implementers would have to >>> touch code. >>>> I think it is worth this if it allows MSRP relay >>> compatibility without >>>> requiring a b2bua. (I'll leave the argument about the difficulty of >>>> guarantying backwards-compatibility with non- standardized >>> devices to >>>> the imagination of the reader.) >>>> >>>> The second issue is that this sort of rewrite can interfere with >>>> TLS >>>> certificate matching. However, I think this will also be true if we >>>> follow the ACM draft, and an SBC rewrites the C-line. This >>> part needs >>>> further study. >>> >>> So, just for my clarification: this modified way of mapping >>> incoming messages would be an correction to legacy MSRP >>> endpoints, right? >>> >>> Also, I assume that would be described in a separate draft, >>> since it's not ACM specific? >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>> >>>>>> -----Original Message----- >>>>>> From: simple-bounces@ietf.org >>>>>> [mailto:simple-bounces@ietf.org] On Behalf Of Hisham Khartabil >>>>>> Sent: 2. maaliskuuta 2009 6:24 >>>>>> To: Simple WG >>>>>> Subject: [Simple] msrp-acm and msrp-relay client interworking >>>>>> >>>>>> Hi All, >>>>>> >>>>>> There seems to be an online debate on how strong a >>> requirement is >>>>>> that an msrp-acm client must be able to communicate with an >>>>>> msrp-relay client using an MSRP session set up using SIP/SDP as >>>>>> signalling protocols. This is a poll requesting input to >>>> see if this >>>>>> is indeed a requirement. >>>>>> Please reply directly tot he mailing list. >>>>>> >>>>>> Thanks, >>>>>> Hisham >>>>>> _______________________________________________ >>>>>> 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 eburger@standardstrack.com Wed Mar 4 18:03:37 2009 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 EA93F28C1B5 for ; Wed, 4 Mar 2009 18:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18JtrO4xZMdG for ; Wed, 4 Mar 2009 18:03:37 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 3D5DD28C14E for ; Wed, 4 Mar 2009 18:03:37 -0800 (PST) Received: from [64.186.172.180] (port=51771 helo=[192.168.200.153]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Lf2wH-00063R-2U for simple@ietf.org; Wed, 04 Mar 2009 18:03:57 -0800 Message-Id: <36B95678-1E9D-48E4-8793-307EDE9CC95D@standardstrack.com> From: Eric Burger To: simple@ietf.org Content-Type: multipart/signed; boundary=Apple-Mail-5-213405557; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Mar 2009 18:04:03 -0800 References: <20090302180844.30D5528C2AD@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [Simple] IPR Claims on RFC 5438 (IMDN) 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, 05 Mar 2009 02:03:38 -0000 --Apple-Mail-5-213405557 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Nokia has asserted they may have IPR claims that may impact IMDN implementations. While I do have an opinion as to the validity of the claims, I cannot offer those opinions in public. I would offer you read the relevant patent applications and make your own determination, or hire an expert. I happen to know a really good one ;-) That said, the claims are NOT about IMDN itself, but the use of mechanisms similar to IMDN with a proxy. Again, it is up to you to decide if the IPR applies to you and if it does, what you want to do about it. If you think the patent will be awarded and your implementation will infringe, Nokia, in their IETF IPR declaration, stated they will license the patent (if it ever issues) under FRAND terms. Begin forwarded message: > From: IETF Secretariat > Date: March 2, 2009 10:08:44 AM PST > To: eburger@standardstrack.com,hisham.khartabil@gmail.com > Cc: jon.peterson@neustar.biz,fluffy@cisco.com,simple@ietf.org,rjsparks@nostrum.com > ,hisham.khartabil@gmail.com,ipr-announce@ietf.org > Subject: Posting of IPR Disclosure > > Dear Eric Burger, Hisham Khartabil: > > An IPR disclosure that pertains to your RFC entitled "Instant Message > Disposition Notification (IMDN)" (RFC5438) was submitted to the IETF > Secretariat > on 2009-03-01 and has been posted on the "IETF Page of Intellectual > Property > Rights Disclosures" (https://datatracker.ietf.org/public/ > ipr_list.cgi). The > title of the IPR disclosure is "Nokia Corporation's Statement about > IPR related > to RFC 5438." > > The IETF Secretariat > > --Apple-Mail-5-213405557 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMDUwMjA0MDNaMCMGCSqGSIb3 DQEJBDEWBBR+WnueUmawDDmWfLPXdnR/QbQbKDCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQC3camujzgrVuu9jw4eFbPPi8sVcZOXVwI31fEsGlc+rRsU AeSpaDjgOwSDwNrqFCffTQiHEcpvFouJWpafHuWVQMqBH5JWZColPzR01iVgIpVyygxCYYMFzjWA gSAlyxP7JJqHjAACSyJQmm1mvpBwxch13N58RmPtDZElN32EQ8KPy5Bql6o1zEBF7se2/1DghO2E ULwwOYi2jiNWvKlYI1tbDDafjLO/bUE+TUqopX1qi74534gkNSzEBh7NGwx3dxLJqXNIYsQNpAbs wU5awromC0+l9bvbHx+QB3JLj6SbLYx67NVpBFhvrijS3fo+uo09EIZCXJ5QNpGZ1mfWAAAAAAAA --Apple-Mail-5-213405557-- From jdrosen@cisco.com Mon Mar 9 08:06:54 2009 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 6CB8928C187 for ; Mon, 9 Mar 2009 08:06:54 -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 9VGhoYSXayNi for ; Mon, 9 Mar 2009 08:06:53 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EA56828C17D for ; Mon, 9 Mar 2009 08:06:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,329,1233532800"; d="scan'208";a="263959969" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 09 Mar 2009 15:07:25 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n29F7P04009116 for ; Mon, 9 Mar 2009 08:07:25 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n29F7PAr026216 for ; Mon, 9 Mar 2009 15:07:25 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 08:07:24 -0700 Received: from [10.32.241.157] ([10.32.241.157]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 08:07:24 -0700 Message-ID: <49B530AC.50906@cisco.com> Date: Mon, 09 Mar 2009 11:07:24 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2009 15:07:24.0697 (UTC) FILETIME=[C0E5F890:01C9A0C8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=449; t=1236611245; x=1237475245; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20updated=20simple-simple=20draft |Sender:=20; bh=QDfxVwAZCrsxPyUkrPqtlRovZARVaNf9+vH5Ss6MmB0=; b=xxuSBa/kEnsJ8bD10W86F9pDcDb6ytxDT4KxfccuA1HNScHCVs+nLGnxPX IrMePTkDV6oIXH7qHlLqR9cYPEx17PlXP6dJC0araH4Kt8BAAkpTOBKTHX3b APXxxwZ3CA; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Simple] updated simple-simple draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 15:06:54 -0000 http://www.ietf.org/internet-drafts/draft-ietf-simple-simple-05.txt Changes: * IMDN -> 5438 * added msrp-acm * xcon framework -> 5239 Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com From root@core3.amsl.com Mon Mar 9 08:15:02 2009 Return-Path: X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BA8D93A6C77; Mon, 9 Mar 2009 08:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309151501.BA8D93A6C77@core3.amsl.com> Date: Mon, 9 Mar 2009 08:15:01 -0700 (PDT) Cc: simple@ietf.org Subject: [Simple] I-D Action:draft-ietf-simple-simple-05.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 15:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : SIMPLE made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence using the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-simple-simple-05.txt Pages : 16 Date : 2009-03-09 The IETF has produced many specifications related to Presence and Instant Messaging with the Session Initiation Protocol (SIP). Collectively, these specifications are known as SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions. This document serves as a guide to the SIMPLE suite of specifications. It breaks them up into categories and explains what each is for and how they relate to each other. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-simple-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-simple-simple-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09080521.I-D@ietf.org> --NextPart-- From jdrosen@cisco.com Mon Mar 9 08:31:37 2009 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 61C773A67E4 for ; Mon, 9 Mar 2009 08:31:37 -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_13=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 N0TFOb8gMz8M for ; Mon, 9 Mar 2009 08:31:36 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id ED3D23A67AF for ; Mon, 9 Mar 2009 08:31:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,330,1233532800"; d="scan'208";a="152910717" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 09 Mar 2009 15:32:10 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n29FWAbs020844; Mon, 9 Mar 2009 08:32:10 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n29FWAgS003474; Mon, 9 Mar 2009 15:32:10 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 08:32:10 -0700 Received: from [10.32.241.157] ([10.32.241.157]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 08:32:09 -0700 Message-ID: <49B53678.3090003@cisco.com> Date: Mon, 09 Mar 2009 11:32:08 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Adam Roach References: <499B3B67.6000006@nostrum.com> In-Reply-To: <499B3B67.6000006@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2009 15:32:09.0494 (UTC) FILETIME=[35E80360:01C9A0CC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3871; t=1236612730; x=1237476730; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20client/server=20standards,=20was=3A=20Re=3A=20[ Simple]=20Comments=20on=20draft-ietf-simple-intradomain-fede ration |Sender:=20; bh=H2XCNDPl9IlCnj2boDQXYzeihFbgypiFr45KvI95ee4=; b=EjiBEB/MEJNuw7wqStBh1zc5njgd8qS+pszWhvF+WLWLC+tW45VCCKuQoq w4aaMgWDS4kwxt7GjMfFSRnsGACAfRUkncRJv+Dl6vy9iwa+++LDEieSILdM 8hJow2kQFH; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "'simple@ietf.org'" Subject: [Simple] client/server standards, was: Re: Comments on draft-ietf-simple-intradomain-federation X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 15:31:37 -0000 thanks for the review, Adam. One rant below, which is orthogonal from the rest of this really, and so I am splitting this off from responses to the rest of your comments: Adam Roach wrote: > I have been asked to do a dedicated review of > draft-ietf-simple-intradomain-federation, and have a number of comments. > > In general: much of the explanatory text is based on some of the > growing pains associated with a relatively new technology. For example: > > In an ideal world, clients would > all implement to standards and this would not happen, but in > practice, the vast majority of presence and IM endpoints work only > (or only work well) with the server from the same vendor. > > While this is true for the time being, I would hope that these > impedance mismatches fade over time as people implement > increasingly standard functionality (in fact, section 7.1.3 > relies on this fact). Keep in mind that RFCs are permanent, while > this problem is (hopefully) temporary. Modified "but in practice" to "but in current practice"... I will also say that, I don't agree with you here. There is ample precedent for the fact that these things never reach 100% standards, or even close, for systems that have a 'trapezoid' kind of model. Systems like that include email, IM/P, telephony. Lets look at those. Firstly, is email. I think its clear that standards like POP and IMAP have been 'done' a very long time. Yet a large number of clients still talk to their servers using proprietary protocols. These include Outlook (which can do pop or imap but typically is used with Microsoft's exchange protocol), Lotus Notes, Blackberry. Even webmail clients arguably use a 'proprietary' interface to talk from client to server, though thin client is different. All have fully standardized on the server-server piece - SMTP. Do you think this is going to change over time? I don't. IM/P at the moment is the same. Mostly proprietary on the client/server links - Yahoo, AOL, Skype, etc on the consumer front - are proprietary. When they do federate, the server-server links are standards based, either SIMPLE or XMPP. Traditional enterprise voice systems, ala legacy PBXs, are also like this. Indeed, for them, the phone->PBX link was never even standardized. The server to server links, via PRI and Q.SIG, were pretty well standardized. The interesting exception here is telephony. Even for analog telephony, the standards for client->server communications - the FXO/FXS port - is standardized. This remains true for cellular as well, with the interface between the phone and the cell towers totally standardized. The difference is that the telephony and cell phone markets sell the endpoint hardware separately from the service that endpoint receives, which requires rigorous standardization on that interface. The market model for email and IM/P is different - typically the client is software based on thus does not need to be purchased separately. That has driven the market in a different direction. My point is that there is strong historical precedent for the never-standardized model on client/server links, and success in adopting standards there is primarily an artifact of the business model, and not just 'wait a bit more'. Also keep in mind nothing is 100%, and even for email there is certainly some fraction of the market which uses a standardized interface from client to server, but I suspect its in the minority for email these days. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com From adam@nostrum.com Mon Mar 9 10:30:26 2009 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 69EA33A6CFF for ; Mon, 9 Mar 2009 10:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMu8mMG4S5r4 for ; Mon, 9 Mar 2009 10:30:25 -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 DD1223A6B73 for ; Mon, 9 Mar 2009 10:30:24 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n29HTUcZ066409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 12:29:31 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49B551FA.6020508@nostrum.com> Date: Mon, 09 Mar 2009 12:29:30 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Jonathan Rosenberg References: <499B3B67.6000006@nostrum.com> <49B53678.3090003@cisco.com> In-Reply-To: <49B53678.3090003@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9080/Fri Mar 6 13:13:38 2009 on shaman.nostrum.com X-Virus-Status: Clean Cc: "'simple@ietf.org'" Subject: Re: [Simple] client/server standards, was: Re: Comments on draft-ietf-simple-intradomain-federation X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 17:30:26 -0000 Jonathan Rosenberg wrote: > My point is that there is strong historical precedent for the > never-standardized model on client/server links, and success in > adopting standards there is primarily an artifact of the business > model, and not just 'wait a bit more'. If you really believe this, then why are you playing in the IETF space at all any more? Work like draft-rosenberg-bliss-problem-statement and draft-rosenberg-sip-target-uri-delivery are predicated on these links being standardized. I think you're oversimplifying the role of standards in client-server communications, and I think you know you're oversimplifying it -- otherwise you wouldn't be working on client-interface extensions. /a From jdrosen@cisco.com Mon Mar 9 10:46:57 2009 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 EFF973A6BB0 for ; Mon, 9 Mar 2009 10:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 M1zKDrLCPQbx for ; Mon, 9 Mar 2009 10:46:55 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 419C228C255 for ; Mon, 9 Mar 2009 10:46:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,330,1233532800"; d="scan'208";a="264077812" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 09 Mar 2009 17:47:27 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n29HlR16025115; Mon, 9 Mar 2009 10:47:27 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n29HlQPA020722; Mon, 9 Mar 2009 17:47:27 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 10:47:26 -0700 Received: from [10.32.241.157] ([10.32.241.157]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 10:47:26 -0700 Message-ID: <49B5562D.9050504@cisco.com> Date: Mon, 09 Mar 2009 13:47:25 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Adam Roach References: <499B3B67.6000006@nostrum.com> <49B53678.3090003@cisco.com> <49B551FA.6020508@nostrum.com> In-Reply-To: <49B551FA.6020508@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2009 17:47:26.0447 (UTC) FILETIME=[1BFCBFF0:01C9A0DF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1391; t=1236620847; x=1237484847; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20client/server=20standards,=20was=3A=20R e=3A=20[Simple]=20Comments=20on=20draft-ietf-simple-intradom ain-federation |Sender:=20; bh=K3Tnsx/6uA6Op1yjzE8ti6MktMRnpXM9HkVp/Ptriqk=; b=BUZTb4PZ3EvwJ2vfKtvbmCelhjyMK+LEA/j716q/fZJzRzAsq9Mx6DMvxS uuGA3Rvl6wwh2dZ/TBGkOM+bV3BKrpvN/zIvrm04Ws5gDs0NNB7tPEv+LSzO Qu7JUVhQZm; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "'simple@ietf.org'" Subject: Re: [Simple] client/server standards, was: Re: Comments on draft-ietf-simple-intradomain-federation X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 17:46:57 -0000 Adam, My own personal feelings and personal participation is not the question here. The question is whether or not we agree that we will, over a long term, see cases where a client works only with a particular server, and that in turn impacts at least some of the motivation parts of this document. -Jonathan R. Adam Roach wrote: > Jonathan Rosenberg wrote: >> My point is that there is strong historical precedent for the >> never-standardized model on client/server links, and success in >> adopting standards there is primarily an artifact of the business >> model, and not just 'wait a bit more'. > > If you really believe this, then why are you playing in the IETF space > at all any more? Work like draft-rosenberg-bliss-problem-statement and > draft-rosenberg-sip-target-uri-delivery are predicated on these links > being standardized. > > I think you're oversimplifying the role of standards in client-server > communications, and I think you know you're oversimplifying it -- > otherwise you wouldn't be working on client-interface extensions. > > /a > -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com From Markus.Isomaki@nokia.com Mon Mar 9 10:51:55 2009 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 E0F6828C212 for ; Mon, 9 Mar 2009 10:51:55 -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_13=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 pv9bDqWwFJja for ; Mon, 9 Mar 2009 10:51:54 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id C6E5C28C14B for ; Mon, 9 Mar 2009 10:51:53 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n29HpXMB025273; Mon, 9 Mar 2009 19:52:21 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Mar 2009 19:51:40 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Mar 2009 19:51:40 +0200 Received: from NOK-AM1MHUB-05.mgdnok.nokia.com (65.54.30.9) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 9 Mar 2009 18:51:39 +0100 Received: from NOK-EUMSG-02.mgdnok.nokia.com ([65.54.30.87]) by NOK-AM1MHUB-05.mgdnok.nokia.com ([65.54.30.9]) with mapi; Mon, 9 Mar 2009 18:51:39 +0100 From: To: , Date: Mon, 9 Mar 2009 18:51:36 +0100 Thread-Topic: [Simple] client/server standards, was: Re: Comments on draft-ietf-simple-intradomain-federation Thread-Index: AcmgzHOaiX20ZgFKQCO36avDp3Jn0QADauog Message-ID: References: <499B3B67.6000006@nostrum.com> <49B53678.3090003@cisco.com> In-Reply-To: <49B53678.3090003@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Mar 2009 17:51:40.0087 (UTC) FILETIME=[B32B2470:01C9A0DF] X-Nokia-AV: Clean Cc: simple@ietf.org Subject: Re: [Simple] client/server standards, was: Re: Comments on draft-ietf-simple-intradomain-federation X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 17:51:56 -0000 Hi Jonathan,=20 You make some good points. I agree that the server-to-server or inter-domai= n part is the most crucial thing to standardize, the client/server interfac= e can often be provider-specific. I would add one important aspect: it is e= xtremely important to have a common namespace for all users, even if they a= ccess the service with different protocols. In e-mail we have it and in tel= ephony (including VoIP) we have it too with E.164. So, a hotmail user can a= ddress a Blackberry user and a Skype(-out) user can address a Comcast VoIP = user. In IM/P (or social networking) we don't really have it yet, as many p= roprietary systems just offer a flat namespace. =20 On the other hand, not every provider or vendor has the resources to develo= p their own client/server protocols. There are a lot of providers who benef= it from client/server standards. We can see this in with SIP in telephony a= nd XMPP in IM/P. There are many benefits, as being able to get your equipme= nt from multiple vendors or even using open source components, rather than = having to design your own solution =E1 la Skype or MSN or RIM, or buing exc= lusively from them. This is true with small players (hundreds of XMPP provi= ders) and with big ones (many large telcos running SIP based VoIP service).= But I agree there is a difference e.g. between consumer and enterprise mar= ket in that regard. The irony with SIP at the moment is that it is often still easier to downlo= ad a proprietary application than configure your standard SIP client with t= he service provider. For instance in Nokia devices just downloading the Giz= mo client and using it is not harder than figuring out how to get the SIP s= ettings for Gizmo service. (Plus that with the proprietary client you actua= lly get IM/P too rather than just voice...) Some further comments inline. > >There is ample precedent for the fact that these things never=20 >reach 100% standards, or even close, for systems that have a=20 >'trapezoid' kind of model. Systems like that include email,=20 >IM/P, telephony. Lets look at those. > >Firstly, is email. I think its clear that standards like POP=20 >and IMAP have been 'done' a very long time. Yet a large number=20 >of clients still talk to their servers using proprietary=20 >protocols. These include Outlook (which can do pop or imap but=20 >typically is used with Microsoft's exchange protocol), Lotus=20 >Notes, Blackberry. Even webmail clients arguably use a=20 >'proprietary' interface to talk from client to server, though=20 >thin client is different. All have fully standardized on the=20 >server-server piece - SMTP. Do you think this is going to=20 >change over time? I don't. > Based on my observation things are definitely not moving towards standardiz= ed protocols such as IMAP or POP. For instance in Nokia devices we nowadays= have to support a half a dozen different "mobile" or "enterprise" e-mail c= lients including Microsoft and RIM and a few others. IMAP and POP are still= used on the consumer side but more and more people have switched to webmai= l. This has partly to de with business model too: if you have a browser or = your specific client, you can push ads and other stuff to the user. If they= can use any POP client, its harder. With enterprise mobile mail we can als= o claim that the proprietary solutions are feature- and efficiency-wise bet= ter than what the IETF standards can offer. This despite of many years of L= EMONADE standards. >IM/P at the moment is the same. Mostly proprietary on the=20 >client/server links - Yahoo, AOL, Skype, etc on the consumer=20 >front - are proprietary.=20 >When they do federate, the server-server links are standards=20 >based, either SIMPLE or XMPP. > >Traditional enterprise voice systems, ala legacy PBXs, are=20 >also like this. Indeed, for them, the phone->PBX link was=20 >never even standardized.=20 >The server to server links, via PRI and Q.SIG, were pretty=20 >well standardized. > The enterprises typically purchase a solution from a single vendor (or a co= uple of vendors who have a tight partnership) and deploy that rather than l= etting every employee choose their own client, so they are mostly fine with= the situation. There is however a certain desire to avoid vendor-lockin so= they to some extent there is interest in standards too.=20 >The interesting exception here is telephony. Even for analog=20 >telephony, the standards for client->server communications -=20 >the FXO/FXS port - is standardized. This remains true for=20 >cellular as well, with the interface between the phone and the=20 >cell towers totally standardized. > >The difference is that the telephony and cell phone markets=20 >sell the endpoint hardware separately from the service that=20 >endpoint receives, which requires rigorous standardization on=20 >that interface. The market model for email and IM/P is=20 >different - typically the client is software based on thus=20 >does not need to be purchased separately. That has driven the=20 >market in a different direction. > There is also one big reason why the "client/server" interface in *current*= cellular telephony is rigorously standardized and highly interoperable. Th= at's because the access/transport and the service parts are tightly integra= ted in such as way that they can't be separated. So, you can't connect to y= our "server" in Finland from a US network without going through the "server= " in the US network. This means that if you want to use your phone in some = other network than your own, all networks and phones have to follow the sam= e "client/server" standard. And roaming is quite important feature in cellu= lar telephony. This is equivalent to Ethernet or WiFi or IP itself having t= o be very standardized; a portable device needs to be able to work everywhe= re in the same way. As we move from integrated network and service to IP ba= sed paradigm and closed handheld devices to ones based on open platforms su= ch as Linux, Symbian, etc. the need to standardize the client/server interf= ace even for mobile telephony is less important. People can just install th= e client that is compatible with their service provider and use it. Having = said that, I think we are still far away from that day when talking about t= he mainstream cellular device/telephony market. There are still many forces= that make standardized client/server interfaces the preferred way to go. >My point is that there is strong historical precedent for the=20 >never-standardized model on client/server links, and success=20 >in adopting standards there is primarily an artifact of the=20 >business model, and not just 'wait a bit more'. Also keep in=20 >mind nothing is 100%, and even for email there is certainly=20 >some fraction of the market which uses a standardized=20 >interface from client to server, but I suspect its in the=20 >minority for email these days. > >-Jonathan R. > >--=20 >Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South >Cisco Fellow Iselin, NJ 08830 >Cisco, Voice Technology Group >jdrosen@cisco.com >http://www.jdrosen.net PHONE: (408) 902-3084 >http://www.cisco.com Markus From jdrosen@cisco.com Mon Mar 9 11:01:41 2009 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 DE3FB28C25D for ; Mon, 9 Mar 2009 11:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 UZq1L0RizlEX for ; Mon, 9 Mar 2009 11:01:40 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3C87D28C256 for ; Mon, 9 Mar 2009 11:01:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,330,1233532800"; d="scan'208";a="264089283" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 09 Mar 2009 18:01:49 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n29I1nAE002257; Mon, 9 Mar 2009 11:01:49 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n29I1ndO000770; Mon, 9 Mar 2009 18:01:49 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 11:01:49 -0700 Received: from [10.32.241.157] ([10.32.241.157]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 11:01:48 -0700 Message-ID: <49B5598B.1040806@cisco.com> Date: Mon, 09 Mar 2009 14:01:47 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Adam Roach References: <499B3B67.6000006@nostrum.com> In-Reply-To: <499B3B67.6000006@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 09 Mar 2009 18:01:48.0666 (UTC) FILETIME=[1DE8EDA0:01C9A0E1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9837; t=1236621709; x=1237485709; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Simple]=20Comments=20on=20draft-ietf-s imple-intradomain-federation |Sender:=20; bh=oqykMRoLKI/LCvW5F8mhBzZaoaf7lY5IfBEAW28byFI=; b=k0y93CElBaKLlZVH2KE86oaoy8bQBilrkC08WmQYBhiMQVbjP3M3q5NBb+ y8ngSMxzAvu37yAmN2qKA8PvaytHu67jYrDtlrCOc1o9P8G/2tigjwMwef4U 2YGyL4kje/E8f0YtpQUQpCPUj2sEcwxQGxQ+BaA9SfXJU/tvitZcY=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "'simple@ietf.org'" Subject: Re: [Simple] Comments on draft-ietf-simple-intradomain-federation X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 18:01:42 -0000 Thanks for the comments, Adam. Responses below. Also note that Avshalom did much of the work on this update and this mail is a consolidation of his responses, and my own: Adam Roach wrote: > I have been asked to do a dedicated review of > draft-ietf-simple-intradomain-federation, and have a number of comments. > > In general: much of the explanatory text is based on some of the > growing pains associated with a relatively new technology. For example: > > In an ideal world, clients would > all implement to standards and this would not happen, but in > practice, the vast majority of presence and IM endpoints work only > (or only work well) with the server from the same vendor. > > While this is true for the time being, I would hope that these > impedance mismatches fade over time as people implement > increasingly standard functionality (in fact, section 7.1.3 > relies on this fact). Keep in mind that RFCs are permanent, while > this problem is (hopefully) temporary. see response in other mail. > > Section 5.2.2: The scaling problems mentioned here assume a > very naďve design. Any product that performs this kind of task > will cluster the routing proxy. Because the data used to process > transactions is slow-changing hard state, such clusters can scale > effectively infinitely. We do not say that scaling is impossible but thyat it is a challenge. Clustering the proxies may be one option here (server fram is mentioned in the document) but the function is centralized in nature and central architectuere have its own challenges even in clusters. > > Section 5.2.3: it would be useful to detail some potential > protocols for the client/database interaction. Making "Database" a > SIP redirect server, for example, would allow this scenario to > work with a broad base of deployed clients. added the following paragraph: Subdmaining can be done via different databases. In order to provide consistent interface to clients, a front-end of a SIP redirect proxies can be implemented. A client would send the SIP request to one of the redirect proxies and the redirect proxy will reply with the right domain after consulting the database in whatever protocol the databases exposes. > > Section 5.2.4: it would be helpful to cite the p2psip work > as a candidate for doing this in the future. Modified last sentence to: "which does not exist today." -> "which is being worked on in the P2PSIP IETF working gorup but still does not exist today." > > Section 5.2.5: the caveat about the number of servers should > probably be stronger here; this approach completely defeats any > scaling-related partitioning.\ Added: Indeed, if multiple servers exist for the purposes of achieving scale, this approach can defeat the very reason those additional servers were deployed. > > Section 6.1.1: if the percentage of the community that is offline > at any given time is large, this approach simply moves any subscription > scaling problem up to the subscriptions on the database. While not > a show-stopper, this is an important property of the system that > should be explained. It should also be noted that static assignment > to a partitioned database can be used to solve this problem (i.e., > you're using the approaches from section 5, but at the database > level instead of the presence/IM server level). Added: Note that this approach actually moves the scaling problem of the routing mechanism to the database, especially when the percentage of the community that is offline is large. > > Section 6.1.2: this has the same scaling issues as 6.1.1. Note that this approach actually moves the scaling problem of the routing mechanism to the database, especially when the percentage of the community that is offline is large. > > Section 6.1.5: This should go into more detail about what > happens when multiple servers think they're authoritative > for a user -- e.g., the forked SUBSCRIBE will establish > multiple subscriptions, and the forking server will be > forced to form a coherent (if not necessarily complete) > state for the subscribing user... One possible scenario where multiple servers will think that they are serving the user would be when a subscription request is forked and reaches to multiple servers, each of them thinks that it serves the user. > > Section 6.2: this should also talk about storing policy > on an external server using, e.g., presence rules and > XCAP. That way, each presence server can access the same > policy information. Changed the beginning of the section. from: "In the exclusive bridging model, policy becomes more complicated." to: "Unless policy is somehow managed in the same database and is accessed by the servers in the exclusive bridging model, policy becomes more complicated in the exclusive bridging model." > > Section 7.1.1: in the third bullet, why is the request routed > to the parent instead of to the root? Routing to the root > would achieve the same effect, but with less traffic. It seems to be more efficient to send directly to root but it assumes that every parent can send directly to the root which may not be the case. Added to the bullet: Note that if the node that receives the request can send the request directly to the root, it should do so thus reducing the traffic in the system. > > Section 7.1.2.2: The advice on presence subscription rejection > is precisely opposite from the common policy model, in which > rights are absent unless granted; and, once granted by a rule, > cannot be revoked. The interaction between these two diametrically > opposed models is likely to lead to some unwanted surprises. I > think the common policy approach is the correct one to take here. > > Consider, for example, the case in which I instruct > an off-the-shelf geoloc server to allow Robert to subscribe to > my location information, but no one else. It interprets this > to mean "reject subscriptions from everyone but Robert" (which is > a reasonable implementation choice). Now, this server is used as > a leaf in a hierarchical tree of presence servers. Suddenly, no > one can see *any* of my presence information except for Robert! > That's certainly not what I intended. It seems quite reasonable > for a subscription rejection at a node other than the root simply > be interpreted to mean "the presence information from this > branch of the tree shall not be composed into the document, but > other information is still allowed." I think the example is a bit misleading; you have here a geolocation subscription, which is rejected if *geoloc* is not to be provided. If we want the geoloc server to be more like a presence server, it would accept the subscription but provide no geolocation information. That aspect of this section IS compliant with common policy. What is not compliant, is the bit about rejection. I agree with you there that, in the proposed model in this document, the composition does not follow common policy. If the subscription is rejected at one presence server, it is rejected everywhere. This can be readily fixed by changing the rule so that a presence server only rejects a subscription if ALL of its downstream servers reject it. However, I wonder if that is really the right thing. The fundamental question is, whether the common-policy model of composition is appropriate in these unioned federation cases. I would think that user expectation is that, if Adam blocks Robert on his IBM server, but didn't bother to do so ALSO on his Microsoft server, Robert would be blocked. > > Section 7.1.2.3: Figure 11 (and the accompanying text) implies > a push model. This can, of course, be achieved through a pull model > as well, such as XCAP. Such an approach requires more integrated > client support, but eliminates the need for a portal (with the > trade-off being deployment of an XCAP server). True - this then becomes a variant on section 7.1.2.4. I added a paragraph there: It is also possible to move the decisionmaking process into each server. In that case, there is still a centralized policy portal and centralized repository of the policy data. The interface between the servers and the repository then becomes some kind of standardized database interface. > > Section 7.2: The formula given to demonstrate commutativity > is a bit confusing. I think you actually mean something like: > > Pi(Pj(x1..xm),y1..yn) = Pj(Pi(y1..yn),x1..xm) > > for all possible inputs x1..xm and y1..yn. I was folding in the OTHER inputs to Pi and Pj into the function itself; the key aspect of this, is which server gets the document first. > > Section 7.2.1: This entire scheme seems less well baked than > the rest of the document. For example, I could point to concrete > standardized mechanisms to create all the systems described so > far; but for 7.2.1, I'd have to do some non-standard stuff (e.g., > indication of a loop in a back-end subscription). Well, this document is a framework overall. There is much in here that would need to be standardized to build it out in each model. Several of these would require agreement on database protocols and schema for example. This is the one case where that new standards work would be a SIP extension - I agree. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com From jmh@joelhalpern.com Mon Mar 9 11:51:46 2009 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 59F7B3A69A7 for ; Mon, 9 Mar 2009 11:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, 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 hcFRiC7IHlNp for ; Mon, 9 Mar 2009 11:51:45 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 8FC0F3A6BE9 for ; Mon, 9 Mar 2009 11:51:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 106734306B5; Mon, 9 Mar 2009 11:52:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-50-192.clppva.btas.verizon.net [71.161.50.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 43404430661; Mon, 9 Mar 2009 11:52:19 -0700 (PDT) Message-ID: <49B5655C.8070804@joelhalpern.com> Date: Mon, 09 Mar 2009 14:52:12 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jonathan Rosenberg References: <499B3B67.6000006@nostrum.com> <49B53678.3090003@cisco.com> <49B551FA.6020508@nostrum.com> <49B5562D.9050504@cisco.com> In-Reply-To: <49B5562D.9050504@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Roach , "'simple@ietf.org'" Subject: Re: [Simple] client/server standards, was: Re: Comments on draft-ietf-simple-intradomain-federation X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 18:51:46 -0000 The fact that someone can write a server that supports a proprietary protocol, and gateway sit to a standard, and can write a client which speaks that proprietary protocol, ought to be irrelevant to us. We could claim that all client-proxy itneractions were out of scope, and we are only interested in standardizing proxy-proxy interactions. That is the model or path we have chosen to go down. Having chosen to go down the path where we are interested in standardized client interaction, it seems to follow that we care about that, and not about what games an implementation is capable of playing using proprietary protocols and gatewaying. After all, the reason for discussing the client-proxy behavior is so that one vendors client can work with another vendors proxy. This is in contrast to the classic pbx case where you had to buy the phones from the pbx vendor. Apologies if I am misunderstanding Jonathan or Adam. Joel Jonathan Rosenberg wrote: > Adam, > > My own personal feelings and personal participation is not the question > here. The question is whether or not we agree that we will, over a long > term, see cases where a client works only with a particular server, and > that in turn impacts at least some of the motivation parts of this > document. > > -Jonathan R. > > Adam Roach wrote: >> Jonathan Rosenberg wrote: >>> My point is that there is strong historical precedent for the >>> never-standardized model on client/server links, and success in >>> adopting standards there is primarily an artifact of the business >>> model, and not just 'wait a bit more'. >> >> If you really believe this, then why are you playing in the IETF space >> at all any more? Work like draft-rosenberg-bliss-problem-statement and >> draft-rosenberg-sip-target-uri-delivery are predicated on these links >> being standardized. >> >> I think you're oversimplifying the role of standards in client-server >> communications, and I think you know you're oversimplifying it -- >> otherwise you wouldn't be working on client-interface extensions. >> >> /a >> > From rjsparks@nostrum.com Mon Mar 9 13:11:28 2009 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 3E56A3A69A8 for ; Mon, 9 Mar 2009 13:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQX57SE4QyH6 for ; Mon, 9 Mar 2009 13:11:26 -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 3F2943A691F for ; Mon, 9 Mar 2009 13:11:25 -0700 (PDT) Received: from dn3-232.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 n29KBv5K078398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 9 Mar 2009 15:11:57 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <477AC51C-D9BC-47D3-8876-4410C45F3F1C@nostrum.com> From: Robert Sparks To: simple mailing list Content-Type: multipart/alternative; boundary=Apple-Mail-237-624279453 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Mar 2009 15:11:57 -0500 References: X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9081/Mon Mar 9 12:51:30 2009 on shaman.nostrum.com X-Virus-Status: Clean Subject: [Simple] Fwd: [RAI] Combining the use of SIP and XMPP in an endpoint X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 20:11:28 -0000 --Apple-Mail-237-624279453 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit in case you aren't watching RAI or SIPPING Begin forwarded message: > From: > Date: March 9, 2009 1:54:33 PM CDT > To: , > Subject: [RAI] Combining the use of SIP and XMPP in an endpoint > > Hi, > > In the spirit of making the best use of open standards for rich > Internet multimedia communication, we have put together the > following draft: > http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-00 > > This memo defines guidelines and protocol extensions for combining > Session Initiation Protocol (SIP) based real-time media sessions > with > Extensible Messaging and Presence Protocol (XMPP) based instant > messaging and presence services in a seamless manner. This is > accomplished by integration and protocol extension support in the > endpoints, without requiring any changes in the SIP or XMPP server > infrastructure. It is even possible that SIP and XMPP services are > offered by different service providers. > > The solution is based on defining some new elements in SIP (headers) > and XMPP (message stanza extensions) to pass around the contact and > correlation information related to the other protocol. > > We would like to get feedback on two levels: > 1) Does such combined use make sense? Or should we keep the two > protocols separated and merely specify how they can interwork > through a gateway? > 2) Do we have a correct technical approach? In the first draft the > correlation part is perhaps even too rigorous, we would like get > feedback if people think we could simplify. > > Please send comments to the SIPPING (sipping@ietf.org) list only. > > Regards, > Markus > > >> -----Original Message----- >> From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On >> Behalf Of Isomaki Markus (Nokia-CIC/Espoo) >> Sent: 16 February, 2009 01:55 >> To: adam@nostrum.com >> Cc: rai@ietf.org >> Subject: Re: [RAI] RAI reorganization - role of SIP >> >> Hi Adam, others, >> >> Adam Roach wrote: >>> >>> If you follow the thread back, this branch of it started from a >>> challenge to Eric's assertion that SIP is used for more than POTS >>> replacement. I'm boggled that we've come so far that such an >> assertion >>> even needs to be given a voice, much less a defense. (Marcus' >> voice is >>> not isolated; several key people have expressed equivalent >> sentiments.) >>> >> >> Just to clarify where I stand: >> >> I agree that communication over Internet should go far beyond >> what POTS has enabled, and of course this has happened already >> in many ways. I don't think anyone challenges that. Our goal >> should be to develop the best possible open standards that can >> deliver various kinds of real-time/messaging/multimedia apps. >> >> The issue that is more controversial is the role of SIP and >> RAI area protocols in general in all of that. SIP is clearly >> taking the POTS/PBX replacement market and has quite good >> fundamentals for telephony and video. However, for other apps >> there are competing/complementary approaches, such as XMPP and >> web/AJAX-based mechanisms. For instance if I was today to >> create an open standard real-time communication app I could >> pick SIP for voice/video, XMPP for presence/IM and a web-based >> solution for some of the conferencing/collaboration features. >> >> The question is where to focus the precious resources in RAI >> to create most *new* value. In addition to developing its own >> protocols it would be good for RAI to think how its protocols >> interact with these "external" protocols and what would be the >> best way to use them together to create the best possible >> solution for Internet users. >> >> Markus >> _______________________________________________ >> RAI mailing list >> RAI@ietf.org >> https://www.ietf.org/mailman/listinfo/rai >> > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai --Apple-Mail-237-624279453 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable in case you aren't watching RAI = or SIPPING

Begin forwarded message:

Date: March 9, 2009 1:54:33 PM = CDT
Subject: = [RAI] Combining the use of SIP and XMPP in an = endpoint
http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-00
=
  This memo defines guidelines and protocol extensions = for combining
  Session Initiation Protocol (SIP) based = real-time media sessions with
  Extensible Messaging and = Presence Protocol (XMPP) based instant
  messaging and = presence services in a seamless manner.  This is
=   accomplished by integration and protocol extension support = in the
  endpoints, without requiring any changes in the = SIP or XMPP server
  infrastructure.  It is even = possible that SIP and XMPP services are
  offered by = different service providers.

The solution is based on defining = some new elements in SIP (headers) and XMPP (message stanza extensions) = to pass around the contact and correlation information related to the = other protocol.

We would like to get feedback on two = levels:
1) Does such combined use make sense? Or should we keep the = two protocols separated and merely specify how they can interwork = through a gateway?
2) Do we have a correct technical approach? In the = first draft the correlation part is perhaps even too rigorous, we would = like get feedback if people think we could simplify.

Please send = comments to the SIPPING (sipping@ietf.org) list = only.

Regards,
Markus


-----Original Message-----
From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] = On
Behalf Of Isomaki Markus = (Nokia-CIC/Espoo)
Sent: 16 = February, 2009 01:55
To: = adam@nostrum.com
Cc: = rai@ietf.org
Subject: Re: = [RAI] RAI reorganization - role of SIP

Hi Adam, = others,

Adam Roach = wrote:

If you follow the thread back, = this branch of it started from a =
challenge to Eric's assertion that SIP is used for more = than POTS
replacement. I'm boggled that = we've come so far that such an
assertion
even needs to be given a voice, = much less a defense. (Marcus'
voice is
not isolated; several key people = have expressed equivalent
sentiments.)


Just to clarify = where I stand:

I agree that = communication over Internet should go far beyond =
what POTS has enabled, and of = course this has happened already
in many ways. I don't think anyone challenges that. Our = goal
should be to develop the = best possible open standards that can
deliver various kinds of real-time/messaging/multimedia = apps.

The issue that = is more controversial is the role of SIP and =
RAI area protocols in general = in all of that. SIP is clearly
taking the POTS/PBX replacement market and has quite good =
fundamentals for telephony = and video. However, for other apps
there are competing/complementary approaches, such as XMPP = and
web/AJAX-based = mechanisms. For instance if I was today to
create an open standard real-time communication app I = could
pick SIP for = voice/video, XMPP for presence/IM and a web-based =
solution for some of the = conferencing/collaboration features.

The question is = where to focus the precious resources in RAI =
to create most *new* value. = In addition to developing its own
protocols it would be good for RAI to think how its = protocols
interact with these = "external" protocols and what would be the
best way to use them together to create the best possible =
solution for Internet = users.

Markus
_______________________________________________
RAI mailing = list
RAI@ietf.org
https://www.ietf.org/mailman/listinfo/rai

___________________________________________= ____
RAI mailing = list
RAI@ietf.org
https://www.ietf.org/mailman/listinfo/rai

= --Apple-Mail-237-624279453-- From jdrosen@cisco.com Mon Mar 9 13:44:27 2009 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 2B5273A688A for ; Mon, 9 Mar 2009 13:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 MerzGKD4mOwy for ; Mon, 9 Mar 2009 13:44:25 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A60373A6816 for ; Mon, 9 Mar 2009 13:44:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,331,1233532800"; d="scan'208";a="66577268" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 09 Mar 2009 20:44:59 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n29Kix8A017303; Mon, 9 Mar 2009 13:44:59 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n29Kix87009984; Mon, 9 Mar 2009 20:44:59 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 13:44:59 -0700 Received: from [10.32.241.157] ([10.32.241.157]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 13:44:59 -0700 Message-ID: <49B57FC9.3020301@cisco.com> Date: Mon, 09 Mar 2009 16:44:57 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ben Campbell References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2009 20:44:59.0173 (UTC) FILETIME=[E981BD50:01C9A0F7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10583; t=1236631499; x=1237495499; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20Comments=20on=20draft-ietf-simple-intra domain-federation-02 |Sender:=20; bh=M7YnDAF14x+Ndsr4ntVc2RRFLTv577oPrny9tDfZw2w=; b=x6bIuRnBHX4ScvSg8lkNEdg7Kkr0W7oaBcNmNXv6PXWrj89BlU/8We7iJI MLQZgwcQCZXzRzm5NBD4oGh4M9fRhwoMjAtRQnFd8seouRZthggqGin5a0Uh 5w4ROCskYU; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Francois Audet , avshalom@il.ibm.com, Simple WG Subject: Re: [Simple] Comments on draft-ietf-simple-intradomain-federation-02 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 20:44:27 -0000 Thanks much for the comments, Ben. Responses inline. As with Adam's comments, much of the work here and many of the responses below come from Avshalom, as this is a consolidated response: Ben Campbell wrote: > Hi, > > Hisham asked me to review draft-ietf-simple-intradomain-federation-02: > > General: > > --I think this is a good analysis in general, but I found it easy to get > lost in all the models. An early summary or terminology section might > help readers get the whole picture, prior to diving into detail on each > model. Maybe even a taxonomy diagram. > > (There are a lot of new terms in this draft, so a glossary would help > one way or another.) I added an overview section near the beginning - hopefully this helps. I think something like that is more useful than a glossary. > > -- It's not clear to me what this document sets out to accomplish. Will > it become a framework for discussing standards work? An architecture > document? Recommended best practices? Something else? I think its a framework for discussing standards work. It defines the problem, discusses models for solving it, and discusses how each would work. Follow on documents would be needed to define some of the specifics, recommended models, and so on. I added a sentence in the abstract about this. > > --I am a little skeptical that the same set of models apply for both > presence and messaging. Certainly some models work better for one than > the other. I think it is likely to have overlaid models where presence > and messaging are treated differently. I can also imagine buying a > presence product from one vendor, and a messaging product from another. This doesn't rule that out; however from a presentation perspective a LOT of the issues are similar - routing in particular, which gets a lot of discussion, is identical. I think its better to call out differences rather than have a whole separate doc or section just on IM. > > --This version appears to change the terminology from "federation" to > "bridging" to avoid confusion with inter-domain federation. The term > "federation" still shows up quite a bit, though. (In particular, in the > file name.) Only in the file name. Deadline submissions is the only reason for that ;) > > Specifics: > > Section 1, third from last paragraph (definition of "domain") > > The draft defines domain in terms of "the right hand side of the > @-sign". I think we are really talking about administrative domains, > which may or may not line up with DNS domains. In fact, limiting domains > to DNS domains has the effect of prejudicing us against the use of > different DNS domains for the purposes of partitioning. There are well > known limitations to that approach, but it should be evaluated based on > those limitations. (I point to the fact that this draft goes on to > discuss such approaches as evidence that "intra-domain" describes > administrative domains rather than DNS domains.) > > (I find it mildly ironic this draft lists Avshalom with a sub-domained > email address :-) ) Fair point - though I do think that partitioned federation with subdomaining *IS* inter-domain federation. However, unioned and exclusive federation can happen even when the subdomains are the same. I'll fix the above to talk about administrative domains and mention this often implies different RHS. > > -- Section 2, 2nd paragraph: "There is never > database replication or state replication across federated systems" > > Never say never. Such replication may not be common, but it is certainly > possible. Changed from: There is never database replication or state replication across federated systems (though a database and DB replication might be used within a component providing routing functions to facilitate bridging). to: Database replication or state replication across federated systems are extremely rare (though a database and DB replication might be used within a component providing routing functions to facilitate bridging). > > -- ... 3rd paragraph: clustering always occurs amongst components from > the same > vendor" > > Never say "always", either :-) always -> most usually > > -- Section 3.4: > > I am skeptical of using "people don't follow standards" as a motivation > for more standards. (assuming any standards work comes out of this, of > course.) We're having this discussion in the other thread. The problem is NOT that 'people don't follow standards', its that, 'people have business reasons for not wanting to have a standardized client/server interface'. Those are NOT the same thing; many such vendors/providers have strong reason to want standards on the server/server links. All of that said, this is just one motivation of several for the work. > > -- ... Last Paragraph, last sentence: > > s/specified/specific fixed > > -- Section 5.2: > > I think the distinction between "central database" and "routing proxy" > is artificial, at least at a logical level. The routing proxy approach > is likely to have in practice multiple proxies looking at a central > database. The central database approach simply moves the routing > function into each PS--but the function still logically exists. Agreed that both feature a central thing, but there are lots of differences between that being a database vs. a proxy. Databases can provide more information but are often harder to standardize; a routing proxy strictly handles routing but would allow us to use an existing standardized interface. Those may not be change the fact that there is a central DB in both cases, but it is a big difference in terms of standards, interop, and other aspects of the architecture. > > -- Section 5.2.6: > Any deployable version of this is probably the same as "central > database" for all practical purposes. Or more to the point, two models > that differ only in how the provisioning system works are probably the > same model from a presence and IM perspective. This one is NOT a central database; its multiple databases independently provisioned. > > -- Section 6: > > The term "exclusive" seems a bit off to me. The difference between the > exclusive and partitioned model seems sort of apples and oranges. A > cleaner taxonomy might distinguish between "static" and "dynamic" > assignment of users to servers, and "single-server" vs > "multiple-servers" at any point in time. Can't you have static > multi-server, static single-server, dynamic single-server, and dynamic > multi-server? This is a very good point. I *think* these are orthogonal, but its not clear. One thing is certain, we'd need a rewrite to address this :( so lets discuss and if there is consensus around such a restructure we can do it. > > -- Section 7, last paragraph: > > Since the example is really not intra-domain bridging, can we omit it? > Or maybe have a separate section for things that might look like > intra-domain bridging at first, but on inspection are not? This particular use case comes up a lot. People have accounts on Yahoo or AOL, and there is a desire to somehow 'reflect' that state into their corporate IM systems. That is effectively inter-domain unioned federation. I think it warrants at least a mention. The interesting thing is - all of the issues in unioned intra-domain federation - presence composition, policy, coherency - all apply to inter-domain unioned federation as well. We could expand the scope of this document to cover that as well; though I am reluctant to do that.... > > -- Section 7.1.1, first sentence: > > All of these items may or may not be needed, depending on how the > servers communicate (back-end subscriptions vs PUBLISH, etc.) I think we > mean to say "and/or", or that "each server needs to be provisioned with > some combination of...". Fair point; the PUBLISH approach is not discussed as much here - the bias is clearly towards back-end subscriptions. A more general way to express the requirement here is that the 'servers need to be provisioned with the topology'. > > -- 7.1.2, third paragraph: > > Any reason not to reference RFC4474 as well as 3325? Added: " or authenticated identity " > > -- 7.1.2.2, starting in paragraph 2: > > I think it's important to mention (again) that this approach to privacy > assumes that back-end subscriptions always happen on behalf of the end > watcher. Also, this model does not hold if servers send PUBLISH to each > other, does it? (i.e. back-end subscriptions are recommended over PUBLISH?) The model itself (distributed provisioning), does hold, but the mechanics would be different. THe document has a definite bias in favor of back end subscriptions vs. publication; primarily this has to do with the fact that you cannot really do ANY policy processing if you only PUBLISH. Thus, PUBLISH is something more appropriate for sources of raw data. > > Discussion of security differences between publish and sub/not models > may be worthy of the security considerations section. > > Section 7.1.3, 2nd bullet: > > It seems like this statement is true in any multi-vendor network, isn't it? It should. But my experience has shown that this is an enormous area of interop problems. The reason is, each client has a particular UI with some kind of jellybeans and text, and the code looks for a specific part of the presence document to find the thing they use to determine the color of that jellybean. As such, if you send it a document that is valid pidf but expressing things differently, there is no interop. A good example of this is, how to determine if the jellybean is 'red' or not? Some folks look for 'closed' in the basic status, others look for a specific activity element, and so on. And as a consequence, you end up with one vendor having the jellybean red, and for the same document, some other vendor has it green, and the customer opens a support case against it, as being defective. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com From root@core3.amsl.com Mon Mar 9 14:00:02 2009 Return-Path: X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2D4E53A687B; Mon, 9 Mar 2009 14:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309210002.2D4E53A687B@core3.amsl.com> Date: Mon, 9 Mar 2009 14:00:02 -0700 (PDT) Cc: simple@ietf.org Subject: [Simple] I-D Action:draft-ietf-simple-intradomain-federation-03.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 21:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Models for Intra-Domain Presence and Instant Messaging (IM) Bridging Author(s) : J. Rosenberg, et al. Filename : draft-ietf-simple-intradomain-federation-03.txt Pages : 47 Date : 2009-03-09 Presence and Instant Messaging (IM) bridging involves the sharing of presence information and exchange of IM across multiple systems within a single domain. As such, it is a close cousin to presence and IM federation, which involves the sharing of presence and IM across differing domains. Presence and IM bridging can be the result of a multi-vendor network, or a consequence of a large organization that requires partitioning. This document examines different use cases and models for intra-domain presence and IM bridging. It is meant to provide a framework for defining requirements and specifications for presence and IM bridging. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-intradomain-federation-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-simple-intradomain-federation-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09135104.I-D@ietf.org> --NextPart-- From ben@estacado.net Mon Mar 9 14:19:29 2009 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 23A553A68AA for ; Mon, 9 Mar 2009 14:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEGQjKnEH0LA for ; Mon, 9 Mar 2009 14:19:28 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id EFE833A6884 for ; Mon, 9 Mar 2009 14:19:27 -0700 (PDT) Received: from dn3-213.estacado.net (dn3-213.estacado.net [172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n29LJejJ061721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Mar 2009 16:19:40 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: <99441662-2C6E-4EC9-A45C-E1DC15BDE227@estacado.net> From: Ben Campbell To: Jonathan Rosenberg In-Reply-To: <49B57FC9.3020301@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Mar 2009 16:19:39 -0500 References: <49B57FC9.3020301@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: Francois Audet , avshalom@il.ibm.com, Simple WG Subject: [Simple] Messaging vs Presence (was Re: Comments on draft-ietf-simple-intradomain-federation-02) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 21:19:29 -0000 On Mar 9, 2009, at 3:44 PM, Jonathan Rosenberg wrote: >> --I am a little skeptical that the same set of models apply for >> both presence and messaging. Certainly some models work better for >> one than the other. I think it is likely to have overlaid models >> where presence and messaging are treated differently. I can also >> imagine buying a presence product from one vendor, and a messaging >> product from another. > > This doesn't rule that out; however from a presentation perspective > a LOT of the issues are similar - routing in particular, which gets > a lot of discussion, is identical. I think its better to call out > differences rather than have a whole separate doc or section just on > IM. Does the use of session-mode messaging change anything? MSP Relays? I think relays _could_ be a very interesting intra and inter-domain tool, due to the TCP connection-sharing feature. (Assuming they get deployed at all, of course.) If nothing else, session mode bridging may start to look more like RTP federation. From dean.willis@softarmor.com Mon Mar 9 14:22:37 2009 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 9DEDC3A6B3B for ; Mon, 9 Mar 2009 14:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wHO9yVLN5Yu for ; Mon, 9 Mar 2009 14:22:37 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id ACEF13A6CA1 for ; Mon, 9 Mar 2009 14:22:36 -0700 (PDT) Received: from [192.168.2.104] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n29LN732013936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 9 Mar 2009 16:23:09 -0500 Message-Id: From: Dean Willis To: Jonathan Rosenberg In-Reply-To: <49B53678.3090003@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Mar 2009 16:23:02 -0500 References: <499B3B67.6000006@nostrum.com> <49B53678.3090003@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: Adam Roach , "'simple@ietf.org'" Subject: Re: [Simple] client/server standards, was: Re: Comments on draft-ietf-simple-intradomain-federation X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 21:22:37 -0000 On Mar 9, 2009, at 10:32 AM, Jonathan Rosenberg wrote: > > The difference is that the telephony and cell phone markets sell the > endpoint hardware separately from the service that endpoint > receives, which requires rigorous standardization on that interface. > The market model for email and IM/P is different - typically the > client is software based on thus does not need to be purchased > separately. That has driven the market in a different direction. > The market direction here appears to be moving the other way. Rather than just Windows 95, we now have multiple mostly incompatible versions of Windows, multiple generations of Mac OS, tens of Linux variants, and hundreds of mobile phone "operating systems". We also have the emergence of the smaller-than-notebook market, including things like the iPod Touch, UMPC, and "netbook" computers. Dozens of new OS and UI approaches are appearing in these areas. Consequently, it is no longer feasible for each "trapezoid" operator to offer a customized UNI application for their trapezoid for every device platform. It's much easier if the UNI interface is standardized, such that for each device platform one or a few competing implementations can make that device work with a broad selection of operators. This of course works against operators who try to control and constrain the user experience such that user equipment within the operator's spam of control is crippled so as to only work with services from that operator; they're going to end up with an ugly swarm of mutant devices that only their marketing department can love. -- Dean From root@core3.amsl.com Mon Mar 9 16:00:01 2009 Return-Path: X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D27B93A6781; Mon, 9 Mar 2009 16:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309230001.D27B93A6781@core3.amsl.com> Date: Mon, 9 Mar 2009 16:00:01 -0700 (PDT) Cc: simple@ietf.org Subject: [Simple] I-D Action:draft-ietf-simple-chat-04.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 23:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Multi-party Chat Using the Message Session Relay Protocol (MSRP) Author(s) : A. Niemi, et al. Filename : draft-ietf-simple-chat-04.txt Pages : 30 Date : 2009-03-09 The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-simple-chat-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-09155018.I-D@ietf.org> --NextPart-- From geir.sandbakken@tandberg.com Mon Mar 9 16:06:04 2009 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 78A723A6CC8 for ; Mon, 9 Mar 2009 16:06:04 -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 0Bq4yZ9L2XMN for ; Mon, 9 Mar 2009 16:06:03 -0700 (PDT) Received: from mail193.messagelabs.com (mail193.messagelabs.com [85.158.140.195]) by core3.amsl.com (Postfix) with SMTP id 042AF3A6884 for ; Mon, 9 Mar 2009 16:06:02 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: geir.sandbakken@tandberg.com X-Msg-Ref: server-5.tower-193.messagelabs.com!1236639996!21490134!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 3891 invoked from network); 9 Mar 2009 23:06:36 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-5.tower-193.messagelabs.com with SMTP; 9 Mar 2009 23:06:36 -0000 Received: from ultra.rd.tandberg.com ([10.47.1.15]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Mar 2009 00:06:35 +0100 Received: from [10.47.19.253] (GSandbakkenT61.rd.tandberg.com [10.47.19.253]) by ultra.rd.tandberg.com (8.13.1/8.13.1) with ESMTP id n29N6ZEt022386 for ; Tue, 10 Mar 2009 00:06:35 +0100 Message-ID: <49B5A0FE.8060705@tandberg.com> Date: Tue, 10 Mar 2009 00:06:38 +0100 From: Geir Arne Sandbakken User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Simple Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 09 Mar 2009 23:06:35.0553 (UTC) FILETIME=[B1BE7110:01C9A10B] Subject: [Simple] Multi-party Chat version 04 submitted X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 23:06:04 -0000 A new version of “Multi-party Chat Using the Message Session Relay Protocol (MSRP)” has been submitted. The new version can be found here: http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-04.txt Changes in version 04: 1. Added failure report handling for private messages 2. Added success and failure report handling for regular messages to the chat room 3. Added sending an anonymous private message example 4. Updated contact details 5. Tried to add a formal attribute definition of the nickname string extending the user element of the Conference Event Package 6. Added IANA Considerations There are currently no known open issues. Thanks, Geir Arne From jdrosen@cisco.com Tue Mar 10 12:58:15 2009 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 453AC3A69A3 for ; Tue, 10 Mar 2009 12:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 nKA1FoDBr39b for ; Tue, 10 Mar 2009 12:58:14 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 43A1A3A6B51 for ; Tue, 10 Mar 2009 12:58:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,337,1233532800"; d="scan'208";a="153703395" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 10 Mar 2009 19:58:49 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2AJwntF018065; Tue, 10 Mar 2009 12:58:49 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n2AJwnpo024961; Tue, 10 Mar 2009 19:58:49 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Mar 2009 12:58:49 -0700 Received: from [10.32.241.157] ([10.32.241.157]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Mar 2009 12:58:49 -0700 Message-ID: <49B6C678.1090003@cisco.com> Date: Tue, 10 Mar 2009 15:58:48 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ben Campbell References: <49B57FC9.3020301@cisco.com> <99441662-2C6E-4EC9-A45C-E1DC15BDE227@estacado.net> In-Reply-To: <99441662-2C6E-4EC9-A45C-E1DC15BDE227@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2009 19:58:49.0225 (UTC) FILETIME=[A0E6F790:01C9A1BA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1593; t=1236715129; x=1237579129; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20Messaging=20vs=20Presence=20(was=20Re=3 A=20Comments=20on=20draft-ietf-simple-intradomain-federation -02) |Sender:=20; bh=/zQMpP/jzso3IdNI1y8iV/tkeeQyyzxVtlsAi90dDV8=; b=XcJPbJHZR+mDxiQlXAJEAHsOrE834atBcpR+ctvP82jGcfN4sj1FZNxoaQ JGH2CAyfE7nQLVtm8ezKy+6YXqtxfBoCrdcOXXFfWuQxuBIgi37rm+kWomgD 6ldrYsWXC9; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Francois Audet , avshalom@il.ibm.com, Simple WG Subject: Re: [Simple] Messaging vs Presence (was Re: Comments on draft-ietf-simple-intradomain-federation-02) 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, 10 Mar 2009 19:58:15 -0000 I don't think session mode changes the issues that are discussed in the document. The issues are orthogonal - agreeng on session vs. pager mode, for example. -Jonathan R. Ben Campbell wrote: > > On Mar 9, 2009, at 3:44 PM, Jonathan Rosenberg wrote: > >>> --I am a little skeptical that the same set of models apply for both >>> presence and messaging. Certainly some models work better for one >>> than the other. I think it is likely to have overlaid models where >>> presence and messaging are treated differently. I can also imagine >>> buying a presence product from one vendor, and a messaging product >>> from another. >> >> This doesn't rule that out; however from a presentation perspective a >> LOT of the issues are similar - routing in particular, which gets a >> lot of discussion, is identical. I think its better to call out >> differences rather than have a whole separate doc or section just on IM. > > Does the use of session-mode messaging change anything? MSP Relays? I > think relays _could_ be a very interesting intra and inter-domain tool, > due to the TCP connection-sharing feature. (Assuming they get deployed > at all, of course.) If nothing else, session mode bridging may start to > look more like RTP federation. > > > > > -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com From rjsparks@nostrum.com Wed Mar 11 10:49:08 2009 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 EFDCF3A6AF6 for ; Wed, 11 Mar 2009 10:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyHQdhlDZel3 for ; Wed, 11 Mar 2009 10:49:08 -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 DAE1F3A6B71 for ; Wed, 11 Mar 2009 10:49:07 -0700 (PDT) Received: from dn3-232.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 n2BHnfLs014038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Mar 2009 12:49:42 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: simple mailing list Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Mar 2009 12:49:41 -0500 X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9093/Wed Mar 11 10:32:37 2009 on shaman.nostrum.com X-Virus-Status: Clean Cc: Simple Chairs Subject: [Simple] Draft Agenda: SIMPLE@IETF74 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, 11 Mar 2009 17:49:09 -0000 Please send comments/requests for changes in quickly: SIMPLE: Wednesday March 25 : 1030-1130 (Morning Session II) 10m - Administrivia 30m - MSRP-ACM - Christer draft-ietf-simple-msrp-acm-00.txt 10m - Chat - Geir Arne draft-ietf-simple-chat-04.txt 10m - Intradomain - Jonathan draft-ietf-simple-intradomain-federation-03.txt From pankaj.munjal@gmail.com Wed Mar 11 23:14:28 2009 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 4C9083A6957 for ; Wed, 11 Mar 2009 23:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHnCf6Zi7uhj for ; Wed, 11 Mar 2009 23:14:27 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 85B183A6868 for ; Wed, 11 Mar 2009 23:14:27 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id l9so357535rvb.49 for ; Wed, 11 Mar 2009 23:15:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=o6ndKiboP/eNuOTkg3In9xaNpQ6tQ2FYBIncEeDLpOA=; b=arJImWVg+xno0rlFjIo/Vmm47NUAMgbCzPFYFlYVHojdoI153bJToU7crzF/JqiqK3 F8f4/aJp2FwdXTQbPt7EfQq97K929YXWwRU+9LqKHd3Ackgg1VMnlZ229b2nwW3s2sV4 JVhy1OAs97qLFn78kastAYoR80/iVmohCQODo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=azDSkWs2t1E2DcHEqBnGh0p1+gwgrhyZtcrbjDxaFNotaguiRxF7R5dOYbq0Ebz00s MU0Rth5XG/jKgVi3rB+nQ5oHYwFxHewZRje23Vnh7MIC7PaDbyxUfBnNUkW+eED9EDcw ilCFdZ3/erltEZwGgcmNQFCPv2Gz4XMSbfo2c= MIME-Version: 1.0 Received: by 10.141.69.12 with SMTP id w12mr4831449rvk.144.1236838504404; Wed, 11 Mar 2009 23:15:04 -0700 (PDT) Date: Thu, 12 Mar 2009 11:45:04 +0530 Message-ID: From: Pankaj Munjal To: simple Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Simple] Partial Publication of elements with more than one instance possible 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, 12 Mar 2009 06:14:28 -0000 Hello all, According to the Presence RFCs, there can be a few elements like , - that can have multiple entries. However, they don't have ids associated with them to identify the instances. If my client is using partial publish to change values of one of such instances, then which instance shall be updated on the Server? (Assuming that my initial PUBLISH had more than one instance for such field) Is this scenario documented in some RFC/draft? Kindly suggest! Regards, Pankaj From smythc@avaya.com Thu Mar 12 04:58:57 2009 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 4CF843A6A62 for ; Thu, 12 Mar 2009 04:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GVFRbg8VAVq for ; Thu, 12 Mar 2009 04:58:56 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id F40893A6B12 for ; Thu, 12 Mar 2009 04:58:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,350,1233550800"; d="scan'208";a="155089107" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 12 Mar 2009 07:59:17 -0400 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.153]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 12 Mar 2009 07:59:17 -0400 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: Thu, 12 Mar 2009 11:58:44 -0000 Message-ID: <4C607BEA097DF048BEA625B974A36618A6324F@306900ANEX2.global.avaya.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Partial Publication of elements with more than oneinstance possible Thread-Index: Acmi2eeSM/RClhFdTdO7RC4spOx+oQAL88fw References: From: "Smyth, Colm (Colm)" To: "Pankaj Munjal" , "simple" Subject: Re: [Simple] Partial Publication of elements with more than oneinstance possible 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, 12 Mar 2009 11:58:57 -0000 Hi Panjaj, Each instance of and is distinguished by a locale (xml:lang). All the best, Colm Smyth Lead/Architect - Avaya Communication Manager Presence Server | Unified Communications AVAYA | smythc@avaya.com | +353 1 656 7843 (x37843) -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Pankaj Munjal Sent: 12 March 2009 06:15 To: simple Subject: [Simple] Partial Publication of elements with more than oneinstance possible Hello all, According to the Presence RFCs, there can be a few elements like , - that can have multiple entries. However, they don't have ids associated with them to identify the instances. If my client is using partial publish to change values of one of such instances, then which instance shall be updated on the Server? (Assuming that my initial PUBLISH had more than one instance for such field) Is this scenario documented in some RFC/draft? Kindly suggest! Regards, Pankaj _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From Martin.Thomson@andrew.com Thu Mar 12 20:37:29 2009 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 2939B3A6A04 for ; Thu, 12 Mar 2009 20:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdTBy3doggTP for ; Thu, 12 Mar 2009 20:37:28 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id EB5D93A69F4 for ; Thu, 12 Mar 2009 20:37:27 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_12_22_57_56 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 12 Mar 2009 22:57:56 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 22:38:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 12 Mar 2009 22:38:01 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-garcia-simple-indirect-presence-publish-01 Thread-Index: AcmjjRxhLu/VGJ87QOa4uH6KuQjAMw== From: "Thomson, Martin" To: , , X-OriginalArrivalTime: 13 Mar 2009 03:38:04.0156 (UTC) FILETIME=[1DBF43C0:01C9A38D] Cc: Simple WG Subject: [Simple] Comments on draft-garcia-simple-indirect-presence-publish-01 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 03:37:29 -0000 SGkgTWlndWVsLCBIYW5uZXMsIEhlbm5pbmcsDQoNCk9uIHRoZSB3aG9sZSwgSSB0aGluayB0aGF0 IHRoaXMgZG9jdW1lbnQgZ2l2ZXMgZmFpciB0cmVhdG1lbnQgdG8gdGhlIHByb2JsZW0uICBBdCBw cm9ibGVtIHRoYXQgSSBhbSBxdWl0ZSBpbnRlcmVzdGVkIGluIHNlZWluZyBzb2x2ZWQuDQoNCkdl bmVyYWwgY29tbWVudHM6DQoNClRoaXMgZG9jdW1lbnQgbmVlZHMgdG8gZ2l2ZSB0aGUgY29uY2Vw dCBvZiBwcmVzZW5jZSBjb21wb3NpdGluZyBtb3JlIHRob3JvdWdoIHRyZWF0bWVudC4gIFBhcnRp Y3VsYXJseSB3aGVuIHlvdSBsb29rIGF0IHRoZSBkYXRhIG1vZGVsIGFuZCByaWNoIHByZXNlbmNl IHBsdXMgbG9jYXRpb24sIHRoZXJlIGlzIGEgcm9sZSB0aGF0IGEgUEEgKHBvdGVudGlhbGx5KSBw bGF5cyBpbiBicmluZ2luZyBhbGwgdGhlc2UgY29tcG9uZW50cyB0b2dldGhlci4gIEluIGVmZmVj dCwgd2hlcmUgcHJlc2VuY2UgaW5mb3JtYXRpb24gaXMgcHJvdmlkZWQgYnkgcmVmZXJlbmNlLCB0 aGUgUEEgaXMgdGhlbiBhYmxlIHRvIHRyZWF0IHRoZSBzZXJ2ZXIgYXMgYW5vdGhlciBwcmVzZW5j ZSBzb3VyY2UuICBUaGlzIGNvbmNlcHQgaXMgYSBrZXkgb25lIHRoYXQgZWxldmF0ZXMgdGhpcyBk b2N1bWVudCB0byBnZW5lcmFsIGFwcGxpY2FiaWxpdHkgZm9yIGFueSB0eXBlIG9mIHByZXNlbmNl IGluZm9ybWF0aW9uLg0KDQpJbiB0aGlzIHJlZ2FyZCwgeW91IG1pZ2h0IGZpbmQgdGhlIGRlZmlu aXRpb24gb2YgcHJlc2VuY2Ugc291cmNlIGluIGRyYWZ0LXRob21zb24tc2ltcGxlLWNvbnQtcHJl c2VuY2UtdmFsLXJlcSB0byBiZSBoZWxwZnVsLg0KDQpJIHRoaW5rIHRoYXQgdGhlIHRlcm1pbm9s b2d5IGNvdWxkIGJlIG1vcmUgY2xvc2VseSBhbGlnbmVkIHdpdGggR2VvcHJpdiB0ZXJtaW5vbG9n eSB3aGVuIHRhbGtpbmcgYWJvdXQgR2VvcHJpdiBwcm90b2NvbHMgYW5kIHJvbGVzLiAgR2VvcHJp diBkb2N1bWVudHMgdXNlIHRoZSB0ZXJtIGxvY2F0aW9uIGluZm9ybWF0aW9uIHNlcnZlciAoTElT KSBpbnN0ZWFkIG9mICJMQ1Agc2VydmVyIi4NCg0KRm9yIGNvbnNpc3RlbmN5IHdpdGggMzg1Niwg dGhlIHRlcm0gcHJlc2VuY2UgYWdlbnQgKFBBKSBpcyBtb3JlIGFwcHJvcHJpYXRlIHRoYW4gcHJl c2VuY2Ugc2VydmVyLg0KDQpTcGVjaWZpY3M6DQoNClNlY3Rpb24gMS4xOg0KDQpSYXRoZXIgdGhh biB1c2UgdGhlIGdlbmVyaWMgdGVybSAicmVmZXJlbmNlIiBpbiB0aGlzIGNvbnRleHQsIEkgdGhp bmsgdGhhdCBpdCBpcyByZWFzb25hYmxlIHRvIHVzZSAibG9jYXRpb24gVVJJIiBhcyBpbnRyb2R1 Y2VkIGJ5IGRyYWZ0LWlldGYtZ2VvcHJpdi1sYnlyLXJlcXVpcmVtZW50cy4NCg0KRmlndXJlIDEg aXMgZW50aXRsZWQgIkN1cnJlbnQgR2VvbG9jYXRpb24gUHJvdG9jb2xzIFJlbGF0aW9uc2hpcCIs IGJ1dCB0byBiZSBjb21wbGV0ZWx5IGNvcnJlY3QgaXQgaXMgZGVzY3JpYmluZyB0aGUgcmVsYXRp b25zaGlwIGJldHdlZW4gY3VycmVudCBwcmVzZW5jZSBwcm90b2NvbHMgYW5kIHRoZSBnZW9sb2Nh dGlvbiBwcm90b2NvbHMuDQoNClRoaXMgc3RhdGVtZW50IChhc2lkZSBmcm9tIG5lZWRpbmcgcy9z ZW5kL3NlbnQvKSBpcyBub3QgcXVpdGUgY29ycmVjdC4NCg0KICAgVGhlIGtpbmQgb2YgcmVmZXJl bmNlIHRoYXQgaXMgZmlyc3QgYWNxdWlyZWQgYW5kIHRoZW4gc2VuZCB0byB0aGUNCiAgIGxvY2F0 aW9uIHJlY2lwaWVudCBkZXRlcm1pbmVzIHRoZSB2YWx1ZSB0aGF0IHRoZSBsb2NhdGlvbiByZWNp cGllbnQNCiAgIGdldHMgaW4gc3RlcCAzLiAgU2VjdGlvbiAxLjIgZGlzY3Vzc2VzIGxvY2F0aW9u IFVSSXMuDQoNCiJraW5kIG9mIHJlZmVyZW5jZSIgaXMgYSBiaXQgdmFndWUuICBJIGFzc3VtZSB0 aGF0IGl0IHJlZmVycyB0byB3aGV0aGVyIHRoZSByZWZlcmVuY2UgaXMgYSBVUkkgb3IgbWF5YmUg dGhlIGFjdHVhbCBVUkkgc2NoZW1lIHVzZWQuICBIb3dldmVyLCB0aGUgdHlwZSBvZiByZWZlcmVu Y2UgaXMgdW5saWtlbHkgdG8gc2F5IGFueXRoaW5nIGFib3V0IHRoZSByZXNvdXJjZSBpdCByZWZl cmVuY2VzLg0KDQpGaWd1cmUgMiBzZWVtcyBvcnBoYW5lZCAtIHRoZXJlIGlzIG5vIHN1cnJvdW5k aW5nIHRleHQuICBJdCdzIGtleSB0byB0aGUgZGlzY3Vzc2lvbiAtIGl0J3MgdGhlIGNvcmUgb2Yg d2hhdCB0aGUgZG9jdW1lbnQgcHJvcG9zZXMsIHNvIGl0IG5lZWRzIHByb3NlIHRvIHN1cHBvcnQg aXQuDQoNClNlY3Rpb24gMS4yOg0KDQpUaGUga2V5IG1lc3NhZ2UgbWlzc2luZyBmcm9tIHRoZSBp bnRyb2R1Y3Rpb24gb2YgdGhpcyBzZWN0aW9uIGlzIGFic2VudC4gIFRoYXQgaXMsIGEgbG9jYXRp b24gVVJJIGlzIGFuIGV4YW1wbGUgb2YgYSByZWZlcmVuY2UgdG8gcHJlc2VuY2UgaW5mb3JtYXRp b24uICBUd28gdGhpbmdzIGRpc3Rpbmd1aXNoIGl0IGZyb20gdGhlIGdlbmVyaWMgInJlZmVyZW5j ZSIgcmVmZXJyZWQgdG8gaW4gZGlzY3Vzc2lvbiBiZWZvcmUgdGhpcyBwb2ludDogKDEpIGl0J3Mg YSBVUkkgYW5kICgyKSBpdCByZWZlcnMgdG8gbG9jYXRpb24gaW5mb3JtYXRpb24gb25seS4NCg0K KEluY2lkZW50YWxseSwgSSBkb24ndCB0aGluayB0aGF0IGl0J3Mgd29ydGggeW91ciB3aGlsZSBj b250aW51aW5nIHRvIGRpc2N1c3MgcmVmZXJlbmNlcyBlbnRpcmVseSBpbiB0aGUgYWJzdHJhY3Qg LSBsZXQncyBqdXN0IGFzc3VtZSB0aGF0IHRoZXkgd2lsbCBiZSBVUklzIGFuZCBtb3ZlIG9uLikN Cg0KSSBkb24ndCB0aGluayB0aGF0IHRoaXMgc2VjdGlvbiBuZWVkcyBhIGRpc2N1c3Npb24gb24g c3RhdGljIGFuZCBkeW5hbWljIGxvY2F0aW9uIFVSSXMuICBUaGlzIGRpZ3Jlc3Npb24gZGlzdHJh Y3RzIGZyb20gdGhlIG1haW4gZ29hbCBvZiB0aGUgZHJhZnQuICBJdCBpcyBzYWZlciAoYW5kIHVs dGltYXRlbHkgZWFzaWVyKSB0byBhc3N1bWUgdGhhdCB0aGUgZG9jdW1lbnQgcmVmZXJlbmNlZCBi eSBhIGxvY2F0aW9uIFVSSSBpcyBkeW5hbWljLiAgVG8gdGhhdCBlbmQsIHRoZSBwcml2YWN5IGRp c2N1c3Npb24gY2FuIGJlIGRyb3BwZWQgYW5kIG1vdmVkIHRvIGEgbW9yZSBhcHByb3ByaWF0ZSBw bGFjZSAoZHJhZnQtaWV0Zi1nZW9wcml2LWxieXItcmVxdWlyZW1lbnRzIG9yIGRyYWZ0LWJhcm5l cy1nZW9wcml2LWxvLXNlYyBtYXliZSkuDQoNClNlY3Rpb24gMS4zOg0KDQpQcmVzZW5jZSBBZ2Vu dCwgUHJlc2VuY2UgU291cmNlLCBwcmVzZW5jZSB0ZXJtcy4uLiBMb2NhdGlvbiBVUkksIExSLCBM UywgTElTLCBnZW9wcml2IHRlcm1zLi4uICBNYXliZSBhZGQgYSBicmllZiBub3RlIGRpc3Rpbmd1 aXNoaW5nIGxvY2F0aW9uIHNlcnZlciBmcm9tIHJlZ2lzdHJhciBhcyB0aGlzIGJlY29tZXMgYW4g b3ZlcmxvYWRlZCB0ZXJtLg0KDQpTZWN0aW9uIDI6DQoNCkknZCBsaWtlIHRvIHNlZSB0aGlzIGVu dGlyZSBzZWN0aW9uIG1hZGUgZ2VuZXJpYy4gIFRoaXMgZG9lc24ndCBuZWVkIHRvIGJlIGxvY2F0 aW9uLXNwZWNpZmljLCBldmVuIGlmIGxvY2F0aW9uIHJlbWFpbnMgdGhlIG9ubHkgdXNlIGZvciB0 aGUgZm9yZXNlZWFibGUgZnV0dXJlLiAgaS5lLjogIkEgcHJlc2VudGl0eSBhY3F1aXJlcyBhIHJl ZmVyZW5jZSB0byBwcmVzZW5jZSBpbmZvcm1hdGlvbiBpbiB0aGUgZm9ybSBvZiBhIFVSSS4iICBU aGVuIHByb3ZpZGUgYW4gZXhhbXBsZTogIkZvciBleGFtcGxlLCBhIEhFTEQgcmVxdWVzdCBpcyBt YWRlIHRvIGEgTElTIHJlcXVlc3RpbmcgYSBsb2NhdGlvbiBVUkkuIg0KDQpJIG9iamVjdCB0byB0 aGUgcmVzdHJpY3Rpb24gdG8gc2lwOiBvciBzaXBzOiBVUklzLiAgSSBzZWUgbm8gcmVhc29uIHdo eSBhIFBBIHRoYXQgaXMgc3VpdGFibHkgZXF1aXBwZWQgY291bGRuJ3QgbWFrZSBhbiBIVFRQIHJl cXVlc3QuICBZb3UgYWxzbyBmb3Jnb3QgcHJlczosIGEgc2NoZW1lIHRoYXQgc2VlbXMgcXVpdGUg YXBwcm9wcmlhdGUuDQoNCkFzIGZvciBvcHRpb25zLCBvcHRpb24gMSBpc24ndCB0ZXJyaWJsZSwg YnV0IG9wdGlvbiAzIGlzIHF1aXRlIGJhZC4gIEkgbGlrZSBvcHRpb24gMi4gIFlvdSBzZWUsIEdl b2xvY2F0aW9uIGlzIHJhdGhlciB0b28gc3BlY2lmaWMgdG8gbG9jYXRpb24gaW5mb3JtYXRpb24u ICBUaGVyZSBpcyBhIHJpc2sgdGhhdCB0aGUgc2VtYW50aWNzIG9mIEdlb2xvY2F0aW9uIGNvdWxk IGJlIGluY29tcGF0aWJsZSB3aXRoIHdoYXQgdGhpcyBuZXcgZnVuY3Rpb25hbGl0eSBtaWdodCB3 YW50LiAgTW9yZSBpbXBvcnRhbnRseSwgSSdkIGxpa2UgdG8gdXNlIHNvbWV0aGluZyB0aGF0IGlz IG5vdCBzcGVjaWZpYyB0byBsb2NhdGlvbiBpbmZvcm1hdGlvbi4NCg0KQSB3aGlsZSBiYWNrICJH ZW9sb2NhdGlvbiIgd2FzIGNhbGxlZCBqdXN0ICJMb2NhdGlvbiIuICBUaGF0IGNvbmZsaWN0ZWQg d2l0aCBhbiBIVFRQIGhlYWRlciB0aGF0IGFscmVhZHkgaGFzIGNsZWFyIHNlbWFudGljcyB0aGF0 IG1pZ2h0IGJlIGNvbmZ1c2VkIHdpdGggdGhlIGludGVudCBvZiB0aGUgR2VvbG9jYXRpb24gaGVh ZGVyLiAgKCJMb2NhdGlvbiIgdGFraW5nIHRoZSBvbGQtZmFzaGlvbmVkIF9uZXR3b3JrXyBsb2Nh dGlvbiBtZWFuaW5nLikgIElmIHlvdSBsb29rIGF0IHRob3NlIHNlbWFudGljcyB0aGV5IGFyZSAo dG8gbWUpIGEgZmFpcmx5IGNsb3NlIG1hdGNoIHdpdGggd2hhdCB5b3UgYXJlIGxvb2tpbmcgZm9y LiAgVGhlICJMb2NhdGlvbiIgaGVhZGVyIHNheXM6ICJ0aGUgYm9keSBvZiB0aGlzIG1lc3NhZ2Ug Y2FuIGJlIGZvdW5kIGhlcmU6IDxVUkk+Ii4gIA0KDQpUaGUgZHJhd2JhY2sgY2FuIGJlIGFkZHJl c3NlZCBieSBoYXZpbmcgdGhlIHNlcnZlciBpbmRpY2F0ZSB0aGF0IGl0IHVuZGVyc3Rvb2QgdGhl IGhlYWRlciBzb21laG93LiAgSSdtIG5vdCB0aGUgZXhwZXJ0IGhlcmUsIGJ1dCB0aGlzIGRvZXNu J3Qgc2VlbSBpbnRyYWN0YWJsZS4gIE1heWJlIHRoaXMgaXMgYSBjYXNlIGZvciBhIG5ldyAnaW5k aXJlY3RwdWInIFJlcXVpcmUgaGVhZGVyIHRhZy4gIEEgNDIwIHdvdWxkIGluZGljYXRlIHRoYXQg dGhlIFVBQyBuZWVkcyB0byBnbyBvZmYgYW5kIGRlcmVmZXJlbmNlIGl0c2VsZi4NCg0KT25jZSB5 b3UgbWFrZSBhIGRlY2lzaW9uIChhbmQgSSdkIGVuY291cmFnZSB5b3UgdG8gY29uc2lkZXIgdGhl IGFib3ZlKSwgdGhlcmUncyBvYnZpb3VzbHkgYSBsb3Qgb2Ygd29yayB0byBkbyBkZWZpbmluZyBo ZWFkZXJzLCB3cml0aW5nIGV4YW1wbGVzIGFuZCBzbyBmb3J0aC4NCg0KU2VjdGlvbiA0Og0KDQpJ IGRvbid0IHRoaW5rIHRoYXQgZG9pbmcgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYnkgcmVmZXJl bmNlIGlzIHJpZ2h0LiAgVGhlcmUgaXMgZ29vZCB0ZXh0IG9uIHRoaXMgaW4gZ2VvcHJpdiBkb2N1 bWVudHM6IHRoZSBhZm9yZW1lbnRpb25lZCBkcmFmdC1pZXRmLWdlb3ByaXYtbGJ5ci1yZXF1aXJl bWVudHMgb3IgZHJhZnQtYmFybmVzLWdlb3ByaXYtbG8tc2VjLCBwbHVzIGRyYWZ0LWlldGYtZ2Vv cHJpdi1zaXAtbG8tcmV0cmFuc21pc3Npb24gYWxsIGhhdmUgdXNlZnVsIHRleHQgYXMgd2VsbC4N Cg0KSW4gdGhlIGVuZCwgdGhlIHNlY3VyaXR5IHN0b3J5IGlzIGEgbG90IHNpbXBsZXIgdGhhbiBz aXAtbG9jYXRpb24tY29udmV5YW5jZS4gIEl0J3MgbW9zdGx5IGFib3V0IHByaXZhY3kuICBUaGVy ZSBhcmUgdHdvIHN0b3JpZXMgdG8gdGVsbDogcG9zc2Vzc2lvbiBtb2RlbCB3aGVyZSB5b3UgcmVs eSBvbiBjaGFubmVsIHNlY3VyaXR5LCBhbmQgYWNjZXNzIGNvbnRyb2wgbW9kZWwsIHdoZXJlIHlv dSByZWFsbHkgZG9uJ3QgY2FyZSB3aG8gZ2V0cyB0aGUgcmVmZXJlbmNlLg0KDQpSZWdhcmRzLA0K TWFydGluDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBt ZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250 YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1h dGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5h dXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ0K From rjsparks@nostrum.com Wed Mar 25 13:06:09 2009 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 581693A6D73; Wed, 25 Mar 2009 13:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOO9OibTZSSH; Wed, 25 Mar 2009 13:06:08 -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 ED81F3A6B91; Wed, 25 Mar 2009 13:06:07 -0700 (PDT) Received: from [130.129.18.254] (dhcp-12fe.meeting.ietf.org [130.129.18.254]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n2PK6RYk098444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Mar 2009 15:06:58 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <29F5ACF3-4CB8-4B0D-A6D1-6F13C62BDE36@nostrum.com> From: Robert Sparks To: SIP IETF , simple mailing list Content-Type: multipart/alternative; boundary=Apple-Mail-26--141133477 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Mar 2009 13:06:27 -0700 X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 130.129.18.254 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.94.2/9167/Wed Mar 25 13:06:32 2009 on shaman.nostrum.com X-Virus-Status: Clean Subject: [Simple] Reminder: SIPit24 registration closes April 30 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, 25 Mar 2009 20:06:09 -0000 --Apple-Mail-26--141133477 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit SIPit 24 registration closes April 30. Please register now if you haven't done so already. Be sure to make your lodging reservations early. Links to more information, including the registration site are below. Thanks, RjS On Mar 3, 2009, at 8:51 AM, Robert Sparks wrote: > Registration for SIPit 24 is open! > SIPit 24 will be held May 18-22, 2009 in Akihabara, Tokyo, Japan > hosted by JPNIC and NICT. > Additional information is available at http://www.sipit.net and http://www.nic.ad.jp/en/sipit24/ --Apple-Mail-26--141133477 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit SIPit 24 registration closes April 30. Please register now if you  
haven't done so already.

Be sure to make your lodging reservations early.

Links to more information, including the registration site are below.

Thanks,

RjS

On Mar 3, 2009, at 8:51 AM, Robert Sparks wrote:

Registration for SIPit 24 is open!
SIPit 24 will be held May 18-22, 2009 in Akihabara, Tokyo, Japan  
hosted by JPNIC and NICT.
Additional information is available at http://www.sipit.net and http://www.nic.ad.jp/en/sipit24/
--Apple-Mail-26--141133477-- From ben@estacado.net Mon Mar 30 14:00:18 2009 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 320B83A6D64 for ; Mon, 30 Mar 2009 14:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxfAPpF0TBb7 for ; Mon, 30 Mar 2009 14:00:17 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 6EFB73A6CBE for ; Mon, 30 Mar 2009 14:00:16 -0700 (PDT) Received: from dn3-213.estacado.net (dn3-213.estacado.net [172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n2UL1B2K007911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 30 Mar 2009 16:01:12 -0500 (CDT) (envelope-from ben@estacado.net) Message-Id: From: Ben Campbell To: Simple WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 30 Mar 2009 16:01:11 -0500 X-Mailer: Apple Mail (2.930.3) Cc: Simple Chairs Subject: [Simple] Draft Minutes for SIMPLE at IETF74 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 21:00:18 -0000 Please review. Send comments or corrections to the list and/or chairs ASAP. Thanks! Ben. ------ Minutes - SIMPLE IETF74 - Wednesday 25 March 2009 - San Francisco, CA, USA Summary: * ACM Draft - The comedia use mostly non-controversial. There are open issues concerning backwards compatibility with MSRP relays. Discussion needs to happen on the list. * Multi-party Chat - The draft will go into WGLC shortly after IETF. * Intra-Domain Bridging - We discussed open issues concerning the taxonomy, role of publish, and policy composition. We ran out of time before completing discussion. The discussion was deferred to the list. Raw notes from Dean Willis: -------------------------------------- Notes on SIMPLE at IETF 74 recorded by Dean Willis Chaired by Ben Campbell, Hisham Khartabil Meeting called to order 10:30 AM Note well presented. Agenda accepted as presented Chairs reviewed status of WG, slides presented. No volunteers for Jabber scribe (note: Dean Willis tried but could not connect, it was working for him yesterday.) Topic: Alternative Connection Model for MSRP by Christer Holmberg Slides presented Rationale for this work reviewed. Item: COMEDIA for ACM. No issues have been raised. Chair polled room, consensus that the approach is not controversial. Will move forward with this working assumption. Issue: Backward Compatibility with SBC/ALG In Path Hadriel believes that the requirement to support the setup attribute in the far-end client may introduce a backward compatibility issue. He does not find this to be a problem, just wants it clarified. Modification of SDP URI was to support relays. No way to support current relays without putting new requirements on clients, and that is OK. Derek noted that there may be conditions in which this negotiation will fail with legacy systems; would rather establish up front that either comedia or a relay is required when that is the case. Ben wishes to avoid having this decision produce islands that cannot connect with each other, and that we should make every effort to make ACM work with current usage as in 4976. Hadriel assets that there is no known proposal for making RFC 4975 work without a change to RFC 4975. Consequently, there is no requirement to make this work. o Question by chairs: Do we need to support the architecture of having MSRP relays? No consensus, median split. Derek asked to revise the question: Should we revise RFC 4975 to make it work? Ben noted that the c-line approach in RFC 4975 is there for a reason, changing it would not be trivial. This probably would have consequences. Further discussion focused on this point. Discussion deferred until after Christer presents proposed solution (next slide). Issue: Alt 2 changes to RFC 4975 Noted that this change has little impact of the security properties, as they are all in the right hand side of the session ID. Issue: TLS impacts with SBC Noted that MSRP already requires hop by hop segmentation of TLS, but that this is visible to the users, whereas the breakage of e2e introduced here is transparent and possible non-consensual. Issue: TLS Certificate Matching This is primarily an impact on server-class devices. Proposed that servers could use a fingerprint approach as used for clients in 4975. Rough consensus to add the proposed negotiation mechanism and guidance, adding discussion of fingerprint usage and consequences. Question: Is this a proposal to solve legacy compatibility by requiring changes to the legacy end points: Answer: Yes. Noted that this is a media-plane question, and we usually negotiate media-plane with SDP. Endpoints can support both approaches and negotiate. Chair noted that there are more opinions in the room than there are on the list. Participants are asked to actually contribute on-list. Topic Multi-Party Chat MSRP by Geir Arne Sandbakken Slides presented Status reviewed. Are we ready for WGLC? Poll: Who has read this version: a few. Noted that the previous version got lots of feedback. Also noted that this approach does not conflict with XCON. General consensus in favor of WGLC noted. Topic: Intra Domain Bridging by Jonathan Rosenberg Slides presented Status reviewed. Open Issue: Partitioned, Unioned, Exclusive taxonomy Proposed to split three terms to 2x2 grid one/many vs static/dynamic Consensus to keep existing terminology noted. Poll: Who has read this or a previous version? (many) Open Issue: Role of Publish Proposal to add discussion accepted. Open Issue: Policy composition and union federation Is common-policy union the right model? Noted that this might create surprises to user-expectations. Need to be able to show what is visible at the root reflects what would be seen by crawling the tree, since users can crawl. Noted that the filter-composition policy seems to mostly correct for user expectations. No consensus noted, further discussion deferred to list. From KHBJ46@motorola.com Tue Mar 31 03:42:36 2009 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 2A19E3A6C50 for ; Tue, 31 Mar 2009 03:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7D6JD1ty9uSg for ; Tue, 31 Mar 2009 03:42:35 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 374CC3A68CD for ; Tue, 31 Mar 2009 03:42:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: KHBJ46@motorola.com X-Msg-Ref: server-8.tower-55.messagelabs.com!1238496212!94378088!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 18237 invoked from network); 31 Mar 2009 10:43:33 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Mar 2009 10:43:33 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n2VAhWVu000433 for ; Tue, 31 Mar 2009 03:43:32 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id n2VAhW7T001607 for ; Tue, 31 Mar 2009 05:43:32 -0500 (CDT) Received: from ZMY16EXM70.ds.mot.com (zmy16exm70.ap.mot.com [10.179.4.29]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id n2VAhVih001596 for ; Tue, 31 Mar 2009 05:43:31 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Mar 2009 18:43:29 +0800 Message-ID: <7FAD6FCE52421841A11B441DEF3A88CA0216BF4B@ZMY16EXM70.ds.mot.com> In-Reply-To: <4C607BEA097DF048BEA625B974A36618A6324F@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Regarding Feature Interaction!!! Thread-Index: Acmi2eeSM/RClhFdTdO7RC4spOx+oQAL88fwA7i83eA= References: <4C607BEA097DF048BEA625B974A36618A6324F@306900ANEX2.global.avaya.com> From: "Deka Sanjeeb Kumar-KHBJ46" To: "Smyth, Colm (Colm)" , "Pankaj Munjal" , "simple" X-CFilter-Loop: Reflected Subject: [Simple] Regarding Feature Interaction!!! 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, 31 Mar 2009 10:42:36 -0000 =20 Hi All, Can anyone help me out for the following: Party A has "Call Waiting" enabled.=20 Party A is in conversation with Emergency(E911) Server. Party B makes a call to Party A during the conversation. I just wanted to know whether Party A should get a Call Waiting tone or it sends a 486 Busy response to Party B. Moreover, is there any document available which explains about the priority of a feature during Feature Interaction? Regards, Sanjeeb _______________________________________________ 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 pankaj.munjal@gmail.com Tue Mar 31 04:27:25 2009 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 2CF353A6C8C for ; Tue, 31 Mar 2009 04:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsdqYxCWHF3j for ; Tue, 31 Mar 2009 04:27:24 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 5B8613A692E for ; Tue, 31 Mar 2009 04:27:21 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so2499650rvb.49 for ; Tue, 31 Mar 2009 04:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=jLgSh43sTGSgdyuuY+chzpjoRcjz8Fj1tuWT2JyfDfU=; b=dkPsR5zY8CwLawedEdxKHI9BYMd5tdqlp5l4/4F+g7egYQqj+5uXvpyeKUr5dPtyed vLxyubo9eGeqo6ZGHbfbqIUZfJ2naCm1mUDgDv9aMJVyrn5FwnpqvsAK4NLfSOnZXn87 JFMJrs6uS5HUMHEFxR+bRwil3CRJPmGqMklOU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=vp9+0wtCDqdd0W1gnW6jPyhA6s/RwxQjnQkf+aW/mo/LK+J2ZZ8nNm+BJ3kH01AiPz nhYcNiBhwzIjiKIg+9gwuzpiEqqD0v/wNiudjdouoCs8BOFCA7elMXg0JR7Ld3euQKq/ o+eVOzt/go3fLhxrQCIsQrdjZQfGjUnFN+wZU= MIME-Version: 1.0 Received: by 10.141.170.10 with SMTP id x10mr3437150rvo.56.1238498900057; Tue, 31 Mar 2009 04:28:20 -0700 (PDT) Date: Tue, 31 Mar 2009 16:58:20 +0530 Message-ID: From: Pankaj Munjal To: Simple@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Simple] Subscription refresh query 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, 31 Mar 2009 11:27:25 -0000 Hello all, I have a query on Subscription refresh on "presence" event package. RFC: 5263, Section 4.5: "If the watcher encounters a processing error while processing the received 'application/pidf-diff+xml' encoded presence document, look at Section 5.1 of [8]. In this case, the watcher SHOULD renew the subscription. The watcher MAY also fall back to normal presence operations by not inserting 'application/pidf-diff+xml' in a new SUBSCRIBE request." My comprehension for this statement is that we need to refresh the Subscription. But to do so, the Presence Client needs to send SUBSCRIBE request on the same dialog with updated Accept Headerr. Now the question is, for a Subscribe refresh request, does the Presence server update it's complete subscription details according to the new SUBSCRIBE request?(Allow Header, exires Header) Or does it consider/update only "expires" based on the new SUBSCRIBE. I'm asking this because, RFC 3265, Section 3.1.6.4. (Refreshing of Subscriptions) states: "When a notifier receives a subscription refresh, assuming that the subscriber is still authorized, the notifier updates the expiration time for the subscription" Here it is talking about only "expiration time". Shall this be a restriction on the Presence server that it shall update only expiration time from SUBSCRIBE refresh request, and not other modified Headers? Kindly clarify. Regards, Pankaj -- All the desirable things in life are either illegal, expensive, fattening, or married to someone else!! From KHBJ46@motorola.com Tue Mar 31 05:43:13 2009 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 D79D33A6CA2 for ; Tue, 31 Mar 2009 05:43:13 -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 Mcp89niATq1D for ; Tue, 31 Mar 2009 05:43:13 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id 1DA9E3A6BFF for ; Tue, 31 Mar 2009 05:43:13 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: KHBJ46@motorola.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1238503451!24542867!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 14084 invoked from network); 31 Mar 2009 12:44:11 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (136.182.1.13) by server-14.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Mar 2009 12:44:11 -0000 Received: from il27exr01.cig.mot.com ([10.17.196.70]) by motgate3.mot.com (8.14.3/8.14.3) with ESMTP id n2VCiAjD028969 for ; Tue, 31 Mar 2009 05:44:10 -0700 (MST) Received: from il27vts01 (il27vts01.cig.mot.com [10.17.196.85]) by il27exr01.cig.mot.com (8.13.1/Vontu) with SMTP id n2VCiALs009764 for ; Tue, 31 Mar 2009 07:44:10 -0500 (CDT) Received: from ZMY16EXM70.ds.mot.com (zmy16exm70.ap.mot.com [10.179.4.29]) by il27exr01.cig.mot.com (8.13.1/8.13.0) with ESMTP id n2VCi9wm009739 for ; Tue, 31 Mar 2009 07:44:10 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Mar 2009 20:44:08 +0800 Message-ID: <7FAD6FCE52421841A11B441DEF3A88CA0216BF80@ZMY16EXM70.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Referred-by Header!!! Thread-Index: Acmi2eeSM/RClhFdTdO7RC4spOx+oQAL88fwA7i83eAABESt4A== From: "Deka Sanjeeb Kumar-KHBJ46" To: X-CFilter-Loop: Reflected Subject: [Simple] Referred-by Header!!! 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, 31 Mar 2009 12:43:13 -0000 Hi All, Is it necessary to send "Anonymous" in Referred-By Header of REFER when the UA has "Permanent Outgoing Caller-Id Block" enabled? It will be very helpful for me if someone show the Referred-By Header, in this case, with an example. Regards, San _______________________________________________ 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 pkyzivat@cisco.com Tue Mar 31 08:28:04 2009 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 8D35A3A6CA2 for ; Tue, 31 Mar 2009 08:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.02 X-Spam-Level: X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[AWL=0.579, 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 Z-QDGREjoZOq for ; Tue, 31 Mar 2009 08:28:03 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8C91C3A6D87 for ; Tue, 31 Mar 2009 08:28:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,453,1233532800"; d="scan'208";a="277450010" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 31 Mar 2009 15:29:03 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2VFT2K5020573; Tue, 31 Mar 2009 08:29:02 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2VFT0U9015388; Tue, 31 Mar 2009 15:29:02 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Mar 2009 11:29:01 -0400 Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Mar 2009 11:29:00 -0400 Message-ID: <49D236BC.6090406@cisco.com> Date: Tue, 31 Mar 2009 11:29:00 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Deka Sanjeeb Kumar-KHBJ46 References: <7FAD6FCE52421841A11B441DEF3A88CA0216BF80@ZMY16EXM70.ds.mot.com> In-Reply-To: <7FAD6FCE52421841A11B441DEF3A88CA0216BF80@ZMY16EXM70.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Mar 2009 15:29:00.0685 (UTC) FILETIME=[6A748BD0:01C9B215] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=992; t=1238513343; x=1239377343; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Simple]=20Referred-by=20Header!!! |Sender:=20; bh=K3g68YVOUtiBdR3tgyvtXiOzZl9XvwYbBKnKoaOY9DY=; b=DZvKp1PY/r12qjQOp8S2jJnt3mCB5LJuXrDtujadVjn3B59fWUvx/ltboT 1RvlLo1iq1fNHeylkHFQtRvVKVGefTjudP2rxz7uViieQSD2BCxI1o7R5ZCO nyaTYcmMH9; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Simple@ietf.org Subject: Re: [Simple] Referred-by Header!!! 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, 31 Mar 2009 15:28:04 -0000 The Referred-By header is *optional*. While I suppose you *could* include one containing Anonymous, IMO it would make a lot more sense to simply omit the header if you are trying to block your identity as the referrer. Thanks, Paul Deka Sanjeeb Kumar-KHBJ46 wrote: > Hi All, > > Is it necessary to send "Anonymous" in Referred-By Header of REFER when > the UA has "Permanent Outgoing Caller-Id Block" enabled? > > It will be very helpful for me if someone show the Referred-By Header, > in this case, with an example. > > Regards, > San > _______________________________________________ > 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 vkg@alcatel-lucent.com Tue Mar 31 14:13:35 2009 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 BF75C3A6991 for ; Tue, 31 Mar 2009 14:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[AWL=-1.145, BAYES_00=-2.599, MANGLED_SAVELE=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSnyIkAZ7Qha for ; Tue, 31 Mar 2009 14:13:34 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id A3F663A682B for ; Tue, 31 Mar 2009 14:13:34 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id n2VLETew001646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Mar 2009 16:14:29 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n2VLETsU007729; Tue, 31 Mar 2009 16:14:29 -0500 (CDT) Message-ID: <49D287B5.6010603@alcatel-lucent.com> Date: Tue, 31 Mar 2009 16:14:29 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Deka Sanjeeb Kumar-KHBJ46 References: <4C607BEA097DF048BEA625B974A36618A6324F@306900ANEX2.global.avaya.com> <7FAD6FCE52421841A11B441DEF3A88CA0216BF4B@ZMY16EXM70.ds.mot.com> In-Reply-To: <7FAD6FCE52421841A11B441DEF3A88CA0216BF4B@ZMY16EXM70.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: simple Subject: Re: [Simple] Regarding Feature Interaction!!! 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, 31 Mar 2009 21:13:35 -0000 Deka Sanjeeb Kumar-KHBJ46 wrote: > Can anyone help me out for the following: > > Party A has "Call Waiting" enabled. > Party A is in conversation with Emergency(E911) Server. > Party B makes a call to Party A during the conversation. > > I just wanted to know whether Party A should get a Call Waiting tone or > it sends a 486 Busy response to Party B. > > Moreover, is there any document available which explains about the > priority of a feature during Feature Interaction? Sanjeeb: Feature Interaction (FI) was a tough enough nut to crack back in the days of centralized PSTN. With the decomposed and distributed architecture of Internet telephony, it is more challenging as each endpoint thinks it knows the absolute version of the truth. There isn't any one document that talks about FI in Internet telephony. I would start with the following pointers and see where you end up: 1) Pamela Zave's research on FI at ATT (see http://www.research.att.com/~pamela/fi.html) -- this has a link to a lot of papers. 2) "Feature Interaction in Internet Telephony", Jonathan Lennox and Henning Schulzrinne. From Proceedings of the Sixth International Workshop on Feature Interactions in Telecommunications and Software Systems, May 2000. Ciao. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From hisham.khartabil@gmail.com Tue Mar 31 15:56:34 2009 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 B265B3A6B0D for ; Tue, 31 Mar 2009 15:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zamSs9--OlHL for ; Tue, 31 Mar 2009 15:56:34 -0700 (PDT) Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id CD0A63A6860 for ; Tue, 31 Mar 2009 15:56:33 -0700 (PDT) Received: by qyk36 with SMTP id 36so1189191qyk.29 for ; Tue, 31 Mar 2009 15:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=WFnh5pmdYNP2K4zTFUk/U+XEUKwcrh6A/uAWC/kejcE=; b=UKANuaMAho3lkAcV7QsOOccNcuUaY+jy5ARknHWXiE28bbOdloqxiUdxedtrySf1GP imS4s4KYWurMPg+6a/5jYYHDttslkouqvKGnQ+n0uM/kVW1287ohn36dlDPxZjkOx9q6 r4qO1Py7QK4tcF33RYjH+FNOV7MZSY4a0DKko= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=fJOgO387n9AFFnUkH1ybMmEYIVG2Tm1OIXkc7a/OxWbisxXp6TrQGEkBjXHVAsRRu1 HkLNwDr/kT6/ehE8Xrg9z6A1/3nQEmGDCfoTs/qu+fDNU3QtZVT/VnAWE+pf/TpK4va/ pNaNOtXPGWhkyI9CCREw2DwhWcA83gvvKX5p8= MIME-Version: 1.0 Received: by 10.150.203.8 with SMTP id a8mr375190ybg.246.1238540252636; Tue, 31 Mar 2009 15:57:32 -0700 (PDT) Date: Wed, 1 Apr 2009 09:57:32 +1100 Message-ID: <66cd252f0903311557k14448ac8m62a6ca46e86e2fd4@mail.gmail.com> From: Hisham Khartabil To: Simple WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP-ACM compatibility 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, 31 Mar 2009 22:56:34 -0000 The MSRP-ACM draft has an open requirements question on backwards compatibility with endpoints that use MSRP relays. In San Francisco some 20 or so people raised their hands one way or another on this question, yet only a much smaller number have engaged in the list discussion. Please offer your opinions on the following questions. We'd appreciate the reasoning behind your opinions, rather than just yes or no votes. We'd really like to hear from every person who raised a hand in San Francisco. If you stated an opinion at the microphone, please restate it here. 1) Is there a requirement for an endpoint that uses the C-line addressing mechanism in the MSRP-ACM draft to be able to talk to an endpoint that uses an MSRP relay (RFC 4976). 2) If you said yes to 1), is it acceptable to update RFC 4975 and/or RFC 4976 to achieve compatibility? If so, how extensively? Much appreciated, Hisham