From sip-bounces@ietf.org Mon Jul 02 00:40:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5DhK-0007FO-Mq; Mon, 02 Jul 2007 00:39:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5DhI-0007FI-Qh for sip-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 00:39:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5DhI-0007FA-EX for sip@ietf.org; Mon, 02 Jul 2007 00:39:36 -0400 Received: from mtssgway1.multitech.co.in ([202.54.39.98] helo=multitech.co.in) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I5DhC-0002yC-ME for sip@ietf.org; Mon, 02 Jul 2007 00:39:36 -0400 Received: (qmail 7507 invoked by uid 507); 2 Jul 2007 04:41:52 -0000 Received: from lakshmi@multitech.co.in by mtsslvpngway by uid 504 with qmail-scanner-1.16 (avp: 4.0.2.2. Clear:. Processed in 1.195708 secs); 02 Jul 2007 04:41:52 -0000 Received: from unknown (HELO multitech.co.in) (192.168.10.1) by 0 with SMTP; 2 Jul 2007 04:41:50 -0000 Received: from [192.168.4.216] (Internet_PC4 [192.168.4.216])(authenticated)by multitech.co.in with ESMTP id l614vP93011181for ; Sun, 1 Jul 2007 10:28:09 +0530 Message-ID: <4687278B.2020309@multitech.co.in> Date: Sun, 01 Jul 2007 09:33:23 +0530 From: Lakshmi User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Synonym: Copied by Synonym (http://www.modulo.ro/synonym) to: archive X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] Need clarification on video with sip stack X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hello, I am Lakshmi and a silent member of this mailing group. I need some clarification on sip stack. I am beginer of sip and got some work to work with sip. The present sip stack what we have is only carries voice information. I have to enhance this voice phone to video phone. Means needs to implement video with sip stack so that sip stack should support this video featuer with voice phone. According to my analysis , SIP doesn't require any modifications since sip concentrates on the session part and doesn't bother about what kind of session it was. And sdp needs to change to do video parameters negotiation (Hope RTP payload also). Kindly clarify this concept or guide me how to proceed to accomplish this task. And also please correct if my analysis is wrong. Regards, -Lakshmi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 02 02:24:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5FKG-0002OX-2j; Mon, 02 Jul 2007 02:23:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5FKE-0002NO-FN for sip-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 02:23:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5FKE-0002NE-4t for sip@ietf.org; Mon, 02 Jul 2007 02:23:54 -0400 Received: from wip-cdc-wd.wipro.com ([203.91.201.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5FJo-0003zs-Qb for sip@ietf.org; Mon, 02 Jul 2007 02:23:54 -0400 Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3652D18079 for ; Mon, 2 Jul 2007 11:53:30 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-cdc-wd.wipro.com (Postfix) with ESMTP id 21A2618053 for ; Mon, 2 Jul 2007 11:53:30 +0530 (IST) Received: from HYD-MDP-MBX01.wipro.com ([10.150.50.181]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Jul 2007 11:53:42 +0530 Received: from HYD-MKD-MBX01.wipro.com ([10.154.50.181]) by HYD-MDP-MBX01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Jul 2007 11:54:01 +0530 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 Subject: RE: [Sip] Need clarification on video with sip stack Date: Mon, 2 Jul 2007 11:54:28 +0530 Message-ID: <24BCDE728664A5429097057C063C9D64029FA600@HYD-MKD-MBX01.wipro.com> In-Reply-To: <4687278B.2020309@multitech.co.in> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Need clarification on video with sip stack Thread-Index: Ace8YyR+Roka4JGzR4GQ+SdkLVlT1wADieLw From: To: , X-OriginalArrivalTime: 02 Jul 2007 06:24:01.0110 (UTC) FILETIME=[9470DF60:01C7BC71] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Lakshmi, All the changes required in SIP stack is w.r.t addition of SDP capabilities to support and negotiate Video codecs and related stuff. SIP stack does not bother about RTP payload at all. It is upto your video application to code and decode the rtp payload . Regards Kamal -----Original Message----- From: Lakshmi [mailto:lakshmi@multitech.co.in]=20 Sent: Sunday, July 01, 2007 9:33 AM To: sip@ietf.org Subject: [Sip] Need clarification on video with sip stack Hello, I am Lakshmi and a silent member of this mailing group. I need some=20 clarification on sip stack. I am beginer of sip and got some work to=20 work with sip. The present sip stack what we have is only carries voice information. I=20 have to enhance this voice phone to video phone. Means needs to=20 implement video with sip stack so that sip stack should support this=20 video featuer with voice phone. According to my analysis , SIP doesn't require any modifications since=20 sip concentrates on the session part and doesn't bother about what kind=20 of session it was. And sdp needs to change to do video parameters negotiation (Hope RTP=20 payload also). Kindly clarify this concept or guide me how to proceed to accomplish this task. And also please correct if my analysis is wrong. Regards, -Lakshmi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 02 03:33:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5GPM-0001KA-Vt; Mon, 02 Jul 2007 03:33:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5GPL-0001Ca-55 for sip-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 03:33:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5GPK-0001CS-PU for sip@ietf.org; Mon, 02 Jul 2007 03:33:14 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5GPF-0000GE-LG for sip@ietf.org; Mon, 02 Jul 2007 03:33:14 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l627WigR005277; Mon, 2 Jul 2007 02:33:03 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 02:33:01 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 09:32:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Jul 2007 09:32:59 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180013717DD@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Agenda for SIP at IETF 69 in Chicago Thread-Index: Ace7glFat0kee34qQZSvhmlArShVvgAuiSOg References: From: "DRAGE, Keith \(Keith\)" To: "Dean Willis" , "IETF SIP" X-OriginalArrivalTime: 02 Jul 2007 07:32:59.0613 (UTC) FILETIME=[372E50D0:01C7BC7B] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.7 (/) X-Scan-Signature: d0396221263e298f392bc82c4294cad8 Cc: Cullen Jennings Subject: [Sip] RE: Draft Agenda for SIP at IETF 69 in Chicago X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1497727174==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1497727174== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BC7B.36EF07B8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7BC7B.36EF07B8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think we should put a couple of "do we charter" items on the agenda: =20 These are the mime body handling draft from Gonzalo, and the proposed INFO handling draft from Eric. =20 So far these are the only two that I can identify as having had discussion and for which we do not have slots. =20 Not sure whether we need a slot for corrections or not - I think Robert was suggesting an ad hoc somewhere to progress this. =20 regards =20 Keith ________________________________ From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Sunday, July 01, 2007 2:51 AM To: IETF SIP Cc: Cullen Jennings; DRAGE, Keith (Keith) Subject: Draft Agenda for SIP at IETF 69 in Chicago =09 =09 Here's the current draft agenda for SIP at IETF 69. I'm sure it is incomplete. Changes will be posted to: http://www.softarmor.com/mediawiki/index.php/SIP_Agenda_IETF_69 Draft SIP Agenda IETF 69 =09 =09 Session 1, Monday July 23 0900-1130 Grand Ballroom Start Time Topic Discussion Lead Reading List 0900 Agenda Bash and Status Chairs This document 0915 SIPS WGLC Francois Audet draft-ietf-sip-sips-05.txt =20 0945 Outbound Rohan Mahy Cullen Jennings draft-ietf-sip-outbound-09.txt =20 1015 Location Conveyance WGLC James Polk draft-ietf-sip-location-conveyance-07.txt =20 1045 Delivering R-URI and Parameters to UA Jonathan Rosenberg draft-rosenberg-sip-ua-loose-route-01.txt =20 1130 End of Session =09 =09 Session 2, Tuesday July 24 0900-1130 Grand Ballroom Start Time Topic Discussion Lead Reading List 0900 Agenda Bash and Status Chairs This document 0905 SAML Hannes Tschofenig draft-ietf-sip-saml-02.txt =20 0930 eTags For Notification Aki Niemi draft-ietf-sip-subnot-etags-00.txt 0950 Domain Certs Vijay Gurbani Scott Lawrence draft-gurbani-sip-domain-certs-05.txt =20 1020 Privacy Guidelines Mayumi Munakata draft-munakata-sip-privacy-guideline-00.txt =20 1040 Privacy Enhancements Mayumi Munakata draft-munakata-sip-privacy-new-00.txt =20 1100 Certificate Authentication Sumanth Channabasappa draft-dotson-sip-certificate-auth-03.txt =20 =09 =09 =09 =09 ------_=_NextPart_001_01C7BC7B.36EF07B8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I think we should put a couple of "do we = charter" items on=20 the agenda:
 
These are the mime body handling draft from = Gonzalo, and=20 the proposed INFO handling draft from Eric.
 
So far these are the only two that I can = identify as having=20 had discussion and for which we do not have slots.
 
Not sure whether we need a slot for corrections = or not - I=20 think Robert was suggesting an ad hoc somewhere to progress=20 this.
 
regards
 
Keith

From: Dean Willis=20 [mailto:dean.willis@softarmor.com]
Sent: Sunday, July 01, = 2007 2:51=20 AM
To: IETF SIP
Cc: Cullen Jennings; DRAGE, Keith=20 (Keith)
Subject: Draft Agenda for SIP at IETF 69 in=20 Chicago

Here's the current draft agenda for SIP at IETF 69. I'm sure it = is=20 incomplete. Changes will be posted to:
= http://www.softarmor.com/mediawiki/index.php/SIP_Agenda_IETF_69
=

Draft SIP Agenda=20 IETF 69

Session 1,=20 Monday July 23 0900-1130 Grand Ballroom

Start=20 Time
Topic
Discussion = Lead
Reading=20 List
0900
Agenda Bash=20 and Status
Chairs
This=20 document
0915
SIPS=20 WGLC
Francois=20 Audet
<= FONT=20 class=3DApple-style-span face=3DHelvetica size=3D3>draft-ietf-sip-sips-05.txt
0945
Outbound
Rohan=20 Mahy
Cullen=20 Jennings
draft-ietf-sip-outbound-09.txt
1015
Location=20 Conveyance WGLC
James=20 Polk
draft-ietf-sip-location-conveyance-07.txt
1045
Delivering=20 R-URI and Parameters to UA
Jonathan=20 Rosenberg
draft-rosenberg-sip-ua-loose-route-01.txt
1130
End of=20 Session


Session 2,=20 Tuesday July 24 0900-1130 Grand Ballroom

Start=20 Time
Topic
Discussion = Lead
Reading=20 List
0900
Agenda Bash=20 and Status
Chairs
This=20 document
0905
SAML
Hannes=20 Tschofenig
<= FONT=20 class=3DApple-style-span face=3DHelvetica size=3D3>draft-ietf-sip-saml-02.txt
0930
eTags For=20 Notification
Aki=20 Niemi
draft-ietf-sip-subnot-etags-00.txt
0950
Domain=20 Certs
Vijay=20 Gurbani
Scott=20 Lawrence
draft-gurbani-sip-domain-certs-05.txt
<= /TR>
1020
Privacy=20 Guidelines
Mayumi=20 Munakata
draft-munakata-sip-privacy-guideline-00.txt
=
1040
Privacy=20 Enhancements
Mayumi=20 Munakata
draft-munakata-sip-privacy-new-00.txt
<= /TR>
1100
Certificate=20 Authentication
Sumanth=20 Channabasappa
draft-dotson-sip-certificate-auth-03.txt

------_=_NextPart_001_01C7BC7B.36EF07B8-- --===============1497727174== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1497727174==-- From sip-bounces@ietf.org Mon Jul 02 09:56:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5MO2-0001Cb-M9; Mon, 02 Jul 2007 09:56:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5MO0-00015B-Ds for sip-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 09:56:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5MO0-00012Q-31; Mon, 02 Jul 2007 09:56:16 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5MNz-0007gM-Uk; Mon, 02 Jul 2007 09:56:16 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A6EDE17623; Mon, 2 Jul 2007 13:55:45 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I5MNV-00012s-8G; Mon, 02 Jul 2007 09:55:45 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 02 Jul 2007 09:55:45 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sip@ietf.org Subject: [Sip] Last Call: draft-ietf-sip-gruu (Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)) to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The IESG has received a request from the Session Initiation Protocol WG (sip) to consider the following document: - 'Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-07-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-14.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11271&rfc_flag=0 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 02 14:31:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Qga-00051f-PN; Mon, 02 Jul 2007 14:31:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5Qga-00051V-2h for sip-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 14:31:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5QgZ-00051N-PW for sip@ietf.org; Mon, 02 Jul 2007 14:31:43 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5QgV-0002uA-69 for sip@ietf.org; Mon, 02 Jul 2007 14:31:43 -0400 Received: from [65.65.155.30] (helo=[192.168.1.2]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I5QgR-0005cz-L3; Mon, 02 Jul 2007 13:31:35 -0500 In-Reply-To: <7374777208BDC7449D5620EF9423256706D0D437@esealmw113.eemea.ericsson.se> References: <5D1A7985295922448D5550C94DE29180013717DD@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF9423256706D0D437@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <273BBA77-21EC-4589-8E9F-867B6C90CA05@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] RE: Draft Agenda for SIP at IETF 69 in Chicago Date: Mon, 2 Jul 2007 13:31:19 -0500 To: Christer Holmberg (JO/LMF) X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: IETF SIP , Cullen Jennings , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 2, 2007, at 4:21 AM, Christer Holmberg (JO/LMF) wrote: > Hi, > > Regarding the loose route issue, I still haven't received any reply > on whether the problem can be solved with the P-Called-Party header > - in which case there would be no problem to discuss. > well, whether it can or can't sounds like something to discuss . . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 02 14:42:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Qqd-0001V3-BA; Mon, 02 Jul 2007 14:42:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5Qqa-000176-RH for sip-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 14:42:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Qqa-0000zb-Dd for sip@ietf.org; Mon, 02 Jul 2007 14:42:04 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5QqC-0005TZ-2v for sip@ietf.org; Mon, 02 Jul 2007 14:41:44 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 02 Jul 2007 11:41:39 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAObiiEarR7PDh2dsb2JhbACPKAIJDiw X-IronPort-AV: i="4.16,488,1175497200"; d="scan'208"; a="165206211:sNHT25541100" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l62IfdVS002898; Mon, 2 Jul 2007 11:41:39 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l62IfOXX009385; Mon, 2 Jul 2007 18:41:37 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 11:41:34 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.20.79]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 11:41:33 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 02 Jul 2007 13:41:28 -0500 To: "DRAGE, Keith \(Keith\)" , "Dean Willis" , "IETF SIP" From: "James M. Polk" Subject: Re: [Sip] RE: Draft Agenda for SIP at IETF 69 in Chicago In-Reply-To: <5D1A7985295922448D5550C94DE29180013717DD@DEEXC1U01.de.luce nt.com> References: <5D1A7985295922448D5550C94DE29180013717DD@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 02 Jul 2007 18:41:33.0967 (UTC) FILETIME=[9D32F9F0:01C7BCD8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=893; t=1183401699; x=1184265699; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20RE=3A=20Draft=20Agenda=20for=20SIP=20at=20IET F=2069=20in=20Chicago |Sender:=20; bh=dBI1BoTwkGo/HoRYpm4hP1THPA2ePZ++KCRmTWB0TNA=; b=OQDBwy+9gTGlxIJZAyE4oE4uuo+wn38Hi7656HznOZPDeDDGB7KR+iKakyrXdg8YzBRpxTO4 0gcxEe+ubw8QCvCPg9pyiuarvKwLNl4G2G/UxUi+DEPH/AaqunKP6Wv0; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 02:32 AM 7/2/2007, DRAGE, Keith \(Keith\) wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C7BC7B.36EF07B8" > >I think we should put a couple of "do we charter" items on the agenda: The new draft agenda is here http://www.softarmor.com/mediawiki/index.php/SIP_Agenda_IETF_69 I'll be nice and give up 15 of my allocated 30 minutes to these other efforts, as I think I'll only need 15min to discuss my 2 IDs > >These are the mime body handling draft from Gonzalo, and the >proposed INFO handling draft from Eric. > >So far these are the only two that I can identify as having had >discussion and for which we do not have slots. > >Not sure whether we need a slot for corrections or not - I think >Robert was suggesting an ad hoc somewhere to progress this. > >regards > >Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 02 14:56:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5R4P-0007Qu-SE; Mon, 02 Jul 2007 14:56:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5R4N-0007Qm-VX for sip-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 14:56:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5R4M-0007QX-Ae for sip@ietf.org; Mon, 02 Jul 2007 14:56:19 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5R4H-0008T6-AU for sip@ietf.org; Mon, 02 Jul 2007 14:56:18 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Jul 2007 14:55:55 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAK/miEZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,488,1175486400"; d="scan'208"; a="64195521:sNHT2755546484" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l62IttPB026477; Mon, 2 Jul 2007 14:55:55 -0400 Received: from dwingwxp ([10.32.240.194]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l62Its6a013233; Mon, 2 Jul 2007 18:55:54 GMT From: "Dan Wing" To: "'SIP Working Group'" Date: Mon, 2 Jul 2007 11:55:54 -0700 Message-ID: <061701c7bcda$9ec23a90$2014590a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace82p2yNu6lfaNzQcq8BXk5gCIEoQ== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1716; t=1183402555; x=1184266555; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20SIP=20Identity=20using=20Media=20Path |Sender:=20 |To:=20=22'SIP=20Working=20Group'=22=20; bh=qAoFSkGTA1TSkN9bT/hwRA2lssmKMTIn0/jCJSl2RhE=; b=CghpsNJtHUIydXnnxfIlBB3pfWJkzNaPcYOMoArGeGAlOHaGzzZ7NC9Rx07cMisRlED2U4NM EbHvh4FvKSvS4QtiMsCxeoja+wAMSBLv257CNAcY5x1JE6vzfSOFRjpF; Authentication-Results: rtp-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ietf-rtpsec@imc.org Subject: [Sip] SIP Identity using Media Path X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org As many of you are aware, the signature created by SIP-Identity (RFC4474) breaks if an SBC or B2BUA modifies the SDP in the SIP body. Typically these modifications include changing the m/c lines (to direct the RTP media through the SBC itself, or through a transcoder), or performing other adjustments of the SDP to interwork with bugs and features of other SIP networks or other endpoints. I just submitted a draft, "SIP Identity using Media Path", which describes a mechanism that allows RFC4474-like signatures and also allows SBCs and B2BUAs to modify the message's SDP. Links to HTML and plain text versions of the Internet Draft are below. Abstract: The existing SIP identity mechanism (RFC4474) creates a signature over the SIP body, including the entire SDP. As part of their normal operation, Session Border Controllers (SBCs) and SIP Back-to-Back User Agents (B2BUAs) modify various fields in the SDP, breaking the signature. This document defines a new mechanism to securely identify the originator of a SIP message while also allowing modification of the SDP by SBCs and B2BUAs. This new mechanism creates a signature over certain SIP headers and certain SDP lines. Proof of identity over the media path using DTLS, TLS, HIP, and an extension to ICE are described. Please send comments on this draft to the SIP mailing list at sip@ietf.org. -d ----- HTML version: http://tinyurl.com/25539z http://svn.resiprocate.org/rep/ietf-drafts/dwing/draft-wing-sip-identity-med ia-00.html plain text version: http://tinyurl.com/2gldnv http://svn.resiprocate.org/rep/ietf-drafts/dwing/draft-wing-sip-identity-med ia-00.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 02 15:52:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5RwZ-0003dp-5h; Mon, 02 Jul 2007 15:52:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5RY7-0008W0-3Q for sip-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 15:27:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5RY6-0008Vp-4V for sip@ietf.org; Mon, 02 Jul 2007 15:27:02 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5RXy-0006HA-KT for sip@ietf.org; Mon, 02 Jul 2007 15:27:02 -0400 Received: from [65.65.155.30] (helo=[192.168.1.2]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I5RXw-0005iS-H9 for sip@ietf.org; Mon, 02 Jul 2007 14:26:54 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) To: IETF SIP Message-Id: <65675D20-C3BA-4237-8771-90ECD67D7186@softarmor.com> From: Dean Willis Date: Mon, 2 Jul 2007 14:26:36 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.7 (/) X-Scan-Signature: 93a9b7eb0f4b3b8a49c341eb77478ab2 X-Mailman-Approved-At: Mon, 02 Jul 2007 15:52:15 -0400 Subject: [Sip] Revised Agenda for SIP at IETF 69 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1830451174==" Errors-To: sip-bounces@ietf.org --===============1830451174== Content-Type: multipart/alternative; boundary=Apple-Mail-6--1061233573 --Apple-Mail-6--1061233573 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed here's the latest: SIP Agenda IETF 69 Session 1, Monday July 23 0900-1130 Grand Ballroom Start Time Topic Discussion Lead Reading List 0900 Agenda Bash and Status Chairs This document 0915 SIPS WGLC Francois Audet draft-ietf-sip-sips-05.txt 0935 Outbound Rohan Mahy Cullen Jennings draft-ietf-sip-outbound-09.txt 1005 Delivering R-URI and Parameters to UA Jonathan Rosenberg draft-rosenberg-sip-ua-loose-route-01.txt 1040 Resource Priority Header Issues James Polk draft-polk-sip-rph-in-responses-00 draft-polk-sip-rph-new-namespaces-01.txt 1100 INFO And What To Do About It Eric Burger 1115 MIME Body Handling Gonzalo Camairllo draft-camarillo-sip-body-handling-01.txt 1130 End of Session Session 2, Tuesday July 24 0900-1130 Grand Ballroom Start Time Topic Discussion Lead Reading List 0900 Agenda Bash and Status Chairs This document 0905 Fork Loop Fix and Corrections Robert Sparks draft-ietf-sip-fork-loop-fix-05 draft-drage-sip-essential-correction-01 0925 SAML Hannes Tschofenig draft-ietf-sip-saml-02.txt 0945 eTags For Notification Aki Niemi draft-ietf-sip-subnot-etags-00.txt 1000 Domain Certs Vijay Gurbani Scott Lawrence draft-gurbani-sip-domain-certs-05.txt 1020 Privacy Guidelines Mayumi Munakata draft-munakata-sip-privacy-guideline-00.txt 1040 Privacy Enhancements Mayumi Munakata draft-munakata-sip-privacy-new-00.txt 1100 Certificate Authentication Steve Dotson draft-dotson-sip-certificate-auth-03.txt --Apple-Mail-6--1061233573 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

here's the = latest:

SIP Agenda IETF 69


Session 1, Monday July 23 0900-1130 Grand = Ballroom

<= TD valign=3D"middle" style=3D"width: 64.0px; margin: 0.0px 0.5px 0.0px = 0.5px; border-style: solid; border-width: 1.0px 1.0px 1.0px 1.0px; = border-color: #808080 #808080 #808080 #808080; padding: 0.0px 2.0px = 0.0px 2.0px">
0935
<= TR>
Start = Time
Topic
Discussion = Lead
Reading = List
0900
Agenda Bash and Status
Chairs
This = document
0915
SIPS WGLC
Francois Audet
Outbound
Rohan Mahy
Cullen Jennings
1005
Delivering R-URI and Parameters to = UA
Jonathan Rosenberg
=
1040
Resource Priority Header Issues
James Polk

draft-polk-sip-rph-new-namespaces-01.txt

1100
INFO And What To Do About = It
Eric Burger

1115
MIME Body Handling
Gonzalo Camairllo
<= /TD>
1130
End of Session



Session 2, Tuesday July 24 0900-1130 Grand = Ballroom

<= TD valign=3D"middle" style=3D"width: 64.0px; margin: 0.0px 0.5px 0.0px = 0.5px; border-style: solid; border-width: 1.0px 1.0px 1.0px 1.0px; = border-color: #808080 #808080 #808080 #808080; padding: 0.0px 2.0px = 0.0px 2.0px">
0945
Start = Time
Topic
Discussion = Lead
Reading = List
0900
Agenda Bash and Status
Chairs
This = document
0905
Fork Loop Fix and Corrections
Robert Sparks

draft-drage-sip-essential-correction-01

0925
SAML
Hannes = Tschofenig
eTags For = Notification
Aki Niemi
1000
Domain Certs
Vijay Gurbani
Scott Lawrence
1020
Privacy = Guidelines
Mayumi Munakata
1040
Privacy Enhancements
Mayumi Munakata
1100
Certificate = Authentication
Steve Dotson
<= /TD>

= --Apple-Mail-6--1061233573-- --===============1830451174== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1830451174==-- From sip-bounces@ietf.org Mon Jul 02 15:52:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5RwX-0003SL-5h; Mon, 02 Jul 2007 15:52:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5I6T-0001tU-Al for sip-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 05:21:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5I6S-0001tM-UP for sip@ietf.org; Mon, 02 Jul 2007 05:21:52 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5I6C-00018h-L9 for sip@ietf.org; Mon, 02 Jul 2007 05:21:52 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 07BB0208A5; Mon, 2 Jul 2007 11:21:36 +0200 (CEST) X-AuditID: c1b4fb3c-af67dbb0000007e1-82-4688c39f1e89 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DEBCA207FE; Mon, 2 Jul 2007 11:21:35 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 11:21:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] RE: Draft Agenda for SIP at IETF 69 in Chicago Date: Mon, 2 Jul 2007 11:21:34 +0200 Message-ID: <7374777208BDC7449D5620EF9423256706D0D437@esealmw113.eemea.ericsson.se> In-Reply-To: <5D1A7985295922448D5550C94DE29180013717DD@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Draft Agenda for SIP at IETF 69 in Chicago Thread-Index: Ace7glFat0kee34qQZSvhmlArShVvgAuiSOgABNvBdA= References: <5D1A7985295922448D5550C94DE29180013717DD@DEEXC1U01.de.lucent.com> From: "Christer Holmberg (JO/LMF)" To: "DRAGE, Keith (Keith)" , "Dean Willis" , "IETF SIP" X-OriginalArrivalTime: 02 Jul 2007 09:21:35.0734 (UTC) FILETIME=[63177960:01C7BC8A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.7 (/) X-Scan-Signature: 7f30a46178edfef2bdd484ce718b5b0a X-Mailman-Approved-At: Mon, 02 Jul 2007 15:52:16 -0400 Cc: Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1428730687==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1428730687== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BC8A.62CCBBC6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7BC8A.62CCBBC6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 Regarding the loose route issue, I still haven't received any reply on = whether the problem can be solved with the P-Called-Party header - in = which case there would be no problem to discuss. =20 Regards, =20 Christer =20 ________________________________ From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 Sent: 2. hein=E4kuuta 2007 10:33 To: Dean Willis; IETF SIP Cc: Cullen Jennings Subject: [Sip] RE: Draft Agenda for SIP at IETF 69 in Chicago =09 =09 I think we should put a couple of "do we charter" items on the agenda: =20 These are the mime body handling draft from Gonzalo, and the proposed = INFO handling draft from Eric. =20 So far these are the only two that I can identify as having had = discussion and for which we do not have slots. =20 Not sure whether we need a slot for corrections or not - I think Robert = was suggesting an ad hoc somewhere to progress this. =20 regards =20 Keith ________________________________ From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Sunday, July 01, 2007 2:51 AM To: IETF SIP Cc: Cullen Jennings; DRAGE, Keith (Keith) Subject: Draft Agenda for SIP at IETF 69 in Chicago =09 =09 Here's the current draft agenda for SIP at IETF 69. I'm sure it is = incomplete. Changes will be posted to: http://www.softarmor.com/mediawiki/index.php/SIP_Agenda_IETF_69 Draft SIP Agenda IETF 69 =09 =09 Session 1, Monday July 23 0900-1130 Grand Ballroom Start Time Topic Discussion Lead Reading List 0900 Agenda Bash and Status Chairs This document 0915 SIPS WGLC Francois Audet draft-ietf-sip-sips-05.txt = =20 0945 Outbound Rohan Mahy Cullen Jennings draft-ietf-sip-outbound-09.txt = =20 1015 Location Conveyance WGLC James Polk draft-ietf-sip-location-conveyance-07.txt = =20 1045 Delivering R-URI and Parameters to UA Jonathan Rosenberg draft-rosenberg-sip-ua-loose-route-01.txt = =20 1130 End of Session =09 =09 Session 2, Tuesday July 24 0900-1130 Grand Ballroom Start Time Topic Discussion Lead Reading List 0900 Agenda Bash and Status Chairs This document 0905 SAML Hannes Tschofenig draft-ietf-sip-saml-02.txt = =20 0930 eTags For Notification Aki Niemi draft-ietf-sip-subnot-etags-00.txt = = 0950 Domain Certs Vijay Gurbani Scott Lawrence draft-gurbani-sip-domain-certs-05.txt = =20 1020 Privacy Guidelines Mayumi Munakata draft-munakata-sip-privacy-guideline-00.txt = =20 1040 Privacy Enhancements Mayumi Munakata draft-munakata-sip-privacy-new-00.txt = =20 1100 Certificate Authentication Sumanth Channabasappa draft-dotson-sip-certificate-auth-03.txt = =20 =09 =09 =09 =09 ------_=_NextPart_001_01C7BC8A.62CCBBC6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Regarding the loose route issue, I still haven't received any = reply on=20 whether the problem can be solved with the P-Called-Party header - in = which case=20 there would be no problem to discuss.
 
Regards,
 
Christer
 

From: DRAGE, Keith (Keith)=20 [mailto:drage@alcatel-lucent.com]
Sent: 2. hein=E4kuuta = 2007=20 10:33
To: Dean Willis; IETF SIP
Cc: Cullen=20 Jennings
Subject: [Sip] RE: Draft Agenda for SIP at IETF 69 = in=20 Chicago

I think we should put a couple of "do we = charter" items=20 on the agenda:
 
These are the mime body handling draft from = Gonzalo, and=20 the proposed INFO handling draft from Eric.
 
So far these are the only two that I can = identify as=20 having had discussion and for which we do not have = slots.
 
Not sure whether we need a slot for = corrections or not -=20 I think Robert was suggesting an ad hoc somewhere to progress=20 this.
 
regards
 
Keith

From: Dean Willis=20 [mailto:dean.willis@softarmor.com]
Sent: Sunday, July 01, = 2007=20 2:51 AM
To: IETF SIP
Cc: Cullen Jennings; DRAGE, = Keith=20 (Keith)
Subject: Draft Agenda for SIP at IETF 69 in=20 Chicago

Here's the current draft agenda for SIP at IETF 69. I'm sure it = is=20 incomplete. Changes will be posted to:
= http://www.softarmor.com/mediawiki/index.php/SIP_Agenda_IETF_69
=

Draft SIP Agenda=20 IETF 69

Session 1,=20 Monday July 23 0900-1130 Grand Ballroom

Start=20 Time
Topic
Discussion=20 Lead
Reading=20 List
0900
Agenda=20 Bash and Status
Chairs
This=20 document
0915
SIPS=20 WGLC
Francois=20 Audet
<= FONT=20 class=3DApple-style-span face=3DHelvetica size=3D3>draft-ietf-sip-sips-05.txt
0945
Outbound
Rohan=20 Mahy
Cullen=20 Jennings
draft-ietf-sip-outbound-09.txt
1015
Location=20 Conveyance WGLC
James=20 Polk
draft-ietf-sip-location-conveyance-07.txt
1045
Delivering=20 R-URI and Parameters to UA
Jonathan=20 Rosenberg
draft-rosenberg-sip-ua-loose-route-01.txt
1130
End of=20 Session



Session 2,=20 Tuesday July 24 0900-1130 Grand Ballroom

Start=20 Time
Topic
Discussion=20 Lead
Reading=20 List
0900
Agenda=20 Bash and Status
Chairs
This=20 document
0905
SAML
Hannes=20 Tschofenig
<= FONT=20 class=3DApple-style-span face=3DHelvetica size=3D3>draft-ietf-sip-saml-02.txt
0930
eTags For=20 Notification
Aki=20 Niemi
draft-ietf-sip-subnot-etags-00.txt
0950
Domain=20 Certs
Vijay=20 Gurbani
Scott=20 Lawrence
draft-gurbani-sip-domain-certs-05.txt
<= /TR>
1020
Privacy=20 Guidelines
Mayumi=20 Munakata
draft-munakata-sip-privacy-guideline-00.txt
=
1040
Privacy=20 Enhancements
Mayumi=20 Munakata
draft-munakata-sip-privacy-new-00.txt
<= /TR>
1100
Certificate=20 Authentication
Sumanth=20 Channabasappa
draft-dotson-sip-certificate-auth-03.txt

------_=_NextPart_001_01C7BC8A.62CCBBC6-- --===============1428730687== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1428730687==-- From sip-bounces@ietf.org Mon Jul 02 18:27:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5UMJ-000809-T0; Mon, 02 Jul 2007 18:27:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5UMH-000804-TV for sip-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 18:27:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5UMH-0007zw-K2 for sip@ietf.org; Mon, 02 Jul 2007 18:27:01 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5UMC-0006bV-70 for sip@ietf.org; Mon, 02 Jul 2007 18:27:01 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AE4C92124B; Tue, 3 Jul 2007 00:26:55 +0200 (CEST) X-AuditID: c1b4fb3e-b1837bb0000007e1-c3-46897bafa8ca Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8B29B211C5; Tue, 3 Jul 2007 00:26:55 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 00:26:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP Identity using Media Path Date: Tue, 3 Jul 2007 00:26:54 +0200 Message-ID: <7374777208BDC7449D5620EF9423256706D44E57@esealmw113.eemea.ericsson.se> In-Reply-To: <061701c7bcda$9ec23a90$2014590a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Identity using Media Path Thread-Index: Ace82p2yNu6lfaNzQcq8BXk5gCIEoQAHC+iw References: <061701c7bcda$9ec23a90$2014590a@amer.cisco.com> From: "Christer Holmberg (JO/LMF)" To: X-OriginalArrivalTime: 02 Jul 2007 22:26:54.0977 (UTC) FILETIME=[18595F10:01C7BCF8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Dan, Chapter 9 says: "in order for the mechanism to work, SBC-type-of-entities must permit = DTLS, TLS, ICE, or HIP messages to be exchanged in the media path." A small question for clarification: at what point must this exchange = (two-way, I assume) work? As soon as the UAS has received the INVITE? Regards, Christer > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: 2. hein=E4kuuta 2007 21:56 > To: 'SIP Working Group' > Cc: ietf-rtpsec@imc.org > Subject: [Sip] SIP Identity using Media Path >=20 > As many of you are aware, the signature created by SIP-Identity > (RFC4474) breaks if an SBC or B2BUA modifies the SDP in the SIP body. > Typically these modifications include changing the m/c lines=20 > (to direct the RTP media through the SBC itself, or through a=20 > transcoder), or performing other adjustments of the SDP to=20 > interwork with bugs and features of other SIP networks or=20 > other endpoints. >=20 >=20 > I just submitted a draft, "SIP Identity using Media Path",=20 > which describes a mechanism that allows RFC4474-like=20 > signatures and also allows SBCs and B2BUAs to modify the=20 > message's SDP. Links to HTML and plain text versions of the=20 > Internet Draft are below. >=20 > Abstract: >=20 > The existing SIP identity mechanism (RFC4474) creates a signature > over the SIP body, including the entire SDP. As part of=20 > their normal > operation, Session Border Controllers (SBCs) and SIP Back-to-Back > User Agents (B2BUAs) modify various fields in the SDP, breaking the > signature. >=20 > This document defines a new mechanism to securely identify the > originator of a SIP message while also allowing modification of the > SDP by SBCs and B2BUAs. This new mechanism creates a=20 > signature over > certain SIP headers and certain SDP lines. Proof of identity over > the media path using DTLS, TLS, HIP, and an extension to ICE are > described. >=20 > Please send comments on this draft to the SIP mailing list at=20 > sip@ietf.org. >=20 > -d >=20 > ----- >=20 > HTML version:=20 > http://tinyurl.com/25539z > http://svn.resiprocate.org/rep/ietf-drafts/dwing/draft-wing-si > p-identity-med > ia-00.html >=20 > plain text version:=20 > http://tinyurl.com/2gldnv > http://svn.resiprocate.org/rep/ietf-drafts/dwing/draft-wing-si > p-identity-med > ia-00.txt >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 02 19:05:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Uxo-0000oG-OH; Mon, 02 Jul 2007 19:05:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5Uxm-0000kU-NW for sip-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 19:05:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Uxm-0000iD-4Y for sip@ietf.org; Mon, 02 Jul 2007 19:05:46 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5Ux2-0003Eq-DC for sip@ietf.org; Mon, 02 Jul 2007 19:05:46 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 02 Jul 2007 19:04:57 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALYhiUZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,489,1175486400"; d="scan'208"; a="125094147:sNHT63929932" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l62N4u0x001150; Mon, 2 Jul 2007 19:04:56 -0400 Received: from dwingwxp ([10.32.240.194]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l62N4t6a024888; Mon, 2 Jul 2007 23:04:56 GMT From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" , Subject: RE: [Sip] SIP Identity using Media Path Date: Mon, 2 Jul 2007 16:04:54 -0700 Message-ID: <083e01c7bcfd$6842e230$2014590a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <7374777208BDC7449D5620EF9423256706D44E57@esealmw113.eemea.ericsson.se> Thread-Index: Ace82p2yNu6lfaNzQcq8BXk5gCIEoQAHC+iwAAFo/cA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1188; t=1183417497; x=1184281497; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20SIP=20Identity=20using=20Media=20Path |Sender:=20 |To:=20=22'Christer=20Holmberg=20\(JO/LMF\)'=22=20,=0A=20=20=20=20=20=20=20=20; bh=v69xEoNL80aaVcIUi1LZPa8au1H+cC+0nek2S2L4TQc=; b=hHC1ba/OKjyteiOaZfzX6DApnGzHWJD6XRTIGvQusFLfhM7jHToPJLFJv8mUZOhF+w6WDcZE axNsRZuLH1DkTEiNt+dFtiwXxZtc2vmVhX1CUsXUGymY++srIl/ODxNz; Authentication-Results: rtp-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Chapter 9 says: > > "in order for the mechanism to work, SBC-type-of-entities > must permit DTLS, TLS, ICE, or HIP messages to be exchanged > in the media path." > > A small question for clarification: at what point must this > exchange (two-way, I assume) work? As soon as the UAS has > received the INVITE? Yes. The DTLS, TLS, ICE, or HIP exchange would need to occur prior to displaying Caller-ID-like information to the user -- otherwise, an attacker could spoof that Caller-ID information. It seems defective, to me, to display Caller-ID information that was spoofed to only later learn (after doing DTLS, TLS, ICE, or HIP) that the calling party had lied about their identity. There is some protection against such an attack that could reduce this risk (the Date: header is signed, so the attacker would need to obtain a relatively recent SIP request) -- that protection might be sufficient in networks that block exchange of packets prior to 200 Ok. If an attacker was able to get ahold of such a SIP request, you would know it when the attacker failed the DTLS, TLS, ICE, or HIP exchange, which I suppose is better than nothing. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 02 22:38:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5YHI-0002Jd-I8; Mon, 02 Jul 2007 22:38:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5YHH-0002JX-8b for sip-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 22:38:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5YHG-0002JP-V8 for sip@ietf.org; Mon, 02 Jul 2007 22:38:06 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5YGE-00006D-Un for sip@ietf.org; Mon, 02 Jul 2007 22:38:06 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 02 Jul 2007 19:37:02 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACpTiUarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,489,1175497200"; d="scan'208"; a="499586358:sNHT26443748" 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 l632b0jO023704 for ; Mon, 2 Jul 2007 19:37:00 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l632awmp012380 for ; Tue, 3 Jul 2007 02:36:58 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <167A3231-404F-41FB-B1E0-3881660359EF@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP From: Cullen Jennings Date: Mon, 2 Jul 2007 19:35:58 -0700 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2633; t=1183430220; x=1184294220; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Security=20issues=20with=20ietf-sip-loop-fix |Sender:=20; bh=auNG9/UXJU5waTYAE/UbE+Ax1cnorS+W5f0f9SggLJg=; b=RSZEZj2XodHW79+eVgbP39BUDUsmkc4hOh/m6CelG5V5QZlLIzwL2PgoR96i/l1nSW3v1LKN zdFq53oziUtlfVvjioX0Q+76cqx/hHFaqUIujoW7jHM0Gnoj2uqX4dcj; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Sip] Security issues with ietf-sip-loop-fix X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (this email with my AD hat on) The type of SIP loops described in ietf-sip-loop-fix can be roughly classified into two categories. Loops that had happened because an accidental registration that causes a loop, and loops that happened due to malicious intent. This draft attempted to deals with both. The abstract describes it as This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic. During IETF LC, substantial comment came up about the security of this draft not really working in the case of malicious loops. A thread ensues that convinced many people on the thread that this draft did not really help with the malicious loops. (Not 100% sure here but I suspect that the authors and chairs were all convinced of this). I will let others explain the issues that came up as we decide what to do next. I think that some of issue was discussed while the working group was considering this draft - however, I suspect that many participants did not understand how easily this security would be defeated. I for one significantly underestimated the how easy it was for a malicious attacker to cause this problem. I apologize to the folks that attempted to explain it to me and I just failed to "get it". Anyways, we need to figure out what to do next with this draft. There are basically two paths forward that I see: 1) reduce the scope so that it only deals with accidental loops and provides no protection against malicious loops. I don't think this would change any of the mechanisms in the draft but it would probably change lots of the text around what security claims the draft made. 2) try to extend or replace the mechanism with one that does protect against malicious attack. A strong candidate to consider would be the work in draft-sparks-sipping-max-breadth. If we go forward with path 1, the value of this draft is probably not super high because Max-Forwards deals with the the accidental loops in most cases (but not all cases). If we go with path 2, the WG will need make sure it OK with the solution. I'm certainly open to other paths forward if someone has a good idea. What I would like to do now is start some discussion about what the working group would like to do with this draft. Thanks, Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 03 05:21:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5eZI-0005eo-9i; Tue, 03 Jul 2007 05:21:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5eZG-0005be-Mr for sip-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 05:21:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5eZG-0005bR-Bo for sip@ietf.org; Tue, 03 Jul 2007 05:21:06 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5eZF-0001D7-Td for sip@ietf.org; Tue, 03 Jul 2007 05:21:06 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKL0016GJA3O4@szxga03-in.huawei.com> for sip@ietf.org; Tue, 03 Jul 2007 17:20:27 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKL009ZLJA3GJ@szxga03-in.huawei.com> for sip@ietf.org; Tue, 03 Jul 2007 17:20:27 +0800 (CST) Received: from t34932 ([10.70.108.127]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKL00LG0JA01Q@szxml03-in.huawei.com> for sip@ietf.org; Tue, 03 Jul 2007 17:20:27 +0800 (CST) Date: Tue, 03 Jul 2007 17:21:01 +0800 From: Linyi Tian To: sip@ietf.org Message-id: <002c01c7bd53$7945a0d0$7f6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: Ace9U3jpv25fK3OAQpyIJDfuOs6LJA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Sip] Comments and questions to draft-ietf-sip-uri-list-conferencing-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, all (1) On section "5. Conference Server Procedures" Many conference servers have restriction to maximum number of attendees for conference. If the users of 'recipient-list' exceeds the limitation, what status code should be returned? --------------------------------------- 7. Security Considerations This document discusses setup of SIP conferences using a request-contained URI-list. Both conferencing and URI-lists services have specific security requirements which will be summarized here. Conferences generally have authorization rules about who can or cannot join a conference, what type of media can or cannot be used, etc. This information is used by the focus to admit or deny participation in a conference. It is RECOMMENDED that these types of authorization rules be used to provide security for a SIP conference. ---------------------------------------- (2) When and how the authorization rules are specified and applied to the conference? Before the conference creation seems not possible since Conf-URI is not assigned. If specified after the conference creation, it seems there is a risk after conf is created but rules are not ready. Some attendees may do something bad which is out of control during that period. Best Regards, Linyi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 03 05:30:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5eiR-00081i-Bx; Tue, 03 Jul 2007 05:30:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5eiP-00081I-Ea for sip-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 05:30:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5eiP-000812-3z for sip@ietf.org; Tue, 03 Jul 2007 05:30:33 -0400 Received: from mail.strom.cz ([89.111.70.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5eht-0004jO-Rq for sip@ietf.org; Tue, 03 Jul 2007 05:30:33 -0400 Received: from exalfa.stromtelecom.cz ([172.16.16.10]) by mail.strom.cz with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 11:30:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Changes to the INVITE transaction to address bug 769 Date: Tue, 3 Jul 2007 11:30:00 +0200 Message-ID: <2DD3CA89774593478BC28081C7392595E019EB@exalfa.stromtelecom.cz> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Changes to the INVITE transaction to address bug 769 Thread-Index: Ace5LQ4MMTkYKeXvQyOZPpl9CvOVXwEIXnWg References: From: "Bohaty David" To: "Robert Sparks" , "SIP IETF" X-OriginalArrivalTime: 03 Jul 2007 09:30:00.0837 (UTC) FILETIME=[BA91D350:01C7BD54] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hello, just my though about the draft, related to the requirement=20 "The client transaction SHOULD start timer D when it enters the "Completed" state for any reason, with a value of at least 32 seconds for unreliable transports, and a value of zero seconds for reliable transports":=20 For client transactions, wouldn't it be better that the timer D is set to 32s even for reliable transport after receiving 200-299 response, so the transaction can collect also responses to a forked INVITE? This would align the INVITE transaction with the UAC Core behaviour, which according to "RFC3261 13.2.2.4 2xx Responses" considers the INVITE transaction completed 64*T1 seconds after the reception of the first 2xx response. Also the 200-299 is retransmitted end-to-end, so the reliability of the transport to the first hop does not really mean that the response or ACK is sent reliably all the way from UAS to UAC, respectivelly from UAC to UAS. =20 David Bohaty System Architect =20 SITRONICS Telecom Solutions, Czech Republic a.s.=20 Tel.: +420 226 532 578, Fax: +420 241 480 899 BB Centrum - Beta, Vyskocilova 1481/4, 140 00 Praha 4, Czech Republic www.sitronicsts.com -----Original Message----- From: Robert Sparks [mailto:rjsparks@estacado.net]=20 Sent: 28 June 2007 04:35 To: SIP IETF Subject: [Sip] Changes to the INVITE transaction to address bug 769 Everyone - I've put together a proposal for addressing the spec bug captured at http://bugs.sipit.net/show_bug.cgi?id=3D769 Please read through http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-00.txt and comment. RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 03 06:19:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5fTM-0005pb-1X; Tue, 03 Jul 2007 06:19:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5fTK-0005pQ-Ni for sip-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 06:19:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5fTK-0005pD-DS for sip@ietf.org; Tue, 03 Jul 2007 06:19:02 -0400 Received: from cluster-f.mailcontrol.com ([85.119.2.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5fTF-0006DL-VI for sip@ietf.org; Tue, 03 Jul 2007 06:19:02 -0400 Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12]) by rly21f.srv.mailcontrol.com (MailControl) with ESMTP id l63AGgaI021029 for ; Tue, 3 Jul 2007 11:18:50 +0100 Received: from ExBE03.nasstar-t1.net ([10.2.10.102]) by exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 11:14:54 +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 Subject: RE: [Sip] WGLC for draft-ietf-sip-sips-05.txt (v.minor error) Date: Tue, 3 Jul 2007 11:14:37 +0100 Message-ID: <165288C2C3E29449AFDE022DD10CC471052017A6@ExBE03.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC for draft-ietf-sip-sips-05.txt (v.minor error) Thread-Index: Ace6W/KAZqEG8GHOThiz27zcp4oxvAC/Q4uA From: "Attila Sipos" To: X-OriginalArrivalTime: 03 Jul 2007 10:14:54.0405 (UTC) FILETIME=[000FAF50:01C7BD5B] X-Scanned-By: MailControl A-07-07-10 (www.mailcontrol.com) on 10.70.0.131 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org See flows sections 6.3 and 6.4. F13' shows an INVITE to Bob's PC but the INVITE message shows: INVITE sip:bob@bobphone.example.com it should be: INVITE sip:bob@bobpc.example.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 03 09:32:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5iUW-0006PS-G7; Tue, 03 Jul 2007 09:32:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5iUU-0006OP-ML for sip-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 09:32:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5iUU-0006Mu-CS for sip@ietf.org; Tue, 03 Jul 2007 09:32:26 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5iTp-0002mV-S4 for sip@ietf.org; Tue, 03 Jul 2007 09:32:25 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 146782017C; Tue, 3 Jul 2007 15:31:45 +0200 (CEST) X-AuditID: c1b4fb3e-b2038bb0000007e1-aa-468a4fbffeb3 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EB69E201F3; Tue, 3 Jul 2007 15:31:43 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 15:31:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP Identity using Media Path Date: Tue, 3 Jul 2007 15:31:42 +0200 Message-ID: <7374777208BDC7449D5620EF9423256706D82893@esealmw113.eemea.ericsson.se> In-Reply-To: <083e01c7bcfd$6842e230$2014590a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Identity using Media Path Thread-Index: Ace82p2yNu6lfaNzQcq8BXk5gCIEoQAHC+iwAAFo/cAAHiWekA== References: <7374777208BDC7449D5620EF9423256706D44E57@esealmw113.eemea.ericsson.se> <083e01c7bcfd$6842e230$2014590a@amer.cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Dan Wing" , X-OriginalArrivalTime: 03 Jul 2007 13:31:43.0731 (UTC) FILETIME=[7EF7D430:01C7BD76] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>Chapter 9 says: >>=20 >>"in order for the mechanism to work, SBC-type-of-entities must permit=20 >>DTLS, TLS, ICE, or HIP messages to be exchanged in the media path." >>=20 >>A small question for clarification: at what point must this exchange=20 >>(two-way, I assume) work? As soon as the UAS has received the INVITE? >=20 >Yes. As we know from our RTPSEC discussions, one of the issues of using SBC-type-of-entities (or gates) is that you MAY NOT have end-to-end media plane connectivity as soon as the INVITE has been sent. Regards, Christer =20 >The DTLS, TLS, ICE, or HIP exchange would need to occur prior=20 >to displaying Caller-ID-like information to the user --=20 >otherwise, an attacker could spoof that Caller-ID=20 >information. It seems defective, to me, to display Caller-ID=20 >information that was spoofed to only later learn (after doing=20 >DTLS, TLS, ICE, or HIP) that the calling party had lied about=20 >their identity. =20 >=20 >There is some protection against such an attack that could=20 >reduce this risk (the Date: header is signed, so the attacker=20 >would need to obtain a relatively recent SIP request) -- that=20 >protection might be sufficient in networks that block=20 >exchange of packets prior to 200 Ok. If an attacker was able=20 >to get ahold of such a SIP request, you would know it when=20 >the attacker failed the DTLS, TLS, ICE, or HIP exchange,=20 >which I suppose is better than nothing. >=20 > -d >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 03 09:50:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5im6-0002ki-Sd; Tue, 03 Jul 2007 09:50:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5im5-0002id-1u for sip-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 09:50:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5im4-0002gY-NN for sip@ietf.org; Tue, 03 Jul 2007 09:50:36 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5iks-0006yh-KE for sip@ietf.org; Tue, 03 Jul 2007 09:50:36 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l63DnKNH081332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jul 2007 08:49:20 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <167A3231-404F-41FB-B1E0-3881660359EF@cisco.com> References: <167A3231-404F-41FB-B1E0-3881660359EF@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Security issues with ietf-sip-loop-fix Date: Tue, 3 Jul 2007 08:49:18 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org We've just submitted an update to the max-breadth draft - it greatly simplified the text of -00 and explores the problem identified in the secdir review of fork-loop-fix a little. In a nutshell, that problem is that an attacker can get a large number (on the order of max-forwards) of AoRs to participate in the attack. In the real world, this is not hard to do. At that point, neither max-forwards nor loop detection mitigates the damage of the attack. Furthermore, the damage is not inherently limited to the services that provided the participating AoRs. The forking behavior can be configured such that an innocent (perhaps not even SIP) endpoint gets a message every time the system forwards and forks. The max-breadth draft as written now controls only the amplitude of such an attack at any given point in time - it could be modified to control the total number of messages the attacked endpoint would see (see open issue #1). You can find the revised max-breadth draft at http://www.nostrum.com/~rjsparks/draft-sparks-sipping-max-breadth-01.txt until it appears in the repository. Even though it says sipping, please (for now) keep the discussion of it on the SIP list. Thanks! RjS On Jul 2, 2007, at 9:35 PM, Cullen Jennings wrote: > > (this email with my AD hat on) > > The type of SIP loops described in ietf-sip-loop-fix can be roughly > classified into two categories. Loops that had happened because an > accidental registration that causes a loop, and loops that happened > due to malicious intent. > > This draft attempted to deals with both. The abstract describes it as > > This document normatively updates RFC 3261, the Session Initiation > Protocol (SIP), to address a security vulnerability identified > in SIP > proxy behavior. This vulnerability enables an attack against SIP > networks where a small number of legitimate, even authorized, SIP > requests can stimulate massive amounts of proxy-to-proxy traffic. > > During IETF LC, substantial comment came up about the security of > this draft not really working in the case of malicious loops. A > thread ensues that convinced many people on the thread that this > draft did not really help with the malicious loops. (Not 100% sure > here but I suspect that the authors and chairs were all convinced > of this). I will let others explain the issues that came up as we > decide what to do next. > > I think that some of issue was discussed while the working group > was considering this draft - however, I suspect that many > participants did not understand how easily this security would be > defeated. I for one significantly underestimated the how easy it > was for a malicious attacker to cause this problem. I apologize to > the folks that attempted to explain it to me and I just failed to > "get it". > > Anyways, we need to figure out what to do next with this draft. > There are basically two paths forward that I see: > > 1) reduce the scope so that it only deals with accidental loops and > provides no protection against malicious loops. I don't think this > would change any of the mechanisms in the draft but it would > probably change lots of the text around what security claims the > draft made. > > 2) try to extend or replace the mechanism with one that does > protect against malicious attack. A strong candidate to consider > would be the work in draft-sparks-sipping-max-breadth. > > If we go forward with path 1, the value of this draft is probably > not super high because Max-Forwards deals with the the accidental > loops in most cases (but not all cases). If we go with path 2, the > WG will need make sure it OK with the solution. I'm certainly open > to other paths forward if someone has a good idea. > > What I would like to do now is start some discussion about what the > working group would like to do with this draft. > > Thanks, Cullen > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 03 10:04:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5izs-0000j5-7I; Tue, 03 Jul 2007 10:04:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5izr-0000ix-Ch for sip-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 10:04:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5izr-0000ip-30 for sip@ietf.org; Tue, 03 Jul 2007 10:04:51 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5iyl-0003B6-7Q for sip@ietf.org; Tue, 03 Jul 2007 10:04:51 -0400 Received: from [172.17.1.65] ([172.17.1.65]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l63E3gTU016707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jul 2007 09:03:42 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: <2DD3CA89774593478BC28081C7392595E019EB@exalfa.stromtelecom.cz> References: <2DD3CA89774593478BC28081C7392595E019EB@exalfa.stromtelecom.cz> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7F26B0C6-AE36-4045-9588-262142B1B7D2@estacado.net> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Changes to the INVITE transaction to address bug 769 Date: Tue, 3 Jul 2007 09:03:40 -0500 To: Bohaty David X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hrmm. I think you're right, and the place where it makes a big difference is at proxies in the path of the 200 that have a TCP hop on either side of them - we want that client transaction to still be there for retransmissions of the 200. Whether the fix is as simple as setting timer D will take more thinking (and I want to wait for more feedback on the rest of the draft before cracking this open). I've started a list of things to work through with this item. Thanks, RjS On Jul 3, 2007, at 4:30 AM, Bohaty David wrote: > Hello, > > just my though about the draft, related to the requirement > "The client transaction SHOULD start timer D when it enters the > "Completed" state for any reason, with a value of at least 32 seconds > for unreliable transports, and a value of zero seconds for reliable > transports": > > For client transactions, wouldn't it be better that the timer D is set > to 32s even for reliable transport after receiving 200-299 > response, so > the transaction can collect also responses to a forked INVITE? This > would align the INVITE transaction with the UAC Core behaviour, which > according to "RFC3261 13.2.2.4 2xx Responses" considers the INVITE > transaction completed 64*T1 seconds after the reception of the > first 2xx > response. > Also the 200-299 is retransmitted end-to-end, so the reliability of > the > transport to the first hop does not really mean that the response > or ACK > is sent reliably all the way from UAS to UAC, respectivelly from > UAC to > UAS. > > > David Bohaty > System Architect > > SITRONICS Telecom Solutions, Czech Republic a.s. > Tel.: +420 226 532 578, Fax: +420 241 480 899 > BB Centrum - Beta, Vyskocilova 1481/4, 140 00 Praha 4, Czech Republic > www.sitronicsts.com > > > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@estacado.net] > Sent: 28 June 2007 04:35 > To: SIP IETF > Subject: [Sip] Changes to the INVITE transaction to address bug 769 > > Everyone - > > I've put together a proposal for addressing the spec bug captured at > http://bugs.sipit.net/show_bug.cgi?id=769 > > Please read through > http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-00.txt > and comment. > > RjS > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 03 10:35:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5jT3-0008DF-5n; Tue, 03 Jul 2007 10:35:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5jSm-00070W-MM for sip-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 10:34:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5jSm-0006yt-Ad; Tue, 03 Jul 2007 10:34:44 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5jS0-0004gS-Sb; Tue, 03 Jul 2007 10:34:44 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 38C3026EED; Tue, 3 Jul 2007 14:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I5j9i-0006Iq-0T; Tue, 03 Jul 2007 10:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 03 Jul 2007 10:15:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-record-route-fix-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Addressing Record-Route issues in the Session Initiation Protocol (SIP) Author(s) : T. Froment, C. Lebel Filename : draft-ietf-sip-record-route-fix-00.txt Pages : 26 Date : 2007-7-3 A typical function of a Session Initiation Protocol (SIP) Proxy is to set a Record-Route header on initial requests in order to make subsequent requests pass through it. This header contains a SIP Uniform Resource Identifier (URI) indicating where and how the subsequent requests should be sent to reach the proxy. Like any SIP URI, it can contain sip or sips schemes, IPV4 or IPV6 addresses, and URI parameters that could influence the routing like different transport parameters (UDP, TCP, SCTP...), or a compression indication like "comp=sigcomp". When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport protocol switching, sip to sips or IPV4 to IPV6 scenarios...), the question arises on what should be put in Record- Route header(s). It is just not possible to make one header having the characteristics of both sides at the same time. This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally recommends the use of the double Record-Route technique as an alternative to the current RFC3261 text, which only describes Record-Route rewriting solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-record-route-fix-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-record-route-fix-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-record-route-fix-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-3094328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-record-route-fix-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-record-route-fix-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-3094328.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Tue Jul 03 11:05:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5jw6-0003OT-OX; Tue, 03 Jul 2007 11:05:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5jw4-0003MX-L7 for sip-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 11:05:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5jw4-0003Lu-At for sip@ietf.org; Tue, 03 Jul 2007 11:05:00 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5jvI-0005Rv-8m for sip@ietf.org; Tue, 03 Jul 2007 11:05:00 -0400 Received: from [65.65.155.30] (helo=[192.168.1.2]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I5jvG-00071b-3g for sip@ietf.org; Tue, 03 Jul 2007 10:04:11 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) To: IETF SIP Message-Id: <8FF10DB5-108B-4EA6-8C50-E3BD8F638670@softarmor.com> From: Dean Willis Date: Tue, 3 Jul 2007 10:03:52 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.7 (/) X-Scan-Signature: e61164d90a5bf7123da65dce5444794e Subject: [Sip] Another revised agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0881381738==" Errors-To: sip-bounces@ietf.org --===============0881381738== Content-Type: multipart/alternative; boundary=Apple-Mail-11--990597451 --Apple-Mail-11--990597451 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed This is getting closer to the final agenda. If you're on the agenda and don't need to be, PLEASE LET ME KNOW! -- Dean SIP Agenda IETF 69 Session 1, Monday July 23 0900-1130 Grand Ballroom Start Time Topic Discussion Lead Reading List 0900 Agenda Bash and Status Chairs This document 0915 SIPS WGLC Francois Audet draft-ietf-sip-sips-05.txt 0935 Outbound Rohan Mahy Cullen Jennings draft-ietf-sip-outbound-09.txt 1005 Delivering R-URI and Parameters to UA Jonathan Rosenberg draft-rosenberg-sip-ua-loose-route-01.txt 1040 Resource Priority Header Issues James Polk draft-polk-sip-rph-in-responses-00 draft-polk-sip-rph-new-namespaces-01.txt 1105 MIME Body Handling Gonzalo Camarillo draft-camarillo-sip-body-handling-01.txt 1130 End of Session Session 2, Tuesday July 24 0900-1130 Grand Ballroom Start Time Topic Discussion Lead Reading List 0900 Agenda Bash and Status Chairs This document 0905 Fork Loop Fix and Corrections Robert Sparks draft-ietf-sip-fork-loop-fix-05 draft-sparks-sip-max-breadth-01 draft-drage-sip-essential-correction-01 0925 SAML Hannes Tschofenig draft-ietf-sip-saml-02 0945 eTags For Notification Aki Niemi draft-ietf-sip-subnot-etags-00.txt 1000 Domain Certs and Connection Reuse Vijay Gurbani Scott Lawrence draft-gurbani-sip-domain-certs-05.txt 1025 UA-Driven Privacy Mayumi Munakata draft-munakata-sip-privacy-new-00.txt 1045 Certificate Authentication Steve Dotson draft-dotson-sip-certificate-auth-03.txt 1100 INFO Considered Harmful Eric Burger draft-burger-sip-info-00 1115 Media identity Dan Wing (waiting) 1130 End of session --Apple-Mail-11--990597451 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

This is getting closer to = the final agenda. If you're on the agenda and don't need to be, PLEASE = LET ME KNOW!

--
Dean
<= BR class=3D"khtml-block-placeholder">

SIP Agenda IETF = 69


Session 1, Monday July 23 0900-1130 Grand = Ballroom

<= TD valign=3D"middle" style=3D"width: 64.0px; margin: 0.0px 0.5px 0.0px = 0.5px; border-style: solid; border-width: 1.0px 1.0px 1.0px 1.0px; = border-color: #808080 #808080 #808080 #808080; padding: 0.0px 2.0px = 0.0px 2.0px">
0935
<= TR>
Start = Time
Topic
Discussion = Lead
Reading = List
0900
Agenda Bash and Status
Chairs
This = document
0915
SIPS WGLC
Francois Audet
Outbound
Rohan Mahy
Cullen Jennings
1005
Delivering R-URI and Parameters to = UA
Jonathan Rosenberg
=
1040
Resource Priority Header Issues
James Polk

draft-polk-sip-rph-new-namespaces-01.txt

1105
MIME Body = Handling
Gonzalo Camarillo
<= /TD>
1130
End of Session



Session 2, Tuesday July 24 0900-1130 Grand = Ballroom

1115
Start = Time
Topic
Discussion = Lead
Reading = List
0900
Agenda Bash and Status
Chairs
This = document
0905
Fork Loop Fix and Corrections
Robert Sparks

draft-sparks-sip-max-breadth-01
draft-drage-sip-essential-correction-01

0925
SAML
Hannes Tschofenig
0945
eTags For = Notification
Aki Niemi
1000
Domain Certs and Connection = Reuse
Vijay Gurbani
Scott = Lawrence
1025
UA-Driven = Privacy
Mayumi Munakata
1045
Certificate = Authentication
Steve Dotson
<= /TD>
1100
INFO Considered = Harmful
Eric Burger
Media identity
Dan Wing
(waiting)
1130
End of session



= --Apple-Mail-11--990597451-- --===============0881381738== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0881381738==-- From sip-bounces@ietf.org Tue Jul 03 13:47:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5mTU-0008J5-NZ; Tue, 03 Jul 2007 13:47:40 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5mTS-0008GK-Ss for sip-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 13:47:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5mTS-0008Fm-By for sip@ietf.org; Tue, 03 Jul 2007 13:47:38 -0400 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5mST-000056-7n for sip@ietf.org; Tue, 03 Jul 2007 13:47:38 -0400 Received: from [127.0.0.1] (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id C1E036C02B; Tue, 3 Jul 2007 13:46:01 -0400 (EDT) Subject: Re: [Sip] Security issues with ietf-sip-loop-fix From: Scott Lawrence To: Cullen Jennings In-Reply-To: <167A3231-404F-41FB-B1E0-3881660359EF@cisco.com> References: <167A3231-404F-41FB-B1E0-3881660359EF@cisco.com> Content-Type: text/plain Organization: Pingtel Corp. Date: Tue, 03 Jul 2007 13:46:36 -0400 Message-Id: <1183484796.4369.30.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Mon, 2007-07-02 at 19:35 -0700, Cullen Jennings wrote: > Anyways, we need to figure out what to do next with this draft. There > are basically two paths forward that I see: > > 1) reduce the scope so that it only deals with accidental loops and > provides no protection against malicious loops. I don't think this > would change any of the mechanisms in the draft but it would probably > change lots of the text around what security claims the draft made. > > 2) try to extend or replace the mechanism with one that does protect > against malicious attack. A strong candidate to consider would be the > work in draft-sparks-sipping-max-breadth. > > If we go forward with path 1, the value of this draft is probably not > super high because Max-Forwards deals with the the accidental loops > in most cases (but not all cases). If we go with path 2, the WG will > need make sure it OK with the solution. I'm certainly open to other > paths forward if someone has a good idea. While I agree that we need a stronger mechanism for the malicious case, I have personally concluded that the earlier loop detection suggested by ietf-sip-loop-fix is a good idea anyway. Especially in those configurations in which the maximum allowed value for Max-Forwards is high (and I think the recommended default of 70 is _very_ high), it is much better to detect the loop earlier than hop limit. I would be in favor of retaining some form of that recommendation. Doing early loop detection will actually make the breadth-limiting approach work better anyway, since it will allow non-looped branches to proceed more quickly by pruning the loops sooner. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs Chief Technology Officer - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 03 14:52:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5nU8-0005iW-63; Tue, 03 Jul 2007 14:52:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5nU7-0005iF-1k for sip-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 14:52:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5nU6-0005i4-9H for sip@ietf.org; Tue, 03 Jul 2007 14:52:22 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5nT7-0004Zp-NE for sip@ietf.org; Tue, 03 Jul 2007 14:52:22 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 03 Jul 2007 14:51:22 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAK43ikZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,493,1175486400"; d="scan'208"; a="125165109:sNHT28012266" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l63IpLSw007971; Tue, 3 Jul 2007 14:51:21 -0400 Received: from dwingwxp ([10.32.240.194]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l63IpJs0001102; Tue, 3 Jul 2007 18:51:20 GMT From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" , Subject: RE: [Sip] SIP Identity using Media Path Date: Tue, 3 Jul 2007 11:51:18 -0700 Message-ID: <16ea01c7bda3$252d8e90$2014590a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <7374777208BDC7449D5620EF9423256706D82893@esealmw113.eemea.ericsson.se> Thread-Index: Ace82p2yNu6lfaNzQcq8BXk5gCIEoQAHC+iwAAFo/cAAHiWekAAKwKZw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2382; t=1183488681; x=1184352681; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20SIP=20Identity=20using=20Media=20Path |Sender:=20 |To:=20=22'Christer=20Holmberg=20\(JO/LMF\)'=22=20,=0A=20=20=20=20=20=20=20=20; bh=Xq2nps6zfw+tU1D3DXegW9EtDPdRSnx4VS2g8MtSdFY=; b=o0Ro9k6TFuJr6hv23Jj0AuuxlVSUUNzH+UJ9vCUCvZmifVtp3Ev4Pchp1QFD9+mEymL2CcZn c7W/AjYYeawlxuOZ7wToo0kiVP9b/3UyTAAmsYEoYwPiTGSlzXnaAryM; Authentication-Results: rtp-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > >>Chapter 9 says: > >> > >>"in order for the mechanism to work, SBC-type-of-entities > >>must permit > >>DTLS, TLS, ICE, or HIP messages to be exchanged in the media path." > >> > >>A small question for clarification: at what point must this > >>exchange > >>(two-way, I assume) work? As soon as the UAS has received > >>the INVITE? > > > >Yes. > > As we know from our RTPSEC discussions, one of the issues of using > SBC-type-of-entities (or gates) is that you MAY NOT have end-to-end > media plane connectivity as soon as the INVITE has been sent. In such a situation, the authentication service will still be able to validate the signature. This may be sufficient until or unless replay attacks are causing havoc. If It Ss Considered that replay attacks are a small problem, then that's all you need to do and breaking the media plane is fine. However, as attackers get more sophisticated and capable of replay attacks, it will be necessary to use DTLS/TLS/HIP/ICE proof of possession of the private key. One could also implement a system where edge SBCs perform the DTLS/TLS/HIP/ICE validation on behalf of the endpoints; this might be suitable for certain network (such as endpoints that cannot or will not support DTLS/TLS/HIP/ICE themselves but who need strong identity for phone calls for whitelists, blacklists, and useful reptuation systems). -d > Regards, > > Christer > > > > >The DTLS, TLS, ICE, or HIP exchange would need to occur prior > >to displaying Caller-ID-like information to the user -- > >otherwise, an attacker could spoof that Caller-ID > >information. It seems defective, to me, to display Caller-ID > >information that was spoofed to only later learn (after doing > >DTLS, TLS, ICE, or HIP) that the calling party had lied about > >their identity. > > > >There is some protection against such an attack that could > >reduce this risk (the Date: header is signed, so the attacker > >would need to obtain a relatively recent SIP request) -- that > >protection might be sufficient in networks that block > >exchange of packets prior to 200 Ok. If an attacker was able > >to get ahold of such a SIP request, you would know it when > >the attacker failed the DTLS, TLS, ICE, or HIP exchange, > >which I suppose is better than nothing. > > > > -d > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 03 16:36:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5p6X-0001mJ-Cm; Tue, 03 Jul 2007 16:36:09 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5p6U-0000yb-Al for sip-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 16:36:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5p6T-0000pz-M5 for sip@ietf.org; Tue, 03 Jul 2007 16:36:05 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5p6T-0004ok-Bq for sip@ietf.org; Tue, 03 Jul 2007 16:36:05 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l63KZDK7026510; Tue, 3 Jul 2007 14:35:13 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 3 Jul 2007 14:35:13 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) 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 Subject: RE: [Sip] Certificate authentication in SIP Date: Tue, 3 Jul 2007 14:35:10 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C62E9B4D@srvxchg3.cablelabs.com> In-Reply-To: <4682CBF1.9000401@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Certificate authentication in SIP Thread-Index: Ace4+/T8skAwSea6Q96YLjFROTaWPQEtSSHw References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com><46819819.5080107@cisco.com> <4681DA3C.8090607@softarmor.com> <4682CBF1.9000401@cisco.com> From: "Steve Dotson" To: "Jonathan Rosenberg" , "Dean Willis" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: IETF SIP List , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jonathan,=20 The use case we are looking at is where the registrar is separate from the edge proxy. While the edge proxy could validate the UA has access to a cert issued by a trusted root, it doesn't necessarily mean the UA has a valid subscription to network services. The edge proxy may/would not have access to this type of registration data, thus the need to authenticate from UA to registrar. The only use case I am aware of is UAs authenticating directly to registrar's, for these same reasons.=20 Steve. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: Wednesday, June 27, 2007 2:43 PM To: Dean Willis Cc: IETF SIP List; DRAGE,Keith (Keith) Subject: Re: [Sip] Certificate authentication in SIP Dean Willis wrote: > Jonathan Rosenberg wrote: >=20 >>Well, I'm going to be contrarian here. I'm not convinced that this is=20 >>needed. >> >>I think certificate based authentication is a great idea. However, I=20 >>am not sure I understand why TLS is not an appropriate solution. >> >=20 >=20 > I think it is very simple why TLS is not appropriate. TLS doesn't work > across proxies, and would therefore require the edge proxy to do=20 > authentication. So what? I think thats what ought to happen. I'd like to see some specific use cases where this can't work with the edge proxy performing the authentication. Keep in mind, we are talking about *certificate* authentication; that doesn't (by definition) required any kind of pre-arranged secret - only a common root CA. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 03 17:03:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5pWU-0005ql-LY; Tue, 03 Jul 2007 17:02:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5pWR-0005Rm-A2 for sip-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 17:02:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5pWQ-0005Or-OU for sip@ietf.org; Tue, 03 Jul 2007 17:02:54 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5pWK-0001HU-OE for sip@ietf.org; Tue, 03 Jul 2007 17:02:54 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l63L2jXB004019; Tue, 3 Jul 2007 15:02:45 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 3 Jul 2007 15:02:45 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) 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 Subject: RE: [Sip] Certificate authentication in SIP Date: Tue, 3 Jul 2007 15:02:42 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C62E9B58@srvxchg3.cablelabs.com> In-Reply-To: <1183141935.3646.30.camel@sukothai.pingtel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Certificate authentication in SIP Thread-Index: Ace6e+wW+FLgkz2vQaSq7V/HIIT9cQDOJxQQ References: <9D18525F6EF33947BDEF23374EF26C7A06CDA1@stntexch11.cis.neustar.com><9AAEDF491EF7CA48AB587781B8F5D7C6016BA6@srvxchg3.cablelabs.com><4685191E.4060903@alcatel-lucent.com> <1183141935.3646.30.camel@sukothai.pingtel.com> From: "Steve Dotson" To: "Scott Lawrence" , "IETF SIP List" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks Vijay, and thanks Scott for the clarification. The SIP cert auth requirements document currently lists a few use cases: - the certificate identifies a device - the certificate identifies a user There could also be the case where the device certificate is mapped to a user for subscription purposes, and there are probably others. As Sumanth states, depending on the agreed upon requirements, the solution could leave these types of specifics as out of scope and just handle the transport and messaging between UA and registrar, or we could go so far as to have certificate profiles and requirements and then work those requirements with the appropriate groups. Thanks. Steve.=20 -----Original Message----- From: Scott Lawrence [mailto:slawrence@pingtel.com]=20 Sent: Friday, June 29, 2007 12:32 PM To: IETF SIP List; ietf-pkix@imc.org Subject: Re: [Sip] Certificate authentication in SIP On Fri, 2007-06-29 at 09:37 -0500, Vijay K. Gurbani wrote: > Sumanth Channabasappa wrote: > > And if we find that certificates need some work to support this=20 > > initiative (e.g., SIP identifiers as subjects), perhaps we can=20 > > present some of those requirements to other WGs. If we find an=20 > > existing solutions that can be used, good (and we can document them=20 > > as such :) ). >=20 > Scott Lawrence and I have spent some time on this issue, i.e., SIP=20 > identifiers as subjects in X.509 certificates. The latest version of=20 > the draft that includes pkix WG comments from Prague and the comments=20 > of the sip WG ADs and others was posted last week to the archives, and > is available at > http://tools.ietf.org/html/draft-gurbani-sip-domain-certs-05 One qualification - the draft above is limited to certificates as whose subject is a SIP domain - not an individual. The goal is to clarify how such certificates are constructed and constrained, and how they should be used to authenticate that a server is authoritative for a domain. > Comments on this version would be extremely helpful. -- Scott Lawrence tel:+1-781-938-5306;ext=3D162 or = sip:slawrence@pingtel.com sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs Chief Technology Officer - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 03 17:13:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5pg6-0004IF-Qq; Tue, 03 Jul 2007 17:12:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5pg4-0004Fc-Kl for sip-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 17:12:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5pg4-0004FP-Aq for sip@ietf.org; Tue, 03 Jul 2007 17:12:52 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5pfx-0003YB-BI for sip@ietf.org; Tue, 03 Jul 2007 17:12:52 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l63LCcZP007123; Tue, 3 Jul 2007 15:12:38 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 3 Jul 2007 15:12:38 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Certificate authentication in SIP Date: Tue, 3 Jul 2007 15:12:35 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C62E9B59@srvxchg3.cablelabs.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C6016BA6@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Certificate authentication in SIP Thread-Index: Ace4SbDXm8unkQ0oRfqVPKlCfnpT+gAsOQlgAEob+ZAACTxZgAAB9SUWANl7ZuA= References: <9D18525F6EF33947BDEF23374EF26C7A06CDA1@stntexch11.cis.neustar.com> <9AAEDF491EF7CA48AB587781B8F5D7C6016BA6@srvxchg3.cablelabs.com> From: "Steve Dotson" To: "Sumanth Channabasappa" , "Peterson, Jon" , "Dan Wing" , "Jonathan Rosenberg" , "DRAGE, Keith (Keith)" X-Approved: ondar X-Spam-Score: 0.6 (/) X-Scan-Signature: d9da51c9fdb90403a7d571fc0f0dbf29 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1259083843==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1259083843== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BDB6.E3201ADA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7BDB6.E3201ADA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jon, =20 I don't want to downplay the challenges of certificate management. However, with TLS gaining traction in different forms, it would seem these issues are being faced already. There are current PKI deployments that could leverage existing investments, and certificates are starting to be used and/or required in different ways in the SIP and mobile space. Using large IPsec deployments as another example, some operators are perfectly fine with managing IPsec relationships with shared secrets, and some see the benefit of certificates.=20 =20 I honestly don't have much background on the "issues" with S/MIME or AIB, and we very well may find after discussing the requirements that an existing solution could be enhanced to meet the requirements. We are obviously open and encourage re-use. =20 Thanks. =20 Steve. ________________________________ From: Sumanth Channabasappa [mailto:sumanth@cablelabs.com]=20 Sent: Friday, June 29, 2007 7:35 AM To: Peterson, Jon; Dan Wing; Jonathan Rosenberg; DRAGE, Keith (Keith) Cc: IETF SIP List Subject: RE: [Sip] Certificate authentication in SIP Jon, But that's not really material - my note certainly wasn't an attempt to rekindle or in any way glamorize S/MIME or AIB. It was rather a reminder that no small part of the reason why those mechanisms didn't set the world on fire was because of generic certificate enrollment problems, user mobility requiring mobile certificate management, the implausibility of certificates with SIP identifiers as subjects, and a myriad of similar problems that have little to do with whether authentication is end-to-end or what have you - they are rather rooted in the easily-underestimated difficulty of managing the relationship between SIP users, SIP devices, and certificates. [S] Would this not be part of the reason that we want to tackle this problem? There are large deployments which use certificates successfully today (such as cable clients). There are potential deployments which would like to use certificates for authentication in SIP networks, without a specified explicit way to do this (or perhaps, lack the understanding). Now, certificate management is a valid concern, and potentially a hard problem, but that is only one part of the puzzle (and may not apply to all deployments).=20 =20 I think we should start by identifying the requirements (since there seems to be some confusion; and the I-D has not been discussed in the WG) and see if existing or new solutions are required. And if we find that certificates need some work to support this initiative (e.g., SIP identifiers as subjects), perhaps we can present some of those requirements to other WGs. If we find an existing solutions that can be used, good (and we can document them as such :) ).=20 - s =20 Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Friday, June 29, 2007 1:00 AM > To: Peterson, Jon; 'Jonathan Rosenberg'; 'DRAGE, Keith (Keith)' > Cc: 'IETF SIP List' > Subject: RE: [Sip] Certificate authentication in SIP > > > The certificate authentication would be used in place of today's Digest > authentication. > > S/MIME and AIB were never used where Digest is used; I don't see the > relationship between what's on the table now and S/MIME and > AIB -- except > that they are two certificate-based authentication schemes, > S/MIME and AIB > are both intended to work end-to-end (between the two SIP > peers desiring to > establish communication with each other), whereas the certificate > authentication being discussed is to replace ("enhance", > whatever word you > prefer) the username/password digest authentication. Digest > authentication > isn't done between peers establishing communication with each > other (except > in a laboratory environment), but Digest is done to > authenticate yourself to > a SIP network so you can gain authorization to interact with that SIP > network --- and that's what's on the table for certificate > authentication. > > -d > > > > -----Original Message----- > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > Sent: Wednesday, June 27, 2007 1:40 PM > > To: Jonathan Rosenberg; DRAGE, Keith (Keith) > > Cc: IETF SIP List > > Subject: RE: [Sip] Certificate authentication in SIP > > > > > > I also have to admit I'm a skeptical. Various forms of > > non-hop-by-hop authentication with certificates were enabled > > by S/MIME, especially in conjunction with entities like AIBs. > > As far as I'm concerned, the mechanics have had their day in > > court, and it didn't go well. We can grapple with the syntax > > to try to find something slightly different that will > > actually appeal to the implementation community, but I don't > > think the problem was that we had the wrong syntax. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > > Sent: Tuesday, June 26, 2007 3:50 PM > > > To: DRAGE, Keith (Keith) > > > Cc: IETF SIP List > > > Subject: Re: [Sip] Certificate authentication in SIP > > > > > > > > > Well, I'm going to be contrarian here. I'm not convinced > > that this is > > > needed. > > > > > > I think certificate based authentication is a great idea. > > > However, I am > > > not sure I understand why TLS is not an appropriate solution. > > > > > > DRAGE, Keith (Keith) wrote: > > > > > > > (As WG chair) > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-dotson-sip-certifica > > > te-auth-03 > > > > .txt > > > > > > > > Describes a set of requirements for: > > > > > > > > This document defines requirements for adding certificate > > > > authentication to the Session Initiation Protocol > (SIP). This > > > > document is being presented with the intention of > > providing clear > > > > requirements to any potential solutions specifying > certificate > > > > authentication within SIP networks. Supporting certificate > > > > authentication in SIP would provide strong authentication and > > > > increase the types of possible deployment scenarios. > > > > > > > > (Before we go any further, please forget all about the solutions > > > > document - that comes later and we are not dealing with it now) > > > > > > > > We need to decide whether there is support for a body of > > > work in this > > > > area, and therefore whether we should charter some > > > requirements work in > > > > the SIP WG. > > > > > > > > (Because this is security related we have agreed that > SIP does the > > > > requirements drafting and not SIPPING) > > > > > > > > So can I hear opinions of the WG on: > > > > > > > > - whether this represents a problem space that > the working group > > > > should draft requirements on? > > > > > > > > - whether the problem space exists but is > something slightly > > > > different, and if so what is that problem space? > > > > > > > > - whether there is a more general problem that > the security area > > > > should be addressing, rather than the SIP group > > addressing something > > > > specific? > > > > > > > > - based on your answers to the first three > questions, whether this > > > > draft is essentially in the right direction to be adopted > > as the WG > > > > draft assuming we create the charter item, or whether we > > > need to seek > > > > some other input draft? > > > > > > > > - and finally, whether (assuming we go ahead with > this work) there > > > > is any work in any other IETF WG that we should take account of? > > > > > > > > > > > > Regards > > > > > > > > Keith > > > > > > > > > > > > > > > > Regards > > > > > > > > Keith > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > > > > > -- > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Cisco Fellow Parsippany, NJ > > > 07054-2711 > > > Cisco Systems > > > jdrosen@cisco.com FAX: =20 > (973) 952-5050 > > > http://www.jdrosen.net PHONE: > (973) 952-5000 > > > http://www.cisco.com =20 > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C7BDB6.E3201ADA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Sip] Certificate authentication in = SIP
Jon,
 
I don't want to downplay the challenges of = certificate=20 management. However, with TLS gaining traction in different forms, it = would seem=20 these issues are being faced already. There are current PKI deployments = that=20 could leverage existing investments, and certificates are starting to be = used=20 and/or required in different ways in the SIP and mobile space. Using = large IPsec=20 deployments as another example, some operators are perfectly fine with = managing=20 IPsec relationships with shared secrets, and some see the benefit of=20 certificates.
 
I honestly don't have much background on the = "issues" with=20 S/MIME or AIB, and we very well may find after discussing the = requirements that=20 an existing solution could be enhanced to meet the requirements. We are=20 obviously open and encourage re-use.
 
Thanks.
 
Steve.

From: Sumanth Channabasappa=20 [mailto:sumanth@cablelabs.com]
Sent: Friday, June 29, 2007 = 7:35=20 AM
To: Peterson, Jon; Dan Wing; Jonathan Rosenberg; DRAGE, = Keith=20 (Keith)
Cc: IETF SIP List
Subject: RE: [Sip] = Certificate=20 authentication in SIP

Jon,


But that's not really material - = my note=20 certainly wasn't an attempt to rekindle or in any way glamorize S/MIME = or AIB.=20 It was rather a reminder that no small part of the reason why those = mechanisms=20 didn't set the world on fire was because of generic certificate = enrollment=20 problems, user mobility requiring mobile certificate management, the=20 implausibility of certificates with SIP identifiers as subjects, and a = myriad of=20 similar problems that have little to do with whether authentication is=20 end-to-end or what have you - they are rather rooted in the=20 easily-underestimated difficulty of managing the relationship between = SIP users,=20 SIP devices, and certificates.
[S] Would this not be part of the = reason that=20 we want to tackle this problem? There are large deployments which use=20 certificates successfully today (such as cable clients). There are = potential=20 deployments which would like to use certificates for authentication in = SIP=20 networks, without a specified explicit way to do this (or perhaps, lack = the=20 understanding). Now, certificate management is a valid concern, and = potentially=20 a hard problem, but that is only one part of the puzzle (and may not = apply to=20 all deployments).
 
I think we should start by identifying the = requirements (since there seems to be some confusion; and the I-D has = not been=20 discussed in the WG) and see if existing or new solutions are required. = And if=20 we find that certificates need some work to support this initiative = (e.g., SIP=20 identifiers as subjects), perhaps we can present some of those = requirements to=20 other WGs. If we find an existing solutions that can be used, good (and = we can=20 document them as such :) ).

- s

 


Jon Peterson
NeuStar, Inc.

> = -----Original=20 Message-----
> From: Dan Wing [mailto:dwing@cisco.com]
> = Sent: Friday,=20 June 29, 2007 1:00 AM
> To: Peterson, Jon; 'Jonathan Rosenberg'; = 'DRAGE,=20 Keith (Keith)'
> Cc: 'IETF SIP List'
> Subject: RE: [Sip]=20 Certificate authentication in SIP
>
>
> The = certificate=20 authentication would be used in place of today's Digest
>=20 authentication.
>
> S/MIME and AIB were never used where = Digest is=20 used; I don't see the
> relationship between what's on the table = now and=20 S/MIME and
> AIB -- except
> that they are two = certificate-based=20 authentication schemes,
> S/MIME and AIB
> are both intended = to work=20 end-to-end (between the two SIP
> peers desiring to
> = establish=20 communication with each other), whereas the certificate
> = authentication=20 being discussed is to replace ("enhance",
> whatever word = you
>=20 prefer) the username/password digest authentication.  = Digest
>=20 authentication
> isn't done between peers establishing = communication with=20 each
> other (except
> in a laboratory environment), but = Digest is=20 done to
> authenticate yourself to
> a SIP network so you = can gain=20 authorization to interact with that SIP
> network --- and that's = what's on=20 the table for certificate
> authentication.
>
>=20 -d
>
>
> > -----Original Message-----
> > = From:=20 Peterson, Jon [mailto:jon.peterson@neustar.biz<= /A>]
>=20 > Sent: Wednesday, June 27, 2007 1:40 PM
> > To: Jonathan = Rosenberg;=20 DRAGE, Keith (Keith)
> > Cc: IETF SIP List
> > = Subject: RE:=20 [Sip] Certificate authentication in SIP
> >
> = >
> > I=20 also have to admit I'm a skeptical. Various forms of
> > = non-hop-by-hop=20 authentication with certificates were enabled
> > by S/MIME, = especially=20 in conjunction with entities like AIBs.
> > As far as I'm = concerned,=20 the mechanics have had their day in
> > court, and it didn't go = well.=20 We can grapple with the syntax
> > to try to find something = slightly=20 different that will
> > actually appeal to the implementation=20 community, but I don't
> > think the problem was that we had = the wrong=20 syntax.
> >
> > Jon Peterson
> > NeuStar,=20 Inc.
> >
> > > -----Original Message-----
> = > >=20 From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]
> = > >=20 Sent: Tuesday, June 26, 2007 3:50 PM
> > > To: DRAGE, Keith=20 (Keith)
> > > Cc: IETF SIP List
> > > Subject: = Re: [Sip]=20 Certificate authentication in SIP
> > >
> > = >
>=20 > > Well, I'm going to be contrarian here. I'm not = convinced
> >=20 that this is
> > > needed.
> > >
> > = > I=20 think certificate based authentication is a great idea.
> > = >=20 However, I am
> > > not sure I understand why TLS is not an=20 appropriate solution.
> > >
> > > DRAGE, Keith = (Keith)=20 wrote:
> > >
> > > > (As WG chair)
> = > >=20 >
> > > >
> > > h= ttp://www.ietf.org/internet-drafts/draft-dotson-sip-certifica
>= =20 > > te-auth-03
> > > > .txt
> > > = >
>=20 > > > Describes a set of requirements for:
> > >=20 >
> > > >    This document defines = requirements=20 for adding certificate
> > > >    = authentication=20 to the Session Initiation Protocol
> (SIP).  This
> = > >=20 >    document is being presented with the intention = of
>=20 > providing clear
> > > >    = requirements to=20 any potential solutions specifying
> certificate
> > > = >    authentication within SIP networks.  = Supporting=20 certificate
> > > >    authentication in = SIP would=20 provide strong authentication and
> > > = >   =20 increase the types of possible deployment scenarios.
> > >=20 >
> > > > (Before we go any further, please forget all = about=20 the solutions
> > > > document - that comes later and we = are not=20 dealing with it now)
> > > >
> > > > We = need to=20 decide whether there is support for a body of
> > > work in=20 this
> > > > area, and therefore whether we should = charter=20 some
> > > requirements work in
> > > > the = SIP=20 WG.
> > > >
> > > > (Because this is = security=20 related we have agreed that
> SIP does the
> > > >=20 requirements drafting and not SIPPING)
> > > >
> = > >=20 > So can I hear opinions of the WG on:
> > > >
> = >=20 > > -       whether this represents = a=20 problem space that
> the working group
> > > > = should draft=20 requirements on?
> > > >
> > > >=20 -       whether the problem space exists = but=20 is
> something slightly
> > > > different, and if = so what=20 is that problem space?
> > > >
> > > >=20 -       whether there is a more general = problem=20 that
> the security area
> > > > should be = addressing,=20 rather than the SIP group
> > addressing something
> > = >=20 > specific?
> > > >
> > > >=20 -       based on your answers to the first = three
> questions, whether this
> > > > draft is=20 essentially in the right direction to be adopted
> > as the = WG
>=20 > > > draft assuming we create the charter item, or whether = we
>=20 > > need to seek
> > > > some other input = draft?
>=20 > > >
> > > > = -       and=20 finally, whether (assuming we go ahead with
> this work) = there
>=20 > > > is any work in any other IETF WG that we should take = account=20 of?
> > > >
> > > >
> > > > = Regards
> > > >
> > > > Keith
> > = >=20 >
> > > >
> > > >
> > > = >=20 Regards
> > > >
> > > > Keith
> > = >=20 >
> > > >
> > > >=20 _______________________________________________
> > > > = Sip=20 mailing list  https://www1.ietf.org= /mailman/listinfo/sip
>=20 > > > This list is for NEW development of the core SIP = Protocol
>=20 > > > Use sip-implementors@cs.columbia.edu for questions = on
>=20 current sip
> > > > Use sipping@ietf.org for new = developments on=20 the
> > application of sip
> > > >
> >=20 >
> > > --
> > > Jonathan D. Rosenberg,=20 Ph.D.           &n= bsp;      =20 600 Lanidex Plaza
> > > Cisco=20 Fellow           &= nbsp;           &n= bsp;          =20 Parsippany, NJ
> > > 07054-2711
> > > Cisco=20 Systems
> > >=20 jdrosen@cisco.com         &n= bsp;           &nb= sp;       =20 FAX:  
> (973) 952-5050
> > > http://www.jdrosen.net  &n= bsp;           &nb= sp;         =20 PHONE:
> (973) 952-5000
> > > http://www.cisco.com
> > = >
>=20 > >
> > >=20 _______________________________________________
> > > Sip = mailing=20 list  https://www1.ietf.org= /mailman/listinfo/sip
>=20 > > This list is for NEW development of the core SIP = Protocol
> >=20 > Use sip-implementors@cs.columbia.edu for questions on current = sip
>=20 > > Use sipping@ietf.org for new developments on the
> = application=20 of sip
> > >
> >
> >
> >=20 _______________________________________________
> > Sip mailing = list  https://www1.ietf.org= /mailman/listinfo/sip
>=20 > This list is for NEW development of the core SIP Protocol
> = > Use=20 sip-implementors@cs.columbia.edu for questions on current sip
> = > Use=20 sipping@ietf.org for new developments on the application of=20 sip
>


_______________________________________________Sip=20 mailing list  https://www1.ietf.org= /mailman/listinfo/sip
This=20 list is for NEW development of the core SIP Protocol
Use=20 sip-implementors@cs.columbia.edu for questions on current sip
Use=20 sipping@ietf.org for new developments on the application of=20 sip

 ------_=_NextPart_001_01C7BDB6.E3201ADA-- --===============1259083843== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1259083843==-- From sip-bounces@ietf.org Tue Jul 03 17:34:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5q12-0000WR-Ei; Tue, 03 Jul 2007 17:34:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5q10-0000OL-HT for sip-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 17:34:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5q10-0000NZ-7U for sip@ietf.org; Tue, 03 Jul 2007 17:34:30 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5q0u-0008PI-EU for sip@ietf.org; Tue, 03 Jul 2007 17:34:30 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 03 Jul 2007 17:34:24 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0KAKZdikZAZnme/2dsb2JhbAAs X-IronPort-AV: i="4.16,494,1175486400"; d="scan'208"; a="64302249:sNHT36896182" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l63LYNRg022891; Tue, 3 Jul 2007 17:34:23 -0400 Received: from dwingwxp ([171.70.231.228]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l63LYNs0010483; Tue, 3 Jul 2007 21:34:23 GMT From: "Dan Wing" To: "'Steve Dotson'" Subject: RE: [Sip] Certificate authentication in SIP Date: Tue, 3 Jul 2007 14:34:22 -0700 Message-ID: <1ab601c7bdb9$ec3bcd10$2014590a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C62E9B59@srvxchg3.cablelabs.com> Thread-Index: Ace4SbDXm8unkQ0oRfqVPKlCfnpT+gAsOQlgAEob+ZAACTxZgAAB9SUWANl7ZuAAALggUA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11801; t=1183498463; x=1184362463; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Certificate=20authentication=20in=20SIP |Sender:=20 |To:=20=22'Steve=20Dotson'=22=20; bh=5XuOUR8iOtqrrNvB2wGepKW63OsfuL4eN/U5kF9mcXU=; b=QyzhE3fFIvO6HXTGuZvEcwkNCxgDzQFeSDT8zo89JY0bKjg4vapM+snkBkfMzIM4lvI9wfcc H2fiu2rMFZPigdT4XBzZ8z3z3ASG3FtWee2E8fUkHYi+12l4gFFBpHb4; Authentication-Results: rtp-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (removed some direct CC's.) > -----Original Message----- > From: Steve Dotson [mailto:S.Dotson@CableLabs.com] > Sent: Tuesday, July 03, 2007 2:13 PM > To: Sumanth Channabasappa; Peterson, Jon; Dan Wing; Jonathan > Rosenberg; DRAGE, Keith (Keith) > Cc: IETF SIP List > Subject: RE: [Sip] Certificate authentication in SIP > > Jon, > > I don't want to downplay the challenges of certificate > management. However, with TLS gaining traction in different > forms, it would seem these issues are being faced already. > There are current PKI deployments that could leverage > existing investments, and certificates are starting to be > used and/or required in different ways in the SIP and mobile > space. Using large IPsec deployments as another example, some > operators are perfectly fine with managing IPsec > relationships with shared secrets, and some see the benefit > of certificates. > > I honestly don't have much background on the "issues" with > S/MIME or AIB, and we very well may find after discussing the > requirements that an existing solution could be enhanced to > meet the requirements. We are obviously open and encourage re-use. AIB copies the headers into a separate MIME part and uses S/MIME to sign that part. The unfortunate lack of MIME support in SIP is a significant barrier to the successful deployment of anything using multipart MIME messages, such as AIB. From the last SIPit, http://www.sipforum.org/content/view/287/171/: > > 2% I break if someone sends me multipart/mime > 24% I pretend multipart/mime doesn't exist if someone > sends it to me > 24% I ignore multipart/mime but will proxy it or hand > it to my application if it shows up > 10% I try to do something useful with multipart/mime I > receive, but I never send it > 4% I ignore multipart/mime that I receive, but I try > to do something useful with multipart/mime I send > 24% I try to do something useful with multipart/mime I > send and receive > 12% Other > If you re-used AIB just for Register, the situation may be better, as you only need the SIP proxy to ignore the multipart portion of the message. You might also read draft-camarillo-sip-body-handling-01.txt on this topic. -d > Thanks. > > Steve. > > ________________________________ > > From: Sumanth Channabasappa [mailto:sumanth@cablelabs.com] > Sent: Friday, June 29, 2007 7:35 AM > To: Peterson, Jon; Dan Wing; Jonathan Rosenberg; DRAGE, Keith (Keith) > Cc: IETF SIP List > Subject: RE: [Sip] Certificate authentication in SIP > > > Jon, > > > But that's not really material - my note certainly wasn't an > attempt to rekindle or in any way glamorize S/MIME or AIB. It > was rather a reminder that no small part of the reason why > those mechanisms didn't set the world on fire was because of > generic certificate enrollment problems, user mobility > requiring mobile certificate management, the implausibility > of certificates with SIP identifiers as subjects, and a > myriad of similar problems that have little to do with > whether authentication is end-to-end or what have you - they > are rather rooted in the easily-underestimated difficulty of > managing the relationship between SIP users, SIP devices, and > certificates. > [S] Would this not be part of the reason that we want to > tackle this problem? There are large deployments which use > certificates successfully today (such as cable clients). > There are potential deployments which would like to use > certificates for authentication in SIP networks, without a > specified explicit way to do this (or perhaps, lack the > understanding). Now, certificate management is a valid > concern, and potentially a hard problem, but that is only one > part of the puzzle (and may not apply to all deployments). > > I think we should start by identifying the requirements > (since there seems to be some confusion; and the I-D has not > been discussed in the WG) and see if existing or new > solutions are required. And if we find that certificates need > some work to support this initiative (e.g., SIP identifiers > as subjects), perhaps we can present some of those > requirements to other WGs. If we find an existing solutions > that can be used, good (and we can document them as such :) ). > > - s > > > > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Friday, June 29, 2007 1:00 AM > > To: Peterson, Jon; 'Jonathan Rosenberg'; 'DRAGE, Keith (Keith)' > > Cc: 'IETF SIP List' > > Subject: RE: [Sip] Certificate authentication in SIP > > > > > > The certificate authentication would be used in place of > today's Digest > > authentication. > > > > S/MIME and AIB were never used where Digest is used; I don't see the > > relationship between what's on the table now and S/MIME and > > AIB -- except > > that they are two certificate-based authentication schemes, > > S/MIME and AIB > > are both intended to work end-to-end (between the two SIP > > peers desiring to > > establish communication with each other), whereas the certificate > > authentication being discussed is to replace ("enhance", > > whatever word you > > prefer) the username/password digest authentication. Digest > > authentication > > isn't done between peers establishing communication with each > > other (except > > in a laboratory environment), but Digest is done to > > authenticate yourself to > > a SIP network so you can gain authorization to interact > with that SIP > > network --- and that's what's on the table for certificate > > authentication. > > > > -d > > > > > > > -----Original Message----- > > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > > Sent: Wednesday, June 27, 2007 1:40 PM > > > To: Jonathan Rosenberg; DRAGE, Keith (Keith) > > > Cc: IETF SIP List > > > Subject: RE: [Sip] Certificate authentication in SIP > > > > > > > > > I also have to admit I'm a skeptical. Various forms of > > > non-hop-by-hop authentication with certificates were enabled > > > by S/MIME, especially in conjunction with entities like AIBs. > > > As far as I'm concerned, the mechanics have had their day in > > > court, and it didn't go well. We can grapple with the syntax > > > to try to find something slightly different that will > > > actually appeal to the implementation community, but I don't > > > think the problem was that we had the wrong syntax. > > > > > > Jon Peterson > > > NeuStar, Inc. > > > > > > > -----Original Message----- > > > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > > > Sent: Tuesday, June 26, 2007 3:50 PM > > > > To: DRAGE, Keith (Keith) > > > > Cc: IETF SIP List > > > > Subject: Re: [Sip] Certificate authentication in SIP > > > > > > > > > > > > Well, I'm going to be contrarian here. I'm not convinced > > > that this is > > > > needed. > > > > > > > > I think certificate based authentication is a great idea. > > > > However, I am > > > > not sure I understand why TLS is not an appropriate solution. > > > > > > > > DRAGE, Keith (Keith) wrote: > > > > > > > > > (As WG chair) > > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-dotson-sip-certifica > > > > te-auth-03 > > > > > .txt > > > > > > > > > > Describes a set of requirements for: > > > > > > > > > > This document defines requirements for adding certificate > > > > > authentication to the Session Initiation Protocol > > (SIP). This > > > > > document is being presented with the intention of > > > providing clear > > > > > requirements to any potential solutions specifying > > certificate > > > > > authentication within SIP networks. Supporting certificate > > > > > authentication in SIP would provide strong > authentication and > > > > > increase the types of possible deployment scenarios. > > > > > > > > > > (Before we go any further, please forget all about > the solutions > > > > > document - that comes later and we are not dealing > with it now) > > > > > > > > > > We need to decide whether there is support for a body of > > > > work in this > > > > > area, and therefore whether we should charter some > > > > requirements work in > > > > > the SIP WG. > > > > > > > > > > (Because this is security related we have agreed that > > SIP does the > > > > > requirements drafting and not SIPPING) > > > > > > > > > > So can I hear opinions of the WG on: > > > > > > > > > > - whether this represents a problem space that > > the working group > > > > > should draft requirements on? > > > > > > > > > > - whether the problem space exists but is > > something slightly > > > > > different, and if so what is that problem space? > > > > > > > > > > - whether there is a more general problem that > > the security area > > > > > should be addressing, rather than the SIP group > > > addressing something > > > > > specific? > > > > > > > > > > - based on your answers to the first three > > questions, whether this > > > > > draft is essentially in the right direction to be adopted > > > as the WG > > > > > draft assuming we create the charter item, or whether we > > > > need to seek > > > > > some other input draft? > > > > > > > > > > - and finally, whether (assuming we go ahead with > > this work) there > > > > > is any work in any other IETF WG that we should take > account of? > > > > > > > > > > > > > > > Regards > > > > > > > > > > Keith > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > Keith > > > > > > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol > > > > > Use sip-implementors@cs.columbia.edu for questions on > > current sip > > > > > Use sipping@ietf.org for new developments on the > > > application of sip > > > > > > > > > > > > > -- > > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > > Cisco Fellow Parsippany, NJ > > > > 07054-2711 > > > > Cisco Systems > > > > jdrosen@cisco.com FAX: > > (973) 952-5050 > > > > http://www.jdrosen.net > PHONE: > > (973) 952-5000 > > > > http://www.cisco.com > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 03 22:38:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5ul0-0003pz-2d; Tue, 03 Jul 2007 22:38:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5uky-0003pq-QQ for sip-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 22:38:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5uky-0003ph-GY for sip@ietf.org; Tue, 03 Jul 2007 22:38:16 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5uku-0005bU-6J for sip@ietf.org; Tue, 03 Jul 2007 22:38:16 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Jul 2007 22:38:12 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHqkikZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,495,1175486400"; d="scan'208"; a="125193877:sNHT27073492" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l642cBNw006140; Tue, 3 Jul 2007 22:38:11 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l642c76a005109; Wed, 4 Jul 2007 02:38:07 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 22:38:07 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 22:38:07 -0400 Message-ID: <468B0812.2090003@cisco.com> Date: Tue, 03 Jul 2007 22:38:10 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Certificate authentication in SIP References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com> <46819819.5080107@cisco.com> <4681DA3C.8090607@softarmor.com> <4682CBF1.9000401@cisco.com> <80A444DE-0EFE-4AD9-A340-DB1AD43DE734@softarmor.com> In-Reply-To: <80A444DE-0EFE-4AD9-A340-DB1AD43DE734@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jul 2007 02:38:07.0187 (UTC) FILETIME=[5A7FDA30:01C7BDE4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1616; t=1183516691; x=1184380691; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20Certificate=20authentication=20in=20SIP |Sender:=20 |To:=20Dean=20Willis=20; bh=i6LBKB++u3VGSKGA3nMp8vf0JS0Mt5OTCsLhXBOZCWY=; b=cLEpfQphCjHmXtHudv7HdTf1m4Y9Qj/sGhbif0AgcGQgxy065fSBKttx9Otpml8FKL42/e0j rXrVzjUgle+q9fRi7q9636DHpXgMcfgMU11e1f8Flfvps0R7n0zKtuJP; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: IETF SIP List , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Dean Willis wrote: >> So what? I think thats what ought to happen. I'd like to see some >> specific use cases where this can't work with the edge proxy >> performing the authentication. Keep in mind, we are talking about >> *certificate* authentication; that doesn't (by definition) required >> any kind of pre-arranged secret - only a common root CA. > > My edge proxy might be provided by MCI, but I might be using a chat > service from another provider overseas. This other provider might be > willing to trust the certificate for authentication (given that I have a > signed cert from MCI, who in turn has a signed CA cert from a recognized > op-level CA). However, the chat provider might not be willing to just > accept P-Asserted-Identity from MCI as an authentication mechanism, > since said provider does not have a trusted peering arrangement with MCI > and therefore ANYBODY could spoof my P-Asserted-Identity. In a case where your chat provider has no relationship whatsoever with this edge proxy, for what purpose would you be connecting to it in the first place? You should connect directly to your chat provider offering the service. Then, if you have a cert - great - authenticate to it using mutual TLS. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 03 22:40:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5umu-0004yL-7R; Tue, 03 Jul 2007 22:40:16 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5ums-0004yG-AK for sip-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 22:40:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5ums-0004y8-0q for sip@ietf.org; Tue, 03 Jul 2007 22:40:14 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5uml-000658-Og for sip@ietf.org; Tue, 03 Jul 2007 22:40:14 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Jul 2007 22:40:08 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACOlikZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,495,1175486400"; d="scan'208"; a="125193934:sNHT26688332" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l642e7Ai006484; Tue, 3 Jul 2007 22:40:07 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l642e7s0006005; Wed, 4 Jul 2007 02:40:07 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 22:40:07 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 22:40:06 -0400 Message-ID: <468B0889.8010005@cisco.com> Date: Tue, 03 Jul 2007 22:40:09 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Steve Dotson Subject: Re: [Sip] Certificate authentication in SIP References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com><46819819.5080107@cisco.com> <4681DA3C.8090607@softarmor.com> <4682CBF1.9000401@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C62E9B4D@srvxchg3.cablelabs.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C62E9B4D@srvxchg3.cablelabs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jul 2007 02:40:06.0594 (UTC) FILETIME=[A1ABEA20:01C7BDE4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1215; t=1183516807; x=1184380807; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20Certificate=20authentication=20in=20SIP |Sender:=20 |To:=20Steve=20Dotson=20; bh=5RTFbwO0R3nfy6/VNLHQ+qC4NsqlCErLrnyIEi2G9zk=; b=Lhx7YUHdy2CljSipNL5K8i7/P1JbrdGu+mt2B1Br+K46gQruwAQBOE7DDoptmMN03xzRhOIt sSPZKQZaw+5eH2RGbKgFh+7YZjC8IBRjAx9qX6Uu25GWlAv1B/hfxTJ2; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: IETF SIP List , "DRAGE, Keith \(Keith\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Steve Dotson wrote: > Hi Jonathan, > > The use case we are looking at is where the registrar is separate from > the edge proxy. Sure. I think that is a valid case. > While the edge proxy could validate the UA has access to > a cert issued by a trusted root, it doesn't necessarily mean the UA has > a valid subscription to network services. No. But, such a proxy could assert the identity it verified. > The edge proxy may/would not > have access to this type of registration data, thus the need to > authenticate from UA to registrar. You lost me here. With mutual TLS, the client can authenticate itself to the edge proxy. The edge proxy can assert the authenticated identity towards the registrar, ala P-A-ID or even better, SIP Identity. THe registrar then authorizes access, and rejects the request if the user is not authorized. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 03 23:11:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5vHI-0004Od-Td; Tue, 03 Jul 2007 23:11:40 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5vHH-0004OS-G2 for sip-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 23:11:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5vHH-0004OK-6F for sip@ietf.org; Tue, 03 Jul 2007 23:11:39 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5vHC-0003S7-Jb for sip@ietf.org; Tue, 03 Jul 2007 23:11:39 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Jul 2007 23:11:34 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACysikZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,495,1175486400"; d="scan'208"; a="125194987:sNHT58340428" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l643BYcS012850; Tue, 3 Jul 2007 23:11:34 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l643BX6c010078; Wed, 4 Jul 2007 03:11:33 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 23:11:33 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 23:11:32 -0400 Message-ID: <468B0FE7.7040908@cisco.com> Date: Tue, 03 Jul 2007 23:11:35 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] UA Loose Routing References: <466F5E26.2000709@cisco.com> <5D1A7985295922448D5550C94DE29180012C9836@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF9423256705397552@esealmw113.eemea.ericsson.se> <5D1A7985295922448D5550C94DE29180012C99F6@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF94232567054171DC@esealmw113.eemea.ericsson.se> <5D1A7985295922448D5550C94DE29180012C9A19@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF94232567054174B3@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF94232567054174B3@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 Jul 2007 03:11:32.0519 (UTC) FILETIME=[05C53B70:01C7BDE9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14342; t=1183518694; x=1184382694; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20UA=20Loose=20Routing |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=5q24ikzpzQCt0BmvRrp2Wv2eycBX4igaZ6LzFXaZCXs=; b=rxmIkKO87c0ZiXSfIzJq6Rzmxujbj9DiRxaNWef2nsAw/S7IXQRw7jRZgkUlg0yXDaQ/osRm vioarzAt9FyJKlweLKXDc8TpNJ7fGnNS2NGuxFSwZ1Gn7VLLCbULMwoZ; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4ec58ef3f343ebf5ac40a04538f9a6fc Cc: IETF SIP List , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, My concern with P-Called-Party-ID is similar to my concern on History-Info. On History-Info, the draft states: Firstly, it would cause the Request-URI to be relegated to nothing more than an indicator of the next hop for the request, identical exactly to the purpose of the Route header field. This results in two things in the SIP specification which do exactly the same thing. Worse still, this is not just for some small feature of SIP (where such duplication might not be a big deal), but rather, it would be a duplication of SIP's primary function - routing of a call towards a target. This concern applies exactly to P-Called-Party-ID. Indeed, its even worse, since now we would have, in a request: Request-URI To P-Called-Party-ID History-Info Route and I challenge you to explain to implementors what the differences are. What would happen when they are inconsistent? My objective was to reduce this count. Indeed I was hopeful that UA-loose-route would allow us to deprecate P-Called-Party-ID, not the other way around. WIth UA-loose-route, we end up with: Request-URI: identifies the target Route: tells you how to get to the target To: tells you the original target History info: sequence of identities of targets which is much cleaner. So, functionally, P-Called-Party-ID could work. Any number of things *can* work. -Jonathan R. Christer Holmberg (JO/LMF) wrote: > Hi, > >> It is entirely appropriate at this stage to put forward >> alternatives. It is even more appropriate to do it now rather than >> in 6 months time. >> >> However please do not expect the editor to elaborate them. If the >> WG has ideas, send text, either by individual author drafts, or by >> the mailing list. > > Regarding the P-Called-Party header, there already IS an RFC > describing the header, and what it is used for. So, IF it already > solves the problem (RFC3455 does say that the header is used to > convey the AOR to the UAS), why would we need a separate draft? The > only additional information that a draft could contain are the > use-cases where receiving the AOR is important - but those use-cases > are solution independent and already described in Jonathan's draft. > > Of course, if we want to define a NEW header, or a NEW URI parameter, > that may be done in a separate draft. > > But, no matter how we do it, I think the author should at least > indicate whether he has already thought about the alternatives that > have been presented, and why he thinks that they don't work. > > Regards, > > Christer > > > > >>> -----Original Message----- From: Christer Holmberg (JO/LMF) >>> [mailto:christer.holmberg@ericsson.com] Sent: Thursday, June 14, >>> 2007 10:51 AM To: DRAGE, Keith (Keith); Jonathan Rosenberg; IETF >>> SIP List Subject: RE: [Sip] UA Loose Routing >>> >>> >>> Hi Keith, >>> >>> The text you sent says: >>> >>> "Consensus noted that we do need some sort of solution for >> the general >>> problem of delivery of URI parameters across contact-routing >>> operations." >>> >>> I have no problems with that. >>> >>> I also have no problem with using Jonathan's draft as base line, >>> because the draft discusses the problem in a good way. >>> >>> But, still: as the text says, the agreement was to come up >> with SOME >>> SORT OF SOLUTION, which to me does not mean that we have agreed >>> to adopt the specific solution in Jonathan's draft. We should >>> also be "allowed" to discuss alternative solutions, whether they >>> >> are based on >>> P-Called-Party, some other header, some URI parameter, or >> whatever... >>> Maybe those alternative solutions do not work, and then we should >>> describe that (as Jonathan has done for the To header- and >>> History header alternatives). >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>>> -----Original Message----- From: DRAGE, Keith (Keith) >>>> [mailto:drage@alcatel-lucent.com] Sent: 14. kesäkuuta 2007 >>>> 12:40 To: Christer Holmberg (JO/LMF); Jonathan Rosenberg; IETF >>>> SIP List Subject: RE: [Sip] UA Loose Routing >>>> >>>> You appear to be questioning whether the solution was >> adopted. The >>>> minutes state: >>>> >>>> >> ------------------------------------------------------------------- >> >>>> Topic: GRUU and Supporting Drafts Led by Jonathan Rosenberg >>>> Slides included in proceedings Read: >>>> draft-ietf-sip-gruu-11,draft-rosenberg-sip-ua-loose-route-00 >>>> >>>> Change since last version reviewed. >>>> >>>> Issue: GRUU subtype names. The room demonstrated a slight >>> preference >>>> for the names used in -11 over known alternatives, but >> nobody seems >>>> particularly enamored with these names and the floor >>> remains open to >>>> suggestions. >>>> >>>> Discussion on ua-loose-route draft deferred to next session. >>>> >>>> >>>> Session 2: Friday 0900-1130 Grand Ballroom C >>>> >>>> >>>> Topic: UA-loose-route, continued from previous session. >>>> >>>> Consensus noted that we do need some sort of solution for >>> the general >>>> problem of delivery of URI parameters across contact-routing >>>> operations. >>>> >>>> Issue: Concerns raised about backward compatibility. Noted that >>>> compliant P-CSCF should be OK. Suggested that we have a >>> design team >>>> revisit call-flows and analyze for backward compatibility >>>> issues. >>>> >>>> Issue: Does GRUU normatively depend on this work? Resolved: >>>> GRUU does not reference this document. However, some >>> participants feel >>>> it should, as the benefit of GRUU cannot be fully >> recognized in the >>>> absence of this specification. The chairs asked for a >> hum, and the >>>> consensus of the room is that GRUU and ua-loose-route can >>>> proceed independently. >>>> >>>> Question: Adopt this draft as baseline text for a WG >> effort, should >>>> the ADs approve the milestone? Consensus to adopt noted by >>>> chairs. To-do: Chairs to work with AD to set new milestone. >>>> >> ---------------------------------------------------------------------- >> >>>> The minutes quite clearly say "Adopt this draft as baseline >>> text for a >>>> WG effort" and given that the charter item now exists, then >>> I believe >>>> that we are entitled to call for the editor (Jonathan) to >>> submit the >>>> current text as draft-ietf-sip-ua-loose-route. >>>> >>>> I agree the file name says loose-route, but I don'y think >> we should >>>> change that. After all, we lose that filename when it gets >>> published >>>> as an RFC anyway. >>>> >>>> The charter item states >>>> >>>> Dec 2007 Delivering request-URI and parameters to UAS via >>>> proxy to WGLC Feb 2008 Delivering request-URI and parameters >>>> to UAS via proxy to IESG (PS) >>>> >>>> I assume that you are OK with this. >>>> >>>> What I would suggest is that you address specific comments to >>>> the title of the deliverable: >>>> >>>> Applying Loose Routing to Session Initiation Protocol (SIP) >>>> User Agents (UA) >>>> >>>> And to the abstract: >>>> >>>> Abstract >>>> >>>> A key part of the behavior of the Session Initiation >>> Protocol (SIP) >>>> is that SIP proxies rewrite the Request-URI as a request moves >>>> throughout the network. Over the years, experience has >>> shown this >>>> to be problematic. It makes it difficult to use Request URI >>>> for service invocation, complicates emergency services, makes >>>> it >>> more complex >>>> to support aliases, and so on. Architecturally, it confounds >>>> the concepts of address and route. This document proposes >> to change >>>> this through a new mechanism called UA loose routing. >>>> >>>> As you think appropriate to your concerns. >>>> >>>> Alternatively, if you (or indeed any other SIP WG member) >> do have a >>>> completely different solution, then there is still time >> to post an >>>> individual draft or post a skeleton of a mechanism to the list. >>>> >>>> >>>> Regards >>>> >>>> Keith >>>> >>>>> -----Original Message----- From: Christer Holmberg (JO/LMF) >>>>> [mailto:christer.holmberg@ericsson.com] Sent: Wednesday, June >>>>> 13, 2007 8:52 PM To: DRAGE, Keith (Keith); Jonathan >>>>> Rosenberg; IETF SIP List Subject: RE: [Sip] UA Loose Routing >>>>> >>>>> >>>>> Hi, >>>>> >>>>> We can call it loose route if we want, but I think the >>>> initial focus >>>>> should be the problem we are going to solve (I don't think >>>> we agreed >>>>> on a specific solution at #67), and we should look into >>> alternative >>>>> solutions (the draft does that in some extent, but >> other possible >>>>> alternatives have also been mentioned). >>>>> >>>>> Or, do you prefer to have separate drafts describing >> alternative >>>>> solutions for the problem? >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>>> -----Original Message----- From: DRAGE, Keith (Keith) >>>>>> [mailto:drage@alcatel-lucent.com] Sent: 13. kesäkuuta 2007 >>>>>> 22:25 To: Jonathan Rosenberg; IETF SIP List Subject: RE: >>>>>> [Sip] UA Loose Routing >>>>>> >>>>>> (As WG chair) >>>>>> >>>>>> As well as agreeing to charter the item, we actually agreed >>>>>> >>>>> at IETF#67 >>>>>> that this draft was a suitable candidate to fulfil that >>>>> charter item. >>>>>> Therefore unless issues are raised with this, I would >>> request the >>>>>> editor (as Jonathan is editor) to submit the next >>> version of this >>>>>> document as draft-ietf-sip-ua-loose-route-00. >>>>>> >>>>>> Regards >>>>>> >>>>>> Keith >>>>>> >>>>>>> -----Original Message----- From: Jonathan Rosenberg >>>>>>> [mailto:jdrosen@cisco.com] Sent: Wednesday, June 13, 2007 >>>>>>> 4:02 AM To: IETF SIP List Subject: [Sip] UA Loose Routing >>>>>>> Issue #1: Backwards >>>> compatibility >>>>>>> I've recently revised my draft on UA loose routing. You >>>>>>> can >>>>>> pick it up >>>>>>> here: >>>>>>> >> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo >>>>>>> se-route-01.txt >>>>>>> >>>>>>> This draft is meant to fulfill one of our charter items: >>>>>>> Feb 2008 Delivering request-URI and parameters to UAS >>>>>>> via proxy to IESG (PS) >>>>>>> >>>>>>> As folks may recall, the GRUU spec used to have these >>>>> things called >>>>>>> grids, which allowed a UA to add its own parameters to >>>>>>> the >>>>>> GRUU before >>>>>>> handing it out. Several GRUU revisions back, this >>>>>>> function >>>>>> got yanked >>>>>>> because it was recognized that the problem was more >>>>>>> general >>>>>> than GRUU, >>>>>>> and would be useful for AOR as well. >>>>>>> >>>>>>> Two IETFs back I presented this draft briefly during a >>>>> SIP session. >>>>>>> There was a lot of interest and people liked it >>>> architecturally, >>>>>>> however there were two open issues that needed to get >>>>>> resolved. This >>>>>>> mail is meant to start discussion on one of them - >> backwards >>>>>>> compatibility. >>>>>>> >>>>>>> THe mechanism basically changes the way proxies handle >>>> requests. >>>>>>> Instead of rewriting the request URI for out-of-dialog >>>> requests, >>>>>>> they'll push a route header and leave the r-uri alone. >>>>>>> This >>>>>> allows the >>>>>>> original R-URI and any parameters it contains to get >>>>>> delivered to the >>>>>>> UAS. >>>>>>> >>>>>>> So, the main issue is, what kinds of backwards >>>>>> compatibility problems >>>>>>> will this cause. The draft provides a basic mechanism >>>>> whereby a UA >>>>>>> includes an option tag in the REGISTER, and the registrar >>>>>>> >>>>> indicates >>>>>>> that it is using this mechanism or not. So we can >>>> negotiate this >>>>>>> between a UA and registrar easily. Now, the problem is >>>>>>> with intermediate proxies. If there is an edge proxy >>>>>>> between the >>>>>> UA and its >>>>>>> registrar, it will now see requests targeted to the UA, >>>>>> which contain >>>>>>> a Route header beyond itself, even though it thinks its >>>>>>> the >>>>>> edge proxy >>>>>>> and the last point of contact before the UA. Technically, >>>>>>> >>>>>> if this edge >>>>>>> proxy is compliant to rfc3261 it would work. However, the >>>>>>> >>>>>> question is >>>>>>> whether proxies in the wild would properly work in >> this case. >>>>>>> If folks can comment based on their own products, or >>>>>>> their experiences, on whether they think this would work, >>>>>>> or >>>>>> concerns they >>>>>>> have, that would be great. THere are solutions that would >>>>>>> >>>>>> allow us to >>>>>>> disable the mechanism when intermediate proxies don't >>>>>> support it, but >>>>>>> they are more complex and I'd rather avoid it. >>>>>>> >>>>>>> THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. >>>>>>> 600 >>> Lanidex Plaza >>>>>>> Cisco Fellow >> Parsippany, NJ >>>>>>> 07054-2711 Cisco Systems jdrosen@cisco.com >>>>>>> FAX: >>>>> (973) 952-5050 >>>>>>> http://www.jdrosen.net PHONE: >>>>> (973) 952-5000 >>>>>>> http://www.cisco.com >>>>>>> >>>>>>> >>>>>>> _______________________________________________ Sip >>>>>>> mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>> This list is for NEW development of the core SIP >> Protocol Use >>>>>>> sip-implementors@cs.columbia.edu for questions on >>>> current sip Use >>>>>>> sipping@ietf.org for new developments on the >>> application of sip >>>>>> >>>>>> _______________________________________________ Sip mailing >>>>>> list https://www1.ietf.org/mailman/listinfo/sip This list >>>>>> is for NEW development of the core SIP Protocol Use >>>>>> sip-implementors@cs.columbia.edu for questions on >>> current sip Use >>>>>> sipping@ietf.org for new developments on the >> application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 03 23:14:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5vKJ-00066a-IB; Tue, 03 Jul 2007 23:14:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5vKI-00066P-30 for sip-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 23:14:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5vKH-00066H-Pb for sip@ietf.org; Tue, 03 Jul 2007 23:14:45 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5vKD-0003q0-A8 for sip@ietf.org; Tue, 03 Jul 2007 23:14:45 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 03 Jul 2007 23:14:41 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABytikZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,495,1175486400"; d="scan'208"; a="64318723:sNHT30008054" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l643EeV2030250; Tue, 3 Jul 2007 23:14:40 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l643Ees0011101; Wed, 4 Jul 2007 03:14:40 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 23:14:40 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 23:14:39 -0400 Message-ID: <468B10A2.5010008@cisco.com> Date: Tue, 03 Jul 2007 23:14:42 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] UA Loose Routing Issue #1: Backwards compatibility References: <466F5E26.2000709@cisco.com> <7374777208BDC7449D5620EF94232567052CE377@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF94232567052CE377@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 Jul 2007 03:14:39.0846 (UTC) FILETIME=[756D1060:01C7BDE9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4920; t=1183518880; x=1184382880; c=relaxed/simple; s=rtpdkim2001; 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[Sip]=20UA=20Loose=20Routing=20Issue=20#1=3A=20Backwa rds=20compatibility |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=RUUJPJ/SRoQe1vGHYqmcLN5tuaqbhQTv+Jhg5A5zW38=; b=t8epA/HAZ/NW7oOvBnxPJyeUMz1IaujIpqGg3YD6ewmam8cmZ18/H9bovh4ndPhNMkgVZmMw /L650loiqbdEwbm3MdcyZGg8vIP+LDK0jftIyYhYMaFsCN9h8IaeopfB; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sorry, the draft is not clear on this. It also works in cases where the proxies translation logic is NOT based on registrations. The basic idea is to apply the ;lr param in this case. So if the proxy looks up the request URI and find that the result is a SIP URI with the ;lr param, it pushes that into the route set rather than rewriting the R-URI. Without the ;lr param, it rewrites the R-URI as it does today. This is merely applying the exactly same logic we have for mid-dialog signaling, but for the initial dialog-forming request. I think there is some elegance in that. So, if we consider this MGC case, the routing logic in the proxy that points to these old MGC would have entries which omit the ;lr parameter, and those pointing to ua-loose-route compliant ones would include it. -Jonathan R. Christer Holmberg (JO/LMF) wrote: > Hi, > > At least with existing MGCs you will have backward compability issues. > > MGCs normally route SIP-to-ISUP calls based on the Request-URI, and if the Request-URI contains e.g. a sos servicetype URN, or a 800 service number, the MGC will not be able to route on those. > > Regards, > > Christer > > > > > >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> Sent: 13. kesäkuuta 2007 6:02 >> To: IETF SIP List >> Subject: [Sip] UA Loose Routing Issue #1: Backwards compatibility >> >> I've recently revised my draft on UA loose routing. You can >> pick it up here: >> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo >> se-route-01.txt >> >> This draft is meant to fulfill one of our charter items: >> Feb 2008 Delivering request-URI and parameters >> to UAS via proxy to >> IESG (PS) >> >> As folks may recall, the GRUU spec used to have these things >> called grids, which allowed a UA to add its own parameters to >> the GRUU before handing it out. Several GRUU revisions back, >> this function got yanked because it was recognized that the >> problem was more general than GRUU, and would be useful for >> AOR as well. >> >> Two IETFs back I presented this draft briefly during a SIP session. >> There was a lot of interest and people liked it >> architecturally, however there were two open issues that >> needed to get resolved. This mail is meant to start >> discussion on one of them - backwards compatibility. >> >> THe mechanism basically changes the way proxies handle >> requests. Instead of rewriting the request URI for >> out-of-dialog requests, they'll push a route header and leave >> the r-uri alone. This allows the original R-URI and any >> parameters it contains to get delivered to the UAS. >> >> So, the main issue is, what kinds of backwards compatibility >> problems will this cause. The draft provides a basic >> mechanism whereby a UA includes an option tag in the >> REGISTER, and the registrar indicates that it is using this >> mechanism or not. So we can negotiate this between a UA and >> registrar easily. Now, the problem is with intermediate >> proxies. If there is an edge proxy between the UA and its >> registrar, it will now see requests targeted to the UA, which >> contain a Route header beyond itself, even though it thinks >> its the edge proxy and the last point of contact before the >> UA. Technically, if this edge proxy is compliant to rfc3261 >> it would work. However, the question is whether proxies in >> the wild would properly work in this case. >> >> If folks can comment based on their own products, or their >> experiences, on whether they think this would work, or >> concerns they have, that would be great. THere are solutions >> that would allow us to disable the mechanism when >> intermediate proxies don't support it, but they are more >> complex and I'd rather avoid it. >> >> THanks, >> Jonathan R. >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany, NJ >> 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 03 23:21:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5vR0-0002NP-3r; Tue, 03 Jul 2007 23:21:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5vQy-0002NC-6v for sip-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 23:21:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5vQx-0002N1-TS for sip@ietf.org; Tue, 03 Jul 2007 23:21:39 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5vQr-0005A3-SH for sip@ietf.org; Tue, 03 Jul 2007 23:21:39 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Jul 2007 23:21:33 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAIOuikZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,495,1175486400"; d="scan'208"; a="125195310:sNHT27657480" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l643LXeK014878; Tue, 3 Jul 2007 23:21:33 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l643LX6a011538; Wed, 4 Jul 2007 03:21:33 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, 3 Jul 2007 23:21:33 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 23:21:32 -0400 Message-ID: <468B123F.4010909@cisco.com> Date: Tue, 03 Jul 2007 23:21:35 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Salvatore Loreto References: <466F5E26.2000709@cisco.com> <1181807651.4027.33.camel@n84.nomadiclab.com> In-Reply-To: <1181807651.4027.33.camel@n84.nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jul 2007 03:21:32.0801 (UTC) FILETIME=[6B90FF10:01C7BDEA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1738; t=1183519293; x=1184383293; c=relaxed/simple; s=rtpdkim1001; 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=20UA=20Loose=20Routing=3A=20redirect |Sender:=20 |To:=20Salvatore=20Loreto=20; bh=v7fG9jV04fFuqzmSfLv54hp6Zu7y6PmNwDZzbhie4L8=; b=X3WjcstGoCKEzWMx9GxczkpiyUglsbgNgL1lClF1jaKMFR5I1FQHap4Fx7D0GtSAT1V2xI6C 9Q5K5ciIYKyz4ZfvRZ/ixwDMCEWrjDV7gdqZRlUbtVpogUgTvN+w6v4c; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: IETF SIP List Subject: [Sip] Re: UA Loose Routing: redirect X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Salvatore Loreto wrote: > Hi Jonathan, > > about the third redirection meaning: > > 3. The server is asking the client to route through an additional > proxy prior to visiting it, so that the recursed request > generated by the client pushes an additional Route onto the Route > set. > > I was wondering if it should be possible insert more than only one contact > into the existing route set. No. > I'd like to know your opinion, because in my understanding it should not possible > due to the "alternative" meaning of different locations into the the Contact > header field; in fact the RFC3261 states: > > "When a redirect server returns a 3xx response to a request, it > populates the list of (one or more) alternative locations into the > Contact header field. An "expires" parameter to the Contact header > field values may also be supplied to indicate the lifetime of the > Contact data." > > > About the persistence of the redirection for a mid-dialog request, > I am not sure it should persist just for the duration of the transaction, > instead the persistence should be managed by the "expires" parameter. The problem is - under what conditions would the proxy utilize this? For all requests whose destination would otherwise be the redirecting UA? Only ones whose R-URI also matches? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 03 23:24:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5vT8-0004vT-DV; Tue, 03 Jul 2007 23:23:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5vT6-0004uG-Qq for sip-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 23:23:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5vT6-0004u8-HI for sip@ietf.org; Tue, 03 Jul 2007 23:23:52 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5vSn-0005aR-Qm for sip@ietf.org; Tue, 03 Jul 2007 23:23:52 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 03 Jul 2007 23:23:33 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHKvikZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,495,1175486400"; d="scan'208"; a="64319022:sNHT27125218" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l643NX1f032119; Tue, 3 Jul 2007 23:23:33 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l643NXs0012489; Wed, 4 Jul 2007 03:23:33 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 23:23:33 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 23:23:32 -0400 Message-ID: <468B12B7.2010806@cisco.com> Date: Tue, 03 Jul 2007 23:23:35 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] UA Loose Routing Issue #1: Backwards compatibility References: <466F5E26.2000709@cisco.com> <200706180229.l5I2TqN0008104@dragon.ariadne.com> In-Reply-To: <200706180229.l5I2TqN0008104@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jul 2007 03:23:32.0882 (UTC) FILETIME=[B323E720:01C7BDEA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1593; t=1183519413; x=1184383413; c=relaxed/simple; s=rtpdkim2001; 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[Sip]=20UA=20Loose=20Routing=20Issue=20#1=3A=20Backwa rds=20compatibility |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=F/y9fLqNy2I+De5jhEpb51uSvIKdT3+T3Q7XtH3+I+w=; b=Yl5Pa+xYHaNQWNVMKlFfmlNq5y0KZVibI3eIfN9shvuMYfn7Ray22mLRh/DmoK7mZUMfIY1U PGA85JmzC1Wn1Ts/VZOIMKbhKH1eTX9q/1sq1lkKYRgJYMuks9PI62wQ; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dale.Worley@comcast.net wrote: > From: Jonathan Rosenberg > > THe mechanism basically changes the way proxies handle requests. Instead > of rewriting the request URI for out-of-dialog requests, they'll push a > route header and leave the r-uri alone. This allows the original R-URI > and any parameters it contains to get delivered to the UAS. > > Unfortunately, I have to say that I dislike this mechanism intensely, > as it changes the whole philosophy of how SIP messages are routed. Well, right now, it happens two ways. So I view it as trying to make it consistent. > > On a more practical level, it only deals with one level of address > mapping, and it's not usable by a UA that doesn't implement the change > -- whereas I would expect that the optimal mechanism is one that > tweaks the behavior of the proxy doing the mapping, and requires no > change from any other system. If the purpose of this is to communicate the targeted URI from the terminating proxy to the UA, I don't see how any mechanism can work unless it is supported by that proxy and that UA. Any of the mechanisms mentioned or discussed (P-Called-Party-ID, To, History-Info) have this property. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 04 02:39:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5yVv-0001ZZ-5y; Wed, 04 Jul 2007 02:38:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5yVu-0001ZR-2o for sip-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 02:38:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5yVt-0001ZJ-NK for sip@ietf.org; Wed, 04 Jul 2007 02:38:57 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5yV6-0001IS-9Y for sip@ietf.org; Wed, 04 Jul 2007 02:38:57 -0400 Received: from [65.65.155.30] (helo=[192.168.1.2]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I5yV4-0007vR-Ln; Wed, 04 Jul 2007 01:38:06 -0500 In-Reply-To: <468B0812.2090003@cisco.com> References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com> <46819819.5080107@cisco.com> <4681DA3C.8090607@softarmor.com> <4682CBF1.9000401@cisco.com> <80A444DE-0EFE-4AD9-A340-DB1AD43DE734@softarmor.com> <468B0812.2090003@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <791E1028-5F3E-438F-9FCE-28FC97B3A188@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Certificate authentication in SIP Date: Wed, 4 Jul 2007 01:37:48 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: IETF SIP List , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 3, 2007, at 9:38 PM, Jonathan Rosenberg wrote: > inline. > > Dean Willis wrote: > >>> So what? I think thats what ought to happen. I'd like to see some >>> specific use cases where this can't work with the edge proxy >>> performing the authentication. Keep in mind, we are talking about >>> *certificate* authentication; that doesn't (by definition) >>> required any kind of pre-arranged secret - only a common root CA. >> My edge proxy might be provided by MCI, but I might be using a >> chat service from another provider overseas. This other provider >> might be willing to trust the certificate for authentication >> (given that I have a signed cert from MCI, who in turn has a >> signed CA cert from a recognized op-level CA). However, the chat >> provider might not be willing to just accept P-Asserted-Identity >> from MCI as an authentication mechanism, since said provider does >> not have a trusted peering arrangement with MCI and therefore >> ANYBODY could spoof my P-Asserted-Identity. > > In a case where your chat provider has no relationship whatsoever > with this edge proxy, for what purpose would you be connecting to > it in the first place? You should connect directly to your chat > provider offering the service. Then, if you have a cert - great - > authenticate to it using mutual TLS. > Well, I might be doing "outbound" with my edge proxy in order to get some help from it for relaying messaging back through my NAT. Or it might be a QoS-controlling proxy ala PacketCable. Or a firewall- control-proxy . . . The chat provider might not just be on the other side of my edge proxy, but on the other side of my home serving proxy too. And the certificate auth stuff would appear to be able to traverse that proxy as well. -- Dea _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 04 03:38:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5zRI-0007fr-Jy; Wed, 04 Jul 2007 03:38:16 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5zRH-0007YJ-3M for sip-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 03:38:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5zRF-0007Mw-OJ for sip@ietf.org; Wed, 04 Jul 2007 03:38:13 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5zQc-0002Mn-Jl for sip@ietf.org; Wed, 04 Jul 2007 03:38:13 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JKN0053Q9696E@siemenscomms.co.uk> for sip@ietf.org; Wed, 04 Jul 2007 08:37:21 +0100 (BST) Date: Wed, 04 Jul 2007 08:37:32 +0100 From: "Elwell, John" Subject: RE: [Sip] SIP Identity using Media Path In-reply-to: <061701c7bcda$9ec23a90$2014590a@amer.cisco.com> To: sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D019F2FA@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Sip] SIP Identity using Media Path Thread-Index: Ace82p2yNu6lfaNzQcq8BXk5gCIEoQBMzNng Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <061701c7bcda$9ec23a90$2014590a@amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dan, The mechanism described for ICE seems to provide an alternative to ICE's password-based mechanism for correlating binding requests with offer-answer exchanges. I have not seen any motivation for this alternative. John > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: 02 July 2007 19:56 > To: 'SIP Working Group' > Cc: ietf-rtpsec@imc.org > Subject: [Sip] SIP Identity using Media Path > > As many of you are aware, the signature created by SIP-Identity > (RFC4474) breaks if an SBC or B2BUA modifies the SDP in the SIP body. > Typically these modifications include changing the m/c lines (to > direct the RTP media through the SBC itself, or through a transcoder), > or performing other adjustments of the SDP to interwork with bugs and > features of other SIP networks or other endpoints. > > > I just submitted a draft, "SIP Identity using Media Path", which > describes a mechanism that allows RFC4474-like signatures and also > allows SBCs and B2BUAs to modify the message's SDP. Links to HTML > and plain text versions of the Internet Draft are below. > > Abstract: > > The existing SIP identity mechanism (RFC4474) creates a signature > over the SIP body, including the entire SDP. As part of > their normal > operation, Session Border Controllers (SBCs) and SIP Back-to-Back > User Agents (B2BUAs) modify various fields in the SDP, breaking the > signature. > > This document defines a new mechanism to securely identify the > originator of a SIP message while also allowing modification of the > SDP by SBCs and B2BUAs. This new mechanism creates a > signature over > certain SIP headers and certain SDP lines. Proof of identity over > the media path using DTLS, TLS, HIP, and an extension to ICE are > described. > > Please send comments on this draft to the SIP mailing list at > sip@ietf.org. > > -d > > ----- > > HTML version: > http://tinyurl.com/25539z > http://svn.resiprocate.org/rep/ietf-drafts/dwing/draft-wing-si p-identity-med > ia-00.html > > plain text version: > http://tinyurl.com/2gldnv > http://svn.resiprocate.org/rep/ietf-drafts/dwing/draft-wing-si p-identity-med > ia-00.txt > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 04 04:10:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5zwK-00017J-1n; Wed, 04 Jul 2007 04:10:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5zwI-00017B-2c for sip-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 04:10:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5zwH-000173-LZ for sip@ietf.org; Wed, 04 Jul 2007 04:10:17 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5zwC-00032G-HW for sip@ietf.org; Wed, 04 Jul 2007 04:10:17 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKN00MOGANHAZ@szxga02-in.huawei.com> for sip@ietf.org; Wed, 04 Jul 2007 16:09:18 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKN00749ANHHC@szxga02-in.huawei.com> for sip@ietf.org; Wed, 04 Jul 2007 16:09:17 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKN00LWUAND80@szxml03-in.huawei.com> for sip@ietf.org; Wed, 04 Jul 2007 16:09:17 +0800 (CST) Date: Wed, 04 Jul 2007 16:09:13 +0800 From: Qian Sun To: 'IETF SIP List' Message-id: <004d01c7be12$9bdd9f70$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: Ace+EputrivbF+T8TceASWvRr9Rctg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sip] Comments on draft-ietf-sip-subnot-etags-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I am not sure whether the following description in this draft is enough for the usage of Entity-tags with filtering. "5.1. Generating Entity-tags The views might correspond to different groups of users that have varying levels of access rights to the resource state, or to subscribers that have modified their subscription using event notification filtering [11]." My consideration is: If a subscriber has a subscription with filter F1, the current corresponding entity-tag is E1. Then the same subscriber MUST NOT send SUBSCRIBE with a new filter F2 and the entity-tag E1 in the conditional header field. i.e., if a subscriber changes filter for an event state, the Suppress-XXX-If-Match should not be used. The client of subscriber has to record the last filter for event state and compare filters. Cheers, Qian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 04 04:17:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I603H-0006wd-Tp; Wed, 04 Jul 2007 04:17:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I603G-0006uq-BV for sip-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 04:17:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I603G-0006uh-0a for sip@ietf.org; Wed, 04 Jul 2007 04:17:30 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I603A-0003oB-Ne for sip@ietf.org; Wed, 04 Jul 2007 04:17:29 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKN00HVYAZD6Q@szxga04-in.huawei.com> for sip@ietf.org; Wed, 04 Jul 2007 16:16:25 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKN004RMAZDKZ@szxga04-in.huawei.com> for sip@ietf.org; Wed, 04 Jul 2007 16:16:25 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKN005IFAZ9IL@szxml04-in.huawei.com> for sip@ietf.org; Wed, 04 Jul 2007 16:16:25 +0800 (CST) Date: Wed, 04 Jul 2007 16:16:21 +0800 From: Qian Sun To: 'IETF SIP List' Message-id: <004e01c7be13$9ad2c9b0$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: Ace+E5qx2WgJK1otTIuk+aMMwEW68Q== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Sip] Nits in draft-ietf-sip-multiple-refer-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Figure 2: Example flow (or)*of* a REFER request containin*g* multiple REFER- Targets Cheers, Qian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 04 04:46:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I60Ub-0006Nk-Cb; Wed, 04 Jul 2007 04:45:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I60UY-0006NZ-Pg for sip-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 04:45:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I60UY-0006NR-70 for sip@ietf.org; Wed, 04 Jul 2007 04:45:42 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I60UT-0007g3-Uc for sip@ietf.org; Wed, 04 Jul 2007 04:45:42 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 04 Jul 2007 04:45:38 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGL7ikZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,496,1175486400"; d="scan'208"; a="125205627:sNHT26495502" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l648jaup014890; Wed, 4 Jul 2007 04:45:36 -0400 Received: from dwingwxp ([10.32.240.194]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l648jYs0029766; Wed, 4 Jul 2007 08:45:35 GMT From: "Dan Wing" To: "'Elwell, John'" , Subject: RE: [Sip] SIP Identity using Media Path Date: Wed, 4 Jul 2007 01:45:34 -0700 Message-ID: <1d5f01c7be17$b07aedc0$2014590a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D019F2FA@GBNTHT12009MSX.gb002.siemens.net> Thread-Index: Ace82p2yNu6lfaNzQcq8BXk5gCIEoQBMzNngAAHQ63A= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1955; t=1183538736; x=1184402736; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20SIP=20Identity=20using=20Media=20Path |Sender:=20 |To:=20=22'Elwell, =20John'=22=20, =20; bh=IzxIaa6I/3YyMVq6xlET2NNro8wuDD6Yo4tYjfQrHTw=; b=ryTAmKLavQlLxYEi+2ZwXaVGMGI2h+aefkpQwbMOaPqMf7ItqTXHVrCh7YfM2Zx5NLPGPWV8 kASMynN5BzqLFF1pZdlInfz4afWEu+2rbKa+iEHZVh2dvSivWzw1djZi; Authentication-Results: rtp-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > The mechanism described for ICE seems to provide an > alternative to ICE's > password-based mechanism for correlating binding requests with > offer-answer exchanges. It's not an alternative to ICE's username and password; the new attributes (PK-CHALLENGE, PK-RESPONSE) would be used in addition to the existing STUN attributes used by ICE's connectivity checks. The ICE username/password would still be used for message integrity and to associate a flow with an endpoint's SDP answer. > I have not seen any motivation for this > alternative. The motivation is proving you know the private key associated with the public key. It's only after that proof that you can be assured the Invite wasn't captured by an attacker, had its SDP replaced with the attacker's IP address, and replayed to you. All of the proof of identity techniques described in the paper exchange a public key over the media path (HIP, DTLS-SRTP, TLS) or in the SIP signaling path (ICE). Then, over the media path, the remote party proves he knows the private key associated with that public key. This proof of knowledge of the private key is part of the handshake for HIP, DTLS, and TLS; what the paper does is describe how ICE can do something similar. The primary purpose of ICE in that family of proof of identity techniques is to provide a modicum of SBC-survivable identity if RTP (or SRTP with Security Descriptions) is used. Things are obviously much more secure if DTLS-SRTP, TLS, or HIP are used, as this ensures nothing is going to inject RTP packets into the stream; using RTP can't ensure that. (Crypto experts will point out there is a mafia fraud attack problem with the ICE technique as described in the paper. That is true, but if you're not going to run SRTP using a secure keying mechanism you're suffering the same risk of someone injecting RTP into your stream as the mafia fraud attack.) -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 04 05:01:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I60jV-0008A1-0Y; Wed, 04 Jul 2007 05:01:09 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I60jS-00089t-Pb for sip-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 05:01:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I60jS-00089i-CT for sip@ietf.org; Wed, 04 Jul 2007 05:01:06 -0400 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I60jN-0001nQ-O4 for sip@ietf.org; Wed, 04 Jul 2007 05:01:06 -0400 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11.20060308/8.12.11) with ESMTP id l6490UL8031872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jul 2007 11:00:30 +0200 Received: from eeek.ingate.se (localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.13.1/8.12.11) with ESMTP id l6490ODj007854; Wed, 4 Jul 2007 11:00:24 +0200 Received: (from hasse@localhost) by eeek.ingate.se (8.13.1/8.13.1/Submit) id l6490JN0007853; Wed, 4 Jul 2007 11:00:19 +0200 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f Subject: Re: [Sip] SIP Identity using Media Path From: Hans Persson To: sip@ietf.org, Dan Wing In-Reply-To: <061701c7bcda$9ec23a90$2014590a@amer.cisco.com> References: <061701c7bcda$9ec23a90$2014590a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Organization: Ingate Systems Date: Wed, 04 Jul 2007 11:00:18 +0200 Message-Id: <1183539618.30723.44.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-35.0.4.el4) X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Wed, 04 Jul 2007 11:00:30 +0200 (CEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org m=E5n 2007-07-02 klockan 11:55 -0700 skrev Dan Wing: > I just submitted a draft, "SIP Identity using Media Path", which > describes a mechanism that allows RFC4474-like signatures and also > allows SBCs and B2BUAs to modify the message's SDP. Links to HTML > and plain text versions of the Internet Draft are below. It's nice to see work like this that tries to handle the reality of installed networks instead of pretending that SBCs don't exist. I'm not sure that I grasp this completely yet, but I'll let it simmer for a while and give it another read later. =3D=3D=3D Comments =3D=3D=3D Section 3, figure 1: This figure is a simplification, since many enterprises will have their own SBCs on their borders: <--- Enterprise-A ----> clients --- PBX --- SBC --- SP1-SBC-1 --- SP1-SBC2 ----+ | +------------------------------------------------------+ | | <--- Enterprise-B ----> +--- SP2-SBC1 --- SP2-SBC2 --- SBC --- PBX --- clients Section 3, "mailto URLs" para: sp1.net and sp2.net (and, later in the document, sp3.net) are (or at least could be) real domains that shouldn't be used. Section 4.1, item about Contact: How can the Contact header usefully be used in the signing process? An SBC along the message path will happily replace it. =3D=3D=3D Editorial nits =3D=3D=3D In the text, RFC references are sometimes written "RFCxxxx" and sometimes "RFC xxxx". Decide on one alternative. Section 3, figure 1: > +----[SP1-SBC1]-[SP1-SBC1]---[SP2-SBC1]-[SP2-SBC2]----+ SP1 has two SBC1. One of them should be SBC2. Section 3, first para after figure 1: > using a mailto URL (e.g., 'sip:john.doe@example.com') Both here and a couple of paragraphs below (under "Mailto URLs:"), sip: URLs are refered to as mailto URLs which sounds very strange. Section 3, "mailto URLs" para: > SP1 would validate the RFC4474 signature modify the SDP. I can't make sense of this sentence. What should it mean? > So that a > new RFC4474 signature can be created using its own public/private > key pair, SP1 needs to modify the From: field.=20 Rewrite this sentence to >> SP1 needs to modify the From: field so that a new RFC4474 signature >> can be created using its own public/private key pair. > Unlike with E.164 > numbers which are globally unique, the SP1 isn't able to Remove the "the" in front of "SP1". Section 4, second list item: > o This new header is signed in addition to the same set of SIP > headers signed by RFC4474 (detailed in ) Detailed in what? Section 4, para before figure 2: > In practice, if the The rest of this sentence has gotten lost somewhere. Please contact the information desk. Section 4, step 1: > Step 1: Originating endpoint prepares to send an Invite and chooses "INVITE" > then sends the Invite to its local SIP proxy. "INVITE" Section 4, step 2: > into the new Identity-Media header. The invite is forwarded "INVITE" Section 4, step 4: > the Invite. It validates the Identity-Media signature is > valid and was validates it was generated by the originating "INVITE" Insert "that" after "It validates". Change "was validates" to "validates that". Section 4, step 5: > authentication service forwards the Invite to the endpoint. "INVITE" Section 4, step 6: > challenge technique from the Invite, and performs that "INVITE" Section 4, step 7: > public key. The terminating endpoint validates the Insert "that" after "validates". Section 4, step 8: > Step 8: You can reliably and honestly indicate calling party > information ("caller-id") to the terminating endpoint, and > ring their phone. Rewrite to=20 >> Step 8: The terminating endpoint can reliably and honestly indicate >> calling party information ("caller-id") and ring the phone. Section 4.1, first para: > "fingerprint"). The specific SDP attribute that are signed depends "attributes" Section 4.1, second para: > The SIP headers that are signed are signed the same as done by Remove the second "signed". > the body is not signed. They signed headers are: "They" -> "The" Section 4.1, item about Date: > the weekday and month items case set as shown in BNF in RFC 3261. Insert "the" before "BNF". Section 4.2: > The authentication service examines the SIP message body for the > application/sdp Content-Type. For all such content-types found, the "all such content-types" -> "all such message bodies" Section 5, para 3: > or HIP session and validates the certificate fingerprint presented in > SIP signaling matches the certificate presented in the TLS, DTLS, Insert "that" after "validates" and insert "the" before "SIP". Section 5.2: Newline missing after SDP example. Section 5.3.1: > subsequent PK-CHALLANGE and PK-RESPONSE, in its SDP. The syntax is a "CHALLENGE" Section 5.3.2.1: > 5.3.2.1. PK-CHALLANGE "CHALLENGE" Section 7.1: Write the list items as complete sentences, i.e. start with capitals and remove ", or" from the end of the first item. > the device to manufacture a new self-signed certificate (or public Insert "needs" after "the device". Section 10.1: > This example shows how two a=3Dfingerprint lines in SDP would populate > a the Media-Fingerprints SIP header field. The following is an > example of an Invite created by the endpoint. "a the" -> "the" "INVITE" Hans --=20 Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210857 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 04 05:26:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I617X-0006GD-IS; Wed, 04 Jul 2007 05:25:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I617W-0006G8-DN for sip-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 05:25:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I617W-0006Fk-1Z for sip@ietf.org; Wed, 04 Jul 2007 05:25:58 -0400 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I617R-0005FE-GF for sip@ietf.org; Wed, 04 Jul 2007 05:25:58 -0400 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11.20060308/8.12.11) with ESMTP id l649PXgV000684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jul 2007 11:25:36 +0200 Received: from eeek.ingate.se (localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.13.1/8.12.11) with ESMTP id l649PSMP009275; Wed, 4 Jul 2007 11:25:28 +0200 Received: (from hasse@localhost) by eeek.ingate.se (8.13.1/8.13.1/Submit) id l649PIv9009270; Wed, 4 Jul 2007 11:25:18 +0200 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f Subject: RE: [Sip] SIP Identity using Media Path From: Hans Persson To: Dan Wing In-Reply-To: <083e01c7bcfd$6842e230$2014590a@amer.cisco.com> References: <083e01c7bcfd$6842e230$2014590a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Organization: Ingate Systems Date: Wed, 04 Jul 2007 11:25:17 +0200 Message-Id: <1183541118.30723.49.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-35.0.4.el4) X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Wed, 04 Jul 2007 11:25:43 +0200 (CEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sip@ietf.org, ietf-rtpsec@imc.org, "'Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org m=E5n 2007-07-02 klockan 16:04 -0700 skrev Dan Wing: > > Chapter 9 says: > >=20 > > "in order for the mechanism to work, SBC-type-of-entities=20 > > must permit DTLS, TLS, ICE, or HIP messages to be exchanged=20 > > in the media path." > >=20 > > A small question for clarification: at what point must this=20 > > exchange (two-way, I assume) work? As soon as the UAS has=20 > > received the INVITE? >=20 > Yes. I think this will have a much better chance of succeeding if the specification requires this exchange to use the same source and destination ports as the media that will later be sent on the same channel. If not, an SBC may lock onto this stream and reject media from other sources. Hans --=20 Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210857 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 04 06:13:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I61rP-0000yV-Sl; Wed, 04 Jul 2007 06:13:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I61rO-0000xV-Lb for sip-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 06:13:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I61rN-0000x0-Tx for sip@ietf.org; Wed, 04 Jul 2007 06:13:21 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I61rJ-0004Fa-1J for sip@ietf.org; Wed, 04 Jul 2007 06:13:21 -0400 Received: (qmail invoked by alias); 04 Jul 2007 10:13:16 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp039) with SMTP; 04 Jul 2007 12:13:16 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+qLdR7y1aq9cM/BX5sdo1Xm2KI22HMVKwFjFm12W yK0N4yYs65IKok Message-ID: <468B72BA.2090904@gmx.net> Date: Wed, 04 Jul 2007 12:13:14 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF SIP List , GEOPRIV X-Y-GMX-Trusted: 0 X-Spam-Score: 1.2 (+) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Cc: Subject: [Sip] Text for the SIP Location Conveyance Security Consideration Section X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0063333552==" Errors-To: sip-bounces@ietf.org --===============0063333552== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi James,
Hi Brian,

below you can find a first attempt to update the security consideration section of
http://tools.ietf.org/html/draft-ietf-sip-location-conveyance-07

Ciao
Hannes

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


Security Considerations

Conveyance of geographical location raises privacy concerns,
and depending on use, there may be confidentiality and access control aspects.  

This section lists scenarios with their corresponding security
and privacy considerations.


Conveying Location by Value


    UA Alice                     SIP Proxy   UAS-A   UAS-B   UAS-C

       |  SIP Message                |          |       |       |
       |---------------------------->|          |       |       |
       |  Location (value/body)      |                  |
       |                             |----------------->|
       |                             |                  |
       |                SIP Message                     |
       |<-----------------------------------------------|
       |                                                |

             Figure z: Location by Value

Figure z shows a SIP message that carries an LbyV in the body of the SIP
message.

Conveying a Reference to Location Information


    UA Alice                  SIP Proxy   UAS-A   UAS-B   UAS-C
                           Location Server
    |  SIP Message                |          |       |       |
    |---------------------------->|          |       |       |
    |                             |  SIP Message + LbyR      |
    |                             |------------------------->|
    |                             |                          |
    |                             |                          |
    |                             |  Resolve LbyR            |
    |                             |<=========================|
    |                             |                          |
    |                             |  PIDF-LO                 |
    |                             |=========================>|
    |                             |                          |
    |  SIP Message                                           |
    |<-------------------------------------------------------|
    |                                                        |
    |                                                        |

             Figure x: Usage Scenario: Proxy adding LbyR


Figure x shows an exchange where a SIP proxy acts as a Location Server and
attaches a LbyR to the header of the bypassing SIP message. A separate
protocol interaction is needed to resolve the reference to a PIDF-LO.


   UA Alice                     LCS       UAS-A   UAS-B   UAS-C

     |  Request LbyR               |          |       |       |
     |---------------------------->|          |       |       |
     |  LbyR                       |          |       |       |
     |<----------------------------|          |       |       |
     |                             |          |       |       |
     |  SIP Message including LbyR                            |
     |------------------------------------------------------->|
     |                             |                          |
     |                             | Resolve LbyR             |
     |                             |<=========================|
     |                             |                          |
     |                             | PIDF-LO                  |
     |                             |=========================>|
     |                                                        |
     |  SIP Message                                           |
     |<-------------------------------------------------------|
     |                                                        |
     |                                                        |

            Figure y: Usage Scenario: End Host adding Reference

Figure y depicts a message exchange where an LbyR was obtained outside the
SIP protocol exchange, in this case using the Location Configuration Protocol, and
where the LbyR is attached to the header or the body of the SIP message.

Security Guidelines

* Determining the Location Recipient

An end point should know whether location information (by value or by reference) will be used for location-based routing or for consumption by the other communication end point. This applies to Figure x, y and z. When location information is meant for consumption by the other communication end point only then the usage of S/MIME is RECOMMENDED to protect the LbyV and LbyR against eavesdropping. The values MUST be placed into the body of the message. Alternatively, in some environments hop-by-hop security using TLS MAY provide sufficient security protection (depending on the location-based application).
Since retargeting and forking might prevent the communication initiator to obtain the correct public key it is suggested to convey the LbyV / LbyR after the initial communication setup, for example, using an UPDATE message. To simplify the management of certificates the usage of SIP CERT is suggested, see [I-D.ietf-sip-cert].

For cases where location-based routing is envisioned S/MIME cannot be used since the entity performing the location based routing interaction is likely not to be known in advance. Hence, TLS MUST be used to protect the LO in transit.

In cases where a proxy adds an LbyR TLS MUST be used from the SIP proxy towards the final recipient.

* Computing a LbyR

To prevent others from accessing the LbyR for a particular entity, the reference to a Location Object MUST NOT be
guessable. It is RECOMMENDED that the reference contains a random component with at least 128 bit of entropy. For providing randomness the best current practice guidelines in RFC 4086 [RFC4086] have to be applied. It is furthermore mandated to use a SIPS URI schema, which implies the usage of TLS with confidentiality protection, to prevent eavesdroppers to observe the protocol exchange between the Location Recipient and the Location Server when dereferencing the LbyR.

These recommendations refer only to Figure x where the SIP proxy adds the reference to the outgoing message. With the scenario in Figure y the acquisition of the LbyR and subsequent conveyance is decoupled and hence it is the responsibility of the LCP specification and ultimately of the LCS to provide a reference with the same randomness.

It is not necessary to digitally sign the PIDF-LO since authentication of Location Server is provided by the dereferencing protocol.

* Content of the PIDF-LO

The PIDF-LO contains identity information and privacy rules. In cases where the end host adds a the PIDF-LO the content of the identity and the rules conveyed to the Location Recipient are under full control by the end point itself. However, when a SIP proxy adds a reference to location information it needs to guess the context. There are, however, a few information elements in the SIP message itself that provide hint about the desirable behavior by the SIP proxy.

When SIP privacy mechanisms, see RFC 3323, are used then the PIDF-LO MUST NOT contain the identity of Target in the entity field of the PIDF document. Furthermore, the extended privacy rules and the Note Well statement MUST NOT provide linkability with the identity of the Target.

When the SIP proxy adds a LbyR and does not know the privacy policies of the Target then it MUST set to the values to the following values:

* The note-well element MUST NOT contain human readable privacy policies.
* The retransmission-allowed element is set to zero (0), i.e., further distribution
   is not allowed.
* The retention-expires field MUST be set to a maximum of 24 hours.
* The extended policy rules MUST not be present.
* The entity field in the PIDF document MUST be empty.

This document does not provide information how the current context of the communication initiator is determined other than by inspecting information provided by RFC 3323 and implicitly via the Service URN [I-D.ietf-ecrit-service-urn]. At the time of writing this specification this functionality is made available within the SIP SAML [I-D.ietf-sip-saml] specification.

--===============0063333552== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0063333552==-- From sip-bounces@ietf.org Wed Jul 04 06:19:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I61xI-0000Zd-NV; Wed, 04 Jul 2007 06:19:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I61xG-0000Z5-UN for sip-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 06:19:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I61xG-0000Yv-K2 for sip@ietf.org; Wed, 04 Jul 2007 06:19:26 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I61xC-0004us-6r for sip@ietf.org; Wed, 04 Jul 2007 06:19:26 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JKN00031GNWSN@siemenscomms.co.uk> for sip@ietf.org; Wed, 04 Jul 2007 11:19:08 +0100 (BST) Date: Wed, 04 Jul 2007 11:19:20 +0100 From: "Elwell, John" Subject: RE: [Sip] SIP Identity using Media Path In-reply-to: <1d5f01c7be17$b07aedc0$2014590a@amer.cisco.com> To: Dan Wing , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D019F348@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Sip] SIP Identity using Media Path Thread-Index: Ace82p2yNu6lfaNzQcq8BXk5gCIEoQBMzNngAAHQ63AAA3mb0A== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D019F2FA@GBNTHT12009MSX.gb002.siemens.net> <1d5f01c7be17$b07aedc0$2014590a@amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dan, Thanks for the explanation. However, I am still not certain I have quite "got it" yet. Let me explain what I think it is doing, and you can confirm or deny. A sends an INVITE request with SDP offer containing ICE candidates and a password. A's local proxy adds the Identity-Media header field. B receives the INVITE request and knows, from the From and Identity-Media header fields, that it has comes from A, and therefore that the password has come from A. So if nobody has been able to eavesdrop on the INVITE request, this gives proof of ownership of STUN requests demonstrating possession of that password. Right? However, the assumption that there is no eavesdropping is not a safe assumption (even if SIPS is use, I think we are all familiar with its limitations). By conveying a public key rather than a password, eavesdropping is not a problem. Right? More below. John > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: 04 July 2007 09:46 > To: Elwell, John; sip@ietf.org > Cc: ietf-rtpsec@imc.org > Subject: RE: [Sip] SIP Identity using Media Path > > > The mechanism described for ICE seems to provide an > > alternative to ICE's > > password-based mechanism for correlating binding requests with > > offer-answer exchanges. > > It's not an alternative to ICE's username and password; the new > attributes (PK-CHALLENGE, PK-RESPONSE) would be used in addition > to the existing STUN attributes used by ICE's connectivity > checks. The ICE username/password would still be used for > message integrity and to associate a flow with an endpoint's > SDP answer. > > > I have not seen any motivation for this > > alternative. > > The motivation is proving you know the private key > associated with the public key. It's only after that > proof that you can be assured the Invite wasn't captured > by an attacker, had its SDP replaced with the attacker's > IP address, and replayed to you. [JRE] The Identity header field would prevent this (although the Identity-Media header field does not). > > All of the proof of identity techniques described in the > paper exchange a public key over the media path (HIP, DTLS-SRTP, > TLS) or in the SIP signaling path (ICE). Then, over the media > path, the remote party proves he knows the private key > associated with that public key. This proof of knowledge of > the private key is part of the handshake for HIP, DTLS, > and TLS; what the paper does is describe how ICE can do > something similar. The primary purpose of ICE in that > family of proof of identity techniques is to provide a > modicum of SBC-survivable identity if RTP (or SRTP > with Security Descriptions) is used. Things are obviously > much more secure if DTLS-SRTP, TLS, or HIP are used, > as this ensures nothing is going to inject RTP packets > into the stream; using RTP can't ensure that. > > > (Crypto experts will point out there is a mafia fraud > attack problem with the ICE technique as described > in the paper. That is true, but if you're not going > to run SRTP using a secure keying mechanism you're > suffering the same risk of someone injecting RTP into > your stream as the mafia fraud attack.) > > -d > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 04 07:08:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I62ie-0007gd-N6; Wed, 04 Jul 2007 07:08:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I62ib-0007Jv-5q for sip-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 07:08:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I62ia-00078Y-5d for sip@ietf.org; Wed, 04 Jul 2007 07:08:20 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I62iW-0008Ny-Mp for sip@ietf.org; Wed, 04 Jul 2007 07:08:20 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l64B7vZT004614; Wed, 4 Jul 2007 06:08:08 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 06:07:59 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 13:07:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Security issues with ietf-sip-loop-fix Date: Wed, 4 Jul 2007 13:07:48 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180013B6164@DEEXC1U01.de.lucent.com> In-Reply-To: <167A3231-404F-41FB-B1E0-3881660359EF@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Security issues with ietf-sip-loop-fix Thread-Index: Ace9Gz+92sBsTjlNTxe9OTDuhREe7ABD9P3g References: <167A3231-404F-41FB-B1E0-3881660359EF@cisco.com> From: "DRAGE, Keith \(Keith\)" To: "Cullen Jennings" , "SIP" X-OriginalArrivalTime: 04 Jul 2007 11:07:56.0980 (UTC) FILETIME=[936FD740:01C7BE2B] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (as individual) With regard to: > If we go forward with path 1, the value of this draft is=20 > probably not super high because Max-Forwards deals with the=20 > the accidental loops in most cases (but not all cases). If=20 > we go with path 2, the WG will need make sure it OK with the=20 > solution. I'm certainly open to other paths forward if=20 > someone has a good idea. There have been comments previously on this list that the default value of 70 for Max-Forwards is too high, and that a lower default value should have been used. Therefore Max-Forwards will find the accidental loops, but will take longer to do it, if the default values are used. Regards Keith=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: Tuesday, July 03, 2007 3:36 AM > To: SIP > Subject: [Sip] Security issues with ietf-sip-loop-fix >=20 >=20 > (this email with my AD hat on) >=20 > The type of SIP loops described in ietf-sip-loop-fix can be=20 > roughly classified into two categories. Loops that had=20 > happened because an accidental registration that causes a=20 > loop, and loops that happened due to malicious intent. >=20 > This draft attempted to deals with both. The abstract describes it as >=20 > This document normatively updates RFC 3261, the Session Initiation > Protocol (SIP), to address a security vulnerability=20 > identified in SIP > proxy behavior. This vulnerability enables an attack against SIP > networks where a small number of legitimate, even authorized, SIP > requests can stimulate massive amounts of proxy-to-proxy traffic. >=20 > During IETF LC, substantial comment came up about the=20 > security of this draft not really working in the case of=20 > malicious loops. A thread ensues that convinced many people=20 > on the thread that this draft did not really help with the=20 > malicious loops. (Not 100% sure here but I suspect that the=20 > authors and chairs were all convinced of this). I will let=20 > others explain the issues that came up as we decide what to do next. >=20 > I think that some of issue was discussed while the working=20 > group was considering this draft - however, I suspect that=20 > many participants did not understand how easily this security=20 > would be defeated. I for one significantly underestimated the=20 > how easy it was for a malicious attacker to cause this=20 > problem. I apologize to the folks that attempted to explain=20 > it to me and I just failed to "get it". >=20 > Anyways, we need to figure out what to do next with this=20 > draft. There are basically two paths forward that I see: >=20 > 1) reduce the scope so that it only deals with accidental=20 > loops and provides no protection against malicious loops. I=20 > don't think this would change any of the mechanisms in the=20 > draft but it would probably change lots of the text around=20 > what security claims the draft made. >=20 > 2) try to extend or replace the mechanism with one that does=20 > protect against malicious attack. A strong candidate to=20 > consider would be the work in draft-sparks-sipping-max-breadth. >=20 > If we go forward with path 1, the value of this draft is=20 > probably not super high because Max-Forwards deals with the=20 > the accidental loops in most cases (but not all cases). If=20 > we go with path 2, the WG will need make sure it OK with the=20 > solution. I'm certainly open to other paths forward if=20 > someone has a good idea. >=20 > What I would like to do now is start some discussion about=20 > what the working group would like to do with this draft. >=20 > Thanks, Cullen >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 04 07:11:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I62lx-0005kG-PA; Wed, 04 Jul 2007 07:11:49 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I62lv-0005k8-H0 for sip-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 07:11:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I62lv-0005k0-7C for sip@ietf.org; Wed, 04 Jul 2007 07:11:47 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I62lq-0000O0-Iu for sip@ietf.org; Wed, 04 Jul 2007 07:11:46 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l64BBfZo003487; Wed, 4 Jul 2007 06:11:41 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 06:11:41 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 13:11:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Security issues with ietf-sip-loop-fix Date: Wed, 4 Jul 2007 13:11:29 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180013B6167@DEEXC1U01.de.lucent.com> In-Reply-To: <167A3231-404F-41FB-B1E0-3881660359EF@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Security issues with ietf-sip-loop-fix Thread-Index: Ace9Gz+92sBsTjlNTxe9OTDuhREe7ABEFBKg References: <167A3231-404F-41FB-B1E0-3881660359EF@cisco.com> From: "DRAGE, Keith \(Keith\)" To: "Cullen Jennings" , "SIP" X-OriginalArrivalTime: 04 Jul 2007 11:11:38.0432 (UTC) FILETIME=[176EBC00:01C7BE2C] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair and document shepherd for this document) We do need to get this resolved, and have therefore allocated a slot to the discussion at the forthcoming IETF meeting of the SIP WG. This does however require material to put on the slides to lead the discussion, rather than spending 15 minutes drawing thoughts out of the microphone stream at the meeting. So please post to the list with views on this before the meeting, ideally backed up with technical thoughts to justify your position. Regards Keith=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: Tuesday, July 03, 2007 3:36 AM > To: SIP > Subject: [Sip] Security issues with ietf-sip-loop-fix >=20 >=20 > (this email with my AD hat on) >=20 > The type of SIP loops described in ietf-sip-loop-fix can be=20 > roughly classified into two categories. Loops that had=20 > happened because an accidental registration that causes a=20 > loop, and loops that happened due to malicious intent. >=20 > This draft attempted to deals with both. The abstract describes it as >=20 > This document normatively updates RFC 3261, the Session Initiation > Protocol (SIP), to address a security vulnerability=20 > identified in SIP > proxy behavior. This vulnerability enables an attack against SIP > networks where a small number of legitimate, even authorized, SIP > requests can stimulate massive amounts of proxy-to-proxy traffic. >=20 > During IETF LC, substantial comment came up about the=20 > security of this draft not really working in the case of=20 > malicious loops. A thread ensues that convinced many people=20 > on the thread that this draft did not really help with the=20 > malicious loops. (Not 100% sure here but I suspect that the=20 > authors and chairs were all convinced of this). I will let=20 > others explain the issues that came up as we decide what to do next. >=20 > I think that some of issue was discussed while the working=20 > group was considering this draft - however, I suspect that=20 > many participants did not understand how easily this security=20 > would be defeated. I for one significantly underestimated the=20 > how easy it was for a malicious attacker to cause this=20 > problem. I apologize to the folks that attempted to explain=20 > it to me and I just failed to "get it". >=20 > Anyways, we need to figure out what to do next with this=20 > draft. There are basically two paths forward that I see: >=20 > 1) reduce the scope so that it only deals with accidental=20 > loops and provides no protection against malicious loops. I=20 > don't think this would change any of the mechanisms in the=20 > draft but it would probably change lots of the text around=20 > what security claims the draft made. >=20 > 2) try to extend or replace the mechanism with one that does=20 > protect against malicious attack. A strong candidate to=20 > consider would be the work in draft-sparks-sipping-max-breadth. >=20 > If we go forward with path 1, the value of this draft is=20 > probably not super high because Max-Forwards deals with the=20 > the accidental loops in most cases (but not all cases). If=20 > we go with path 2, the WG will need make sure it OK with the=20 > solution. I'm certainly open to other paths forward if=20 > someone has a good idea. >=20 > What I would like to do now is start some discussion about=20 > what the working group would like to do with this draft. >=20 > Thanks, Cullen >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 04 09:32:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I64xh-0002na-6E; Wed, 04 Jul 2007 09:32:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I64xe-0002nU-SA for sip-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 09:32:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I64xe-0002nM-IO for sip@ietf.org; Wed, 04 Jul 2007 09:32:02 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I64xQ-0000uu-Bt for sip@ietf.org; Wed, 04 Jul 2007 09:32:02 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JKN00338PKMON@siemenscomms.co.uk> for sip@ietf.org; Wed, 04 Jul 2007 14:31:35 +0100 (BST) Date: Wed, 04 Jul 2007 14:31:46 +0100 From: "Elwell, John" In-reply-to: To: sip@ietf.org, eburger@standardstrack.com Message-id: <0D5F89FAC29E2C41B98A6A762007F5D019F3A2@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: I-D ACTION:draft-burger-sip-info-00.txt Thread-Index: Ace9nx9bqwi2FhK9SvaDkphpmcx2tQAiR+Yg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Subject: [Sip] RE: I-D ACTION:draft-burger-sip-info-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Eric, I would just like to correct a slight inaccuracy in this draft. RFC 3372 does not specify the use of INFO for QSIG, but RFC 3204 (which is referenced by RFC 3372) does define the MIME type for QSIG. The transport of QSIG using the SIP INFO method is instead specified in Standard ECMA-355 from Ecma-International. This is indeed a very similar usage of INFO to that specified in RFC 3372 and should be allowed in the proposed update to RFC 2976. John > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 03 July 2007 19:15 > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-burger-sip-info-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Session Initiation Protocol (SIP) > INFO Method Context > Author(s) : E. Burger > Filename : draft-burger-sip-info-00.txt > Pages : 8 > Date : 2007-7-3 > > The purpose of the INFO request for the Session Initiation Protocol > (SIP), as described by RFC 2976, is to provide mid-session SIP User > Agent (UA)-to-SIP UA application data transport. In the > years since > the introduction of the INFO request, experience with the > use of the > INFO request indicates a number of problems. This > document explains > why there flaws of using INFO; and explains why it is > not possible to create a > framework to rescue INFO for general purpose use. Thus, this > document restricts the use of INFO to that described in RFC 3372 > (SIP-T). > are INFO-based, proprietary protocols in the wild; the > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-burger-sip-info-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in > the body of > the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-burger-sip-info-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-burger-sip-info-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 04 11:00:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I66LV-0001Jt-JM; Wed, 04 Jul 2007 11:00:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I5opK-0001Yo-Oe for sip-confirm+ok@megatron.ietf.org; Tue, 03 Jul 2007 16:18:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5opK-0001XK-EQ for sip@ietf.org; Tue, 03 Jul 2007 16:18:22 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5oom-0008Mz-FL for sip@ietf.org; Tue, 03 Jul 2007 16:18:22 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l63KHeZ3014313; Tue, 3 Jul 2007 15:17:40 -0500 (CDT) Received: from ILEXC1U02.ndc.lucent.com ([135.3.39.3]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 15:17:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] New draft modifying RFC 4412 for Responses Date: Tue, 3 Jul 2007 15:17:39 -0500 Message-ID: <7D096A439A3D0D48A3D10872022CFD0901508F16@ILEXC1U02.ndc.lucent.com> In-Reply-To: <28F05913385EAC43AF019413F674A0171246E0B5@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New draft modifying RFC 4412 for Responses Thread-Index: Ace3W2f+6x2g9e7DRLOthcOhgFiGbwDBngVAAMvGtmA= References: <28F05913385EAC43AF019413F674A0171246E0B5@OCCLUST04EVS1.ugd.att.com> From: "GOLDMAN, STUART O \(STUART\)" To: "DOLLY, MARTIN C, ATTLABS" , "Janet P Gunn" , "James M. Polk" X-OriginalArrivalTime: 03 Jul 2007 20:17:40.0056 (UTC) FILETIME=[34781580:01C7BDAF] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae X-Mailman-Approved-At: Wed, 04 Jul 2007 11:00:43 -0400 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1347011630==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1347011630== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BDAF.3443EFCF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7BDAF.3443EFCF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 It does seem useful to be able to include the RPH in the response messages, and I don't see any downside in allowing this. =20 Stuart Goldman Alcatel-Lucent=20 sgoldman@alcatel-lucent.com 602 493 8438 =20 =20 ________________________________ From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]=20 Sent: Friday, June 29, 2007 8:29 AM To: Janet P Gunn; James M. Polk Cc: sip@ietf.org Subject: RE: [Sip] New draft modifying RFC 4412 for Responses =20 Hello, =20 Agreed. In addition, not having the RPH in the responses would mean the proxies would have to maintain the state of the RPH value. =20 Martin =20 ________________________________ From: Janet P Gunn [mailto:jgunn6@csc.com]=20 In working on specifying and deploying systems that will actually use the RPH with the ets and wps namespaces, we have found several contexts in which the RPH on the response is very useful.=20 1) Error reporting. RFC 4412 does not give clear direction on the treatment of RPH with syntax errors (out of range priority values, duplicate namespaces, etc.) We have found that including the RPH in the 4xx responses is usesful in addressing the errors.=20 2) In our system, we often set the ets RPH (with default priority) based on the "ETS-DN""dialed number" or uri, before authentication and before knowing the correct priority value. Including the RPH in the response is a useful way of conveying the correct priority value back to nodes earlier in the "call flow".=20 3) Similarly, if an RP actor receives a SIP INVITE with the ETS-DN, but no RPH it may, after authenticating the call, include RPH in the responses in order to inform nodes earlier in the call flow that this is a priority call.=20 4) If the RPH is being used to prioritize processing (of both messages and responses) in the SIP user agent, including the RPH in the response allows the receiving RP actor to give the response "ETS treatment" before checking on the "state" of the call. This is particularly relevant when the RP actor itself is congested.=20 Janet ------_=_NextPart_001_01C7BDAF.3443EFCF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

It = does seem useful to be able to include the RPH in the response messages, and I = don’t see any downside in allowing this.

 

Stuart = Goldman

Alcatel-Lucent =

sgoldman@alcatel-lucent.com

602 493 = 8438

 

=

 

From: = DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]
Sent: Friday, June 29, = 2007 8:29 AM
To: Janet P Gunn; James = M. Polk
Cc: sip@ietf.org
Subject: RE: [Sip] New = draft modifying RFC 4412 for Responses

 

Hello,

 

Agreed. In addition, not having the = RPH in the responses would mean the proxies would have to maintain the state of = the RPH value.

 

Martin

 

From: Janet = P Gunn [mailto:jgunn6@csc.com]

In working on = specifying and deploying systems that will actually use the RPH with the ets and = wps namespaces, we have found several contexts in which the RPH  on the response is very useful.

1)        Error reporting.  RFC 4412 does not = give clear direction on the treatment of RPH with syntax errors (out of range priority values, duplicate namespaces, etc.)  We have found that = including the RPH in the  4xx responses is usesful in addressing the errors. =
2)        In our system, we often set the ets =  RPH (with default priority)  based on the “ETS-DN”“dialed number” or uri, before authentication and before knowing the = correct priority value.  Including the RPH in the response is a useful way = of conveying the correct priority value back to nodes earlier in the = “call flow”.
3)        Similarly, if an RP actor receives a SIP = INVITE with the ETS-DN, but no RPH it may, after authenticating the call, = include RPH in the responses in order to inform  nodes earlier in the call flow = that this is a priority call.
4)        If the RPH is being used to prioritize = processing (of both messages and responses) in the SIP user agent, including the = RPH in the response allows the receiving RP actor to give the response = “ETS treatment” before checking on the “state” of the call.  This is particularly relevant when the RP actor itself is = congested.

Janet

------_=_NextPart_001_01C7BDAF.3443EFCF-- --===============1347011630== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1347011630==-- From sip-bounces@ietf.org Wed Jul 04 12:40:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I67tr-0007CP-6b; Wed, 04 Jul 2007 12:40:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I67tq-0007BG-8k for sip-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 12:40:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I67tp-0007B8-Nl for sip@ietf.org; Wed, 04 Jul 2007 12:40:17 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I67th-0004Wv-RP for sip@ietf.org; Wed, 04 Jul 2007 12:40:17 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 04 Jul 2007 12:40:10 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHtqi0ZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,498,1175486400"; d="scan'208"; a="125222263:sNHT33789572" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l64Ge9n9001906; Wed, 4 Jul 2007 12:40:09 -0400 Received: from dwingwxp ([10.32.240.194]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l64Ge36a013784; Wed, 4 Jul 2007 16:40:08 GMT From: "Dan Wing" To: "'Hans Persson'" , Subject: RE: [Sip] SIP Identity using Media Path Date: Wed, 4 Jul 2007 09:40:02 -0700 Message-ID: <1dbc01c7be59$fbd62270$2014590a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <1183539618.30723.44.camel@eeek.ingate.se> Thread-Index: Ace+Gd+1mZGbB63fSbi5GA3N5+TpCwAPyvDw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7102; t=1183567209; x=1184431209; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20SIP=20Identity=20using=20Media=20Path |Sender:=20 |To:=20=22'Hans=20Persson'=22=20,=20; bh=F1Q8mpV3RbG0lyQ5TRd5sbTFKEfkY86blV8Mm6rc6no=; b=i+oJHVarGPANWbNN2EHmhdBy2Iur34wTdeXpD7Em5vJCKaJWZHdWsff5SDGj5qiizJDxw74g O5OoQHIafHXjvj9ktVIutJ2seuo1TxBL9OE2DaT8lRYmOJa1UhvlRhp9; Authentication-Results: rtp-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > I just submitted a draft, "SIP Identity using Media Path", which > > describes a mechanism that allows RFC4474-like signatures and also > > allows SBCs and B2BUAs to modify the message's SDP. Links to HTML > > and plain text versions of the Internet Draft are below. > > It's nice to see work like this that tries to handle the reality of > installed networks instead of pretending that SBCs don't exist. Thanks. > I'm not sure that I grasp this completely yet, but I'll let it simmer > for a while and give it another read later. > > > === Comments === > > Section 3, figure 1: > > This figure is a simplification, since many enterprises will > have their > own SBCs on their borders: > > <--- Enterprise-A ----> > clients --- PBX --- SBC --- SP1-SBC-1 --- SP1-SBC2 ----+ > | > +------------------------------------------------------+ > | > | <--- Enterprise-B ----> > +--- SP2-SBC1 --- SP2-SBC2 --- SBC --- PBX --- clients True. I'll figure out a clearer way to diagram that. > Section 3, "mailto URLs" para: > > sp1.net and sp2.net (and, later in the document, sp3.net) are (or at > least could be) real domains that shouldn't be used. Agreed; I may go with "sp1.example.net" and "sp2.example.net", although this is less clear than using unique top-level domain names. > Section 4.1, item about Contact: > > How can the Contact header usefully be used in the signing process? An > SBC along the message path will happily replace it. I have removed that in -01 (which isn't yet published, of course). There was some thought it was necessary, but I agree it should be removed from the signature. On a similar note, I am considering removing CallId from the signature. Oftentimes the Call Id value contains an IP address (in dotted decimal or hex), and an SBC or B2BUA may also want to rewrite such a CallId. I have made a note of that in -01 so this can be discussed. > === Editorial nits === Thanks for the list of nits - I'll get those cleaned up in -01. -d > In the text, RFC references are sometimes written "RFCxxxx" and > sometimes "RFC xxxx". Decide on one alternative. > > > Section 3, figure 1: > > > +----[SP1-SBC1]-[SP1-SBC1]---[SP2-SBC1]-[SP2-SBC2]----+ > > SP1 has two SBC1. One of them should be SBC2. > > Section 3, first para after figure 1: > > > using a mailto URL (e.g., 'sip:john.doe@example.com') > > Both here and a couple of paragraphs below (under "Mailto > URLs:"), sip: > URLs are refered to as mailto URLs which sounds very strange. > > Section 3, "mailto URLs" para: > > > SP1 would validate the RFC4474 signature modify the SDP. > > I can't make sense of this sentence. What should it mean? > > > So that a > > new RFC4474 signature can be created using its own > public/private > > key pair, SP1 needs to modify the From: field. > > Rewrite this sentence to > > >> SP1 needs to modify the From: field so that a new RFC4474 signature > >> can be created using its own public/private key pair. > > > Unlike with E.164 > > numbers which are globally unique, the SP1 isn't able to > > Remove the "the" in front of "SP1". > > > Section 4, second list item: > > > o This new header is signed in addition to the same set of SIP > > headers signed by RFC4474 (detailed in ) > > Detailed in what? > > > Section 4, para before figure 2: > > > In practice, if the > > The rest of this sentence has gotten lost somewhere. Please > contact the > information desk. > > > Section 4, step 1: > > > Step 1: Originating endpoint prepares to send an Invite and chooses > > "INVITE" > > > then sends the Invite to its local SIP proxy. > > "INVITE" > > > Section 4, step 2: > > > into the new Identity-Media header. The invite is forwarded > > "INVITE" > > > Section 4, step 4: > > > the Invite. It validates the Identity-Media signature is > > valid and was validates it was generated by the > originating > > "INVITE" > > Insert "that" after "It validates". Change "was validates" to > "validates > that". > > > Section 4, step 5: > > > authentication service forwards the Invite to the endpoint. > > "INVITE" > > > Section 4, step 6: > > > challenge technique from the Invite, and performs that > > "INVITE" > > > Section 4, step 7: > > > public key. The terminating endpoint validates the > > Insert "that" after "validates". > > > Section 4, step 8: > > > Step 8: You can reliably and honestly indicate calling party > > information ("caller-id") to the terminating > endpoint, and > > ring their phone. > > Rewrite to > > >> Step 8: The terminating endpoint can reliably and > honestly indicate > >> calling party information ("caller-id") and ring > the phone. > > > Section 4.1, first para: > > > "fingerprint"). The specific SDP attribute that are signed depends > > "attributes" > > > Section 4.1, second para: > > > The SIP headers that are signed are signed the same as done by > > Remove the second "signed". > > > the body is not signed. They signed headers are: > > "They" -> "The" > > > Section 4.1, item about Date: > > > the weekday and month items case set as shown in BNF in RFC 3261. > > Insert "the" before "BNF". > > > Section 4.2: > > > The authentication service examines the SIP message body for the > > application/sdp Content-Type. For all such content-types > found, the > > "all such content-types" -> "all such message bodies" > > > Section 5, para 3: > > > or HIP session and validates the certificate fingerprint > presented in > > SIP signaling matches the certificate presented in the TLS, DTLS, > > Insert "that" after "validates" and insert "the" before "SIP". > > > Section 5.2: > > Newline missing after SDP example. > > > Section 5.3.1: > > > subsequent PK-CHALLANGE and PK-RESPONSE, in its SDP. The > syntax is a > > "CHALLENGE" > > > Section 5.3.2.1: > > > 5.3.2.1. PK-CHALLANGE > > "CHALLENGE" > > > Section 7.1: > > Write the list items as complete sentences, i.e. start with > capitals and > remove ", or" from the end of the first item. > > > the device to manufacture a new self-signed certificate (or public > > Insert "needs" after "the device". > > > Section 10.1: > > > This example shows how two a=fingerprint lines in SDP would populate > > a the Media-Fingerprints SIP header field. The following is an > > example of an Invite created by the endpoint. > > "a the" -> "the" > > "INVITE" > > > Hans > > -- > Hans Persson Ingate - Firewalls with SIP & NAT > Ingate Systems AB +46 13 210857 http://www.ingate.com/ > > Private: > http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 04 13:01:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I68EM-0002rI-KQ; Wed, 04 Jul 2007 13:01:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I68EM-0002rD-0O for sip-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 13:01:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I68EL-0002r5-N2 for sip@ietf.org; Wed, 04 Jul 2007 13:01:29 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I68ED-0008TK-Ob for sip@ietf.org; Wed, 04 Jul 2007 13:01:29 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 04 Jul 2007 13:01:21 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHdui0ZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,498,1175486400"; d="scan'208"; a="64346814:sNHT26184332" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l64H1LOO023515; Wed, 4 Jul 2007 13:01:21 -0400 Received: from dwingwxp ([10.32.240.194]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l64H1Js0016788; Wed, 4 Jul 2007 17:01:20 GMT From: "Dan Wing" To: "'Hans Persson'" Subject: RE: [Sip] SIP Identity using Media Path Date: Wed, 4 Jul 2007 10:01:19 -0700 Message-ID: <1dbd01c7be5c$f21e2900$2014590a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <1183541118.30723.49.camel@eeek.ingate.se> Thread-Index: Ace+HU7gUtOIr1U8TCOijEQKnlmCdAAPklhQ DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1285; t=1183568481; x=1184432481; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20SIP=20Identity=20using=20Media=20Path |Sender:=20 |To:=20=22'Hans=20Persson'=22=20; bh=37yz3HAlzBV5X0Kbj5Plxo9bbSL2trbUGUxFteamaL8=; b=O34w1MU7Qtt7VomGgeOOcQGl+fqsxYGbRbNYdIzDzxDKI5DJutrmDH+vZ42k8Fi8ECKhX6Re eMZrIFDxqU4gNxGEi1oXb0Z8tnKvDgofGXKnXmc98ik/HZpRrMuEgNFe; Authentication-Results: rtp-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sip@ietf.org, ietf-rtpsec@imc.org, "'Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > m=E5n 2007-07-02 klockan 16:04 -0700 skrev Dan Wing: >=20 > > > Chapter 9 says: > > >=20 > > > "in order for the mechanism to work, SBC-type-of-entities=20 > > > must permit DTLS, TLS, ICE, or HIP messages to be exchanged=20 > > > in the media path." > > >=20 > > > A small question for clarification: at what point must this=20 > > > exchange (two-way, I assume) work? As soon as the UAS has=20 > > > received the INVITE? > >=20 > > Yes. >=20 > I think this will have a much better chance of succeeding if the > specification requires this exchange to use the same source and > destination ports as the media that will later be sent on the same > channel. Yes, that is how HIP's key exchange, TLS, DTLS-SRTP, and ICE all function. > If not, an SBC may lock onto this stream and reject=20 > media from other sources. Yes, I agree that will give the best chance. Of course, it is always possible for an SBC (or firewall) to block such messages=20 anyway (as has been discussed on the RTPSEC mailer). -d > Hans >=20 > --=20 > Hans Persson Ingate - Firewalls with SIP & NAT > Ingate Systems AB +46 13 210857 http://www.ingate.com/ >=20 > Private: =20 > http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 04 13:18:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I68Uq-0002rk-Fh; Wed, 04 Jul 2007 13:18:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I68Up-0002re-7R for sip-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 13:18:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I68Uo-0002rT-Ta for sip@ietf.org; Wed, 04 Jul 2007 13:18:30 -0400 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I68Uk-0003Ri-CR for sip@ietf.org; Wed, 04 Jul 2007 13:18:30 -0400 Received: from [192.168.0.101] (ua-83-227-239-180.cust.bredbandsbolaget.se [83.227.239.180]) (authenticated bits=0) by usagi.ingate.se (8.12.11.20060308/8.12.11) with ESMTP id l64HIGVh027060 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Jul 2007 19:18:16 +0200 Subject: RE: [Sip] SIP Identity using Media Path From: Hans Persson To: Dan Wing In-Reply-To: <1dbc01c7be59$fbd62270$2014590a@amer.cisco.com> References: <1dbc01c7be59$fbd62270$2014590a@amer.cisco.com> Content-Type: text/plain Organization: Ingate Systems Date: Wed, 04 Jul 2007 19:13:54 +0200 Message-Id: <1183569234.6837.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on usagi.ingate.se X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.8 X-Spam-Report: * 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on usagi.ingate.se X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Wed, 04 Jul 2007 19:18:22 +0200 (CEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: sip@ietf.org, ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ons 2007-07-04 klockan 09:40 -0700 skrev Dan Wing: > > <--- Enterprise-A ----> > > clients --- PBX --- SBC --- SP1-SBC-1 --- SP1-SBC2 ----+ > > | > > +------------------------------------------------------+ > > | > > | <--- Enterprise-B ----> > > +--- SP2-SBC1 --- SP2-SBC2 --- SBC --- PBX --- clients > > True. I'll figure out a clearer way to diagram that. Possibly it gets better if done up-down instead of left-right. > > Section 3, "mailto URLs" para: > > > > sp1.net and sp2.net (and, later in the document, sp3.net) are (or at > > least could be) real domains that shouldn't be used. > > Agreed; I may go with "sp1.example.net" and "sp2.example.net", > although this is less clear than using unique top-level domain > names. Perhaps it would be clearer to use for instance sp1.example.com, sp2.example.net and sp3.example.org. > > Section 4.1, item about Contact: > > > > How can the Contact header usefully be used in the signing process? An > > SBC along the message path will happily replace it. > > I have removed that in -01 (which isn't yet published, of course). There > was some thought it was necessary, but I agree it should be removed > from the signature. > > On a similar note, I am considering removing CallId from the signature. > Oftentimes the Call Id value contains an IP address (in dotted decimal > or hex), and an SBC or B2BUA may also want to rewrite such a CallId. I > have made a note of that in -01 so this can be discussed. I thought about that as well, but apparently I forgot about adding it to my mail. I think it would be a good idea to take Call-ID out as well. Hans -- Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 04 13:19:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I68VN-0003Gu-K5; Wed, 04 Jul 2007 13:19:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I68VM-0003Gp-7T for sip-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 13:19:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I68VL-0003Gh-UC for sip@ietf.org; Wed, 04 Jul 2007 13:19:03 -0400 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I68VD-0003Ua-09 for sip@ietf.org; Wed, 04 Jul 2007 13:19:03 -0400 Received: from [192.168.0.101] (ua-83-227-239-180.cust.bredbandsbolaget.se [83.227.239.180]) (authenticated bits=0) by usagi.ingate.se (8.12.11.20060308/8.12.11) with ESMTP id l64HITMf027078 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Jul 2007 19:18:29 +0200 Subject: RE: [Sip] SIP Identity using Media Path From: Hans Persson To: Dan Wing In-Reply-To: <1dbd01c7be5c$f21e2900$2014590a@amer.cisco.com> References: <1dbd01c7be5c$f21e2900$2014590a@amer.cisco.com> Content-Type: text/plain Organization: Ingate Systems Date: Wed, 04 Jul 2007 19:18:10 +0200 Message-Id: <1183569490.6837.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on usagi.ingate.se X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.8 X-Spam-Report: * 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on usagi.ingate.se X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Wed, 04 Jul 2007 19:18:30 +0200 (CEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sip@ietf.org, ietf-rtpsec@imc.org, "'Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ons 2007-07-04 klockan 10:01 -0700 skrev Dan Wing: > Yes, I agree that will give the best chance. Of course, it is > always possible for an SBC (or firewall) to block such messages > anyway (as has been discussed on the RTPSEC mailer). But that would at least mean that the SBC would have to look inside the media stream to see that not everything in it is (S)RTP, instead of just looking at the source and destination. It may happen, of course, but at least it's less likely. When it does appear, it would require an SBC that can recognize the security interchange for what it is and allow it to pass even though it isn't media. I'm not sure if that can reasonably be done. Hans -- Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 04 13:26:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I68cC-0002Xc-7l; Wed, 04 Jul 2007 13:26:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I68cA-0002XK-Qk for sip-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 13:26:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I68cA-0002XC-H4 for sip@ietf.org; Wed, 04 Jul 2007 13:26:06 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I68c6-0004Lu-3l for sip@ietf.org; Wed, 04 Jul 2007 13:26:06 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 04 Jul 2007 13:26:02 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAAd1i0ZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,498,1175486400"; d="scan'208"; a="125224038:sNHT30729064" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l64HQ15F012520; Wed, 4 Jul 2007 13:26:01 -0400 Received: from dwingwxp ([10.32.240.194]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l64HPws0020399; Wed, 4 Jul 2007 17:25:58 GMT From: "Dan Wing" To: "'Elwell, John'" , Subject: RE: [Sip] SIP Identity using Media Path Date: Wed, 4 Jul 2007 10:25:57 -0700 Message-ID: <1dc201c7be60$645701b0$2014590a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D019F348@GBNTHT12009MSX.gb002.siemens.net> Thread-Index: Ace82p2yNu6lfaNzQcq8BXk5gCIEoQBMzNngAAHQ63AAA3mb0AAO2OxA DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5189; t=1183569961; x=1184433961; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20SIP=20Identity=20using=20Media=20Path |Sender:=20 |To:=20=22'Elwell, =20John'=22=20, =20; bh=VqwmNG7CDPbyuflvQWNzbBXOsN9ZUcmpAoMrzYzKjzw=; b=Va+/JV1PSXUvb0L8vvoqVORCvB0xlqUQm1TXcyxD4CMpyEytt5EINPpkxhmPDjSDldYFuXyV e+79YW9I4dm3bJZ9DLcLgGXwiLUW4+yhqnlDBoyEkWLHzhH2SmZV/TtV; Authentication-Results: rtp-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Wednesday, July 04, 2007 3:19 AM > To: Dan Wing; sip@ietf.org > Cc: ietf-rtpsec@imc.org > Subject: RE: [Sip] SIP Identity using Media Path > > Dan, > > Thanks for the explanation. However, I am still not certain I > have quite > "got it" yet. Let me explain what I think it is doing, and you can > confirm or deny. > > A sends an INVITE request with SDP offer containing ICE > candidates and a > password. A's local proxy adds the Identity-Media header field. B > receives the INVITE request and knows, from the From and > Identity-Media > header fields, that it has comes from A, and therefore that > the password > has come from A. So if nobody has been able to eavesdrop on the INVITE > request, this gives proof of ownership of STUN requests demonstrating > possession of that password. Right? Yes -- you could accomplish exactly that by only validating the signature over the headers and not doing the HIP/ICE/DTLS-SRTP/TLS media path validation. However, this means you have transitive trust of all the SIP proxies along the path. It also means you don't think an attacker has captured a valid, signed Invite, and is replaying it towards you. > However, the assumption that there is no eavesdropping is not a safe > assumption (even if SIPS is use, I think we are all familiar with its > limitations). By conveying a public key rather than a password, > eavesdropping is not a problem. Right? Right. (Although I have variously convinced myself there is still a mafia fraud attack problem with the ICE technique, and have convinced myself there isn't such an attack. I'll need to leave that analysis until later when I have sufficient time to write it up. Today I think there isn't a problem (because the public key is authenticated by A's signature, which prevents a man-in-the-middle from doing a mafia fraud attack by replacing the A's public key with his own public key.) > More below. > > John > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: 04 July 2007 09:46 > > To: Elwell, John; sip@ietf.org > > Cc: ietf-rtpsec@imc.org > > Subject: RE: [Sip] SIP Identity using Media Path > > > > > The mechanism described for ICE seems to provide an > > > alternative to ICE's > > > password-based mechanism for correlating binding requests with > > > offer-answer exchanges. > > > > It's not an alternative to ICE's username and password; the new > > attributes (PK-CHALLENGE, PK-RESPONSE) would be used in addition > > to the existing STUN attributes used by ICE's connectivity > > checks. The ICE username/password would still be used for > > message integrity and to associate a flow with an endpoint's > > SDP answer. > > > > > I have not seen any motivation for this > > > alternative. > > > > The motivation is proving you know the private key > > associated with the public key. It's only after that > > proof that you can be assured the Invite wasn't captured > > by an attacker, had its SDP replaced with the attacker's > > IP address, and replayed to you. > [JRE] The Identity header field would prevent this (although the > Identity-Media header field does not). Right. To combat this attack, Identity (RFC4474) relies on IP address and port numbers. However, NATs, TURN, and SBCs reduce the value of the IP address and port numbers as a unique identifier of a flow before the RFC4474 replay window has expired. SIP-Identity-Media doesn't use IP addresses -- rather, it has the endpoints prove they know the private key associated with their public key. This allows SBCs to rewrite m/c lines, and also removes the risk, inherient in RFC4474, that an attacker will be able to get your recently-used transport address assigned to them by the same NAT or TURN server. -d > > All of the proof of identity techniques described in the > > paper exchange a public key over the media path (HIP, DTLS-SRTP, > > TLS) or in the SIP signaling path (ICE). Then, over the media > > path, the remote party proves he knows the private key > > associated with that public key. This proof of knowledge of > > the private key is part of the handshake for HIP, DTLS, > > and TLS; what the paper does is describe how ICE can do > > something similar. The primary purpose of ICE in that > > family of proof of identity techniques is to provide a > > modicum of SBC-survivable identity if RTP (or SRTP > > with Security Descriptions) is used. Things are obviously > > much more secure if DTLS-SRTP, TLS, or HIP are used, > > as this ensures nothing is going to inject RTP packets > > into the stream; using RTP can't ensure that. > > > > > > (Crypto experts will point out there is a mafia fraud > > attack problem with the ICE technique as described > > in the paper. That is true, but if you're not going > > to run SRTP using a secure keying mechanism you're > > suffering the same risk of someone injecting RTP into > > your stream as the mafia fraud attack.) > > > > -d > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 04 13:27:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I68dS-0005L1-VG; Wed, 04 Jul 2007 13:27:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I68dR-0005Hl-96 for sip-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 13:27:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I68dQ-0005Gl-UE for sip@ietf.org; Wed, 04 Jul 2007 13:27:24 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I68dH-0004dJ-5s for sip@ietf.org; Wed, 04 Jul 2007 13:27:24 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 04 Jul 2007 13:27:15 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAAd1i0ZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,498,1175486400"; d="scan'208"; a="125224079:sNHT28053520" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l64HRENf028965; Wed, 4 Jul 2007 13:27:14 -0400 Received: from dwingwxp ([10.32.240.194]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l64HRDs0020586; Wed, 4 Jul 2007 17:27:13 GMT From: "Dan Wing" To: "'Hans Persson'" Subject: RE: [Sip] SIP Identity using Media Path Date: Wed, 4 Jul 2007 10:27:12 -0700 Message-ID: <1dc301c7be60$8ff64dd0$2014590a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <1183569234.6837.5.camel@localhost.localdomain> Thread-Index: Ace+X1T3kIrHpOPTRcCFDOsCexxANwAARVfA DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2164; t=1183570034; x=1184434034; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20SIP=20Identity=20using=20Media=20Path |Sender:=20 |To:=20=22'Hans=20Persson'=22=20; bh=aMyIdgp8g4NDr5fhtcSZu3JymdZXb7ArlM67SgUvG0g=; b=UgUZff6vrpjoDbW7GwKLlOK+YVZUkIdUYvroIlZDhl9+JYYZ6xBjV+2GVerDskmxlJuPkIFk gpsEvcrUuGOXaZrJtdqTP5vDkqjsaIk24QuSm7KqKxT46jLAvsnV7Z3O; Authentication-Results: rtp-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: sip@ietf.org, ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > > <--- Enterprise-A ----> > > > clients --- PBX --- SBC --- SP1-SBC-1 --- SP1-SBC2 ----+ > > > | > > > +------------------------------------------------------+ > > > | > > > | <--- Enterprise-B ----> > > > +--- SP2-SBC1 --- SP2-SBC2 --- SBC --- PBX --- clients > > > > True. I'll figure out a clearer way to diagram that. > > Possibly it gets better if done up-down instead of left-right. I'll fire up Jave and draw circles. > > > Section 3, "mailto URLs" para: > > > > > > sp1.net and sp2.net (and, later in the document, sp3.net) > are (or at > > > least could be) real domains that shouldn't be used. > > > > Agreed; I may go with "sp1.example.net" and "sp2.example.net", > > although this is less clear than using unique top-level domain > > names. > > Perhaps it would be clearer to use for instance sp1.example.com, > sp2.example.net and sp3.example.org. That would work; thanks for the suggestion. > > > Section 4.1, item about Contact: > > > > > > How can the Contact header usefully be used in the > signing process? An > > > SBC along the message path will happily replace it. > > > > I have removed that in -01 (which isn't yet published, of > course). There > > was some thought it was necessary, but I agree it should be removed > > from the signature. > > > > On a similar note, I am considering removing CallId from > the signature. > > Oftentimes the Call Id value contains an IP address (in > dotted decimal > > or hex), and an SBC or B2BUA may also want to rewrite such > a CallId. I > > have made a note of that in -01 so this can be discussed. > > I thought about that as well, but apparently I forgot about > adding it to > my mail. I think it would be a good idea to take Call-ID out as well. Ok, thanks. -d > Hans > > -- > Hans Persson Ingate - Firewalls with SIP & NAT > Ingate Systems AB +46 13 210877 http://www.ingate.com/ > > Private: > http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 04 13:34:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I68k2-0007gK-NX; Wed, 04 Jul 2007 13:34:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I68k1-0007fI-4w for sip-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 13:34:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I68k0-0007d1-QO for sip@ietf.org; Wed, 04 Jul 2007 13:34:12 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I68jr-0005aC-4c for sip@ietf.org; Wed, 04 Jul 2007 13:34:12 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 04 Jul 2007 13:34:03 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAG92i0ZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,498,1175486400"; d="scan'208"; a="125224343:sNHT26676850" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l64HY2WG030439; Wed, 4 Jul 2007 13:34:02 -0400 Received: from dwingwxp ([10.32.240.194]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l64HY16a022553; Wed, 4 Jul 2007 17:34:01 GMT From: "Dan Wing" To: "'Hans Persson'" Subject: RE: [Sip] SIP Identity using Media Path Date: Wed, 4 Jul 2007 10:34:00 -0700 Message-ID: <1dc401c7be61$833719c0$2014590a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <1183569490.6837.10.camel@localhost.localdomain> Thread-Index: Ace+X2Dig74OrYVtTxKdnvVFAvQxpAAATfzw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1189; t=1183570442; x=1184434442; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20SIP=20Identity=20using=20Media=20Path |Sender:=20 |To:=20=22'Hans=20Persson'=22=20; bh=uL2yUkvTIo6ZN97SEiNKjOynG0GTtpiadlYhQT/8wjY=; b=OtHdelU0NcflrU9WeXoqrZkcQc1Zk2sjyZqD5ilm4+xkyuSlg+sKypH7sx96NhfntYC6DQCo aNSRyEL2mgz6TuNb5puZeXdA08wplA0Asqv+RGuYH5y26y6NOevqSpQh; Authentication-Results: rtp-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sip@ietf.org, ietf-rtpsec@imc.org, "'Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > Yes, I agree that will give the best chance. Of course, it is > > always possible for an SBC (or firewall) to block such messages > > anyway (as has been discussed on the RTPSEC mailer). > > But that would at least mean that the SBC would have to look > inside the media stream to see that not everything in it is > (S)RTP, instead of just looking at the source and destination. Many SBCs, and some firewalls, include "RTP inspection". They drop packets that aren't RTP packets (such as ICE packets, DTLS-SRTP packets [draft-ietf-avt-dtls-srtp], and RTCP packets [draft-ietf-avt-rtp-and-rtcp-mux]. > It may happen, of course, but at least it's less likely. When it does > appear, it would require an SBC that can recognize the security > interchange for what it is and allow it to pass even though it isn't > media. I'm not sure if that can reasonably be done. Unless or until another solution to providing Identity is proposed, I think it'll be necessary. Identity is important so that the industry can build reliable and useful whitelists, blacklists, and reputation systems -- which are all necessary for call routing and mitigating spam. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 04 13:37:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I68my-0001ie-GD; Wed, 04 Jul 2007 13:37:16 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I68mx-0001bR-7Z for sip-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 13:37:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I68mw-0001ZF-IV for sip@ietf.org; Wed, 04 Jul 2007 13:37:14 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I68ml-0006MA-31 for sip@ietf.org; Wed, 04 Jul 2007 13:37:14 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 04 Jul 2007 13:37:02 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOd2i0ZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,498,1175486400"; d="scan'208"; a="64348082:sNHT28527920" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l64Hb2HY014873; Wed, 4 Jul 2007 13:37:02 -0400 Received: from dwingwxp ([10.32.240.194]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l64Hb1s0022037; Wed, 4 Jul 2007 17:37:01 GMT From: "Dan Wing" To: , Date: Wed, 4 Jul 2007 10:37:01 -0700 Message-ID: <1dce01c7be61$ee593f80$2014590a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace84/2A2DQkD36tTvuTB3F0bx7qeABfdg5Q DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1892; t=1183570622; x=1184434622; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20FW=3A=20IPR=20Statement=20RE=3A=20draft-wing-sip-identity-med ia-00.txt |Sender:=20 |To:=20,=20; bh=II9P+2UiTsK1r5WcY6LwR8OViwGoiq/Iu32A3EWKjWY=; b=l37pqhwGGMC0JkE3ddEQzFIWylc3E39SBLOl171X+wYjWvjM1P0w7r7yky8D1+oFaEwCsPN4 VQf8Lvk0if9CPDDHkQy7RAf0+rVJQ3pBI5cIHbbRW7GyDkcXP9XxQMC7; Authentication-Results: rtp-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [Sip] FW: IPR Statement RE: draft-wing-sip-identity-media-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Rachel Albright [mailto:ralbrigh@cisco.com] > Sent: Monday, July 02, 2007 1:03 PM > To: ietf-ipr@ietf.org > Cc: dwing@cisco.com > Subject: IPR Statement RE: draft-wing-sip-identity-media-00.txt > > Cisco is the owner of one or more pending unpublished patent > applications relating to the subject matter of "SIP Identity > using Media Path" . > > If technology in this document is included in a standard > adopted by IETF and any claims of any Cisco patents are > necessary for practicing the standard, any party will have > the right to use any such patent claims under reasonable, > non-discriminatory terms, with reciprocity, to implement and > fully comply with the standard. > > The reasonable non-discriminatory terms are: > > If this standard is adopted, Cisco will not assert any > patents owned or controlled by Cisco against any party for > making, using, selling, importing or offering for sale a > product that implements the standard, provided, however that > Cisco retains the right to assert its patents (including the > right to claim past royalties) against any party that asserts > a patent it owns or controls (either directly or indirectly) > against Cisco or any of Cisco's affiliates or successors in > title or against any products of Cisco or any products of any > of Cisco's affiliates either alone or in combination with > other products; and Cisco retains the right to assert its > patents against any product or portion thereof that is not > necessary for compliance with the standard. > > Royalty-bearing licenses will be available to anyone who > prefers that option. > > For information contact: > > Dan Lang > Director, Patents and Standards IPR > Cisco Systems > +1 408-526-6672 > standards-ipr@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 04 20:08:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Etn-0002A0-FG; Wed, 04 Jul 2007 20:08:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6Etm-00024O-CF for sip-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 20:08:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Etm-00023x-1K for sip@ietf.org; Wed, 04 Jul 2007 20:08:42 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6Etl-0003tU-Q8 for sip@ietf.org; Wed, 04 Jul 2007 20:08:41 -0400 Received: from [10.31.13.240] (stdhcp-240.va.neustar.com [10.31.13.240]) by ns3.neustar.com (Postfix) with ESMTP id ED62F175C1; Thu, 5 Jul 2007 00:08:10 +0000 (GMT) Message-ID: <468C366E.1000004@neustar.biz> Date: Wed, 04 Jul 2007 17:08:14 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: SIP IETF Subject: Re: [Sip] SIP Saml Review by Marcos Dytz and Sebastian Felis References: <0D22E3C1A7D7A843B12BF8C6F0A40758021496CA@MCHP7IDA.ww002.siemens.net> In-Reply-To: <0D22E3C1A7D7A843B12BF8C6F0A40758021496CA@MCHP7IDA.ww002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Marcos Dytz , Sebastian Felis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org [this is a response to ostensibly "substantive" comments wrt the sip-saml draft] Marcos Dytz said (via Hannes): > > 1) I believe that it would be good to leave a bit the emphasis on > authentication and providing different uses of the protocol Sebastian Felis said (via Hannes): > > In my point of view, the draft focuses only on trait-based > authorization and tries to deploy trait-based authorization using SAML. > It does not try to specify SAML over SIP, which I was expected. I'm assuming that both of the above are essentially saying: Perhaps the SIP SAML Profile should be generalized so it may be applied to other use cases in a SIP context. yes? This spec is presently designed for a fairly narrow use case, derived from RFC4474 "SIP Identity", and RFC4484 "Trait-Based Authorization Requirements for SIP". This use case is summarized in section 4 of draft-ietf-sip-saml-02 like so.. 4. Specification Scope The scope of this specification is: o Specify a SIP profile of SAML -- aka a "SIP SAML profile" -- such that a subject's profile attributes, and their domain's certificate, can be conveyed to a relying party using SAML. In doing so, satisfy the requirements outlined in [RFC4484], and compose with [RFC4474]. Which arguably leaves essential things unsaid, such as.. - "using SAML" here means "using a SAML assertion", not using one of the existing SAML profiles. This is a _new_, SIP-specific, SAML profile. - we're _not_ trying to concoct a fully-general "authorization mechanism" as imagined in RFC4484. Rather, we're simply trying to provide a means to convey (some undefined (sub)set of) a subject's profile attributes in the specific context of "authenticated identity management" as defined in RFC4474. As such, -sip-saml-02, presently meets (only) a subset of the requirements in RFC4484. For example, Requirement 3 of Section 5 of RFC4484 stipulates that an authorization assertion must be deliverable to a SIP UAC either by reference or by value, and -sip-saml-02 presently defines by-reference only. - enhancing -sip-saml-02, meaning the "SIP SAML Profile", to address additional use cases, and/or fully meet RFC4484's requirements, would add significant complexity to the specification. So, if the WG were to decide that -sip-saml-02 ought to, at this time, address additional use cases, and/or fully meet RFC4484's requirements, then we need to do yet more significant work on it. Otherwise, it seems fairly close to being complete. Thoughts? =JeffH ps: Just to clarify on this comment.. > It does not try to specify SAML over SIP, which I was expected. This seems to me to be indicative of a misunderstanding of SAML, because the phrase "SAML over SIP" doesn't make much actual sense. SAML per se is not "just a concrete protocol" that can be simply layered above another protocol, as HTTP is layered over TCP. Rather, it's a _framework_, that must be profiled for particular contexts of use, e.g. SIP Authenticated Identity Management. Sometimes folks, when thinking of SAML, are thinking of just one of the existing SAML profiles (e.g. Web SSO) and imagining that to be "SAML" or "the SAML protocol", and further imagine said "protocol" somehow being layered over some other protocol. This line of thinking wrt SAML isn't workable. Rather one needs to think in terms of making use of applicable pieces of SAML's "abstract classes" (in the "SAML core" specification) and freshly concretely applying them to the target use case and protocols, thus crafting a new SAML profile(s) (and binding(s)) -- which is exactly what -sip-saml-02 does. See also.. How to Study and Learn SAML http://identitymeme.org/how-to-study-and-learn-saml/ --- end _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 04 23:21:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6HuG-00073K-Gh; Wed, 04 Jul 2007 23:21:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6HuE-00073A-G2 for sip-confirm+ok@megatron.ietf.org; Wed, 04 Jul 2007 23:21:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6HuE-000732-6C for sip@ietf.org; Wed, 04 Jul 2007 23:21:22 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6HuA-0004fM-At for sip@ietf.org; Wed, 04 Jul 2007 23:21:22 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKO00HRXRXZLS@szxga01-in.huawei.com> for sip@ietf.org; Thu, 05 Jul 2007 11:20:24 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKO00L20RXYAH@szxga01-in.huawei.com> for sip@ietf.org; Thu, 05 Jul 2007 11:20:23 +0800 (CST) Received: from x18916 ([10.85.28.183]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKO00MM2RXVCU@szxml04-in.huawei.com> for sip@ietf.org; Thu, 05 Jul 2007 11:20:22 +0800 (CST) Date: Thu, 05 Jul 2007 11:20:19 +0800 From: Peili Xu In-reply-to: <0D5F89FAC29E2C41B98A6A762007F5D019F3A2@GBNTHT12009MSX.gb002.siemens.net> To: sip@ietf.org Message-id: <01a301c7beb3$6a6b9f90$b71c550a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Ace9nx9bqwi2FhK9SvaDkphpmcx2tQAiR+YgACFB1QA= X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Subject: [Sip] comments on draft-burger-sip-info-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Eric et al, I would appreciate this draft for detailed analysis for the flaws of using INFO. But since we are touching some proprietary implementations now, I don't think we can ever prohibit implementation of such usage even a new RFC is published. I guess people started to use INFO just because it was the only seemingly suitable mid-dialg SIP Request at that time. In fact, for proprietary implementation, people can still use other requests (introduced later e.g. MESSAGE) for the same purpose. Do we need to explicit prohibiting using of MESSAGE for such purpose, if similar implementations evolve in the future? People are using INFO to fulfill some real requirements, if we belive INFO is not the right way, I would propose we start to find and standardize more prefered solution instead of just prohibiting using of sth. We've already done sth for DTMF, right? Instead of updating RFC 2976 just for this purpose, maybe an informational document to give some guidline is enough. Regards. Peili > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 03 July 2007 19:15 > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-burger-sip-info-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Session Initiation Protocol (SIP) > INFO Method Context > Author(s) : E. Burger > Filename : draft-burger-sip-info-00.txt > Pages : 8 > Date : 2007-7-3 > > The purpose of the INFO request for the Session Initiation Protocol > (SIP), as described by RFC 2976, is to provide mid-session SIP User > Agent (UA)-to-SIP UA application data transport. In the years > since > the introduction of the INFO request, experience with the use of > the > INFO request indicates a number of problems. This document > explains > why there flaws of using INFO; and explains why it is > not possible to create a > framework to rescue INFO for general purpose use. Thus, this > document restricts the use of INFO to that described in RFC 3372 > (SIP-T). > are INFO-based, proprietary protocols in the wild; the > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-burger-sip-inf o-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then "get > draft-burger-sip-info-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-burger-sip-info-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 05:26:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Nad-0006KO-LC; Thu, 05 Jul 2007 05:25:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6Nac-0006KG-F7 for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 05:25:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Nac-0006K8-1O for sip@ietf.org; Thu, 05 Jul 2007 05:25:30 -0400 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6NaX-0000dK-FY for sip@ietf.org; Thu, 05 Jul 2007 05:25:30 -0400 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11.20060308/8.12.11) with ESMTP id l659PLOt006999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Jul 2007 11:25:21 +0200 Received: from eeek.ingate.se (localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.13.1/8.12.11) with ESMTP id l659PGWJ022515; Thu, 5 Jul 2007 11:25:16 +0200 Received: (from hasse@localhost) by eeek.ingate.se (8.13.1/8.13.1/Submit) id l659OwAw022509; Thu, 5 Jul 2007 11:24:58 +0200 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f Subject: Re: [Sip] WGLC for draft-ietf-sip-sips-05.txt From: Hans Persson To: audet@nortel.com In-Reply-To: <3D4B049E-23D0-459D-AD58-3D8AF2AB8BE7@softarmor.com> References: <3D4B049E-23D0-459D-AD58-3D8AF2AB8BE7@softarmor.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Ingate Systems Date: Thu, 05 Jul 2007 11:24:58 +0200 Message-Id: <1183627498.10598.23.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-35.0.4.el4) X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Thu, 05 Jul 2007 11:25:22 +0200 (CEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: IETF SIP , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org fre 2007-06-29 klockan 09:42 -0500 skrev Dean Willis: > I'm pleased to announce that the authors think that the SIPS draft is > ready for working group last call. This draft has had the privilege > of more review prior to WGLC than most of our other efforts, so > perhaps it won't be too controversial. > > Please make a final read through the draft and bring any comments > back to this list. I've gone through the diff between the current version and the last one I read, and on the whole it looks good to me. Some editorial nits are listed below. Section 3.1.1, para 1: > the Proxy is the TLS server side. This directionality implies that "proxy" > directions (e..g, an incoming call), the UA must keep the TLS "e.g." Section 3.1.1, para 2: > connection also solves the NAT and Firewall problem as it ensures "firewall" Section 3.1.2, para 1: > place, the UAC would therefore take on the role of the TLS Client and "client" > SIP, a UA or a Proxy act both as UAC and UAS depending on if they are "proxy" > is very convenient. This allows for TLS connections to be set-up or "set up" Section 3.1.2, para 3: > most residential SIP deployments for example. Mutual TLS can be used Insert comma after "deployments". > in those environments, but only if the connection is always stated by "stated" is a strange word here. Do you mean "started"? Section 3.1.2, last para: > For this reasons, mutual TLS is mostly used in server-to-server "this" -> "these" Section 3.1.3, para 4: > message (From, To, Request-URI, Contact header field, Route, etc.). Why "Contact header field" and not just "Contact" like for the others? Section 3.4, para 6: > allowed, which would preclude the use of NATs or Firewalls. "firewalls" Section 4.1, para 3: > SIP URI, it SHOULD respond with a 418 (SIPS Not Allowed). UAS that > do not support the SIPS URI scheme altogether "SHOULD reject the "UAS" would be more readable as "UASs". Change "altogether" to "at all". Section 4.1, last para: > response code 419 (SIPS Required) Missing period at end of sentence. Section 4.1.2, para 8: > reject requests using the SIP Scheme with 419 (SIPS Required). A UA "scheme" Section 4.2, para 5: > response, it MUST NOT recurse on it. The Proxy SHOULD forward the "proxy" Section 4.3, para 1: > Using a Redirect Server with TLS instead of using a Proxy has some "redirect server", "proxy" > established connection between the Proxy and the UAS (such as with "proxy" Section A.3: > (similar to what the transport=tls used to mean) has been suggested Remove "the". Hans -- Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210857 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 05:56:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6O4p-0000T1-Uc; Thu, 05 Jul 2007 05:56:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6O4o-0000Si-3N for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 05:56:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6O4n-0000Sa-Pa for sip@ietf.org; Thu, 05 Jul 2007 05:56:41 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6O4j-0004Ix-94 for sip@ietf.org; Thu, 05 Jul 2007 05:56:41 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l659uak0016742 for ; Thu, 5 Jul 2007 04:56:36 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 04:56:36 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 11:56:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-09.txt Date: Thu, 5 Jul 2007 11:56:27 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180013B65F3@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-outbound-09.txt Thread-Index: Ace49IPCnkOSkEzERXqjqcEU5eHCWAF9U8eQ References: From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 05 Jul 2007 09:56:33.0735 (UTC) FILETIME=[C4D64570:01C7BEEA] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) We now have a new version of outbound. There hasn't exactly been a flurry of comments since it was posted - does that mean it is now ready for WGLC. It has agenda time at the next IETF meeting, with a view to starting WGLC not long after that meeting. If you believe there are issues with the current version of this document, then you need to post them to the list, so that they can be either resolved there, or addressed in the meeting. I am posting the extract of the minutes of the last meeting so that you can remind yourself of the issues addressed in this new version.=20 Remember you can also gain access to diff versions here: http://tools.ietf.org/html/draft-ietf-sip-outbound-09 Regards Keith --------------------------------------- Topic: Outbound Led by Cullen Jennings Slides presented and included in proceedings Issue: Keepalive for TCP, CRLF vs. Inline STUN Extended discussion of this issue occurred, with each of several factions represented.=20 It was noted that the current document dropped out discussion of using tags in Path header to resolve configuration questions when Path is used. This is to be repaired in the next revision of the document. Following discussion the chairs polled on the question of whether the room felt that the issue needed to be resolved "today" and whether they would be willing to accept either approach based on a rough consensus. There was a clear consensus to do so. The chairs then polled the room on option 1 (STUN) vs option 2 (CRLF). An approximate 2/3 majority favored CRLF. The ADs decalred "rough consensus" in favor of CRLF. This consensus is to be re-reviewed on the mailing list. Issue: When to do Keepalives? Proposed that there is no longer a need for a keep-tcp parameter, and that the keepalive-time parameter will suffice. There was no objection noted to this proposal. Issue: Simplifying Instance-ID Types Proposed that SIPS-dependent option be dropped. No objections noted to proprosal. Issue: OPTIONS Probing for STUN support Extended discussion occurred. Proposed that discussion of using OPTIONS be deleted. No objections were noted (just slight whimpering from one of the chairs). Issue: Procedures for failures within 120s of REGISTER Proposed that discussion be deleted. A consensus in favor of the proposal was recorded. Noted that Outbound will be tested at the next SIPIT, and that WGLC for Outbound is imminent, so we should get any issues raised on the list ASAP. ---------------------------------------------------- > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Wednesday, June 27, 2007 8:50 PM > To: i-d-announce@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-09.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol=20 > Working Group of the IETF. >=20 > Title : Managing Client Initiated Connections=20 > in the Session Initiation Protocol (SIP) > Author(s) : C. Jennings, R. Mahy > Filename : draft-ietf-sip-outbound-09.txt > Pages : 42 > Date : 2007-6-27 > =09 > The Session Initiation Protocol (SIP) allows proxy servers to > initiate TCP connections and send asynchronous UDP=20 > datagrams to User > Agents in order to deliver requests. However, many practical > considerations, such as the existence of firewalls and Network > Address Translators (NATs), prevent servers from connecting to User > Agents in this way. This specification defines behaviors for User > Agents, registrars and proxy servers that allow requests to be > delivered on existing connections established by the User=20 > Agent. It > also defines keep alive behaviors needed to keep NAT bindings open > and specifies the usage of multiple connections. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-09.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then=20 > "get draft-ietf-sip-outbound-09.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-outbound-09.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 06:16:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ONw-0003No-MA; Thu, 05 Jul 2007 06:16:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6ONu-0003HX-Gv for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 06:16:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ONt-0003Ej-KU for sip@ietf.org; Thu, 05 Jul 2007 06:16:25 -0400 Received: from sip.tutpro.com ([192.98.100.10] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6ONp-0002tU-8O for sip@ietf.org; Thu, 05 Jul 2007 06:16:25 -0400 Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 45CFB1EC00E; Thu, 5 Jul 2007 13:16:20 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nKD97Fho9fc; Thu, 5 Jul 2007 13:16:17 +0300 (EEST) Received: from taimen (nuclease112.gprs.dnafinland.fi [62.78.108.112]) by tutpro.com (Postfix) with ESMTP; Thu, 5 Jul 2007 13:16:17 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id C52A4AC353; Thu, 5 Jul 2007 13:16:08 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18060.50408.676432.689965@tutpro.com> Date: Thu, 5 Jul 2007 13:16:08 +0300 To: "DRAGE, Keith \(Keith\)" Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-09.txt In-Reply-To: <5D1A7985295922448D5550C94DE29180013B65F3@DEEXC1U01.de.lucent.com> References: <5D1A7985295922448D5550C94DE29180013B65F3@DEEXC1U01.de.lucent.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org DRAGE, Keith \(Keith\) writes: > We now have a new version of outbound. There hasn't exactly been a > flurry of comments since it was posted - does that mean it is now ready > for WGLC. there was comment on it by someone from nokia, which made sense. i don't see a point of making a last call, before those issues have been dealt with. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 06:26:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6OXr-0005sO-40; Thu, 05 Jul 2007 06:26:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6OXq-0005sJ-AH for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 06:26:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6OXp-0005s8-WE for sip@ietf.org; Thu, 05 Jul 2007 06:26:42 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6OWw-0005Tj-LD for sip@ietf.org; Thu, 05 Jul 2007 06:26:41 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l65APjox007668; Thu, 5 Jul 2007 05:25:45 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 05:25:45 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 12:25:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-09.txt Date: Thu, 5 Jul 2007 12:25:46 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180013B6619@DEEXC1U01.de.lucent.com> In-Reply-To: <18060.50408.676432.689965@tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-outbound-09.txt Thread-Index: Ace+7ZX2d3Aw1Fr9QkqniW8SPf5FVAAAOQUg References: <5D1A7985295922448D5550C94DE29180013B65F3@DEEXC1U01.de.lucent.com> <18060.50408.676432.689965@tutpro.com> From: "DRAGE, Keith \(Keith\)" To: "Juha Heinanen" X-OriginalArrivalTime: 05 Jul 2007 10:25:44.0052 (UTC) FILETIME=[D81B7340:01C7BEEE] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Agreed. If there had been no comments I would have said that. What I am trying to do at the moment is persuade all you people out there to get stuff on the list (and start discussing it) before the IETF meeting so we can address those issues before or in the IETF meeting. If necessary, there will then be a revised draft, and we will WGLC that. Regards Keith =20 > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com]=20 > Sent: Thursday, July 05, 2007 11:16 AM > To: DRAGE, Keith (Keith) > Cc: sip@ietf.org > Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-outbound-09.txt=20 >=20 > DRAGE, Keith \(Keith\) writes: >=20 > > We now have a new version of outbound. There hasn't=20 > exactly been a > flurry of comments since it was posted -=20 > does that mean it is now ready > for WGLC. >=20 > there was comment on it by someone from nokia, which made=20 > sense. i don't see a point of making a last call, before=20 > those issues have been dealt with. >=20 > -- juha >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 08:02:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Q2B-0001Pc-VB; Thu, 05 Jul 2007 08:02:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6Q2A-0001Kj-1R for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 08:02:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Q29-0001KW-HB for sip@ietf.org; Thu, 05 Jul 2007 08:02:05 -0400 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Q11-0005bg-7n for sip@ietf.org; Thu, 05 Jul 2007 08:02:05 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id E5C06741E1; Thu, 5 Jul 2007 14:00:53 +0200 (CEST) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30910-01-66; Thu, 5 Jul 2007 14:00:53 +0200 (CEST) Received: from [193.11.30.13] (dhcp-wavelan-vo-13.publik.su.se [193.11.30.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id 591E07402D; Thu, 5 Jul 2007 14:00:51 +0200 (CEST) Message-ID: <468CDD19.1080602@it.su.se> Date: Thu, 05 Jul 2007 13:59:21 +0200 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-09.txt References: <5D1A7985295922448D5550C94DE29180013B65F3@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180013B65F3@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.056 tagged_above=-99 required=7 tests=[AWL=0.256, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org DRAGE, Keith (Keith) wrote: > (As WG chair) > > We now have a new version of outbound. There hasn't exactly been a > flurry of comments since it was posted - does that mean it is now ready > for WGLC. > > It has agenda time at the next IETF meeting, with a view to starting > WGLC not long after that meeting. If you believe there are issues with > the current version of this document, then you need to post them to the > list, so that they can be either resolved there, or addressed in the > meeting. I never received an explanation of what kind of attacks could be avoided by an edge proxy using an algorithm that generates flow tokens that "cannot be modified by attackers" (section 5.2 of outbound-09). This was the last e-mail in the thread the last time I brought it up on the list : http://www1.ietf.org/mail-archive/web/sip/current/msg18336.html. This leads me to think that either 1) the security threats haven't been addressed properly or 2) that there in fact was no security threat so the requirement for an edge proxy to generate flows that "cannot be modified by attackers" is just unnecessary, and should therefor be removed or 3) there really _is_ something that gets significantly better by this requirement, and it should simply be explained in the draft. /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 09:52:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Rkv-0008R1-6g; Thu, 05 Jul 2007 09:52:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6Rkt-0008Ko-CN for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 09:52:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Rkt-0008Kg-2W for sip@ietf.org; Thu, 05 Jul 2007 09:52:23 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Rkp-0007fn-Kz for sip@ietf.org; Thu, 05 Jul 2007 09:52:23 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l65DqCG7055704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Jul 2007 08:52:12 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <5D1A7985295922448D5550C94DE29180013B6164@DEEXC1U01.de.lucent.com> References: <167A3231-404F-41FB-B1E0-3881660359EF@cisco.com> <5D1A7985295922448D5550C94DE29180013B6164@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <76DF7CA2-28BB-4850-8CB0-197CDA60A090@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Security issues with ietf-sip-loop-fix Date: Thu, 5 Jul 2007 08:52:05 -0500 To: "DRAGE, Keith \(Keith\)" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: Cullen Jennings , SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org To put a fine point on this - the kind of accidental loop you are talking about here is one that does not have a fork in it. It is possible (but much more unlikely) to set up something similar to the attack in the draft by accident and a max-forwards as low as even 20 won't help much. RjS On Jul 4, 2007, at 6:07 AM, DRAGE, Keith ((Keith)) wrote: > (as individual) > > With regard to: > >> If we go forward with path 1, the value of this draft is >> probably not super high because Max-Forwards deals with the >> the accidental loops in most cases (but not all cases). If >> we go with path 2, the WG will need make sure it OK with the >> solution. I'm certainly open to other paths forward if >> someone has a good idea. > > There have been comments previously on this list that the default > value > of 70 for Max-Forwards is too high, and that a lower default value > should have been used. Therefore Max-Forwards will find the accidental > loops, but will take longer to do it, if the default values are used. > > Regards > > Keith > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Tuesday, July 03, 2007 3:36 AM >> To: SIP >> Subject: [Sip] Security issues with ietf-sip-loop-fix >> >> >> (this email with my AD hat on) >> >> The type of SIP loops described in ietf-sip-loop-fix can be >> roughly classified into two categories. Loops that had >> happened because an accidental registration that causes a >> loop, and loops that happened due to malicious intent. >> >> This draft attempted to deals with both. The abstract describes it as >> >> This document normatively updates RFC 3261, the Session Initiation >> Protocol (SIP), to address a security vulnerability >> identified in SIP >> proxy behavior. This vulnerability enables an attack against SIP >> networks where a small number of legitimate, even authorized, SIP >> requests can stimulate massive amounts of proxy-to-proxy traffic. >> >> During IETF LC, substantial comment came up about the >> security of this draft not really working in the case of >> malicious loops. A thread ensues that convinced many people >> on the thread that this draft did not really help with the >> malicious loops. (Not 100% sure here but I suspect that the >> authors and chairs were all convinced of this). I will let >> others explain the issues that came up as we decide what to do next. >> >> I think that some of issue was discussed while the working >> group was considering this draft - however, I suspect that >> many participants did not understand how easily this security >> would be defeated. I for one significantly underestimated the >> how easy it was for a malicious attacker to cause this >> problem. I apologize to the folks that attempted to explain >> it to me and I just failed to "get it". >> >> Anyways, we need to figure out what to do next with this >> draft. There are basically two paths forward that I see: >> >> 1) reduce the scope so that it only deals with accidental >> loops and provides no protection against malicious loops. I >> don't think this would change any of the mechanisms in the >> draft but it would probably change lots of the text around >> what security claims the draft made. >> >> 2) try to extend or replace the mechanism with one that does >> protect against malicious attack. A strong candidate to >> consider would be the work in draft-sparks-sipping-max-breadth. >> >> If we go forward with path 1, the value of this draft is >> probably not super high because Max-Forwards deals with the >> the accidental loops in most cases (but not all cases). If >> we go with path 2, the WG will need make sure it OK with the >> solution. I'm certainly open to other paths forward if >> someone has a good idea. >> >> What I would like to do now is start some discussion about >> what the working group would like to do with this draft. >> >> Thanks, Cullen >> >> >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 10:13:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6S55-0007AF-BE; Thu, 05 Jul 2007 10:13:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6IuV-0001u6-M8 for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 00:25:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6IuV-0001tx-Cj for sip@ietf.org; Thu, 05 Jul 2007 00:25:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ItV-00014b-UZ for sip@ietf.org; Thu, 05 Jul 2007 00:24:41 -0400 Received: from nz-out-0506.google.com ([64.233.162.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6ItQ-0003c6-0s for sip@ietf.org; Thu, 05 Jul 2007 00:24:41 -0400 Received: by nz-out-0506.google.com with SMTP id n1so1638623nzf for ; Wed, 04 Jul 2007 21:24:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=EZLIzWAQWrjmZzMwxSZvJS5chOLj/vFoMEmNHwI+OtsAqx9wBRu+/T/L5GWbkMOYO+BaaNxeBQxFIw6mEBtSLYbIaR+sTywrF21arlD8MsOzT+rupi6mrNGu2BVnJPnps/PsyzU7x81MDEvfW3vcFTv/EKS9Jq6bmlJ1O3vn99U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=DD2Fxc4Qtzx3ukwyPZmYIjkhXH0gR8cOOTu/LMeF0QTetZLC6qgMky84qHkCR3n210jt5TCQn+1x3RPxNfgopriYJ9zPmMECHTE8xHK9cE3HnuQUqxV9fxNLY1Zb3ov1RoyZ1fz9euozKbmKeM1+4Qr/M6neh/qKxzWrsKR1Hjw= Received: by 10.115.15.1 with SMTP id s1mr7835845wai.1183609474938; Wed, 04 Jul 2007 21:24:34 -0700 (PDT) Received: by 10.115.49.7 with HTTP; Wed, 4 Jul 2007 21:24:34 -0700 (PDT) Message-ID: <509b63310707042124s7a98bf64k35f4661205558280@mail.gmail.com> Date: Thu, 5 Jul 2007 01:24:34 -0300 From: "Marcos Dytz" To: "Jeff Hodges" Subject: Re: [Sip] SIP Saml Review by Marcos Dytz and Sebastian Felis In-Reply-To: <468C366E.1000004@neustar.biz> MIME-Version: 1.0 References: <0D22E3C1A7D7A843B12BF8C6F0A40758021496CA@MCHP7IDA.ww002.siemens.net> <468C366E.1000004@neustar.biz> X-Spam-Score: 1.1 (+) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 X-TMDA-Confirmed: Thu, 05 Jul 2007 00:25:43 -0400 X-Mailman-Approved-At: Thu, 05 Jul 2007 10:13:14 -0400 Cc: SIP IETF , Sebastian Felis , "Tschofenig, Hannes" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1341001703==" Errors-To: sip-bounces@ietf.org --===============1341001703== Content-Type: multipart/alternative; boundary="----=_Part_133727_4227886.1183609474905" ------=_Part_133727_4227886.1183609474905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, I agree on the limitations described below by Jeff. My concern was with the emphasis on authentication throughout the draft, but I had in mind that it was actually targeting that particular point (in the same way that sip-paying targets payment). Nevertheless, are there ideas to develop new drafts on further cases for SIP/SAML? In my personal opinion, the protocol offers many technical advantages (and flexibilities) that could be required for more general use cases. By adopting and developing new cases, the overall protocol would only be gaining a larger market share and could very well adopt some synergy among the different areas. As for Sebastian, I have the impression that he would like to see more integration and deployment details. I had problems to fulfill the gaps on integration while working on my thesis (e.g., enveloping SAML assertions in SIP message - usually workflows target the transaction state and avoid mentioning how to converge that with SIP - I did my implementation in the way I thought best, but every developer is free to choose different formats if specification does not define these little details). As for your final points, agree to limitations due to complexity and partial fulfilment of RFC4484. If further work is to be applied on the draft, I believe the best action would be to leave the draft as it is and start another work from scratch. Regards, Marcos PS: I am rusty on software architecture. Can we describe SAML as a framework? Isn't there a better terminology? On 7/4/07, Jeff Hodges wrote: > > [this is a response to ostensibly "substantive" comments wrt the sip-saml > draft] > > Marcos Dytz said (via Hannes): > > > > 1) I believe that it would be good to leave a bit the emphasis on > > authentication and providing different uses of the protocol > > Sebastian Felis said (via Hannes): > > > > In my point of view, the draft focuses only on trait-based > > authorization and tries to deploy trait-based authorization using SAML. > > It does not try to specify SAML over SIP, which I was expected. > > > I'm assuming that both of the above are essentially saying: > > Perhaps the SIP SAML Profile should be generalized so it may be applied > to other use cases in a SIP context. > > yes? > > > This spec is presently designed for a fairly narrow use case, derived from > RFC4474 "SIP Identity", and RFC4484 "Trait-Based Authorization > Requirements for > SIP". This use case is summarized in section 4 of draft-ietf-sip-saml-02 > like so.. > > 4. Specification Scope > > The scope of this specification is: > > o Specify a SIP profile of SAML -- aka a "SIP SAML profile" -- such > that a subject's profile attributes, and their domain's > certificate, can be conveyed to a relying party using SAML. In > doing so, satisfy the requirements outlined in [RFC4484], and > compose with [RFC4474]. > > > Which arguably leaves essential things unsaid, such as.. > > - "using SAML" here means "using a SAML assertion", not using one of the > existing SAML profiles. This is a _new_, SIP-specific, SAML profile. > > - we're _not_ trying to concoct a fully-general "authorization mechanism" > as imagined in RFC4484. Rather, we're simply trying to provide a means > to convey (some undefined (sub)set of) a subject's profile attributes > in the specific context of "authenticated identity management" as > defined > in RFC4474. As such, -sip-saml-02, presently meets (only) a subset of > the requirements in RFC4484. For example, Requirement 3 of Section 5 of > RFC4484 stipulates that an authorization assertion must be deliverable > to a SIP UAC either by reference or by value, and -sip-saml-02 > presently defines by-reference only. > > - enhancing -sip-saml-02, meaning the "SIP SAML Profile", to address > additional use cases, and/or fully meet RFC4484's requirements, > would add significant complexity to the specification. > > So, if the WG were to decide that -sip-saml-02 ought to, at this time, > address > additional use cases, and/or fully meet RFC4484's requirements, then we > need to > do yet more significant work on it. Otherwise, it seems fairly close to > being > complete. > > Thoughts? > > =JeffH > > ps: > > Just to clarify on this comment.. > > > It does not try to specify SAML over SIP, which I was expected. > > This seems to me to be indicative of a misunderstanding of SAML, because > the > phrase "SAML over SIP" doesn't make much actual sense. SAML per se is not > "just > a concrete protocol" that can be simply layered above another protocol, as > HTTP > is layered over TCP. Rather, it's a _framework_, that must be profiled for > particular contexts of use, e.g. SIP Authenticated Identity Management. > Sometimes folks, when thinking of SAML, are thinking of just one of the > existing SAML profiles (e.g. Web SSO) and imagining that to be "SAML" or > "the > SAML protocol", and further imagine said "protocol" somehow being layered > over > some other protocol. This line of thinking wrt SAML isn't workable. Rather > one > needs to think in terms of making use of applicable pieces of SAML's > "abstract > classes" (in the "SAML core" specification) and freshly concretely > applying > them to the target use case and protocols, thus crafting a new SAML > profile(s) > (and binding(s)) -- which is exactly what -sip-saml-02 does. > > See also.. > > How to Study and Learn SAML > http://identitymeme.org/how-to-study-and-learn-saml/ > > > --- > end > > > > > > ------=_Part_133727_4227886.1183609474905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello,
 
I agree on the limitations described below by Jeff. My concern was with the emphasis on authentication throughout the draft, but I had in mind that it was actually targeting that particular point (in the same way that sip-paying targets payment).
 
Nevertheless, are there ideas to develop new drafts on further cases for SIP/SAML? In my personal opinion, the protocol offers many technical advantages (and flexibilities) that could be required for more general use cases. By adopting and developing new cases, the overall protocol would only be gaining a larger market share and could very well adopt some synergy among the different areas.
 
As for Sebastian, I have the impression that he would like to see more integration and deployment details. I had problems to fulfill the gaps on integration while working on my thesis (e.g., enveloping SAML assertions in SIP message - usually workflows target the transaction state and avoid mentioning how to converge that with SIP - I did my implementation in the way I thought best, but every developer is free to choose different formats if specification does not define these little details).
 
As for your final points, agree to limitations due to complexity and partial fulfilment of RFC4484. If further work is to be applied on the draft, I believe the best action would be to leave the draft as it is and start another work from scratch.
 
Regards,
 
Marcos
 
PS: I am rusty on software architecture. Can we describe SAML as a framework? Isn't there a better terminology?
 
On 7/4/07, Jeff Hodges <Jeff.Hodges@neustar.biz> wrote:
[this is a response to ostensibly "substantive" comments wrt the sip-saml draft]

Marcos Dytz < marcos.dytz@gmail.com> said  (via Hannes):
>
> 1) I believe that it would be good to leave a bit the emphasis on
> authentication and providing different uses of the protocol

Sebastian Felis said (via Hannes):
>
> In my point of view, the draft focuses only on trait-based
> authorization and tries to deploy trait-based authorization using SAML.
> It does not try to specify SAML over SIP, which I was expected.


I'm assuming that both of the above are essentially saying:

  Perhaps the SIP SAML Profile should be generalized so it may be applied
  to other use cases in a SIP context.

yes?


This spec is presently designed for a fairly narrow use case, derived from
RFC4474 "SIP Identity", and RFC4484 "Trait-Based Authorization Requirements for
SIP". This use case is summarized in section 4 of draft-ietf-sip-saml-02 like so..

  4.  Specification Scope

     The scope of this specification is:

     o  Specify a SIP profile of SAML -- aka a "SIP SAML profile" -- such
        that a subject's profile attributes, and their domain's
        certificate, can be conveyed to a relying party using SAML.  In
        doing so, satisfy the requirements outlined in [RFC4484], and
        compose with [RFC4474].


Which arguably leaves essential things unsaid, such as..

- "using SAML" here means "using a SAML assertion", not using one of the
   existing SAML profiles. This is a _new_, SIP-specific, SAML profile.

- we're _not_ trying to concoct a fully-general "authorization mechanism"
   as imagined in RFC4484. Rather, we're simply trying to provide a means
   to convey (some undefined (sub)set of) a subject's profile attributes
   in the specific context of "authenticated identity management" as defined
   in RFC4474. As such, -sip-saml-02, presently meets (only) a subset of
   the requirements in RFC4484. For example, Requirement 3 of Section 5 of
   RFC4484 stipulates that an authorization assertion must be deliverable
   to a SIP UAC either by reference or by value, and -sip-saml-02
   presently defines by-reference only.

- enhancing -sip-saml-02, meaning the "SIP SAML Profile", to address
   additional use cases, and/or fully meet RFC4484's requirements,
   would add significant complexity to the specification.

So, if the WG were to decide that -sip-saml-02 ought to, at this time, address
additional use cases, and/or fully meet RFC4484's requirements, then we need to
do yet more significant work on it. Otherwise, it seems fairly close to being
complete.

Thoughts?

=JeffH

ps:

Just to clarify on this comment..

> It does not try to specify SAML over SIP, which I was expected.

This seems to me to be indicative of a misunderstanding of SAML, because the
phrase "SAML over SIP" doesn't make much actual sense. SAML per se is not "just
a concrete protocol" that can be simply layered above another protocol, as HTTP
is layered over TCP. Rather, it's a _framework_, that must be profiled for
particular contexts of use, e.g. SIP Authenticated Identity Management.
Sometimes folks, when thinking of SAML, are thinking of just one of the
existing SAML profiles (e.g. Web SSO) and imagining that to be "SAML" or "the
SAML protocol", and further imagine said "protocol" somehow being layered over
some other protocol. This line of thinking wrt SAML isn't workable. Rather one
needs to think in terms of making use of applicable pieces of SAML's "abstract
classes" (in the "SAML core" specification) and freshly concretely applying
them to the target use case and protocols, thus crafting a new SAML profile(s)
(and binding(s)) -- which is exactly what -sip-saml-02 does.

See also..

How to Study and Learn SAML
http://identitymeme.org/how-to-study-and-learn-saml/


---
end






------=_Part_133727_4227886.1183609474905-- --===============1341001703== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1341001703==-- From sip-bounces@ietf.org Thu Jul 05 11:48:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6TZ9-0003Me-Me; Thu, 05 Jul 2007 11:48:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6TZ7-0003LR-OW for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 11:48:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6TZ7-0003Kv-96 for sip@ietf.org; Thu, 05 Jul 2007 11:48:21 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6TYF-0005kr-Fp for sip@ietf.org; Thu, 05 Jul 2007 11:48:21 -0400 Received: from [10.0.0.170] (adsl-71-158-178-228.dsl.rcsntx.sbcglobal.net [71.158.178.228]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l65Fl9Si008420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Jul 2007 10:47:14 -0500 (CDT) (envelope-from bcampen@estacado.net) In-Reply-To: <468CDD19.1080602@it.su.se> References: <5D1A7985295922448D5550C94DE29180013B65F3@DEEXC1U01.de.lucent.com> <468CDD19.1080602@it.su.se> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <8B8F934A-51C9-487D-B104-2A368014AB95@estacado.net> From: Byron Campen Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-09.txt Date: Thu, 5 Jul 2007 10:47:06 -0500 To: Fredrik Thulin X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0725409107==" Errors-To: sip-bounces@ietf.org --===============0725409107== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-10--815200160; protocol="application/pkcs7-signature" --Apple-Mail-10--815200160 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I am in agreement here. There are plenty of ways to hijack a registration without forging a flow-token. We could just remove the entire Record-Route/Path stack (depending on whether we're hijacking a dialog, or a registration), and substitute one of our own, bypassing any logic at the proxies entirely. If the network is set up in such a way that doing so would prevent requests from being successfully forwarded, we could always remove the flow-token from the last hop, and insert a Record-Route/Path header field value that would cause stuff to be routed anywhere we please. I suppose if the edge-proxy _only_ accepts Route headers with flow tokens (ie, Route headers without will just cause the request to fail), and bypassing the edge-proxy is impossible (ie, the network, including endpoints, is configured to forward all traffic to the edge proxy regardless of what is in the Route headers), cryptographic protection of flow tokens would help. But, in the general case, it will not afford us any meaningful protection. We need to rely on something like TLS (which, conveniently enough, outbound makes it easy to do). Best regards, Byron Campen > DRAGE, Keith (Keith) wrote: >> (As WG chair) >> We now have a new version of outbound. There hasn't exactly been a >> flurry of comments since it was posted - does that mean it is now >> ready >> for WGLC. >> It has agenda time at the next IETF meeting, with a view to starting >> WGLC not long after that meeting. If you believe there are issues >> with >> the current version of this document, then you need to post them >> to the >> list, so that they can be either resolved there, or addressed in the >> meeting. > > I never received an explanation of what kind of attacks could be > avoided by an edge proxy using an algorithm that generates flow > tokens that "cannot be modified by attackers" (section 5.2 of > outbound-09). > > This was the last e-mail in the thread the last time I brought it > up on the list : > > http://www1.ietf.org/mail-archive/web/sip/current/msg18336.html. > > This leads me to think that either > > 1) the security threats haven't been addressed properly > > or > > 2) that there in fact was no security threat so the requirement > for an > edge proxy to generate flows that "cannot be modified by > attackers" > is just unnecessary, and should therefor be removed > or > > 3) there really _is_ something that gets significantly better by > this > requirement, and it should simply be explained in the draft. > > /Fredrik > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --Apple-Mail-10--815200160 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGKTCCAuIw ggJLoAMCAQICEAda7Ce+sudhzrOd9CS5wJQwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDkyNTE0NDUzNloXDTA3MDkyNTE0NDUz NlowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWxjwykU0M R1yTjA3db2wzExKsMhLa/mc2ekFkBP9BVXi4OHacKSZM3a9T0bWvPcw97ycBfDZX3q2prMRsPUep svJWA0wbiWyOtLzuQGWaQQ6rYbvYlRxil/teAJb1fAKdfFXIXXsiqcdHkhbFn/J7oSn1BCz6v9/v M1zgGNeMPIR34bo9A0hW+QZJxwkSg4KZHdaQ50WcKXtdHdBg46s+0bvDqNmmt7eP91UJk9aiyxyw ZdWVNxzF1oj+nfsnsaHv1py6l62Je82mHsvIZwdSAic1PtXVpU8QmkLJHPmkBEVtN/uHMQ95xgxi eFO5hbYuAT9f7V0ZGe7pUJBR3KwdAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGJjYW1wZW5AZXN0YWNh ZG8ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAeJC75lz4KrtNdPOovb3fkqzD i2HXuOtYHCTOPMc5xJGLdqSF5sc8bwd4mIfevi9Ji4Ccj85A6qINQM/v4OjAvxPkwRwXey/YN6kl 19Te3Eh/t9l4zo2wPdbHTipyc8YJ0GAtT4/fwWiboW3+aquk8DGc7ityr9cdAYY1jAud7d0wggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWls QHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB AMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO 3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gE f6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNy bDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYv wPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bG CE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEAda7Ce+sudhzrOd9CS5wJQwCQYFKw4D AhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNzA1 MTU0NzA2WjAjBgkqhkiG9w0BCQQxFgQUHmiRgdgHCQcMBIhHHFR3K8iP0ncwgYUGCSsGAQQBgjcQ BDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHWuwnvrLn Yc6znfQkucCUMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAhAHWuwnvrLnYc6znfQkucCUMA0GCSqGSIb3DQEBAQUABIIBALfPq0cY 87tdzO6p7iITccLANyUOZfrDyQKw+cvBU0cdzVHHuAWC+F5jJJOal1Iny0uTrOeglhqpp6zjGjfY 6NWXXOOLhX8saFmFQyRSakIl3gcy47DlLDHuw3iVC1OovrTlqw9Ndv9wOC0hALHh0qTTOzPAo4Qs bLdybyiDuuzAyLzHr1Hkt0CMwDGViOr9qvJYkkLaF0fMjM43EDmUbF7MP/CWUWbdkYO6pSlurdVk Za6eOdSWDh5UEqh5Zhcoj7LPwoPwbgP3RHBthWyN/mhrR1OlKHojTdP+Fl4qSFCAMrnaeDWUSTWJ WidcHjHbgVl+fIB0kDp0iPHI+c/6xf0AAAAAAAA= --Apple-Mail-10--815200160-- --===============0725409107== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0725409107==-- From sip-bounces@ietf.org Thu Jul 05 16:18:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Xmf-0007Qh-Nx; Thu, 05 Jul 2007 16:18:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6Xmd-0007J4-Of for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 16:18:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Xmc-0007G4-SH for sip@ietf.org; Thu, 05 Jul 2007 16:18:34 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6Xmc-0004To-KZ for sip@ietf.org; Thu, 05 Jul 2007 16:18:34 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Jul 2007 16:18:10 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABLvjEZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175486400"; d="scan'208"; a="64433523:sNHT31207064" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l65KIACt008716 for ; Thu, 5 Jul 2007 16:18:10 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l65KIA6a028234 for ; Thu, 5 Jul 2007 20:18:10 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 16:18:10 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 16:18:09 -0400 Message-ID: <468D5205.5040705@cisco.com> Date: Thu, 05 Jul 2007 16:18:13 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2007 20:18:09.0916 (UTC) FILETIME=[9B17DBC0:01C7BF41] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1769; t=1183666690; x=1184530690; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Open=20issue=20in=20the=20hitchhikers=20guide=20-=20seriously !=20Relation=20to=20essential=0A=20corrections |Sender:=20 |To:=20IETF=20SIP=20List=20; bh=gdzcTg/FtekQ2w23li29hFywtupxYnAk/07iSHVxrnk=; b=gEKCtg9SDLFz5w5XjhURRjIUeS2oyTWaIfyaGvfbL8CFVSUalMVTfbh0lq2cZG29922lBsuy Sfub/PHaHy4nUYL3RGUHFqJhgu0tCDkT/n5tNS7NkAYuBSDI5NMUdfnx; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Sip] Open issue in the hitchhikers guide - seriously! Relation to essential corrections X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I was working on my regular update to the sip hitchhikers guide: http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers-guide-02.txt and ran into an issue. We are now pursuing the SIP essential corrections process: http://www.ietf.org/internet-drafts/draft-drage-sip-essential-correction-01.txt which has begun to produce internet drafts, that are draft-ietf-sip-XXX, which will be tracked and produced by the working group. The question is, do these drafts get included into the hitchhikers guide or not. My view on this, is NO, they do not. The reason is that these drafts will never reach RFC, only the collected essential correction RFC. So, once that first RFC is produced, the hitchhikers guide would reference that, and that would encompass everything. So, in the interim, what I'd propose is that the running I-D version of hitchhikers guide have an "essential corrections" draft, which in fact references all of the I-Ds currently in line for essential correction. Unfortunately, its not clear which drafts those are. record-route-fix, yes. What about loop-fix? Is that going in? It would be convenient to have a way of clearly knowing what drafts are going to be for essential corrections. Is the rule: draft-ietf-sip-*-fix are drafts targeted for essential correction? If so, I think that should be clearly stated in the drage-essential-corrections draft. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 16:50:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6YH1-0008Ex-EU; Thu, 05 Jul 2007 16:49:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6YGz-0008Eh-Vv for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 16:49:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6YGz-0008EZ-7O for sip@ietf.org; Thu, 05 Jul 2007 16:49:57 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6YGv-0008OF-Mk for sip@ietf.org; Thu, 05 Jul 2007 16:49:57 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l65KnqZ5025852; Thu, 5 Jul 2007 13:49:52 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l65KnoLt016460; Thu, 5 Jul 2007 13:49:50 -0700 Received: from 172.24.29.29 ([172.24.29.29]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Thu, 5 Jul 2007 20:49:50 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 05 Jul 2007 16:49:48 -0400 Subject: Re: [Sip] RE: I-D ACTION:draft-burger-sip-info-00.txt From: Eric Burger To: "Elwell, John" Message-ID: Thread-Topic: [Sip] RE: I-D ACTION:draft-burger-sip-info-00.txt Thread-Index: Ace9nx9bqwi2FhK9SvaDkphpmcx2tQAiR+YgAEdx314= In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D019F3A2@GBNTHT12009MSX.gb002.siemens.net> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Good catch. I'll fix that if there is another draft. On 7/4/07 9:31 AM, "Elwell, John" wrote: > Eric, > > I would just like to correct a slight inaccuracy in this draft. RFC 3372 > does not specify the use of INFO for QSIG, but RFC 3204 (which is > referenced by RFC 3372) does define the MIME type for QSIG. The > transport of QSIG using the SIP INFO method is instead specified in > Standard ECMA-355 from Ecma-International. This is indeed a very similar > usage of INFO to that specified in RFC 3372 and should be allowed in the > proposed update to RFC 2976. > > John > >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: 03 July 2007 19:15 >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-burger-sip-info-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Session Initiation Protocol (SIP) >> INFO Method Context >> Author(s) : E. Burger >> Filename : draft-burger-sip-info-00.txt >> Pages : 8 >> Date : 2007-7-3 >> >> The purpose of the INFO request for the Session Initiation Protocol >> (SIP), as described by RFC 2976, is to provide mid-session SIP User >> Agent (UA)-to-SIP UA application data transport. In the >> years since >> the introduction of the INFO request, experience with the >> use of the >> INFO request indicates a number of problems. This >> document explains >> why there flaws of using INFO; and explains why it is >> not possible to create a >> framework to rescue INFO for general purpose use. Thus, this >> document restricts the use of INFO to that described in RFC 3372 >> (SIP-T). >> are INFO-based, proprietary protocols in the wild; the >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-burger-sip-info-00.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in >> the body of >> the message. >> You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-burger-sip-info-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-burger-sip-info-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant >> mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 16:56:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6YNJ-0002XS-OO; Thu, 05 Jul 2007 16:56:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6YNI-0002XL-8d for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 16:56:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6YNH-0002XD-V7 for sip@ietf.org; Thu, 05 Jul 2007 16:56:27 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6YND-0000fZ-92 for sip@ietf.org; Thu, 05 Jul 2007 16:56:27 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l65KuFGX000912; Thu, 5 Jul 2007 13:56:16 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l65KuEgS023804; Thu, 5 Jul 2007 13:56:14 -0700 Received: from 172.24.29.29 ([172.24.29.29]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Thu, 5 Jul 2007 20:56:14 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 05 Jul 2007 16:56:12 -0400 Subject: Re: [Sip] comments on draft-burger-sip-info-00.txt From: Eric Burger To: Peili Xu Message-ID: Thread-Topic: [Sip] comments on draft-burger-sip-info-00.txt Thread-Index: Ace9nx9bqwi2FhK9SvaDkphpmcx2tQAiR+YgACFB1QAAJmlCVA== In-Reply-To: <01a301c7beb3$6a6b9f90$b71c550a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I was trying to be subtle for those that knew, and not so subtle for those that do not folks. Believe me, the folks at my old (and, for that matter, new) employer would probably get upset if I said, "MSCML is not allowed to work." Likewise, I think folks at my old nemesis and my new found best friends would get upset if I said, "MSML is not allowed to work." However, I did NOT want to be seen as leaving the door open for more and more uses of INFO. What the draft sets out to do is say, "The one and only IETF sanctioned use of INFO is for the SIP-T case." I.e., there won't be any Standards Track INFO RFC's. However, to keep everyone with a legacy happy, Section 4 subtly states: In recognition of existing, proprietary use of INFO, proxies MUST NOT take any action other than that described by RFC 3261 and RFC 2976 with respect to handling INFO requests. This is the escape hatch: one can still use INFO, subject to all of the dangers enumerated in Section 2. Moreover, the draft explicitly states that SIP "network elements" must not "add value" by killing INFO messages they do not understand. On 7/4/07 11:20 PM, "Peili Xu" wrote: > > > Hi Eric et al, > > I would appreciate this draft for detailed analysis for > the flaws of using INFO. > > But since we are touching some proprietary > implementations now, > I don't think we can ever prohibit implementation of > such usage even a new RFC is published. > > I guess people started to use INFO just because it was > the only seemingly suitable mid-dialg > SIP Request at that time. In fact, for proprietary > implementation, people can still use other requests > (introduced later e.g. MESSAGE) for the same purpose. Do > we need to explicit prohibiting using of MESSAGE for > such purpose, if similar implementations evolve in the > future? > > People are using INFO to fulfill some real requirements, > if we belive INFO is not the right way, > I would propose we start to find and standardize more > prefered solution instead of just prohibiting using of > sth. > We've already done sth for DTMF, right? > > Instead of updating RFC 2976 just for this purpose, > maybe an informational document to give some guidline is > enough. > > > Regards. > Peili > > > >> -----Original Message----- >> From: Internet-Drafts@ietf.org > [mailto:Internet-Drafts@ietf.org] >> Sent: 03 July 2007 19:15 >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-burger-sip-info-00.txt >> >> A New Internet-Draft is available from the on-line > Internet-Drafts >> directories. >> >> >> Title : Session Initiation Protocol > (SIP) >> INFO Method Context >> Author(s) : E. Burger >> Filename : draft-burger-sip-info-00.txt >> Pages : 8 >> Date : 2007-7-3 >> >> The purpose of the INFO request for the Session > Initiation Protocol >> (SIP), as described by RFC 2976, is to provide > mid-session SIP User >> Agent (UA)-to-SIP UA application data transport. > In the years >> since >> the introduction of the INFO request, experience > with the use of >> the >> INFO request indicates a number of problems. This > document >> explains >> why there flaws of using INFO; and explains why > it is >> not possible to create a >> framework to rescue INFO for general purpose use. > Thus, this >> document restricts the use of INFO to that > described in RFC 3372 >> (SIP-T). >> are INFO-based, proprietary protocols in the wild; > the >> >> >> A URL for this Internet-Draft is: >> > http://www.ietf.org/internet-drafts/draft-burger-sip-inf > o-00.txt >> >> To remove yourself from the I-D Announcement list, > send a message to >> i-d-announce-request@ietf.org with the word > unsubscribe in the body of >> the message. >> You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. > Login with the >> username "anonymous" and a password of your e-mail > address. After >> logging in, type "cd internet-drafts" and then "get >> draft-burger-sip-info-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE > /internet-drafts/draft-burger-sip-info-00.txt". >> >> NOTE: The mail server at ietf.org can return the > document in >> MIME-encoded form by using the "mpack" utility. > To use this >> feature, insert the command "ENCODING mime" > before the "FILE" >> command. To decode the response(s), you will > need "munpack" or >> a MIME-compliant mail reader. Different > MIME-compliant mail readers >> exhibit different behavior, especially when > dealing with >> "multipart" MIME messages (i.e. documents which > have been split >> up into multiple messages), so check your local > documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant > mail reader >> implementation to automatically retrieve the ASCII > version of the >> Internet-Draft. >> > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol Use sip-implementors@cs.columbia.edu for > questions on current sip Use sipping@ietf.org for new > developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 17:00:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6YQd-0006hO-OT; Thu, 05 Jul 2007 16:59:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6YQb-0006eC-P5 for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 16:59:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6YQb-0006e4-BN for sip@ietf.org; Thu, 05 Jul 2007 16:59:53 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6YQa-00020x-Ay for sip@ietf.org; Thu, 05 Jul 2007 16:59:53 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A035C200CE; Thu, 5 Jul 2007 22:59:35 +0200 (CEST) X-AuditID: c1b4fb3e-b2038bb0000007e1-34-468d5bb7b17c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7020E200B5; Thu, 5 Jul 2007 22:59:35 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 22:59:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] UA Loose Routing Date: Thu, 5 Jul 2007 22:59:31 +0200 Message-ID: <7374777208BDC7449D5620EF9423256706F9BF74@esealmw113.eemea.ericsson.se> In-Reply-To: <468B0FE7.7040908@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] UA Loose Routing Thread-Index: Ace96Q/OV4zjIfjjSFeRgImCTVm8jgAm7BUg References: <466F5E26.2000709@cisco.com> <5D1A7985295922448D5550C94DE29180012C9836@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF9423256705397552@esealmw113.eemea.ericsson.se> <5D1A7985295922448D5550C94DE29180012C99F6@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF94232567054171DC@esealmw113.eemea.ericsson.se> <5D1A7985295922448D5550C94DE29180012C9A19@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF94232567054174B3@esealmw113.eemea.ericsson.se> <468B0FE7.7040908@cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 05 Jul 2007 20:59:35.0151 (UTC) FILETIME=[64689FF0:01C7BF47] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c853ec6e79db43c8dbe6774215da1042 Cc: IETF SIP List , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >My concern with P-Called-Party-ID is similar to my concern on=20 >History-Info. On History-Info, the draft states: >=20 > Firstly, it would cause the Request-URI to be relegated to nothing > more than an indicator of the next hop for the request, identical > exactly to the purpose of the Route header field. This results in > two things in the SIP specification which do exactly the same = thing. > Worse still, this is not just for some small feature of SIP (where > such duplication might not be a big deal), but rather, it would be = a > duplication of SIP's primary function - routing of a call towards = a > target. >=20 > This concern applies exactly to P-Called-Party-ID. Indeed,=20 > its even worse, since now we would have, in a request: >=20 > Request-URI > To > P-Called-Party-ID > History-Info > Route >=20 >and I challenge you to explain to implementors what the=20 >differences are.=20 >What would happen when they are inconsistent? > >My objective was to reduce this count. Indeed I was hopeful=20 >that UA-loose-route would allow us to deprecate=20 >P-Called-Party-ID, not the other way around. WIth=20 >UA-loose-route, we end up with: >=20 >Request-URI: identifies the target >Route: tells you how to get to the target >To: tells you the original target >History info: sequence of identities of targets If people can't explain to their implementors the meaning of different = SIP headers maybe THAT is something we should concentrate on, and if = needed write a draft about. >which is much cleaner. If we would re-do SIP I am sure lots of things could be done cleaner. P-Called-Party-ID does not change the current routing mechanism, and it = does not have the potential issue with proxies (and possible also SBCs) = that you have mentioned. And the proxy re-writing the R-URI can use the = mechanism no matter if the UA supports it or not.=20 (And, naturally the mechanism would of course be backward compatible = with entities and networks that already support P-Called-Party-ID.) >So, functionally, P-Called-Party-ID could work. Any number of things = *can* work. Yes, but P-Called-Party-ID is a standardized mechanism, made for this = purpose, which most likely does work. Regards, Christer > Christer Holmberg (JO/LMF) wrote: > > Hi, > >=20 > >> It is entirely appropriate at this stage to put forward=20 > alternatives.=20 > >> It is even more appropriate to do it now rather than in 6 months=20 > >> time. > >>=20 > >> However please do not expect the editor to elaborate them.=20 > If the WG=20 > >> has ideas, send text, either by individual author drafts,=20 > or by the=20 > >> mailing list. > >=20 > > Regarding the P-Called-Party header, there already IS an RFC=20 > > describing the header, and what it is used for. So, IF it already=20 > > solves the problem (RFC3455 does say that the header is=20 > used to convey=20 > > the AOR to the UAS), why would we need a separate draft? The only=20 > > additional information that a draft could contain are the use-cases=20 > > where receiving the AOR is important - but those use-cases are=20 > > solution independent and already described in Jonathan's draft. > >=20 > > Of course, if we want to define a NEW header, or a NEW URI=20 > parameter,=20 > > that may be done in a separate draft. > >=20 > > But, no matter how we do it, I think the author should at least=20 > > indicate whether he has already thought about the alternatives that=20 > > have been presented, and why he thinks that they don't work. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >>> -----Original Message----- From: Christer Holmberg (JO/LMF)=20 > >>> [mailto:christer.holmberg@ericsson.com] Sent: Thursday, June 14, > >>> 2007 10:51 AM To: DRAGE, Keith (Keith); Jonathan=20 > Rosenberg; IETF SIP=20 > >>> List Subject: RE: [Sip] UA Loose Routing > >>>=20 > >>>=20 > >>> Hi Keith, > >>>=20 > >>> The text you sent says: > >>>=20 > >>> "Consensus noted that we do need some sort of solution for > >> the general > >>> problem of delivery of URI parameters across contact-routing=20 > >>> operations." > >>>=20 > >>> I have no problems with that. > >>>=20 > >>> I also have no problem with using Jonathan's draft as base line, =20 > >>> because the draft discusses the problem in a good way. > >>>=20 > >>> But, still: as the text says, the agreement was to come up > >> with SOME > >>> SORT OF SOLUTION, which to me does not mean that we have=20 > agreed to=20 > >>> adopt the specific solution in Jonathan's draft. We=20 > should also be=20 > >>> "allowed" to discuss alternative solutions, whether they > >>>=20 > >> are based on > >>> P-Called-Party, some other header, some URI parameter, or > >> whatever... > >>> Maybe those alternative solutions do not work, and then=20 > we should =20 > >>> describe that (as Jonathan has done for the To header-=20 > and History=20 > >>> header alternatives). > >>>=20 > >>> Regards, > >>>=20 > >>> Christer > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>>> -----Original Message----- From: DRAGE, Keith (Keith)=20 > >>>> [mailto:drage@alcatel-lucent.com] Sent: 14. kes=E4kuuta 2007 = 12:40=20 > >>>> To: Christer Holmberg (JO/LMF); Jonathan Rosenberg; IETF=20 > SIP List=20 > >>>> Subject: RE: [Sip] UA Loose Routing > >>>>=20 > >>>> You appear to be questioning whether the solution was > >> adopted. The > >>>> minutes state: > >>>>=20 > >>>>=20 > >> ------------------------------------------------------------------- > >>=20 > >>>> Topic: GRUU and Supporting Drafts Led by Jonathan=20 > Rosenberg Slides=20 > >>>> included in proceedings Read: > >>>> draft-ietf-sip-gruu-11,draft-rosenberg-sip-ua-loose-route-00 > >>>>=20 > >>>> Change since last version reviewed. > >>>>=20 > >>>> Issue: GRUU subtype names. The room demonstrated a slight > >>> preference > >>>> for the names used in -11 over known alternatives, but > >> nobody seems > >>>> particularly enamored with these names and the floor > >>> remains open to > >>>> suggestions. > >>>>=20 > >>>> Discussion on ua-loose-route draft deferred to next session. > >>>>=20 > >>>>=20 > >>>> Session 2: Friday 0900-1130 Grand Ballroom C > >>>>=20 > >>>>=20 > >>>> Topic: UA-loose-route, continued from previous session. > >>>>=20 > >>>> Consensus noted that we do need some sort of solution for > >>> the general > >>>> problem of delivery of URI parameters across contact-routing=20 > >>>> operations. > >>>>=20 > >>>> Issue: Concerns raised about backward compatibility. Noted that =20 > >>>> compliant P-CSCF should be OK. Suggested that we have a > >>> design team > >>>> revisit call-flows and analyze for backward compatibility issues. > >>>>=20 > >>>> Issue: Does GRUU normatively depend on this work? Resolved:=20 > >>>> GRUU does not reference this document. However, some > >>> participants feel > >>>> it should, as the benefit of GRUU cannot be fully > >> recognized in the > >>>> absence of this specification. The chairs asked for a > >> hum, and the > >>>> consensus of the room is that GRUU and ua-loose-route=20 > can proceed=20 > >>>> independently. > >>>>=20 > >>>> Question: Adopt this draft as baseline text for a WG > >> effort, should > >>>> the ADs approve the milestone? Consensus to adopt noted=20 > by chairs.=20 > >>>> To-do: Chairs to work with AD to set new milestone. > >>>>=20 > >>=20 > --------------------------------------------------------------------- > >> - > >>=20 > >>>> The minutes quite clearly say "Adopt this draft as baseline > >>> text for a > >>>> WG effort" and given that the charter item now exists, then > >>> I believe > >>>> that we are entitled to call for the editor (Jonathan) to > >>> submit the > >>>> current text as draft-ietf-sip-ua-loose-route. > >>>>=20 > >>>> I agree the file name says loose-route, but I don'y think > >> we should > >>>> change that. After all, we lose that filename when it gets > >>> published > >>>> as an RFC anyway. > >>>>=20 > >>>> The charter item states > >>>>=20 > >>>> Dec 2007 Delivering request-URI and parameters to UAS via=20 > >>>> proxy to WGLC Feb 2008 Delivering request-URI and parameters > >>>> to UAS via proxy to IESG (PS) > >>>>=20 > >>>> I assume that you are OK with this. > >>>>=20 > >>>> What I would suggest is that you address specific=20 > comments to the=20 > >>>> title of the deliverable: > >>>>=20 > >>>> Applying Loose Routing to Session Initiation Protocol (SIP) User=20 > >>>> Agents (UA) > >>>>=20 > >>>> And to the abstract: > >>>>=20 > >>>> Abstract > >>>>=20 > >>>> A key part of the behavior of the Session Initiation > >>> Protocol (SIP) > >>>> is that SIP proxies rewrite the Request-URI as a request moves=20 > >>>> throughout the network. Over the years, experience has > >>> shown this > >>>> to be problematic. It makes it difficult to use Request URI for=20 > >>>> service invocation, complicates emergency services, makes it > >>> more complex > >>>> to support aliases, and so on. Architecturally, it=20 > confounds the=20 > >>>> concepts of address and route. This document proposes > >> to change > >>>> this through a new mechanism called UA loose routing. > >>>>=20 > >>>> As you think appropriate to your concerns. > >>>>=20 > >>>> Alternatively, if you (or indeed any other SIP WG member) > >> do have a > >>>> completely different solution, then there is still time > >> to post an > >>>> individual draft or post a skeleton of a mechanism to the list. > >>>>=20 > >>>>=20 > >>>> Regards > >>>>=20 > >>>> Keith > >>>>=20 > >>>>> -----Original Message----- From: Christer Holmberg (JO/LMF)=20 > >>>>> [mailto:christer.holmberg@ericsson.com] Sent:=20 > Wednesday, June 13,=20 > >>>>> 2007 8:52 PM To: DRAGE, Keith (Keith); Jonathan Rosenberg; IETF=20 > >>>>> SIP List Subject: RE: [Sip] UA Loose Routing > >>>>>=20 > >>>>>=20 > >>>>> Hi, > >>>>>=20 > >>>>> We can call it loose route if we want, but I think the > >>>> initial focus > >>>>> should be the problem we are going to solve (I don't think > >>>> we agreed > >>>>> on a specific solution at #67), and we should look into > >>> alternative > >>>>> solutions (the draft does that in some extent, but > >> other possible > >>>>> alternatives have also been mentioned). > >>>>>=20 > >>>>> Or, do you prefer to have separate drafts describing > >> alternative > >>>>> solutions for the problem? > >>>>>=20 > >>>>> Regards, > >>>>>=20 > >>>>> Christer > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>>> -----Original Message----- From: DRAGE, Keith (Keith)=20 > >>>>>> [mailto:drage@alcatel-lucent.com] Sent: 13. kes=E4kuuta 2007 > >>>>>> 22:25 To: Jonathan Rosenberg; IETF SIP List Subject: RE: > >>>>>> [Sip] UA Loose Routing > >>>>>>=20 > >>>>>> (As WG chair) > >>>>>>=20 > >>>>>> As well as agreeing to charter the item, we actually agreed > >>>>>>=20 > >>>>> at IETF#67 > >>>>>> that this draft was a suitable candidate to fulfil that > >>>>> charter item. > >>>>>> Therefore unless issues are raised with this, I would > >>> request the > >>>>>> editor (as Jonathan is editor) to submit the next > >>> version of this > >>>>>> document as draft-ietf-sip-ua-loose-route-00. > >>>>>>=20 > >>>>>> Regards > >>>>>>=20 > >>>>>> Keith > >>>>>>=20 > >>>>>>> -----Original Message----- From: Jonathan Rosenberg=20 > >>>>>>> [mailto:jdrosen@cisco.com] Sent: Wednesday, June 13, 2007 > >>>>>>> 4:02 AM To: IETF SIP List Subject: [Sip] UA Loose=20 > Routing Issue=20 > >>>>>>> #1: Backwards > >>>> compatibility > >>>>>>> I've recently revised my draft on UA loose routing. You can > >>>>>> pick it up > >>>>>>> here: > >>>>>>>=20 > >> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo > >>>>>>> se-route-01.txt > >>>>>>>=20 > >>>>>>> This draft is meant to fulfill one of our charter items:=20 > >>>>>>> Feb 2008 Delivering request-URI and=20 > parameters to UAS > >>>>>>> via proxy to IESG (PS) > >>>>>>>=20 > >>>>>>> As folks may recall, the GRUU spec used to have these > >>>>> things called > >>>>>>> grids, which allowed a UA to add its own parameters to the > >>>>>> GRUU before > >>>>>>> handing it out. Several GRUU revisions back, this function > >>>>>> got yanked > >>>>>>> because it was recognized that the problem was more general > >>>>>> than GRUU, > >>>>>>> and would be useful for AOR as well. > >>>>>>>=20 > >>>>>>> Two IETFs back I presented this draft briefly during a > >>>>> SIP session. > >>>>>>> There was a lot of interest and people liked it > >>>> architecturally, > >>>>>>> however there were two open issues that needed to get > >>>>>> resolved. This > >>>>>>> mail is meant to start discussion on one of them - > >> backwards > >>>>>>> compatibility. > >>>>>>>=20 > >>>>>>> THe mechanism basically changes the way proxies handle > >>>> requests. > >>>>>>> Instead of rewriting the request URI for out-of-dialog > >>>> requests, > >>>>>>> they'll push a route header and leave the r-uri alone. > >>>>>>> This > >>>>>> allows the > >>>>>>> original R-URI and any parameters it contains to get > >>>>>> delivered to the > >>>>>>> UAS. > >>>>>>>=20 > >>>>>>> So, the main issue is, what kinds of backwards > >>>>>> compatibility problems > >>>>>>> will this cause. The draft provides a basic mechanism > >>>>> whereby a UA > >>>>>>> includes an option tag in the REGISTER, and the registrar > >>>>>>>=20 > >>>>> indicates > >>>>>>> that it is using this mechanism or not. So we can > >>>> negotiate this > >>>>>>> between a UA and registrar easily. Now, the problem is with=20 > >>>>>>> intermediate proxies. If there is an edge proxy between the > >>>>>> UA and its > >>>>>>> registrar, it will now see requests targeted to the UA, > >>>>>> which contain > >>>>>>> a Route header beyond itself, even though it thinks its the > >>>>>> edge proxy > >>>>>>> and the last point of contact before the UA. Technically, > >>>>>>>=20 > >>>>>> if this edge > >>>>>>> proxy is compliant to rfc3261 it would work. However, the > >>>>>>>=20 > >>>>>> question is > >>>>>>> whether proxies in the wild would properly work in > >> this case. > >>>>>>> If folks can comment based on their own products, or their=20 > >>>>>>> experiences, on whether they think this would work, or > >>>>>> concerns they > >>>>>>> have, that would be great. THere are solutions that would > >>>>>>>=20 > >>>>>> allow us to > >>>>>>> disable the mechanism when intermediate proxies don't > >>>>>> support it, but > >>>>>>> they are more complex and I'd rather avoid it. > >>>>>>>=20 > >>>>>>> THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. > >>>>>>> 600 > >>> Lanidex Plaza > >>>>>>> Cisco Fellow > >> Parsippany, NJ > >>>>>>> 07054-2711 Cisco Systems jdrosen@cisco.com > >>>>>>> FAX: > >>>>> (973) 952-5050 > >>>>>>> http://www.jdrosen.net PHONE: > >>>>> (973) 952-5000 > >>>>>>> http://www.cisco.com > >>>>>>>=20 > >>>>>>>=20 > >>>>>>> _______________________________________________ Sip=20 > mailing list =20 > >>>>>>> https://www1.ietf.org/mailman/listinfo/sip > >>>>>>> This list is for NEW development of the core SIP > >> Protocol Use > >>>>>>> sip-implementors@cs.columbia.edu for questions on > >>>> current sip Use > >>>>>>> sipping@ietf.org for new developments on the > >>> application of sip > >>>>>>=20 > >>>>>> _______________________________________________ Sip=20 > mailing list =20 > >>>>>> https://www1.ietf.org/mailman/listinfo/sip This list=20 > is for NEW=20 > >>>>>> development of the core SIP Protocol Use=20 > >>>>>> sip-implementors@cs.columbia.edu for questions on > >>> current sip Use > >>>>>> sipping@ietf.org for new developments on the > >> application of sip > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 17:15:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Yg2-0005J4-3e; Thu, 05 Jul 2007 17:15:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6Yfn-0004ts-1r for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 17:15:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Yfl-0004rh-4V; Thu, 05 Jul 2007 17:15:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6Yfk-0003pF-Ry; Thu, 05 Jul 2007 17:15:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 877BC175F1; Thu, 5 Jul 2007 21:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I6YfG-0004NI-1l; Thu, 05 Jul 2007 17:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 05 Jul 2007 17:15:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-consent-framework-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-sip-consent-framework-02.txt Pages : 29 Date : 2007-7-5 The Session Initiation Protocol (SIP) supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including amplification, and DoS (Denial of Service) attacks. This document identifies a framework for consent- based communications in SIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-consent-framework-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-consent-framework-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-consent-framework-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-5165632.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-consent-framework-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-consent-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-5165632.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Thu Jul 05 17:45:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Z8e-0006WM-Ai; Thu, 05 Jul 2007 17:45:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6Z8d-0006WA-5O for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 17:45:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Z8c-0006W0-Qe for sip@ietf.org; Thu, 05 Jul 2007 17:45:22 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Z8Y-0001Ix-Ep for sip@ietf.org; Thu, 05 Jul 2007 17:45:22 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l65LjF9S026636; Thu, 5 Jul 2007 15:45:15 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Thu, 5 Jul 2007 15:45:15 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Certificate authentication in SIP Date: Thu, 5 Jul 2007 15:45:14 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C62E9C30@srvxchg3.cablelabs.com> In-Reply-To: <468B0889.8010005@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Certificate authentication in SIP Thread-Index: Ace95KOqep3EXRZJTEiCwVTCpCAN9ABaKY0g References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com><46819819.5080107@cisco.com> <4681DA3C.8090607@softarmor.com> <4682CBF1.9000401@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C62E9B4D@srvxchg3.cablelabs.com> <468B0889.8010005@cisco.com> From: "Steve Dotson" To: "Jonathan Rosenberg" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: IETF SIP List , "DRAGE, Keith \(Keith\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Maybe this is na=EFve, but doesn't this alter the operator trust model?=20 I always envisioned P-A-ID (as an example) as a way for a home network = to tell a 3rd party service "trust this one, they are authenticated", as = long as the home network and the service had a relationship. Having an = edge proxy in a visited domain telling the home network "trust this one" = seems to turn things around. Steve. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: Tuesday, July 03, 2007 8:40 PM To: Steve Dotson Cc: Dean Willis; IETF SIP List; DRAGE,Keith (Keith) Subject: Re: [Sip] Certificate authentication in SIP Steve Dotson wrote: > Hi Jonathan, >=20 > The use case we are looking at is where the registrar is separate from = > the edge proxy. Sure. I think that is a valid case. > While the edge proxy could validate the UA has access to a cert issued = > by a trusted root, it doesn't necessarily mean the UA has a valid=20 > subscription to network services. No. But, such a proxy could assert the identity it verified. > The edge proxy may/would not > have access to this type of registration data, thus the need to=20 > authenticate from UA to registrar. You lost me here. With mutual TLS, the client can authenticate itself to = the edge proxy. The edge proxy can assert the authenticated identity = towards the registrar, ala P-A-ID or even better, SIP Identity. THe = registrar then authorizes access, and rejects the request if the user is = not authorized. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 17:58:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ZKr-00049z-U5; Thu, 05 Jul 2007 17:58:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6ZKr-00049o-8L for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 17:58:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ZKq-00049g-Ux for sip@ietf.org; Thu, 05 Jul 2007 17:58:00 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6ZKm-0002xK-Jj for sip@ietf.org; Thu, 05 Jul 2007 17:58:00 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Jul 2007 17:57:56 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAAoGjUZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175486400"; d="scan'208"; a="64443490:sNHT30938132" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l65LvuV8019944; Thu, 5 Jul 2007 17:57:56 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l65Lvq6a026692; Thu, 5 Jul 2007 21:57:52 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); Thu, 5 Jul 2007 17:57:52 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 17:57:51 -0400 Message-ID: <468D6963.4050104@cisco.com> Date: Thu, 05 Jul 2007 17:57:55 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Certificate authentication in SIP References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com> <46819819.5080107@cisco.com> <4681DA3C.8090607@softarmor.com> <4682CBF1.9000401@cisco.com> <80A444DE-0EFE-4AD9-A340-DB1AD43DE734@softarmor.com> <468B0812.2090003@cisco.com> <791E1028-5F3E-438F-9FCE-28FC97B3A188@softarmor.com> In-Reply-To: <791E1028-5F3E-438F-9FCE-28FC97B3A188@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2007 21:57:51.0755 (UTC) FILETIME=[888C0DB0:01C7BF4F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2612; t=1183672676; x=1184536676; c=relaxed/simple; s=rtpdkim2001; 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[Sip]=20Certificate=20authentication=20in=20SIP |Sender:=20 |To:=20Dean=20Willis=20; bh=uehjUuQlEO80BF09HL/DlxJQqYtx/rqM5fHVN7c+RzY=; b=rJh9sVNTsBrc77L8MTfKg7XyB9HbSr28V0OOui4d236r+VhNOaQh5sDlxXzq8uTbBrCPk1bj KMa9uwfmb/2HqxM6JHUikpKVpzQxZDU1WFVfLAYAxHH35QmZTDNSVuoM; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: IETF SIP List , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Dean Willis wrote: > > On Jul 3, 2007, at 9:38 PM, Jonathan Rosenberg wrote: > >> inline. >> >> Dean Willis wrote: >> >>>> So what? I think thats what ought to happen. I'd like to see some >>>> specific use cases where this can't work with the edge proxy >>>> performing the authentication. Keep in mind, we are talking about >>>> *certificate* authentication; that doesn't (by definition) required >>>> any kind of pre-arranged secret - only a common root CA. >>> My edge proxy might be provided by MCI, but I might be using a chat >>> service from another provider overseas. This other provider might be >>> willing to trust the certificate for authentication (given that I >>> have a signed cert from MCI, who in turn has a signed CA cert from a >>> recognized op-level CA). However, the chat provider might not be >>> willing to just accept P-Asserted-Identity from MCI as an >>> authentication mechanism, since said provider does not have a trusted >>> peering arrangement with MCI and therefore ANYBODY could spoof my >>> P-Asserted-Identity. >> >> In a case where your chat provider has no relationship whatsoever with >> this edge proxy, for what purpose would you be connecting to it in the >> first place? You should connect directly to your chat provider >> offering the service. Then, if you have a cert - great - authenticate >> to it using mutual TLS. >> > > Well, I might be doing "outbound" with my edge proxy in order to get > some help from it for relaying messaging back through my NAT. Why can't you do that with the edge proxy in your home providers network? > Or it > might be a QoS-controlling proxy ala PacketCable. Or a > firewall-control-proxy . . . Ah, well QoS control is much better handled through policy server peering than SIP connectivity. And it works for non-SIP things. Why is it that SIP is the vehicle for getting QoS in a visited network? Is this problem not more generic? > > The chat provider might not just be on the other side of my edge proxy, > but on the other side of my home serving proxy too. And the certificate > auth stuff would appear to be able to traverse that proxy as well. I don't follow the picture you have in mind. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 18:03:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ZQY-0005cG-07; Thu, 05 Jul 2007 18:03:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6ZQV-0005TL-Kk for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 18:03:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ZQV-0005TD-2Y for sip@ietf.org; Thu, 05 Jul 2007 18:03:51 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6ZQR-0003VR-Ov for sip@ietf.org; Thu, 05 Jul 2007 18:03:51 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Jul 2007 18:03:47 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAAoGjUZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175486400"; d="scan'208"; a="64444275:sNHT29773468" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l65M3ll4022254; Thu, 5 Jul 2007 18:03:47 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l65M3l6a028212; Thu, 5 Jul 2007 22:03:47 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); Thu, 5 Jul 2007 18:03:47 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 18:03:46 -0400 Message-ID: <468D6AC6.80402@cisco.com> Date: Thu, 05 Jul 2007 18:03:50 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Steve Dotson Subject: Re: [Sip] Certificate authentication in SIP References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com><46819819.5080107@cisco.com> <4681DA3C.8090607@softarmor.com> <4682CBF1.9000401@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C62E9B4D@srvxchg3.cablelabs.com> <468B0889.8010005@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C62E9C30@srvxchg3.cablelabs.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C62E9C30@srvxchg3.cablelabs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 05 Jul 2007 22:03:47.0061 (UTC) FILETIME=[5C537250:01C7BF50] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2021; t=1183673027; x=1184537027; c=relaxed/simple; s=rtpdkim2001; 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[Sip]=20Certificate=20authentication=20in=20SIP |Sender:=20 |To:=20Steve=20Dotson=20; bh=L8yWe/CwJbtFawjiU8IoVKw0gOi9jk9YjGQ8z3681Ys=; b=YeVaofOGnvxTLK2zz/b6gL+i7/GeuvGhKxALZLBwIVzE0LcL8WURfe3J37/ERPHqkuwAE8Sk 95Cil2MaDKtkjmuMup09D5JMRj1mIpIXVvAMLnnDgaOFejwVpvQKhFI7; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: IETF SIP List , "DRAGE, Keith \(Keith\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Steve Dotson wrote: > Maybe this is naïve, but doesn't this alter the operator trust model? > > > I always envisioned P-A-ID (as an example) as a way for a home > network to tell a 3rd party service "trust this one, they are > authenticated", as long as the home network and the service had a > relationship. Having an edge proxy in a visited domain telling the > home network "trust this one" seems to turn things around. P-A-ID asserts identity between providers with trust, yes that is true. SIP Identity works with lesser degrees of trust, but if you don't trust the signing domain, of course it doesn't work. However, my point is, one of the two following scenarios always apply: 1. the edge proxy is trusted by the home proxy, in which case you can use mutual TLS to authenticate the client to the edge proxy, and then P-A-ID or SIP Identity from edge proxy to home proxy, *OR* 2. there is no trust at all between visited and home networks. In this case, you shouldn't be connectign to a visited proxy in the first place. COnnect to the home proxy in your home network. Then, case 1 applies again. In other words, the entire motivation behind this draft is based on an assumption that a client needs to connect to its actual proxy through an intermediate proxy that no one trusts. SO many things get broken in that model. So, don't do it! This idea of a visited proxy with whom I have no relationship, is totally broken. ALl of the reasons people list for wanting them, we have far better solutions for (NAT traversal, firewall traversal, QoS). I'll note further that QoS can never work in a model without trust. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 18:08:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ZVP-0003dH-8T; Thu, 05 Jul 2007 18:08:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6ZVN-0003d8-Ep for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 18:08:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ZVN-0003d0-2p for sip@ietf.org; Thu, 05 Jul 2007 18:08:53 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6ZVM-00041j-Pb for sip@ietf.org; Thu, 05 Jul 2007 18:08:52 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 05 Jul 2007 18:08:52 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAC8IjUZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175486400"; d="scan'208"; a="125320981:sNHT36599480" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l65M8qh8010340; Thu, 5 Jul 2007 18:08:52 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l65M8o6a029386; Thu, 5 Jul 2007 22:08:50 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 18:08:50 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 18:08:49 -0400 Message-ID: <468D6BF5.4090801@cisco.com> Date: Thu, 05 Jul 2007 18:08:53 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] UA Loose Routing References: <466F5E26.2000709@cisco.com> <5D1A7985295922448D5550C94DE29180012C9836@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF9423256705397552@esealmw113.eemea.ericsson.se> <5D1A7985295922448D5550C94DE29180012C99F6@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF94232567054171DC@esealmw113.eemea.ericsson.se> <5D1A7985295922448D5550C94DE29180012C9A19@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF94232567054174B3@esealmw113.eemea.ericsson.se> <468B0FE7.7040908@cisco.com> <7374777208BDC7449D5620EF9423256706F9BF74@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256706F9BF74@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2007 22:08:49.0717 (UTC) FILETIME=[10B91650:01C7BF51] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3316; t=1183673332; x=1184537332; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20UA=20Loose=20Routing |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=648IOyS0EWxhTZJZmFpncU0FFYUna5/GEm8a7PUqSR4=; b=VqEUlWpQUoD6S9aavJ8JP68XtNVwMLLfZrhLsfAAVJJxvZEsM71BQ+wvTI4fyE3TssyOzPeg thIoGC22nZYzmQVtawt1+2GUYHFOIsszL/RU+f443xh94fZulyG/MOca; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: IETF SIP List , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Christer Holmberg (JO/LMF) wrote: > Hi, > >> My concern with P-Called-Party-ID is similar to my concern on >> History-Info. On History-Info, the draft states: >> >> Firstly, it would cause the Request-URI to be relegated to nothing >> more than an indicator of the next hop for the request, identical >> exactly to the purpose of the Route header field. This results in >> two things in the SIP specification which do exactly the same >> thing. Worse still, this is not just for some small feature of SIP >> (where such duplication might not be a big deal), but rather, it >> would be a duplication of SIP's primary function - routing of a >> call towards a target. >> >> This concern applies exactly to P-Called-Party-ID. Indeed, its even >> worse, since now we would have, in a request: >> >> Request-URI To P-Called-Party-ID History-Info Route >> >> and I challenge you to explain to implementors what the differences >> are. What would happen when they are inconsistent? >> >> My objective was to reduce this count. Indeed I was hopeful that >> UA-loose-route would allow us to deprecate P-Called-Party-ID, not >> the other way around. WIth UA-loose-route, we end up with: >> >> Request-URI: identifies the target Route: tells you how to get to >> the target To: tells you the original target History info: sequence >> of identities of targets > > If people can't explain to their implementors the meaning of > different SIP headers maybe THAT is something we should concentrate > on, and if needed write a draft about. Its not a question of documentation. Its that we would in fact have multiple headers which mean the same thing. > >> which is much cleaner. > > If we would re-do SIP I am sure lots of things could be done cleaner. > > > P-Called-Party-ID does not change the current routing mechanism, and > it does not have the potential issue with proxies (and possible also > SBCs) that you have mentioned. And the proxy re-writing the R-URI can > use the mechanism no matter if the UA supports it or not. Sure, but its useless unless the UA supports it. So my point is, in all cases, we are talking about changes to UA and to proxy to do something useful here. The UA-loose-route mechanism doesn't require any changes beyond those two. I do agree, that UA-loose-route requires a discovery mechanism, so the proxy knows whether to do this or not. But that is not difficult. > > (And, naturally the mechanism would of course be backward compatible > with entities and networks that already support P-Called-Party-ID.) > >> So, functionally, P-Called-Party-ID could work. Any number of >> things *can* work. > > Yes, but P-Called-Party-ID is a standardized mechanism, made for this > purpose, which most likely does work. We have lots of P-headers that already exist. That doesn't mean we shouldn't bother to provide an architecturally better solution. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 18:35:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Zuu-0000gY-0U; Thu, 05 Jul 2007 18:35:16 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6Zus-0000gQ-NA for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 18:35:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Zus-0000gH-DV for sip@ietf.org; Thu, 05 Jul 2007 18:35:14 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Zuo-0003Mc-1E for sip@ietf.org; Thu, 05 Jul 2007 18:35:14 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 05 Jul 2007 18:35:10 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAC8PjUZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175486400"; d="scan'208"; a="125322414:sNHT30581948" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l65MZ9aS017691; Thu, 5 Jul 2007 18:35:09 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l65MZ9s0029038; Thu, 5 Jul 2007 22:35:09 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 18:35:09 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.78]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 18:35:09 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 05 Jul 2007 17:35:14 -0500 To: "Francois Audet" , From: "James M. Polk" Subject: RE: [Sip] New draft modifying RFC 4412 for Responses In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10E7A7F6@zrc2hxm0.corp.nor tel.com> References: <1ECE0EB50388174790F9694F77522CCF10E7A7F6@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 05 Jul 2007 22:35:09.0375 (UTC) FILETIME=[BE45C4F0:01C7BF54] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3424; t=1183674909; x=1184538909; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Sip]=20New=20draft=20modifying=20RFC=204412=20for=20 Responses |Sender:=20 |To:=20=22Francois=20Audet=22=20,=20; bh=YufNk69wRdo+dA9EaJI9ykFLls2jDcpApG/8LFvi62E=; b=TQwe/4CbkkLa2TBpU1q3XCaRvnY0gt9+2hCHPqXTf+GAkw+A1ELvQkWHOz0mPMRWzMlAxVQa gfGsVaKdD7sa5NoZZr6ltGq2zMCThvNdxUYp4GXwxvP7nUTX12WZBdEW; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois in-line At 11:29 AM 6/18/2007, Francois Audet wrote: >Hi James, > >It might be useful to have some wording on the limitations of using >a response to carry a Resource-Priority header in a response. Do you have any text (or direction) to offer that you would want to see in this ID? >Specifically, a UAS can not use a response to carry the >Resource-Priority in cases where the Resource-Priority "absolutely >has" to be delivered to the UAC. It is therefore only useable for >cases where a forking proxy may discard the response (i.e., forward >another instead) without breaking anything. I have to admit, I do not understand this use-case (as it is written), since I'm not sure what you are referring to when you say "..."absolutely has" to be delivered to the UAC". Right now, RPH isn't in any response, so when did it become a situation of "..."absolutely has" to be delivered...". Remind me what HEFP is again... >In other words,you need to think about HEFP before using this draft. > >In some scenarios, this is probably the desired behavior. > >In other scenarios, it may not acceptable. So instead, for those scenarios, >the terminating side would have to send a new request with a >Resource-Priority >instead of using a response. > > > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Saturday, June 16, 2007 14:14 > > To: sip@ietf.org > > Subject: [Sip] New draft modifying RFC 4412 for Responses > > > > SIP WG > > > > Here is a new ID I've written because of implementation > > considerations to allow a SIP Resource-Priority header (RPH) > > in responses, which RFC 4412 currently disallows, assuming > > only that stateful devices will use RPH. There have been > > many requests to have this "only stateful devices" > > restriction relaxed, in certain scenarios. This ID does > > this, and proposes how IANA is changed accordingly wrt RPH. > > This ID does nothing else. > > > > Comments are appreciated. > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > > >directories. > > > > > > Title : Allowing SIP Resource Priority Header in > > > SIP Responses > > > Author(s) : J. Polk > > > Filename : draft-polk-sip-rph-in-responses-00.txt > > > Pages : 6 > > > Date : 2007-6-15 > > > > > > The Session Initiation Protocol (SIP) Resource Priority Header > > > (RPH), in its current form, is ignored in SIP responses. > > This was a > > > design choice during RFC 4412's development. This is now > > considered > > > a bad design choice in certain scenarios. This document corrects > > > RFC 4412's communications model by optionally allowing a > > SIP server > > > or user agent client to process the Resource-Priority Header in a > > > response. > > > > > >A URL for this Internet-Draft is: > > >http://www.ietf.org/internet-drafts/draft-polk-sip-rph-in-res > > ponses-00. > > >txt > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 20:22:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6bac-0008NA-7E; Thu, 05 Jul 2007 20:22:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6baZ-0008G3-7w for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 20:22:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6baY-0008DS-SV for sip@ietf.org; Thu, 05 Jul 2007 20:22:22 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6baY-0008EE-KP for sip@ietf.org; Thu, 05 Jul 2007 20:22:22 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 05 Jul 2007 17:22:21 -0700 X-IronPort-AV: i="4.16,505,1175497200"; d="scan'208"; a="6885271:sNHT395742738" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l660MLM6003186; Thu, 5 Jul 2007 17:22:21 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l660MLXH018318; Fri, 6 Jul 2007 00:22:21 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 20:22:20 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.78]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 20:22:20 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 05 Jul 2007 19:22:19 -0500 To: hgs@cs.columbia.edu From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jul 2007 00:22:20.0536 (UTC) FILETIME=[B78B0F80:01C7BF63] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1067; t=1183681341; x=1184545341; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Conveyance=20-08=20and=20Geolocation-Error=20header |Sender:=20; bh=A2Qg8zERE71DLVvTmKTGGGUFdWAN+B/0H/CdLOF657U=; b=e8azCCmSAFpUcC79q+xR6NsEBpX96dkwl5zsDnBxgNQiV1W9RKKt1wibc2Upo6g86YMZwykz +woRv+7INURJkV/Y2NrkfRjtftBXLiIIxjPS81Zr9uSO45r18zAgnkIy; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip@ietf.org Subject: [Sip] Conveyance -08 and Geolocation-Error header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Henning Regarding Conveyance -08 and the new Geolocation-Error header that you want to replace the Warning header code(s) function (section 3.4 of the -07 ID)... What fields do you want in the header? #1 error-code, #2 text-string explaining what error it is #? Do you need anything else? Warning had/has the node ID of the sending entity. Do you want that in the new Geolocation-Error header? Do you really see a purpose in having that piece there? Attempting to put the final pieces of -08 together, and this new header is less than straightforward in writing it. Is this viable ABNF for what you want? Geolocation-Error = "Geolocation-Error" HCOLON (locationErrorValue *(COMMA locationErrorValue)) locationErrorValue = numeric-code *(SEMI geoloc-error-param) numeric-code = decimal-string geoloc-error-param = "code" EQUAL error-text-string / generic-param ; (from RFC 3261) error-text-string = string (anyone) let me know what you think Thanks James _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 20:36:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6boS-0002m0-WD; Thu, 05 Jul 2007 20:36:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6boS-0002h9-6f for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 20:36:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6boR-0002f0-S9 for sip@ietf.org; Thu, 05 Jul 2007 20:36:43 -0400 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6boL-0002zK-An for sip@ietf.org; Thu, 05 Jul 2007 20:36:43 -0400 Received: from unknown (HELO 306181ANEX3.global.avaya.com) ([135.9.6.103]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Jul 2007 20:36:35 -0400 X-IronPort-AV: i="4.16,505,1175486400"; d="scan'208"; a="34705752:sNHT11475078" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Certificate authentication in SIP Date: Thu, 5 Jul 2007 18:36:17 -0600 Message-ID: <166476A2803C3B4994D744DFD57A942F160C08@306181ANEX3.global.avaya.com> In-Reply-To: <468D6AC6.80402@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Certificate authentication in SIP Thread-Index: Ace/UK3GB9F5O1QCQ4WuvoYmqXE4TAAE8aDA References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com><46819819.5080107@cisco.com><4681DA3C.8090607@softarmor.com> <4682CBF1.9000401@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C62E9B4D@srvxchg3.cablelabs.com><468B0889.8010005@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C62E9C30@srvxchg3.cablelabs.com> <468D6AC6.80402@cisco.com> From: "Rai, Anupam (Anupam)" To: "Jonathan Rosenberg" , "Steve Dotson" X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: IETF SIP List , "DRAGE, Keith \(Keith\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (1) Will the the P-A-ID syntax require modification to carry UA's = certificate related information (Obtained during mutual TLS) from edge = proxy to home proxy or registrar ? (2) Edge proxy utilizing TLS offloaders. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: Thursday, July 05, 2007 3:04 PM To: Steve Dotson Cc: IETF SIP List; DRAGE,Keith (Keith); Dean Willis Subject: Re: [Sip] Certificate authentication in SIP Steve Dotson wrote: > Maybe this is na=EFve, but doesn't this alter the operator trust = model? >=20 >=20 > I always envisioned P-A-ID (as an example) as a way for a home network = > to tell a 3rd party service "trust this one, they are authenticated",=20 > as long as the home network and the service had a relationship. Having = > an edge proxy in a visited domain telling the home network "trust this = > one" seems to turn things around. P-A-ID asserts identity between providers with trust, yes that is true.=20 SIP Identity works with lesser degrees of trust, but if you don't trust = the signing domain, of course it doesn't work. However, my point is, one of the two following scenarios always apply: 1. the edge proxy is trusted by the home proxy, in which case you can = use mutual TLS to authenticate the client to the edge proxy, and then = P-A-ID or SIP Identity from edge proxy to home proxy, *OR* 2. there is no trust at all between visited and home networks. In this = case, you shouldn't be connectign to a visited proxy in the first place. = COnnect to the home proxy in your home network. Then, case 1 applies = again. In other words, the entire motivation behind this draft is based on an=20 assumption that a client needs to connect to its actual proxy through an = intermediate proxy that no one trusts. SO many things get broken in that = model. So, don't do it! This idea of a visited proxy with whom I have no = relationship, is totally broken. ALl of the reasons people list for=20 wanting them, we have far better solutions for (NAT traversal, firewall=20 traversal, QoS). I'll note further that QoS can never work in a model=20 without trust. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 20:53:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6c4X-0005Aj-9d; Thu, 05 Jul 2007 20:53:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6c4V-000576-6I for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 20:53:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6c4U-00056r-PX for sip@ietf.org; Thu, 05 Jul 2007 20:53:18 -0400 Received: from an-out-0708.google.com ([209.85.132.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6c4P-0005L4-4x for sip@ietf.org; Thu, 05 Jul 2007 20:53:18 -0400 Received: by an-out-0708.google.com with SMTP id c17so11219anc for ; Thu, 05 Jul 2007 17:53:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IbncICDo5/sxu2xNx+37r/DVQ7DeWEZC4swjC00R4xuVYPZ8xmD984gJa/FbrxyVwjV/II577eTuu9BuUG7KFcvqZfU+7Z1yOtPcqCuAD/MmDW9q7E33vNqogAfZFjlvV/l0V0fZ2MHNx/n37VJQuOV8yHP7/SrfPIAXrYbawYc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HtVl45XiEa7lt1AReTby53dX6AILZXp3IHoBImCGmpor2GEDO2qghIDRry2eLNEnX4bGDjn14plkJg7ebhTZTuCa7k8Aw+A2w38HAxCI+YoNZ+Z2chn78btIzgzh5q/WmlRPHRUdX9qTfgjtF9vhj9XlyE1ewAdAnHiIg+ANnEY= Received: by 10.100.47.9 with SMTP id u9mr84980anu.1183683190835; Thu, 05 Jul 2007 17:53:10 -0700 (PDT) Received: by 10.100.124.4 with HTTP; Thu, 5 Jul 2007 17:53:10 -0700 (PDT) Message-ID: <953beacc0707051753h56e27db6o9c03136d6a7e862a@mail.gmail.com> Date: Thu, 5 Jul 2007 17:53:10 -0700 From: "Rohan Mahy" To: "Fredrik Thulin" Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-09.txt In-Reply-To: <468CDD19.1080602@it.su.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5D1A7985295922448D5550C94DE29180013B65F3@DEEXC1U01.de.lucent.com> <468CDD19.1080602@it.su.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Fredrik, 1) In this version I added text in the current Security Consideration to help clarify this. See the diffs in Section 13 here: http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip-outbound.diff.html I thought I already sent you a message about this topic, but in any case I will post my response here. The goal is to make sure that *no new attacks* are made possible by the introduction of this extension. An active attacker can hijack your TCP connection before you add outbound. If you want to prevent active attacks, you need TLS, whether you are using outbound or not. The most important thing to mention about the security of outbound is that is at least as secure as SIP without outbound, and that the security gets quite good when you add Digest. 2) When we originally talked about Algorithm 1 vs. Algorithm 2, there was some attack we discussed that caused us to say that hijacking is possible without the additional security in Algorithm 2. I spoke with Cullen about this today, and neither or us could recall the specific attack. It is possible that Algorithm 2 only prevents attacks that are irrelevant based on the principle I mention in point 1 above, but I want to make sure that we go back and look at the specific cases that were mentioned on the list. thanks, -rohan On 7/5/07, Fredrik Thulin wrote: > DRAGE, Keith (Keith) wrote: > > (As WG chair) > > > > We now have a new version of outbound. There hasn't exactly been a > > flurry of comments since it was posted - does that mean it is now ready > > for WGLC. > > > > It has agenda time at the next IETF meeting, with a view to starting > > WGLC not long after that meeting. If you believe there are issues with > > the current version of this document, then you need to post them to the > > list, so that they can be either resolved there, or addressed in the > > meeting. > > I never received an explanation of what kind of attacks could be avoided > by an edge proxy using an algorithm that generates flow tokens that > "cannot be modified by attackers" (section 5.2 of outbound-09). > > This was the last e-mail in the thread the last time I brought it up on > the list : > > http://www1.ietf.org/mail-archive/web/sip/current/msg18336.html. > > This leads me to think that either > > 1) the security threats haven't been addressed properly > > or > > 2) that there in fact was no security threat so the requirement for an > edge proxy to generate flows that "cannot be modified by attackers" > is just unnecessary, and should therefor be removed > or > > 3) there really _is_ something that gets significantly better by this > requirement, and it should simply be explained in the draft. > > /Fredrik > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 21:32:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6cgE-0007dw-94; Thu, 05 Jul 2007 21:32:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6cgC-0007dl-Tz for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 21:32:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6cgC-0007dO-It for sip@ietf.org; Thu, 05 Jul 2007 21:32:16 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6cgC-00081t-C7 for sip@ietf.org; Thu, 05 Jul 2007 21:32:16 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l661Vckb019883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 5 Jul 2007 21:31:43 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <81A2A0E9-FDF4-48EC-92E4-C02B6BD05948@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Thu, 5 Jul 2007 21:31:34 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: sip@ietf.org Subject: [Sip] Re: Conveyance -08 and Geolocation-Error header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org James, I think your #1 and #2 covers it, in addition to an identifier that points to the location element that suffers from the problem identified. (The latter was discussed, if I recall correctly, but seems to be missing from your syntax proposal.) I don't feel strongly about identifying the originator of the error, but it might be useful to have an extensible parameter list, in standard SIP header fashion, so that we can easily add more debugging information later. Henning On Jul 5, 2007, at 8:22 PM, James M. Polk wrote: > Henning > > Regarding Conveyance -08 and the new Geolocation-Error header that > you want to replace the Warning header code(s) function (section > 3.4 of the -07 ID)... > > What fields do you want in the header? > > #1 error-code, > #2 text-string explaining what error it is > #? > > Do you need anything else? > > Warning had/has the node ID of the sending entity. Do you want that > in the new Geolocation-Error header? Do you really see a purpose > in having that piece there? > > Attempting to put the final pieces of -08 together, and this new > header is less than straightforward in writing it. > > Is this viable ABNF for what you want? > > Geolocation-Error = "Geolocation-Error" HCOLON (locationErrorValue > *(COMMA locationErrorValue)) > locationErrorValue = numeric-code *(SEMI geoloc-error-param) > numeric-code = decimal-string > geoloc-error-param = "code" EQUAL error-text-string > / generic-param ; (from RFC 3261) > error-text-string = string > > (anyone) let me know what you think > > Thanks > James _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 21:32:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6cgr-00008d-76; Thu, 05 Jul 2007 21:32:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6cgo-00008L-RK for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 21:32:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6cgo-00008D-GL for sip@ietf.org; Thu, 05 Jul 2007 21:32:54 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6cgo-00085L-AD for sip@ietf.org; Thu, 05 Jul 2007 21:32:54 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 05 Jul 2007 21:32:46 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPY3jUZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175486400"; d="scan'208"; a="125332765:sNHT26404212" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l661WjFm005640; Thu, 5 Jul 2007 21:32:45 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l661Wfs0004126; Fri, 6 Jul 2007 01:32:41 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 21:32:40 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 21:32:39 -0400 Message-ID: <468D9BBB.4010107@cisco.com> Date: Thu, 05 Jul 2007 21:32:43 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Rai, Anupam (Anupam)" Subject: Re: [Sip] Certificate authentication in SIP References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com><46819819.5080107@cisco.com><4681DA3C.8090607@softarmor.com> <4682CBF1.9000401@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C62E9B4D@srvxchg3.cablelabs.com><468B0889.8010005@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C62E9C30@srvxchg3.cablelabs.com> <468D6AC6.80402@cisco.com> <166476A2803C3B4994D744DFD57A942F160C08@306181ANEX3.global.avaya.com> In-Reply-To: <166476A2803C3B4994D744DFD57A942F160C08@306181ANEX3.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2007 01:32:39.0915 (UTC) FILETIME=[8A7D33B0:01C7BF6D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=895; t=1183685566; x=1184549566; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20Certificate=20authentication=20in=20SIP |Sender:=20 |To:=20=22Rai,=20Anupam=20(Anupam)=22=20; bh=0FEfU96Nv/Tr7pcqQXoTN758hnGu8GJ7+LDpN/Jml5Q=; b=sKY8REjQvaaox/E9Kx+OvfPWsyWjPUhCvd5Ktj5lnE+88XBVp6fDJHDcOPtXg6vZNZziAhMT tn9H1Qks3g26rySHveRjPpP/L56dgK2cqurCYybxXVnJxfZK105lMdd/; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Steve Dotson , IETF SIP List , "DRAGE, Keith \(Keith\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rai, Anupam (Anupam) wrote: > > (1) Will the the P-A-ID syntax require modification to carry UA's > certificate related information (Obtained during mutual TLS) from > edge proxy to home proxy or registrar ? Yes. You'd get nothing but the identity. Do you need more? > (2) Edge proxy utilizing TLS > offloaders. The offloader would need to pass the identity to the server. If it acted as a simple SIP proxy in addition to doing TLS offload, it would work fine. There are other non-standard ways of passing this identity also. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 21:45:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ctE-0002Ap-41; Thu, 05 Jul 2007 21:45:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6ctC-0002Ae-TA for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 21:45:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ctC-0002AW-JV for sip@ietf.org; Thu, 05 Jul 2007 21:45:42 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6ct8-000510-9X for sip@ietf.org; Thu, 05 Jul 2007 21:45:42 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 05 Jul 2007 21:45:38 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAIs7jUZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175486400"; d="scan'208"; a="125333367:sNHT28700458" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l661jbVp008857; Thu, 5 Jul 2007 21:45:37 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l661jb6a012817; Fri, 6 Jul 2007 01:45:37 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 21:45:37 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.78]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 21:45:37 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 05 Jul 2007 20:45:36 -0500 To: Henning Schulzrinne From: "James M. Polk" In-Reply-To: <81A2A0E9-FDF4-48EC-92E4-C02B6BD05948@cs.columbia.edu> References: <81A2A0E9-FDF4-48EC-92E4-C02B6BD05948@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jul 2007 01:45:37.0285 (UTC) FILETIME=[59D67350:01C7BF6F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2651; t=1183686337; x=1184550337; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20Conveyance=20-08=20and=20Geolocation-Error=20header |Sender:=20 |To:=20Henning=20Schulzrinne=20; bh=iWntoqWDZfDocEiu4x5z1c/w2Eq4YbQXOqAznwsal4g=; b=Vg7Mx3aXBjaWJ0oLy6Xd3ZdqnmMbigKJfvhTgQwZ74xm6z/FUiT4kEaeOo/kg8jYn2lugf6B HW9+FN03jYDzwurN2m6ykvJCNM6VEhFbVui0jvJ4CCGNz5qk94o4pMTt; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: sip@ietf.org Subject: [Sip] Re: Conveyance -08 and Geolocation-Error header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 08:31 PM 7/5/2007, Henning Schulzrinne wrote: >James, > >I think your #1 and #2 covers it, in addition to an identifier that >points to the location element that suffers from the problem >identified. (The latter was discussed, if I recall correctly, but >seems to be missing from your syntax proposal.) this is the Warning header's nodeID part. I wanted to know if you wanted that to remain in this new header. I sounds like you do. Question - what's the difference between "...he location element that suffers from the problem identified..." mentioned above and how you "... don't feel strongly about identifying the originator of the error". Aren't they the same node? If not, I need to understand, as I define what ID goes into this header. Another point - should this error header only be in the 424 (Bad Location Information) response, or all 4XX responses, allowing a transaction to be successful - but without the location piece of the information exchange being good? This was discussed, but I don't think the discussion ever concluded. >I don't feel strongly about identifying the originator of the error, >but it might be useful to have an extensible parameter list, in >standard SIP header fashion, so that we can easily add more debugging >information later. I agree with this last point. Do you want something more than the existing "generic-param (from RFC 3261)" I have there now? >Henning > >On Jul 5, 2007, at 8:22 PM, James M. Polk wrote: > >>Henning >> >>Regarding Conveyance -08 and the new Geolocation-Error header that >>you want to replace the Warning header code(s) function (section >>3.4 of the -07 ID)... >> >>What fields do you want in the header? >> >>#1 error-code, >>#2 text-string explaining what error it is >>#? >> >>Do you need anything else? >> >>Warning had/has the node ID of the sending entity. Do you want that >>in the new Geolocation-Error header? Do you really see a purpose >>in having that piece there? >> >>Attempting to put the final pieces of -08 together, and this new >>header is less than straightforward in writing it. >> >>Is this viable ABNF for what you want? >> >>Geolocation-Error = "Geolocation-Error" HCOLON (locationErrorValue >> *(COMMA locationErrorValue)) >>locationErrorValue = numeric-code *(SEMI geoloc-error-param) >>numeric-code = decimal-string >>geoloc-error-param = "code" EQUAL error-text-string >> / generic-param ; (from RFC 3261) >>error-text-string = string >> >>(anyone) let me know what you think >> >>Thanks >>James _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 21:53:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6d15-0004iu-Cm; Thu, 05 Jul 2007 21:53:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6d13-0004id-Rv for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 21:53:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6d13-0004iT-I2 for sip@ietf.org; Thu, 05 Jul 2007 21:53:49 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6d0z-0005sZ-7i for sip@ietf.org; Thu, 05 Jul 2007 21:53:49 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l661rbMo028372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 5 Jul 2007 21:53:42 -0400 (EDT) In-Reply-To: References: <81A2A0E9-FDF4-48EC-92E4-C02B6BD05948@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Thu, 5 Jul 2007 21:53:33 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: sip@ietf.org Subject: [Sip] Re: Conveyance -08 and Geolocation-Error header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Let me try to explain: Let's say proxy P1 inserts location information L1, and user agent U1 inserts L2. I want to identity L1 and L2, not necessarily the IP addresses or host names for proxy P1 or user agent U1 (which may or may not be unique, if NATs are involved). The reason is simple - some element may insert location information, and the poor sender will try to figure out an error for location information it has never inserted. I think this should be in all responses, as calls may succeed even if the location information, or one piece of it, happens to be bad. I still want to know that the call may have been routed without taking the location information into consideration, say, and why. The 3261 generic-param is fine with me. Henning On Jul 5, 2007, at 9:45 PM, James M. Polk wrote: > Question - what's the difference between "...he location element > that suffers from the problem identified..." mentioned above and > how you "... don't feel strongly about identifying the originator > of the error". Aren't they the same node? > > If not, I need to understand, as I define what ID goes into this > header. > > Another point - should this error header only be in the 424 (Bad > Location Information) response, or all 4XX responses, allowing a > transaction to be successful - but without the location piece of > the information exchange being good? > > This was discussed, but I don't think the discussion ever concluded. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 22:07:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dET-0002Q5-0Y; Thu, 05 Jul 2007 22:07:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6dER-0002Ie-Iu for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 22:07:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dER-0002IR-75 for sip@ietf.org; Thu, 05 Jul 2007 22:07:39 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6dEQ-0004Or-W1 for sip@ietf.org; Thu, 05 Jul 2007 22:07:39 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Jul 2007 22:07:30 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAChBjUZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175486400"; d="scan'208"; a="64459033:sNHT28830110" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6627UlQ032732; Thu, 5 Jul 2007 22:07:30 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6627U6a018455; Fri, 6 Jul 2007 02:07:30 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); Thu, 5 Jul 2007 22:07:30 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.78]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 22:07:29 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 05 Jul 2007 21:07:28 -0500 To: Henning Schulzrinne From: "James M. Polk" In-Reply-To: References: <81A2A0E9-FDF4-48EC-92E4-C02B6BD05948@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jul 2007 02:07:29.0770 (UTC) FILETIME=[6823C4A0:01C7BF72] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2357; t=1183687650; x=1184551650; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20Conveyance=20-08=20and=20Geolocation-Error=20header |Sender:=20 |To:=20Henning=20Schulzrinne=20; bh=/Gpq3nyG+LLIdgSGXhq6EDzfFwTZ6G3WeccZF27U4yE=; b=vC7gxmf3wI1+I8RaM6/bQRTBoQAVi0sXHJSMxKpL9tINrATHlNCbgdQwgO8O7RGRxvqyGyRX w5nyGAzJaKP0mn7sJJefs8taw7OiGRLHyNh3KtzV90K8wZZ1sKkSTX59; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: sip@ietf.org Subject: [Sip] Re: Conveyance -08 and Geolocation-Error header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 08:53 PM 7/5/2007, Henning Schulzrinne wrote: >Let me try to explain: > >Let's say proxy P1 inserts location information L1, and user agent U1 >inserts L2. I want to identity L1 and L2, not necessarily the IP >addresses or host names for proxy P1 or user agent U1 (which may or >may not be unique, if NATs are involved). this is important... many of us had realized this was a problem, I just didn't realize this new header solved it (yet). It will now! >The reason is simple - some element may insert location information, >and the poor sender will try to figure out an error for location >information it has never inserted. > >I think this should be in all responses, all? even 5XXs and 6XXs? I'm have a pragmatic attack thinking how in the world a UAS can process enough of a request to figure out location is bad, but still error the message because of something it can't do more fundamentally with the request outside of location. There aren't that many 5XX and 6XX responses, so I'm not fighting it - just trying to understand what you want. I'm open to all 4XX (cuz I can see this working in most 4XX responses (like a double error of "this *and* that" were wrong with this request), which is why I offered it (instead of limiting this to just the 424). >as calls may succeed even if >the location information, or one piece of it, happens to be bad. I >still want to know that the call may have been routed without taking >the location information into consideration, say, and why. > >The 3261 generic-param is fine with me. good! Thanks! >Henning > >On Jul 5, 2007, at 9:45 PM, James M. Polk wrote: > >>Question - what's the difference between "...he location element >>that suffers from the problem identified..." mentioned above and >>how you "... don't feel strongly about identifying the originator >>of the error". Aren't they the same node? >> >>If not, I need to understand, as I define what ID goes into this >>header. >> >>Another point - should this error header only be in the 424 (Bad >>Location Information) response, or all 4XX responses, allowing a >>transaction to be successful - but without the location piece of >>the information exchange being good? >> >>This was discussed, but I don't think the discussion ever concluded. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 22:10:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dGp-0000Jh-Oo; Thu, 05 Jul 2007 22:10:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6dGl-0000GS-Ur for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 22:10:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dGk-0000E2-Ur; Thu, 05 Jul 2007 22:10:03 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6dGk-0004c7-EH; Thu, 05 Jul 2007 22:10:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 2992B175C5; Fri, 6 Jul 2007 02:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I6dGj-0002CX-MY; Thu, 05 Jul 2007 22:10:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 05 Jul 2007 22:10:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-acr-code-05.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Rejecting Anonymous Requests in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-acr-code-05.txt Pages : 8 Date : 2007-07-05 The Session Initiation Protocol (SIP) allows for users to make anonymous calls. However, users receiving such calls have the right to reject them because they are anonymous. SIP has no way to indicate to the caller that the reason for call rejection was that the call was anonymous. Such an indication is useful to allow the call to be retried without anonymity. This specification defines a new SIP response code for this purpose. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-acr-code-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-acr-code-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-acr-code-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-07-05220838.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-acr-code-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-acr-code-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-07-05220838.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Thu Jul 05 22:10:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dHH-00015Y-Kn; Thu, 05 Jul 2007 22:10:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6dHF-000151-0L for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 22:10:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dHE-00014p-KS; Thu, 05 Jul 2007 22:10:32 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6dHE-0004dE-CV; Thu, 05 Jul 2007 22:10:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 17FA617573; Fri, 6 Jul 2007 02:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I6dGj-0002CT-Ln; Thu, 05 Jul 2007 22:10:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 05 Jul 2007 22:10:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-hitchhikers-guide-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : A Hitchhiker's Guide to the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-hitchhikers-guide-03.txt Pages : 32 Date : 2007-07-05 The Session Initiation Protocol (SIP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SIP. This specification serves as a guide to the SIP RFC series. It lists the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers-guide-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-hitchhikers-guide-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-hitchhikers-guide-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-07-05220342.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-hitchhikers-guide-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-hitchhikers-guide-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-07-05220342.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Thu Jul 05 22:13:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dKC-0005Gn-S9; Thu, 05 Jul 2007 22:13:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6dKB-0005FS-55 for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 22:13:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dKA-0005EH-PY for sip@ietf.org; Thu, 05 Jul 2007 22:13:34 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6dKA-0004sc-JS for sip@ietf.org; Thu, 05 Jul 2007 22:13:34 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Jul 2007 22:13:30 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAChBjUZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175486400"; d="scan'208"; a="125335605:sNHT24998754" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l662DTE7001728 for ; Thu, 5 Jul 2007 22:13:29 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l662DTs0012801 for ; Fri, 6 Jul 2007 02:13:29 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); Thu, 5 Jul 2007 22:13:29 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 22:13:29 -0400 Message-ID: <468DA54C.4090909@cisco.com> Date: Thu, 05 Jul 2007 22:13:32 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2007 02:13:29.0436 (UTC) FILETIME=[3E8471C0:01C7BF73] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=773; t=1183688010; x=1184552010; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Updated=20hittchhikers=20guide=20to=20SIP |Sender:=20 |To:=20IETF=20SIP=20List=20; bh=WP7IfD/LmcYhullqyqi1ftXdnDdewGaBRIwm2pVcr8c=; b=IYQzoJbwXNnw1VALyfNtf72kv3CLQ1j7Z2bsmTg50uSAwFzvBaDIjowqm8kAsRC47GvriyBn mGeYVD3U2hHKXVjxiA+/todoGJK7eaq1YV0nMC7+53XSJoF2qypcrn8T; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Sip] Updated hittchhikers guide to SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've just submitted a new version of the hitchhikers guide. You can pick it up at: http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers-guide-03.txt The changes from -02 are: * connected-identity -> RFC4916 * added record-route-fix and grouped it with fork-loop-fix into a new item under SIP core called "essential corrections" * added subnot-etags under event packages * added sip-sips to core specs Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 22:15:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dME-0006MA-HJ; Thu, 05 Jul 2007 22:15:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6dMD-0006Hz-6J for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 22:15:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dMC-0006Hm-R6 for sip@ietf.org; Thu, 05 Jul 2007 22:15:40 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6dMC-0004yj-KO for sip@ietf.org; Thu, 05 Jul 2007 22:15:40 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l662Eidf026301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 5 Jul 2007 22:14:49 -0400 (EDT) In-Reply-To: References: <81A2A0E9-FDF4-48EC-92E4-C02B6BD05948@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Thu, 5 Jul 2007 22:14:41 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sip@ietf.org Subject: [Sip] Re: Conveyance -08 and Geolocation-Error header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > all? even 5XXs and 6XXs? I'm have a pragmatic attack thinking how > in the world a UAS can process enough of a request to figure out > location is bad, but still error the message because of something > it can't do more fundamentally with the request outside of > location. There aren't that many 5XX and 6XX responses, so I'm not > fighting it - just trying to understand what you want. > I'm not a friend of being overly prescriptive and trying to predict all cases, including future status codes. In most cases, inserting the information may not make sense, but it is always harmless, even if it goes along with a 5xx or 6xx response. After all, both types of errors may occur at the same time. If the location information is broken, I want to be told about it, regardless of what other problems the SIP request had. (Plus, the location error information may have been inserted along the way by a proxy trying to use it for location routing. The UAS getting the location error indication shouldn't just swallow this information - it's useful to the UAC.) Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 22:15:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dMP-0007A5-KV; Thu, 05 Jul 2007 22:15:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6dMP-00077g-4O for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 22:15:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dMO-00076S-O8 for sip@ietf.org; Thu, 05 Jul 2007 22:15:52 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6dMO-00054M-Hh for sip@ietf.org; Thu, 05 Jul 2007 22:15:52 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 05 Jul 2007 22:15:52 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJpCjUZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175486400"; d="scan'208"; a="125335714:sNHT25174496" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l662FqBw020151 for ; Thu, 5 Jul 2007 22:15:52 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l662Fp6a019909 for ; Fri, 6 Jul 2007 02:15:51 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 22:15:51 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 22:15:51 -0400 Message-ID: <468DA5DB.2070402@cisco.com> Date: Thu, 05 Jul 2007 22:15:55 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2007 02:15:51.0830 (UTC) FILETIME=[93640B60:01C7BF73] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=875; t=1183688152; x=1184552152; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Updated=20acr-code |Sender:=20 |To:=20IETF=20SIP=20List=20; bh=1vueY/xjI/1Nbsd8Jun5eWtEOvBxUrpMaSedQdB7RTQ=; b=SYkES0lH+8WYFKqfsF5uI4yBrTU9pUQmPcbk9aM/6KZttslKPJzrTRNeNVu1X9illVNrStGa +iMwvu+KG2Yt8WrfIwSO9xbVwy4qBn4/qTxp9dA+5akp5X/K0Ajceak5; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sip] Updated acr-code X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've submitted an update to the acr-code draft. You can pick it up at: http://www.ietf.org/internet-drafts/draft-ietf-sip-acr-code-05.txt This draft addresses AD comments raised during AD evaluation. The primary change is that, previously, the specification indicated that a P-A-ID header field with an anonymous URI in it would count as an anonymous request. However, P-A-ID doesn't reflect what the user wants, which is strictly in the From. Consequently, PAID is really irrelevant here. So, this condition was removed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 22:28:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dYK-0002xa-T2; Thu, 05 Jul 2007 22:28:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6dYJ-0002sX-Gf for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 22:28:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dYJ-0002sP-5s for sip@ietf.org; Thu, 05 Jul 2007 22:28:11 -0400 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6dYI-00064k-Vp for sip@ietf.org; Thu, 05 Jul 2007 22:28:11 -0400 Received: from 103.6.9.135.in-addr.arpa (HELO 306181ANEX3.global.avaya.com) ([135.9.6.103]) by nj300815-nj-outbound.avaya.com with ESMTP; 05 Jul 2007 22:27:38 -0400 X-IronPort-AV: i="4.16,505,1175486400"; d="scan'208"; a="35466109:sNHT8842998" 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 Subject: RE: [Sip] Certificate authentication in SIP Date: Thu, 5 Jul 2007 20:27:21 -0600 Message-ID: <166476A2803C3B4994D744DFD57A942F160C11@306181ANEX3.global.avaya.com> In-Reply-To: <468D9BBB.4010107@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Certificate authentication in SIP Thread-Index: Ace/bcu09H3kVTuxRfyynHaLTwfxrgABONPA References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com><46819819.5080107@cisco.com><4681DA3C.8090607@softarmor.com> <4682CBF1.9000401@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C62E9B4D@srvxchg3.cablelabs.com><468B0889.8010005@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C62E9C30@srvxchg3.cablelabs.com> <468D6AC6.80402@cisco.com> <166476A2803C3B4994D744DFD57A942F160C08@306181ANEX3.global.avaya.com> <468D9BBB.4010107@cisco.com> From: "Rai, Anupam (Anupam)" To: "Jonathan Rosenberg" X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Steve Dotson , IETF SIP List , "DRAGE, Keith \(Keith\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 inline > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Thursday, July 05, 2007 6:33 PM > To: Rai, Anupam (Anupam) > Cc: Steve Dotson; IETF SIP List; DRAGE,Keith (Keith); Dean Willis > Subject: Re: [Sip] Certificate authentication in SIP >=20 >=20 >=20 > Rai, Anupam (Anupam) wrote: > >=20 > > (1) Will the the P-A-ID syntax require modification to carry UA's=20 > > certificate related information (Obtained during mutual=20 > TLS) from edge=20 > > proxy to home proxy or registrar ? >=20 > Yes. You'd get nothing but the identity. Do you need more? >=20 [Anupam Rai] Identity as asserted by certificate presented by UA during mutual TLS or identity as established by edge proxy after consulting some authentication service/database ? >=20 > > (2) Edge proxy utilizing TLS > > offloaders. >=20 > The offloader would need to pass the identity to the server.=20 > If it acted as a simple SIP proxy in addition to doing TLS=20 > offload, it would work fine. There are other non-standard=20 > ways of passing this identity also. >=20 > -Jonathan R. >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 22:38:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dhu-0006QU-Ut; Thu, 05 Jul 2007 22:38:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6dht-0006GX-3K for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 22:38:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dhs-0006CZ-GJ for sip@ietf.org; Thu, 05 Jul 2007 22:38:04 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6dhs-0007Yu-9l for sip@ietf.org; Thu, 05 Jul 2007 22:38:04 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 05 Jul 2007 22:38:04 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAINHjUZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175486400"; d="scan'208"; a="125336396:sNHT35359540" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l662c3a1024447; Thu, 5 Jul 2007 22:38:03 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l662bos2016203; Fri, 6 Jul 2007 02:37:55 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 22:37:51 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 22:37:50 -0400 Message-ID: <468DAB02.1070805@cisco.com> Date: Thu, 05 Jul 2007 22:37:54 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Rai, Anupam (Anupam)" Subject: Re: [Sip] Certificate authentication in SIP References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com><46819819.5080107@cisco.com><4681DA3C.8090607@softarmor.com> <4682CBF1.9000401@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C62E9B4D@srvxchg3.cablelabs.com><468B0889.8010005@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C62E9C30@srvxchg3.cablelabs.com> <468D6AC6.80402@cisco.com> <166476A2803C3B4994D744DFD57A942F160C08@306181ANEX3.global.avaya.com> <468D9BBB.4010107@cisco.com> <166476A2803C3B4994D744DFD57A942F160C11@306181ANEX3.global.avaya.com> In-Reply-To: <166476A2803C3B4994D744DFD57A942F160C11@306181ANEX3.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2007 02:37:51.0030 (UTC) FILETIME=[A5B1FD60:01C7BF76] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1492; t=1183689483; x=1184553483; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20Certificate=20authentication=20in=20SIP |Sender:=20 |To:=20=22Rai,=20Anupam=20(Anupam)=22=20; bh=uLplY0Y7fyNnVddycV/5i2RDXRKTK9A++7k9biu714o=; b=OXp9GHRKGLp62nt6CdCbi0EkWz41IAHqY+bK1CSv9Yjw2wIdsZ/2uorDDaSAsFXeD0lzuWPC kGrH2CE2/RI1REd4y+clJeIRGUCXg+aCSJMfYSqKIs9r1VZaezYAY7U6; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Steve Dotson , IETF SIP List , "DRAGE, Keith \(Keith\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline: Rai, Anupam (Anupam) wrote: > > inline > >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> Sent: Thursday, July 05, 2007 6:33 PM >> To: Rai, Anupam (Anupam) >> Cc: Steve Dotson; IETF SIP List; DRAGE,Keith (Keith); Dean Willis >> Subject: Re: [Sip] Certificate authentication in SIP >> >> >> >> Rai, Anupam (Anupam) wrote: >>> (1) Will the the P-A-ID syntax require modification to carry UA's >>> certificate related information (Obtained during mutual >> TLS) from edge >>> proxy to home proxy or registrar ? >> Yes. You'd get nothing but the identity. Do you need more? >> > [Anupam Rai] > Identity as asserted by certificate presented by UA during mutual TLS or > identity as established by edge proxy after consulting some > authentication service/database ? As asserted by the certificate. In other words, the edge proxy would validate the client cert, extract the subjectAltName which presumably has something like joe@example.com somewhere and then shoves that into a P-Asserted-ID. Or if it matches the From it would use RFC 4474 and sign the request. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 22:59:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6e2L-0003a7-2z; Thu, 05 Jul 2007 22:59:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6e2J-0003YL-I5 for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 22:59:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6e2J-0003YD-8Q for sip@ietf.org; Thu, 05 Jul 2007 22:59:11 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6e2E-0004Gh-UJ for sip@ietf.org; Thu, 05 Jul 2007 22:59:11 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 05 Jul 2007 22:59:00 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJZMjUZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175486400"; d="scan'208"; a="125337289:sNHT211314608" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l662wxUp029544; Thu, 5 Jul 2007 22:58:59 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l662wx6a026505; Fri, 6 Jul 2007 02:58:59 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 22:58:59 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.78]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 22:58:59 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 05 Jul 2007 21:58:57 -0500 To: Henning Schulzrinne From: "James M. Polk" In-Reply-To: References: <81A2A0E9-FDF4-48EC-92E4-C02B6BD05948@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jul 2007 02:58:59.0132 (UTC) FILETIME=[998AFFC0:01C7BF79] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1986; t=1183690739; x=1184554739; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20Conveyance=20-08=20and=20Geolocation-Error=20header |Sender:=20 |To:=20Henning=20Schulzrinne=20; bh=jS7ivhbsnvSbw5pOxIEY7yzBUz2dFjsa/H0SUWie76U=; b=WTk5ShE3OiGLH0/fEOUMd4ed/sqnR/GUFc5fS2FTJq3KqRaOxKXu9k5/c5/qR51YEnHy5rOy gjqVgbQh1ArxPv+4+lQRXNedQA7FPMMBG61DT64Rtso9spPKZUpBArGX; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sip@ietf.org Subject: [Sip] Re: Conveyance -08 and Geolocation-Error header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 09:14 PM 7/5/2007, Henning Schulzrinne wrote: >>all? even 5XXs and 6XXs? I'm have a pragmatic attack thinking how >>in the world a UAS can process enough of a request to figure out >>location is bad, but still error the message because of something >>it can't do more fundamentally with the request outside of >>location. There aren't that many 5XX and 6XX responses, so I'm not >>fighting it - just trying to understand what you want. > >I'm not a friend of being overly prescriptive and trying to predict >all cases, including future status codes. In most cases, inserting >the information may not make sense, but it is always harmless, even >if it goes along with a 5xx or 6xx response. After all, both types of >errors may occur at the same time. If the location information is >broken, I want to be told about it, regardless of what other problems >the SIP request had. (Plus, the location error information may have >been inserted along the way by a proxy trying to use it for location >routing. The UAS getting the location error indication shouldn't just >swallow this information - it's useful to the UAC.) fair -- the text is changed to allow it in all responses New topic -- Do we want at all to try and tackle mapping of which location goes with which error, to make sure each receiver of the response pays attention or ignores what they are supposed to (wrt locationValues)? If this is a good idea, would a header parameter sequence number (mapped between Geolocation header and Geolocation-Error header) do the trick? I think we'll just need to make sure the numbers don't replicate another sequence number within the same Call-ID, and not be universally unique through space and time. This might be a little too much to take on this late (to the deadline) or it just might be too silly of an idea *or* do you think the host ID within the Geolocation-Error header might be enough to cover this idea. >Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 23:03:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6e6g-0000cO-OX; Thu, 05 Jul 2007 23:03:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6e6c-0000Tg-N0 for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 23:03:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6e6c-0000QX-B8 for sip@ietf.org; Thu, 05 Jul 2007 23:03:38 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6e6T-0004ut-RM for sip@ietf.org; Thu, 05 Jul 2007 23:03:38 -0400 Received: from unknown (HELO 306181ANEX3.global.avaya.com) ([135.9.6.103]) by co300216-co-outbound.avaya.com with ESMTP; 05 Jul 2007 23:03:29 -0400 X-IronPort-AV: i="4.16,505,1175486400"; d="scan'208"; a="38518312:sNHT12906384" 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 Subject: RE: [Sip] Certificate authentication in SIP Date: Thu, 5 Jul 2007 21:02:48 -0600 Message-ID: <166476A2803C3B4994D744DFD57A942F160C13@306181ANEX3.global.avaya.com> In-Reply-To: <468DAB02.1070805@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Certificate authentication in SIP Thread-Index: Ace/dstAA/B45lzIQIeXLcR3p+de/gAArVWA References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com><46819819.5080107@cisco.com><4681DA3C.8090607@softarmor.com> <4682CBF1.9000401@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C62E9B4D@srvxchg3.cablelabs.com><468B0889.8010005@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C62E9C30@srvxchg3.cablelabs.com> <468D6AC6.80402@cisco.com> <166476A2803C3B4994D744DFD57A942F160C08@306181ANEX3.global.avaya.com> <468D9BBB.4010107@cisco.com> <166476A2803C3B4994D744DFD57A942F160C11@306181ANEX3.global.avaya.com> <468DAB02.1070805@cisco.com> From: "Rai, Anupam (Anupam)" To: "Jonathan Rosenberg" X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Steve Dotson , IETF SIP List , "DRAGE, Keith \(Keith\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Thursday, July 05, 2007 7:38 PM > To: Rai, Anupam (Anupam) > Cc: Steve Dotson; IETF SIP List; DRAGE,Keith (Keith); Dean Willis > Subject: Re: [Sip] Certificate authentication in SIP >=20 > inline: >=20 > Rai, Anupam (Anupam) wrote: > > =20 > > inline > >=20 > >> -----Original Message----- > >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >> Sent: Thursday, July 05, 2007 6:33 PM > >> To: Rai, Anupam (Anupam) > >> Cc: Steve Dotson; IETF SIP List; DRAGE,Keith (Keith); Dean Willis > >> Subject: Re: [Sip] Certificate authentication in SIP > >> > >> > >> > >> Rai, Anupam (Anupam) wrote: > >>> (1) Will the the P-A-ID syntax require modification to carry UA's=20 > >>> certificate related information (Obtained during mutual > >> TLS) from edge > >>> proxy to home proxy or registrar ? > >> Yes. You'd get nothing but the identity. Do you need more? > >> > > [Anupam Rai] > > Identity as asserted by certificate presented by UA during=20 > mutual TLS=20 > > or identity as established by edge proxy after consulting some=20 > > authentication service/database ? >=20 > As asserted by the certificate. In other words, the edge=20 > proxy would validate the client cert, extract the=20 > subjectAltName which presumably has something like=20 > joe@example.com somewhere and then shoves that into a=20 > P-Asserted-ID. Or if it matches the From it would use RFC=20 > 4474 and sign the request. [Anupam Rai] It would be nice to include some more information related to certificate presented by UA. At a minimum identity of the UA's certificate issuer is required. >=20 > -Jonathan R. >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 23:06:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6e9k-0000Y8-0B; Thu, 05 Jul 2007 23:06:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6e9i-0000Y3-0n for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 23:06:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6e9h-0000Xv-Mq for sip@ietf.org; Thu, 05 Jul 2007 23:06:49 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6e9h-00021i-GZ for sip@ietf.org; Thu, 05 Jul 2007 23:06:49 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6636BpS006200 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 5 Jul 2007 23:06:16 -0400 (EDT) In-Reply-To: References: <81A2A0E9-FDF4-48EC-92E4-C02B6BD05948@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <96FBB1C8-A367-4069-A622-29C44568C6E8@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Thu, 5 Jul 2007 23:06:09 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: sip@ietf.org Subject: [Sip] Re: Conveyance -08 and Geolocation-Error header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > New topic -- Do we want at all to try and tackle mapping of which > location goes with which error, to make sure each receiver of the > response pays attention or ignores what they are supposed to (wrt > locationValues)? > > If this is a good idea, would a header parameter sequence number > (mapped between Geolocation header and Geolocation-Error header) do > the trick? I think we'll just need to make sure the numbers don't > replicate another sequence number within the same Call-ID, and not > be universally unique through space and time. > Agreed. > This might be a little too much to take on this late (to the > deadline) or it just might be too silly of an idea *or* do you > think the host ID within the Geolocation-Error header might be > enough to cover this idea. I'm not sure what format the hostID has. If IP address, you could end up with two 192.168.0.1, from different hosts, which would be rather confusing. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 05 23:23:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ePm-0000WU-M8; Thu, 05 Jul 2007 23:23:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6ePi-0000BZ-Bt for sip-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 23:23:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ePi-0000Ar-1V; Thu, 05 Jul 2007 23:23:22 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6ePh-0003pO-Sm; Thu, 05 Jul 2007 23:23:21 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id B6BEC2ACA6; Fri, 6 Jul 2007 03:22:31 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I6eOt-00042t-GK; Thu, 05 Jul 2007 23:22:31 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 05 Jul 2007 23:22:31 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sip@ietf.org Subject: [Sip] Last Call: draft-ietf-sip-acr-code (Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)) to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The IESG has received a request from the Session Initiation Protocol WG (sip) to consider the following document: - 'Rejecting Anonymous Requests in the Session Initiation Protocol (SIP) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-07-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-acr-code-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14158&rfc_flag=0 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 06 02:22:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6hCm-0002GE-Vo; Fri, 06 Jul 2007 02:22:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6hCl-0002Fz-N3 for sip-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 02:22:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6hCl-0002Fi-50 for sip@ietf.org; Fri, 06 Jul 2007 02:22:11 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6hCk-0007fQ-Un for sip@ietf.org; Fri, 06 Jul 2007 02:22:11 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 06 Jul 2007 02:22:02 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACt8jUZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,506,1175486400"; d="scan'208"; a="125344932:sNHT29296888" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l666M2j6015479; Fri, 6 Jul 2007 02:22:02 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l666M2s0023236; Fri, 6 Jul 2007 06:22:02 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 02:22:02 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.78]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 02:22:01 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 06 Jul 2007 01:21:59 -0500 To: Henning Schulzrinne From: "James M. Polk" In-Reply-To: <96FBB1C8-A367-4069-A622-29C44568C6E8@cs.columbia.edu> References: <81A2A0E9-FDF4-48EC-92E4-C02B6BD05948@cs.columbia.edu> <96FBB1C8-A367-4069-A622-29C44568C6E8@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jul 2007 06:22:01.0716 (UTC) FILETIME=[F6EDCB40:01C7BF95] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1181; t=1183702922; x=1184566922; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20Conveyance=20-08=20and=20Geolocation-Error=20header |Sender:=20 |To:=20Henning=20Schulzrinne=20; bh=3D3iE3GZnZ9afrXDNCfQXsYLc/bpoFunNf4/vlvVkL8=; b=YkI6oQ238N+mHMImiqKJXOx3tz4SHnaugBDXobMeLylRWF2AChVsQCNiFe/nK/ZK67Edq70T q5Ky8f6Rrd5l+e71NYwgIC8auxVaqJtICgCVV9WkW73eqyHMTQlSxH0Z; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sip@ietf.org Subject: [Sip] Re: Conveyance -08 and Geolocation-Error header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 10:06 PM 7/5/2007, Henning Schulzrinne wrote: >>New topic -- Do we want at all to try and tackle mapping of which >>location goes with which error, to make sure each receiver of the >>response pays attention or ignores what they are supposed to (wrt >>locationValues)? >> >>If this is a good idea, would a header parameter sequence number >>(mapped between Geolocation header and Geolocation-Error header) do >>the trick? I think we'll just need to make sure the numbers don't >>replicate another sequence number within the same Call-ID, and not >>be universally unique through space and time. > >Agreed. > >>This might be a little too much to take on this late (to the >>deadline) or it just might be too silly of an idea *or* do you >>think the host ID within the Geolocation-Error header might be >>enough to cover this idea. > >I'm not sure what format the hostID has. If IP address, you could end >up with two 192.168.0.1, from different hosts, which would be rather >confusing. Conveyance -07 gave a Warning hostID of alice.example.com as the format. I agree this shouldn't likely ever be an IP address - due to your exact example problem. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 06 02:46:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6haV-0001ne-W5; Fri, 06 Jul 2007 02:46:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6haU-0001e4-5L for sip-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 02:46:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6haQ-0001Nl-NZ for sip@ietf.org; Fri, 06 Jul 2007 02:46:38 -0400 Received: from mvimap.mailvision.net ([212.143.248.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6haJ-0003Lw-Qg for sip@ietf.org; Fri, 06 Jul 2007 02:46:38 -0400 Received: from localhost (localhost [127.0.0.1]) by mvimap.mailvision.net (Postfix) with ESMTP id 78EE0768E65; Fri, 6 Jul 2007 08:44:29 +0300 (IDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-10 required=5 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599] Received: from mvimap.mailvision.net ([127.0.0.1]) by localhost (mvimap.mailvision.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+Ph9Z9cspBs; Fri, 6 Jul 2007 08:44:20 +0300 (IDT) Received: from diego-besprosvans-mac-mini.local (diegob.bb.netvision.net.il [212.143.127.193]) by mvimap.mailvision.net (Postfix) with ESMTP id CCA81768E63; Fri, 6 Jul 2007 08:44:18 +0300 (IDT) Message-ID: <468DE2ED.70501@mailvision.com> Date: Fri, 06 Jul 2007 09:36:29 +0300 From: Diego B User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Updated hittchhikers guide to SIP References: <468DA54C.4090909@cisco.com> In-Reply-To: <468DA54C.4090909@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi; After a brief reading I found this document very useful as a guide to the SIP maze. Just 2 typos regarding 3325 and 3323 (pages 5 and 9). They define the header P-Asserted-Identity and not P-Asserted-ID. Thank you for putting together this document Diego B Jonathan Rosenberg wrote: > I've just submitted a new version of the hitchhikers guide. You can > pick it up at: > http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers-guide-03.txt > > > The changes from -02 are: > > > * connected-identity -> RFC4916 > * added record-route-fix and grouped it with fork-loop-fix into a new > item under SIP core called "essential corrections" > * added subnot-etags under event packages > * added sip-sips to core specs > > Thanks, > Jonathan R. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 06 05:20:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6jzE-0005ya-HX; Fri, 06 Jul 2007 05:20:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6jzD-0005yQ-6B for sip-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 05:20:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6jzC-0005yI-Sr for sip@ietf.org; Fri, 06 Jul 2007 05:20:22 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I6jz8-0004lR-F7 for sip@ietf.org; Fri, 06 Jul 2007 05:20:22 -0400 Received: (qmail invoked by alias); 06 Jul 2007 09:20:17 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp015) with SMTP; 06 Jul 2007 11:20:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/V6GNvJDrV5DGE8EhWAod2F+sQDTKhwKsmk9ew/Z 3FHyNwIQVIcBGB Message-ID: <468E0950.9020000@gmx.net> Date: Fri, 06 Jul 2007 11:20:16 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Updated hittchhikers guide to SIP References: <468DA54C.4090909@cisco.com> <468DE2ED.70501@mailvision.com> In-Reply-To: <468DE2ED.70501@mailvision.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jonathan, A comment on the emergency services. The text does not address any of the citizen-to-authority emergency work. Hence, the term "emergency services and the mentioning of 911 might be a bit misleading You might want to change the section heading to something like "Preemption and Precedence". Ciao Hannes _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 06 05:23:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6k2a-0000GL-SZ; Fri, 06 Jul 2007 05:23:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6k2Y-0008Ok-So for sip-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 05:23:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6k2Y-0008MM-H9 for sip@ietf.org; Fri, 06 Jul 2007 05:23:50 -0400 Received: from [63.110.43.12] (helo=mail.covergence.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6k2U-0005CP-4q for sip@ietf.org; Fri, 06 Jul 2007 05:23:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Jul 2007 05:23:45 -0400 Message-ID: <0D1719326D64BD4E9F92A0C12023767802395B75@eserv.covergence.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Index: Ace/r1n3xOKnnSDuTSuCYLZPDQGSSQ== From: "David Wray" To: X-Spam-Score: 1.8 (+) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Subject: [Sip] (no subject) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1359228144==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1359228144== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C7BFAF.5A1A6E5F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7BFAF.5A1A6E5F Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7BFAF.5A1A6E5F" ------_=_NextPart_002_01C7BFAF.5A1A6E5F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable unsubscribe =20 David Wray Project Engineer, EMEA =20 Tel:+44 (0)7866 479935 Email: dwray@covergence.com =20 ******Covergence, Inc. Confidential and Proprietary******* Notice: The information in this message and any attachments is intended only for the designated recipients or their authorized delegates and contains confidential and/or proprietary information. Disclosure, use, or copying of the information contained in this message or attachments by anyone other than the designated recipients or delegates is strictly prohibited. If you have received this message in error, please destroy it and notify the sender by e-mail or by calling 978-823-5242. =20 =20 ------_=_NextPart_002_01C7BFAF.5A1A6E5F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

unsubscribe

 

David = Wray

Project = Engineer, EMEA

 

Tel:+44 (0)7866 479935

Email: dwray@covergence.com

******Covergence, = Inc. Confidential and Proprietary*******

Notice: The = information in this message and any attachments is intended only for the designated = recipients or their authorized delegates and contains confidential and/or proprietary information.  Disclosure, use, or copying of the information = contained in this message or attachments by anyone other than the designated = recipients or delegates is strictly prohibited. If you have received this message in = error, please destroy it and notify the sender by e-mail or by calling 978-823-5242. 

 

------_=_NextPart_002_01C7BFAF.5A1A6E5F-- ------_=_NextPart_001_01C7BFAF.5A1A6E5F Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODdhqgAzAHcAACH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACwAAAAAqgAzAIUQCAgQ CCkQKRAQKSkpKTExKVoxShkxQlIxa0oxa2tSSlpaa2N7a2Nja5xjjFqEa5yEhIyEjKWEpYytnIyl nK29vb2lvbWtxZSt5rXOxb3e1t7Fxebe5t7mCAjmECnmQkrma2vmnAjmnCnmlGvmlIzmnK3mvSnm vUrvvbXmxQj3xXv/1ub35oT35rX//+bm7+////8BAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB AgMBAgMBAgMBAgMBAgMBAgMG/0CYcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6 zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFhoeIiYqLjI2OUCsfkiiPlUYuHx0eLpadQyUdIJ6VLi0t MCseKzCmnFUUBxCjYhoSDBAZRC8SEAwVQi0iIqckLi4iIacwFb0QGkMaFDAWuDAvFLcRCL5CHBS9 0kMSGi8QCxQvRMzn6UMZEbe5lRUEBwsHBL/L9QsKAwwwjoVgMURFiBOcIBBIwEBBPiESYtX75XDB gnru8FkksECIBo4K7BFQ0I7BAAUXSQqhcNLigHCNXBw40C7kC5kHnsGQ8BIGi/8QIlwZVAGDAgFZ Qi4+m1AP3U4CFoTQk/bCppAMR2FowCdhJQFpRrtqJQAww78hCuW1udnFqL5lCjhUCPAWxgEFrEKY OOUiRDIYIYloGBCVJVLAB4a44Lis55B+MDiQHcLBQNd7rmA4aADjXjtrWQXDyKDTSYXSn4e8qAuN AoWopy24Zg0FwoDSAWFAEICbAYF0J0IQbXHQ2t1bC8ydnTBArUKdH2UpTM4gOT5yB8RaUxABMF4i nEIiV94R2oINFSSc1moBd4UK6TIwy7B6grT37V6Q02BBrQT6FbgwDgUccHCYFApxYIRvuN3zjEEI jTCQVgYo4IA5EGQIFgEKelT/oWsI5KQbR+bAk2GBX0FzwAQvhKbLAQY8cOEtEMAU2QQcvJPBOM5A 0GEFFACZAQUaOBNkf0BWMIFHRDKwAYFXRTDBMxFoMGV6VdiG2i88NfhbQMi0YMJfLxRQnhFGlZbB XQigJI8EBOCmWopCtNhdm4Jt4B0T9+XimnpTQnTka0VlYIFsG0gQpFP8ReMCkXWuVuWUijpFRQUv uZImpt15NFlAJwhTXFI0mcfll0Io8F0RmB6YIYUwcbBiZyKmuoALWqp2ji7ovLfTkPy1QwGOFQxp YDTqPRqbRxcMudMzj5LjI5EUZEaFCw71ylhnX+m3wG1DEJeCCARJNRJ9a8ZZ65S6EHHEi2vyfEtg OQPI0iJMLxggC1YL0LebNB8dAJ8GDrG2owbP/JIkEbLlkl576rnmzTh1brDaaNAp6vALallRVT0c taPBRQbU0/ExIphgLSwgL6CTUR0+pSqMBKT4gkn4GNDpVtqVGY5RIGtXgT/4IEBbFcpieYkaGFBA XxFDwndJC9Z2U0F/n+k3xAZ0vuC1Z0yuJ4QL5AgW82oW6KnLkE9zoZ+cswhhAQBREYEZFlXHvcYL Fy3AADzZ6r0IBRZZFEHHgieu+OKMN+7445BHLvnklFdu+eWYZ6755px3XkVqnocu+uhIBAEAOw== ------_=_NextPart_001_01C7BFAF.5A1A6E5F-- --===============1359228144== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1359228144==-- From sip-bounces@ietf.org Fri Jul 06 06:09:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6kkH-0005Av-4p; Fri, 06 Jul 2007 06:09:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6kkF-0005Aq-Cm for sip-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 06:08:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6kkF-0005Ad-2Z for sip@ietf.org; Fri, 06 Jul 2007 06:08:59 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6kkB-00010B-Jh for sip@ietf.org; Fri, 06 Jul 2007 06:08:59 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l66A8m1J002727 for ; Fri, 6 Jul 2007 05:08:53 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 05:08:02 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 12:07:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-consent-framework-02.txt Date: Fri, 6 Jul 2007 12:07:56 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180013B6987@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-consent-framework-02.txt Thread-Index: Ace/SbZkAr5IUrF/QcO+BXadu1m9bgAa3KXw References: From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 06 Jul 2007 10:07:58.0946 (UTC) FILETIME=[87AAEC20:01C7BFB5] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair)=20 I am in the process of preparing the publication request on this document to IESG, and this revision is to address various issues (none of them particularly technical) identified during that process. If you identify any issues with this document a comment within the next couple of days will possibly receive attention (before the document deadline) else it may have to wait for the IESG last call to be handled. Regards Keith > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Thursday, July 05, 2007 10:15 PM > To: i-d-announce@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-consent-framework-02.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol=20 > Working Group of the IETF. >=20 > Title : A Framework for Consent-Based=20 > Communications in the Session Initiation Protocol (SIP) > Author(s) : J. Rosenberg, et al. > Filename : draft-ietf-sip-consent-framework-02.txt > Pages : 29 > Date : 2007-7-5 > =09 > The Session Initiation Protocol (SIP) supports communications across > many media types, including real-time audio, video, text, instant > messaging, and presence. In its current form, it allows session > invitations, instant messages, and other requests to be delivered > from one party to another without requiring explicit consent of the > recipient. Without such consent, it is possible for SIP to be used > for malicious purposes, including amplification, and DoS (Denial of > Service) attacks. This document identifies a framework=20 > for consent- > based communications in SIP. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-consent-fra > mework-02.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then=20 > "get draft-ietf-sip-consent-framework-02.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-consent-framework-02.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 06 11:41:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6pw3-0007yD-5L; Fri, 06 Jul 2007 11:41:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6pw0-0007qC-Tf for sip-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 11:41:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6pw0-0007mk-Gw for sip@ietf.org; Fri, 06 Jul 2007 11:41:28 -0400 Received: from alnrmhc15.comcast.net ([204.127.225.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6pvw-0003yk-75 for sip@ietf.org; Fri, 06 Jul 2007 11:41:28 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc15) with ESMTP id <20070706154123b1500ce29ce>; Fri, 6 Jul 2007 15:41:23 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l66FfM8t006895 for ; Fri, 6 Jul 2007 11:41:22 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l66FfMcJ006891; Fri, 6 Jul 2007 11:41:22 -0400 Date: Fri, 6 Jul 2007 11:41:22 -0400 Message-Id: <200707061541.l66FfMcJ006891@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net X-Spam-Score: 0.2 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [Sip] Notes on draft-camarillo-sip-body-handling-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Technical: - Related to Open Issue 3, there is also the question of what the Content-Disposition of a response body is. For SDP answers, "session" makes sense, but the body may contain control information that doesn't fall under "session" or "render" cleanly. - Section 4.1: "If the handling of a 'multipart/alternative' body is required, the UA MUST set the 'handling' parameter of the 'multipart/alternative' body and to the last body part within the 'multipart/alternative' to 'required'." Is there a typo here? The whole point of multipart/alternative is that one need only understand one component, and tagging the last component 'required' contradicts this. It would seem that even if the whole body was "required", any individual component would be "optional". (Though of course, the reader is obliged to understand at least one component.) Indeed, the handling of any component of a multipart/alternative is implied by its membership in the multipart/alternative and need not be stated. - In regard to error reporting, perhaps we should use the Warning header and describe the problem in natural language, rather than trying to provide errors that can be processed automatically. - In regard to other multipart types: This specification recommends support for 'multipart/mixed' and 'multipart/alternative'. At present, there are no SIP extensions that use different 'multipart' subtypes such as parallel [RFC2046], digest [RFC2046], or related [RFC2387]. If such extensions were to be defined in the future, their authors would need to make sure (e.g., by using an option-tag or by other means) that entities receiving those 'multipart' subtypes were able to process them. As stated earlier, UAs treat unknown 'multipart' subtypes as 'multipart/ mixed'. Since there is a standard fallback, an extension does not need to provide an option-tag as long as it is willing to have its multipart type processed as multipart/mixed. So it would be more accurate to say "If such extensions were to be defined in the future, their authors might need to provide UAs a way (e.g., by using an option-tag) to make sure that entities receiving those 'multipart' subtypes were able to process them as such." Editorial: - There is a tendency of the terminology to overlook the fact that all SIP bodies are MIME bodies, and to use "MIME body" as synonymous with "MIME multipart body". E.g., in section 1, "Multipart message bodies are encoded using the MIME (Multipurpose Internet Mail Extensions) [RFC2045] format." is literally correct but suggests that non-multipart message bodies somehow aren't encoded using MIME. In reality, Content-Type is a MIME header, etc. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 06 14:28:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6sXV-0000mU-5r; Fri, 06 Jul 2007 14:28:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6sXT-0000mI-7h for sip-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 14:28:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6sXS-0000mA-Ov for sip@ietf.org; Fri, 06 Jul 2007 14:28:18 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6sXN-0003cT-KK for sip@ietf.org; Fri, 06 Jul 2007 14:28:18 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 06 Jul 2007 14:28:13 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwPAMsmjkZAZnme/2dsb2JhbACIVqFW X-IronPort-AV: i="4.16,509,1175486400"; d="scan'208"; a="64520245:sNHT30074890" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l66ISDsI007477; Fri, 6 Jul 2007 14:28:13 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l66IRt6w004470; Fri, 6 Jul 2007 18:28:13 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 14:27:39 -0400 Received: from [10.86.240.180] ([10.86.240.180]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 14:27:39 -0400 Message-ID: <468E899A.7070806@cisco.com> Date: Fri, 06 Jul 2007 14:27:38 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Sip] Re: Conveyance -08 and Geolocation-Error header References: <81A2A0E9-FDF4-48EC-92E4-C02B6BD05948@cs.columbia.edu> In-Reply-To: <81A2A0E9-FDF4-48EC-92E4-C02B6BD05948@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2007 18:27:39.0286 (UTC) FILETIME=[5557C360:01C7BFFB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4061; t=1183746493; x=1184610493; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20Re=3A=20Conveyance=20-08=20and=20Geolocation- Error=20header |Sender:=20 |To:=20Henning=20Schulzrinne=20; bh=M040ULh6m+rl6Z6gBYhwUd+FMVpIznuH7G3uyZOzpDI=; b=KlgCYkYYjlbbh7GUPeHDTcWV6LTIQkw37pxI0ncMl9tNQPznO3oLJ2ra1qKTvqmIGhyTkDie ZYyeLsd63jk6KHsHqUUOYJJ9KbNYGVw98kbIXM2eUdONd/1uWt9y830y; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sip@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hmm. I've been behind on reading. I was having a side conversation with James on this, and it looks like some of that would be worth sharing here. James was asking me for ideas of how to handle this "identifier". The following is what I last sent to James: Paul Kyzivat wrote: > What do you expect will happen as a result of identifying the source of the error? > > Do you expect that the source will itself recognize that it has made a mistake and do something about it? Or do you expect some other element to keep notes on which nodes do a bad job of supplying addresses? > > Also, do you expect the node that inserts the address to remember what address it inserted when it gets the error response? Or some other node other than the one that inserted it to remember it? > > The answer to these questions impacts the kind of solution that is appropriate. > > If the UAS is the one to detect the problem, and also the one to log the problem for future use, then it must be possible to actually determine the address of the source of the address. An index into the Via list might be adequate for that. Or, the "inserted-by" could be changed to actually include the address of the node doing the insertion. > > If the node doing the insertion is responsible for tracking its own failures, then its probably bad to assume that it will remember what it inserted. So the actual offending address should probably be included in the error response. In that case, there is probably something in that address that will allow the offender to recognize that it was the source of the problem. > > If some other node (other than the UAS and the offending node) is responsible for logging the problem, then it will certainly want the offending address as well. So again it should be included in the response. And again, there probably isn't need of anything else. > > At least that's my take based on what little info I have. Paul Henning Schulzrinne wrote: > James, > > I think your #1 and #2 covers it, in addition to an identifier that > points to the location element that suffers from the problem identified. > (The latter was discussed, if I recall correctly, but seems to be > missing from your syntax proposal.) > > I don't feel strongly about identifying the originator of the error, but > it might be useful to have an extensible parameter list, in standard SIP > header fashion, so that we can easily add more debugging information later. > > Henning > > On Jul 5, 2007, at 8:22 PM, James M. Polk wrote: > >> Henning >> >> Regarding Conveyance -08 and the new Geolocation-Error header that you >> want to replace the Warning header code(s) function (section 3.4 of >> the -07 ID)... >> >> What fields do you want in the header? >> >> #1 error-code, >> #2 text-string explaining what error it is >> #? >> >> Do you need anything else? >> >> Warning had/has the node ID of the sending entity. Do you want that in >> the new Geolocation-Error header? Do you really see a purpose in >> having that piece there? >> >> Attempting to put the final pieces of -08 together, and this new >> header is less than straightforward in writing it. >> >> Is this viable ABNF for what you want? >> >> Geolocation-Error = "Geolocation-Error" HCOLON (locationErrorValue >> *(COMMA locationErrorValue)) >> locationErrorValue = numeric-code *(SEMI geoloc-error-param) >> numeric-code = decimal-string >> geoloc-error-param = "code" EQUAL error-text-string >> / generic-param ; (from RFC 3261) >> error-text-string = string >> >> (anyone) let me know what you think >> >> Thanks >> James > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 06 14:41:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6sk0-0007m4-SX; Fri, 06 Jul 2007 14:41:16 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6sjy-0007lU-Vf for sip-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 14:41:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6sjy-0007lL-JR for sip@ietf.org; Fri, 06 Jul 2007 14:41:14 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6sjy-0007io-8G for sip@ietf.org; Fri, 06 Jul 2007 14:41:14 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 06 Jul 2007 11:41:05 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAF4pjkarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,509,1175497200"; d="scan'208"; a="6438900:sNHT15022488" 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 l66If2SG008720; Fri, 6 Jul 2007 11:41:02 -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.12.10/8.12.6) with ESMTP id l66If2ka003099; Fri, 6 Jul 2007 18:41:02 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); Fri, 6 Jul 2007 11:41:02 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 11:41:01 -0700 Message-ID: <468E8CC1.70909@cisco.com> Date: Fri, 06 Jul 2007 14:41:05 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Diego B Subject: Re: [Sip] Updated hittchhikers guide to SIP References: <468DA54C.4090909@cisco.com> <468DE2ED.70501@mailvision.com> In-Reply-To: <468DE2ED.70501@mailvision.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2007 18:41:02.0017 (UTC) FILETIME=[33CECB10:01C7BFFD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1204; t=1183747265; x=1184611265; 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=20[Sip]=20Updated=20hittchhikers=20guide=20to=20SIP |Sender:=20; bh=sOwarwo5OyoJY/LBmvpK0v6vzSs/D/3Tx6+SqijNq3I=; b=gNW9Nxj4LXTOEd1nAx0El58UJPsaxnyLT3qCmYAnjB54Chg5sELpDuyjHCPF0ZM1TPn9Kd9v nD9ty0A38eCsDI2X9aZiehKqsudA2Nw1YxwY1gM1oC6VZVgwbY7i3Vn2; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Fixed. Thanks! -Jonathan R. Diego B wrote: > Hi; > After a brief reading I found this document very useful as a guide to > the SIP maze. > > Just 2 typos regarding 3325 and 3323 (pages 5 and 9). They define the > header P-Asserted-Identity and not P-Asserted-ID. > > Thank you for putting together this document > > Diego B > > Jonathan Rosenberg wrote: >> I've just submitted a new version of the hitchhikers guide. You can >> pick it up at: >> http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers-guide-03.txt >> >> >> The changes from -02 are: >> >> >> * connected-identity -> RFC4916 >> * added record-route-fix and grouped it with fork-loop-fix into a new >> item under SIP core called "essential corrections" >> * added subnot-etags under event packages >> * added sip-sips to core specs >> >> Thanks, >> Jonathan R. > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 06 14:52:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6sun-0005VD-A1; Fri, 06 Jul 2007 14:52:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6sul-0005Hs-JZ for sip-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 14:52:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6sul-0005Ai-0e for sip@ietf.org; Fri, 06 Jul 2007 14:52:23 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6sug-00062b-N6 for sip@ietf.org; Fri, 06 Jul 2007 14:52:22 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 06 Jul 2007 14:52:19 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwPALcrjkZAZnme/2dsb2JhbACIVqF/ X-IronPort-AV: i="4.16,509,1175486400"; d="scan'208"; a="125400102:sNHT27554326" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l66IqIkL023917; Fri, 6 Jul 2007 14:52:18 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l66Iq4sC018261; Fri, 6 Jul 2007 18:52:18 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 14:52:11 -0400 Received: from [10.86.240.180] ([10.86.240.180]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 14:52:11 -0400 Message-ID: <468E8F5A.5070902@cisco.com> Date: Fri, 06 Jul 2007 14:52:10 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] Notes on draft-camarillo-sip-body-handling-01 References: <200707061541.l66FfMcJ006891@dragon.ariadne.com> In-Reply-To: <200707061541.l66FfMcJ006891@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2007 18:52:11.0194 (UTC) FILETIME=[C2AB19A0:01C7BFFE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1661; t=1183747938; x=1184611938; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20Notes=20on=20draft-camarillo-sip-body-handlin g-01 |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=kFuDIQB8gvbDPtsLyu5RBXiRDNmKl2AZvlQgIxaJ4cg=; b=o9Y74bj5PRRfuQXCMm7SnTvLD/nLDkMa4EjmNYZjDXvrnWoauL7Hy7RsVuhLAzFLmM2Ifvwb btzk5HV458x8d7c+u5HYfbtKmOLKtWQK2eTUz8wAy4qdUew2Yy6qfWBx; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dale.Worley@comcast.net wrote: > - Section 4.1: "If the handling of a 'multipart/alternative' body is > required, the UA MUST set the 'handling' parameter of the > 'multipart/alternative' body and to the last body part within the > 'multipart/alternative' to 'required'." The general recommendation for processing multipart/alternative is to process the *last* part that you are capable of understanding. Thus the least capable recipient will be processing the first and ignoring the rest. > Is there a typo here? The whole point of multipart/alternative is > that one need only understand one component, and tagging the last > component 'required' contradicts this. > > It would seem that even if the whole body was "required", any > individual component would be "optional". (Though of course, the > reader is obliged to understand at least one component.) Indeed, the > handling of any component of a multipart/alternative is implied by its > membership in the multipart/alternative and need not be stated. I think clearly the goal is that if handling of the multipart/alternative itself is "required", then *one* of the alternatives is to be understood and processed, but no particular one is required. If handling for the multipart is "optional" then either one of the parts may be processed, or none. The question is: what is the way to express that? I think I'm with Dale, that the handling parameter on the multipart/alternative specifies the intent, that all the contained parts should be optional, and the semantics of processing the alternative implies that one of the parts will be. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 06 15:25:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6tQT-0006DW-D1; Fri, 06 Jul 2007 15:25:09 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6tQR-0006Cd-6U for sip-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 15:25:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6tQQ-0006CL-QP for sip@ietf.org; Fri, 06 Jul 2007 15:25:06 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6tQQ-0005wR-Jw for sip@ietf.org; Fri, 06 Jul 2007 15:25:06 -0400 Received: from [10.31.13.240] (stdhcp-240.va.neustar.com [10.31.13.240]) by ns3.neustar.com (Postfix) with ESMTP id AE189175E0; Fri, 6 Jul 2007 19:25:05 +0000 (GMT) Message-ID: <468E971E.1090804@neustar.biz> Date: Fri, 06 Jul 2007 12:25:18 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Marcos Dytz , SIP IETF Subject: Re: [Sip] SIP Saml Review by Marcos Dytz and Sebastian Felis References: <0D22E3C1A7D7A843B12BF8C6F0A40758021496CA@MCHP7IDA.ww002.siemens.net> <468C366E.1000004@neustar.biz> <509b63310707042124s7a98bf64k35f4661205558280@mail.gmail.com> In-Reply-To: <509b63310707042124s7a98bf64k35f4661205558280@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Sebastian Felis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Marcos Dytz wrote: > > I agree on the limitations described below by Jeff. My concern was with > the emphasis on authentication throughout the draft, but I had in mind > that it was actually targeting that particular point (in the same way > that sip-paying targets payment). Ok. > Nevertheless, are there ideas to develop new drafts on further cases for > SIP/SAML? Yes. Hannes has a few "in the queue". > In my personal opinion, the protocol offers many technical which protocol? > advantages (and flexibilities) that could be required for more general > use cases. > By adopting and developing new cases, the overall protocol > would only be gaining a larger market share and could very well adopt > some synergy among the different areas. here, by "..the overall protocol..", you mean "SIP+SAML"? > As for Sebastian, I have the impression that he would like to see more > integration and deployment details. I had problems to fulfill the gaps > on integration while working on my thesis (e.g., enveloping SAML > assertions in SIP message - usually workflows target the transaction > state and avoid mentioning how to converge that with SIP - I did my > implementation in the way I thought best, but every developer is free to > choose different formats if specification does not define these little > details). But you weren't implementing what is specified in draft-ietf-sip-saml-02 were you? Do you have pointers to any documentation or papers about your work? Or the code? :) > As for your final points, agree to limitations due to complexity and > partial fulfilment of RFC4484. If further work is to be applied on the > draft, I believe the best action would be to leave the draft as it is > and start another work from scratch. Ok, fine by me. thanks again for your feedback, =JeffH _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 06 16:19:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6uGy-0003YM-2s; Fri, 06 Jul 2007 16:19:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6uGx-0003Um-9U for sip-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 16:19:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6uGw-0003Tm-Ub for sip@ietf.org; Fri, 06 Jul 2007 16:19:22 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6uGw-0001eX-Kx for sip@ietf.org; Fri, 06 Jul 2007 16:19:22 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 06 Jul 2007 13:19:22 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAFZAjkarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,509,1175497200"; d="scan'208"; a="177838740:sNHT30564297" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l66KJLEZ005069 for ; Fri, 6 Jul 2007 13:19:21 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l66KJLXH018703 for ; Fri, 6 Jul 2007 20:19:21 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); Fri, 6 Jul 2007 13:19:21 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 13:19:21 -0700 Message-ID: <468EA3CD.9060208@cisco.com> Date: Fri, 06 Jul 2007 16:19:25 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2007 20:19:21.0721 (UTC) FILETIME=[F04E2E90:01C7C00A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1629; t=1183753162; x=1184617162; 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:=20ICE=20tutorial=20in=20Chicago=20[DO=20NOT=20REPLY] |Sender:=20; bh=/a2gGbj9z3uAeaOyVraQo7NcVcWVa35n/rdAvyWYEgQ=; b=N4H1HEjsP2uL1w5QG0OFh1nSlvmNjpXF/aV9CFLSlg2QviJDyN4J0weoGfsIJH4LzXNSvwKH +BQgMHOuAJpUfgnxygLLZAZVJHTq0SbjunKGjsHsqiq5PPMX2rmvubHu; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Sip] ICE tutorial in Chicago [DO NOT REPLY] X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-16.txt) [-17 should be available shortly] WHEN: Tuesday, July 24, 2007, 1145-1245 (lunch logistics are in progress and will be announced ASAP) WHERE: Red Lacquar WHO: Anyone that would like to learn more about ICE. WHY: ICE, developed by the mmusic working group, has been defined as the IETF tool for NAT traversal for SIP-based media. It is also seeing increased usage for traversal for other kinds of application traffic - anything worrying about any-to-any communications. In this tutorial, we will overview the background of the problem, consider the requirements driving ICE, and provide an overview of how ICE works. An understanding of SIP is not required. The tutorial will be based on the pending -17 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice) so I can get a count of the number of participants for lunch purposes. !DO NOT REPLY TO THIS NOTE! -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 06 19:13:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6wys-0007Ml-Tw; Fri, 06 Jul 2007 19:12:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6wyr-0007CT-GJ for sip-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 19:12:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6wyr-00079D-2L for sip@ietf.org; Fri, 06 Jul 2007 19:12:53 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6wyq-0003Yk-KP for sip@ietf.org; Fri, 06 Jul 2007 19:12:52 -0400 Received: from [10.31.13.240] (stdhcp-240.va.neustar.com [10.31.13.240]) by ns4.neustar.com (Postfix) with ESMTP id ED8EB2ACB9 for ; Fri, 6 Jul 2007 23:12:31 +0000 (GMT) Message-ID: <468ECC6E.5050504@neustar.biz> Date: Fri, 06 Jul 2007 16:12:46 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: IETF SIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Subject: [Sip] wrt SIP Saml Review by Jiri Kuthan - "missing scenarios" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jiri Kuthan wrote: > I'm personally missing scenarios which > > - use redirection as opposed to proxy mode. IMO, it is beneficial to have > the AS operated in 3xx mode for better scalability. Perhaps you could explain a bit more what you mean here because it isn't all that clear what the differences would be. In poking around thru, say, RFC3665 section "3.6. Session via Redirect and Proxy Servers with SDP in ACK", it isn't clear to me that there is necessarily a salient difference between it's scenario and the one depicted in draft-ietf-sip-saml-02 fig 1. Here's RFC3665 Session via Redirect and Proxy Servers.. Alice Redirect Server Proxy 3 Bob | | | | | INVITE F1 | | | |--------------->| | | | 302 F2 | | | |<---------------| | | | ACK F3 | | | |--------------->| | | | INVITE F4 | | |-------------------------------->| INVITE F5 | | 100 F6 |--------------->| |<--------------------------------| 180 F7 | | 180 F8 |<---------------| |<--------------------------------| | | | 200 F9 | | 200 F10 |<---------------| |<--------------------------------| | | ACK F11 | | |-------------------------------->| ACK F12 | | |--------------->| | Both Way RTP Media | |<================================================>| | | BYE F13 | | BYE F14 |<---------------| |<--------------------------------| | | 200 F15 | | |-------------------------------->| 200 F16 | | |--------------->| | | | ..and here's -sip-saml-02 fig 1.. +--------+ +--------------+ +--------+ |Alice@ | |Authentication| | Bob@ | |example | |Service | |example2| |.com | |@example.com | |.com | +---+----+ +------+-------+ +---+----+ | | | | INVITE | | |---------------------->| | | From:alice@foo.com | | | | | | 407 Proxy auth. req. | | |<----------------------| | | Challenge | | | | | | ACK | | |---------------------->| | | | | | INVITE w/authn creds | | |---------------------->| | | | INVITE | | | w/Identity header | | |--------------------->| | | and Identity-Info | | | | | | HTTP GET SAML assn | | |<==================== | | | and domain cert | | | | | | HTTP 200 OK + assn | | |=====================>| | | and domain cert | | 200 OK | | |<----------------------+----------------------| | | | ..so it seems that given the way in which RFC4474 works, either of the Redirect server or Proxy 3 in the former figure could instigate authn of the user/UAC, whereupon things would proceed more-or-less as depicted in the latter. yes/no? > - use SAML-by-value, in addition to SAML-by-reference. I personally find > the SAML-by-reference quite non-real-time and harder-to-scale too. Yes, this is not-yet-well-resolved piece of the architecture. Given present restrictions wrt SIP intermediaries only being able to add SIP headers to a SIP request message -- it offhand would have to be the UAC that embeds a SAML assertion into a SIP request it is originating. We (SIP WG) should perhaps think about this and whether we think it is a practical use case that would indeed see some use. Below is one example of such an approach (there's various ways to approach its details). Is this an approach we should pursue in addition to the one presently spec'd in -sip-saml-2 ? > Perhaps there are arguments why proxy+by/reference is the best thing, but > if that's the case I think they should be mentioned in the document. Yes, ok. Part of the rationale was that this sort of approach will work with present-day unmodified UACs, and all of the workable "include-SAML-assertion-by-value" approaches that we could think of involved UAC enhancements to support the new funtionality (this of course skirts the controversial sip-proxy-placing-BLOB-values-in-SIP-header approach, e.g. using a data: URL). So we felt that specifying the draft narrowly, and focusing on enhancements to proxy-tier functionality was the way to go for now. thoughts? HTH, =JeffH ------- Fig 4: "caller-driven, authn+attr, SAML Assertion embedded in INVITE" Caller explicitly executes protocol, i.e. "caller-driven" in that caller stipulates at least some of info that is to be embodied in resulting assertion. Caller places SAML Assertion in INVITE msg body; Assertion has an and optionally a . Callee obtains SAML Assertion directly from INVITE message. protocol message count (only include msgs w/CSeq=N+1): Caller-to-AS: 3 AS-to-callee: 1 Protocols employed: SIP and SAML (via HTTP/SOAP) NOTE: The interaction between caller and the AS is in the style of the "SAML Token Service", which is specified in draft form in section "3.3 SAML Token Service Profile" of [9]. Caller and AS must speak at least one flavor of SAML protocol. Relying party needs only to be capable of understanding SAML assertion. Does not need to employ any SAML protocols. [9] SAML 2.0 Single Sign-On with Constrained Delegation (and SAML Token Service Proposal (Shib design note)) http://shibboleth.internet2.edu/docs/draft-cantor-saml-sso-delegation-01.pdf Callee's UA or Caller's Domain's Callee's Domain's Caller AS & SIP Proxy SIP Proxy +--------+ +--------------+ +--------+ |Alice@ | |Authentication| | Bob@ | |example | |Service | |example2| |.com | |@example.com | |com | | | | (AS) | | | +---+----+ +------+-------+ +---+----+ - - | | | ^ ^ | INVITE | | | | |---------------------->| | | | From:alice@foo.com | | | C | To:sip:bob@example.com| | | S | | | | e | 407 Proxy auth. req. | | | q |<----------------------| | | | Challenge | | | = | | | | | | | | N | | | | | | | | | | ACK | | | V |---------------------->| | | - | | | | | | | | | [Alice marshalls | | | | authn credentials | | | | in resp to challenge]| | | | | | | | | | | - |Request Authn+Attr Assn| | | ^ |via Authn Request Prot | | | . |======================>| | | . | | | | . | | | | . | bob@example2.com | [AS is configured | | . | | OOB to "know" which | | . | Assn returned | "profile attributes"| | . |<======================| to return in Assns. | | . | | Relying party meta- | | . | | data could be also | | . | | employed. Or SAML | | . | | request protocol | | . | Alice@example.com| extension could be | | . | used.] | | . | | | | . | foo=bar | | | . | | | . | | | D . | | | . | INVITE + authorization| | I | | header w/marshalled creds | | |---------------------->| | A | | From:alice@foo.com | | | | To:sip:bob@example.com| | L | | | | | | | | O | | | | | | Alice@example.com| | G | | | | | | | | | | foo=bar | | | | | | | | | | | | | | | | | | | |INVITE + authorization| | C | |header w/marshalled creds | S | |--------------------->| | e | | From:alice@foo.com | [this would | q | | To:sip:bob@example.com thus convey an | | | | "unsolicited | = | | | response" as | | | discussed in | | Alice@example.com [5] & [3]. ] | | | | | | N | | foo=bar | | | | | | + | | | | | | | | 1 | | | | | | | | | | | | | | | 200 OK | | . V |<----------------------+----------------------| . - | | | . . V ------- end _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 06 20:27:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6y8C-0004u5-8i; Fri, 06 Jul 2007 20:26:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6y8A-0004ts-SG for sip-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 20:26:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6y8A-0004tk-Gy for sip@ietf.org; Fri, 06 Jul 2007 20:26:34 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6y7v-00024Z-7A for sip@ietf.org; Fri, 06 Jul 2007 20:26:34 -0400 Received: from [10.31.13.240] (stdhcp-240.va.neustar.com [10.31.13.240]) by ns3.neustar.com (Postfix) with ESMTP id 8F3DE175D0 for ; Sat, 7 Jul 2007 00:25:48 +0000 (GMT) Message-ID: <468EDD9A.9080403@neustar.biz> Date: Fri, 06 Jul 2007 17:26:02 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: IETF SIP List Subject: Re: [Sip] SIP SAML Review by Richard Barnes - security/privacy considerations References: <4679F41A.4020805@bbn.com> In-Reply-To: <4679F41A.4020805@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Richard Barnes wrote: > > 1. It's never made clear what entity is the Subject of the conveyed > assertions. This could be a critical distinction, e.g., if one party > assumes that it's the UAC being discussed, and the other the user of the > UAC. section "6.1.4.1.2. Element: " stipulates.. The element SHOULD contain both a element and a element. The value of the element MUST be the same as the Address of Record (AoR) value used in computing the "signed-identity-digest" which forms the value of the Identity header. See Section 9 of [RFC4474]. So, whatever is (currently) being stuffed into AoRs also goes into the Subject/NameID element. Does that answer this? > 2. Section 9 needs a discussion the nature of the assurances provided by > SAML assertions. Yes, though more specifically, the nature of the assurances provided by a SAML assertion constructed, and referenced by a SIP request, as specified in this spec. > In general, in order for it to be verifiable that the > SAML assertion was issued by the Authentication Service, there must be > proof that the holder of the private key used to create the > Identity-Info header. Agreed, though this is in the spec. >There are several ways to do this: > 2.a. The SAML assertion is signed with the appropriate private key This is specified in section "6.1.4. Assertion Profile Description/Overall SAML assertion profile requirements:"... The SAML assertion MUST be signed by the same key as used to sign the contents of the Identity header field. Signing of SAML assertions is defined in Section 5.4 of [OASIS.saml-core-2.0-os]. > 2.c. The Identity-Info is integrity-protected from the point where it is > added by the Authentication Service until it reaches the UAS. This is a basic feature of rfc4474. > 3. The list of threats and countermeasures in Section 9 is incomplete. > For instance: > 3.a. There's no discussion of threats of attacks by elements of the SIP > signaling path (e.g., manipulating the URI in the Identity-Info header) > 3.b. The anti-replay mechanism should reference the expiry elements > built into the assertion (e.g., the NotOnOrAfter attribute) yes, ok. > 4. The document isn't clear on whether or not the assertions MUST be > signed by the issuer. This is specified in section "6.1.4. Assertion Profile Description/Overall SAML assertion profile requirements:"... The SAML assertion MUST be signed by the same key as used to sign the contents of the Identity header field. Signing of SAML assertions is defined in Section 5.4 of [OASIS.saml-core-2.0-os]. ..tho perhaps we should clarify that the wielder of this key is "the issuer". > Section 6.1.5, step 3 seems to imply that the > assertion will be signed, but Section 9.3 seems to assume that this > isn't necessarily the case. hm, I don't see that. RFC4474 goes into gory detail wrt the signing of the identity headers and I didn't want to replicate it here. Plus as noted above, the -sip-saml-02 says assn MUST be signed (with same key as signed Identity header field). > IMHO, it should be that the assertion MUST > be signed by the same key used to generate the identity digest. agreed ;) > 5. No mention is made of the possible sensitivity of the contents of > SAML assertions. It's possible that these assertions could contain > sensitive information about the Subject, such as statements about what > identities the subject holds. ah, indeed. good catch. > There should be some discussion about > what measures should be taken in this case, e.g., the use of HTTPS and > authentication of dereferencing clients. ok. > Section 6.1.5, Step 3: > Section 5.4 of the indicated reference doesn't say anything about how > signatures are verified. well, that's not exactly true. There's info therein about certain first-order properties assns must have in order to verify correctly and such, so it still needs to be referenced imho. But yes, it doesn't provide a step-by-step guide for doing so. > Instead, this should reference Section 3.2 of > the XMLdsig document referenced. will be more explicit about the references into XMLdsig -- presently it's just a blanket ref. > Also is this TODO resolved? we're working on it. I think we should alloc a new sip error value, as has been proposed by Hannes. just need to choose one. > Section 6.1.5, Step 5: > Specify how this verification is done, e.g., by verifying that the > signed-identity-digest and the signature on the SAML assertion are both > verifiable with the key in the cert in the assertion. agreed, good catch. > Section 6.1.5, Step 7: > The relevant field in the X.509 certificate are Subject and Subject > Alternative Name (not Issuer and Issuer Alternative Name). The Issuer > of the assertion is the Subject of the certificate. ah! yeah, another good catch. Also we should probably reference section 13.4 of rfc4474. thanks for your review, =JeffH _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 06 20:41:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6yMH-00056V-Mw; Fri, 06 Jul 2007 20:41:09 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6yMG-00056J-R1 for sip-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 20:41:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6yMG-000565-Gf for sip@ietf.org; Fri, 06 Jul 2007 20:41:08 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6yMG-0002zJ-BU for sip@ietf.org; Fri, 06 Jul 2007 20:41:08 -0400 Received: from [10.31.13.240] (stdhcp-240.va.neustar.com [10.31.13.240]) by ns4.neustar.com (Postfix) with ESMTP id E3E222ACB2; Sat, 7 Jul 2007 00:40:17 +0000 (GMT) Message-ID: <468EE100.9070009@neustar.biz> Date: Fri, 06 Jul 2007 17:40:32 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: SIP IETF Subject: Re: [Sip] SIP Saml Review by Marcos Dytz - security considerations References: <0D22E3C1A7D7A843B12BF8C6F0A40758021496CA@MCHP7IDA.ww002.siemens.net> In-Reply-To: <0D22E3C1A7D7A843B12BF8C6F0A40758021496CA@MCHP7IDA.ww002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ext Marcos Dytz X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -------- Original Message -------- > Subject: [Sip] SIP Saml Review by Marcos Dytz > Date: Mon, 18 Jun 2007 10:39:20 +0200 > From: Tschofenig, Hannes > To: SIP IETF > CC: ext Marcos Dytz > > 6) I believe that it is valid that together with signing part of the > message, some fields are hashed in order to improve security. Hm, I'm not sure I understand. Can you please explain more fully? thanks, =JeffH _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 06 20:54:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6yZD-0006F9-1J; Fri, 06 Jul 2007 20:54:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6yZA-0006Ex-Uv for sip-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 20:54:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6yZA-0006Ep-LR for sip@ietf.org; Fri, 06 Jul 2007 20:54:28 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6yZA-0003FQ-G8 for sip@ietf.org; Fri, 06 Jul 2007 20:54:28 -0400 Received: from [10.31.13.240] (stdhcp-240.va.neustar.com [10.31.13.240]) by ns0.neustar.com (Postfix) with ESMTP id 3E7F832935 for ; Sat, 7 Jul 2007 00:54:28 +0000 (GMT) Message-ID: <468EE452.7040703@neustar.biz> Date: Fri, 06 Jul 2007 17:54:42 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] Comments draft-ietf-sip-saml-02 - marc.willekens - security considerations References: <67043E463DDBFD4A8087ED940BFF756B0179715F@BRU0038A.ww018.siemens.net> In-Reply-To: <67043E463DDBFD4A8087ED940BFF756B0179715F@BRU0038A.ww018.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -------- Original Message -------- > Subject: [Sip] Comments draft-ietf-sip-saml-02 > Date: Thu, 21 Jun 2007 16:47:46 +0200 > From: Willekens, Marc > To: > > > [Page30] Security considerations > > Is it possible to redirect messages to an own authentication service by > manipulating the end-device? hm, do you mean e.g. that the receiving proxy UAS might, acting as an AS, issue a "407 Proxy authentication request" back up the signaling path? > How can the called party trust the > authentication service assigned by the caller? Well, this is more of an overall question and thus falls into the realm of "sip identity" rfc4474. I think that the best we have at this time is section "13.4. Domain Names and Subordination" of rfc4474. Note that it references out to the Security Considerations section of rfc3280 "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". Note also that rfc4474 sec 13.4 notes in it's 2nd-to-last paragraph that.. "Some federations of service providers, for example, might only trust certificates that have been provided by a certificate authority operated by the federation." perhaps that's the best we can do for now. Perhaps we need to explain this better in -sip-saml-xx. =JeffH _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 06 21:34:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6zC1-0001bm-Aw; Fri, 06 Jul 2007 21:34:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I6zBz-0001aN-IP for sip-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 21:34:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6zBz-0001Zv-61 for sip@ietf.org; Fri, 06 Jul 2007 21:34:35 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6zBy-000795-R7 for sip@ietf.org; Fri, 06 Jul 2007 21:34:35 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l671Y1IX016991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 6 Jul 2007 21:34:01 -0400 (EDT) In-Reply-To: <468E899A.7070806@cisco.com> References: <81A2A0E9-FDF4-48EC-92E4-C02B6BD05948@cs.columbia.edu> <468E899A.7070806@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] Re: Conveyance -08 and Geolocation-Error header Date: Fri, 6 Jul 2007 21:34:01 -0400 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: sip@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My general take is that the source, on the return trip, should be able to identify location information it has inserted. Note that a single UA or proxy could theoretically insert two locations (e.g., geo + civic) or reference and value, so some additional identification beyond the node may be necessary. If it weren't for various SBCs mucking with Via's, the Via solution sounds interesting, but maybe the simple host name is easiest. The problem with the host name (or Via) is that the party discovering the error and the party inserting the location are generally *NOT* the same. The error is likely to be discovered far downstream, e.g., by the UAS or the PSAP proxy. The UAS or PSAP proxy has no way to know what node inserted the location, since the Geolocation header field currently only says "endpoint" or "server". Thus, another variation that allows host identification and avoids this problem: Just define ;inserted-by to use the host name, and then use the same parameter in the error indication. Henning On Jul 6, 2007, at 2:27 PM, Paul Kyzivat wrote: > Hmm. I've been behind on reading. I was having a side conversation > with James on this, and it looks like some of that would be worth > sharing here. James was asking me for ideas of how to handle this > "identifier". > > The following is what I last sent to James: > > Paul Kyzivat wrote: >> What do you expect will happen as a result of identifying the >> source of the error? >> Do you expect that the source will itself recognize that it has >> made a mistake and do something about it? Or do you expect some >> other element to keep notes on which nodes do a bad job of >> supplying addresses? >> Also, do you expect the node that inserts the address to remember >> what address it inserted when it gets the error response? Or some >> other node other than the one that inserted it to remember it? >> The answer to these questions impacts the kind of solution that is >> appropriate. >> If the UAS is the one to detect the problem, and also the one to >> log the problem for future use, then it must be possible to >> actually determine the address of the source of the address. An >> index into the Via list might be adequate for that. Or, the >> "inserted-by" could be changed to actually include the address of >> the node doing the insertion. >> If the node doing the insertion is responsible for tracking its >> own failures, then its probably bad to assume that it will >> remember what it inserted. So the actual offending address should >> probably be included in the error response. In that case, there is >> probably something in that address that will allow the offender to >> recognize that it was the source of the problem. >> If some other node (other than the UAS and the offending node) is >> responsible for logging the problem, then it will certainly want >> the offending address as well. So again it should be included in >> the response. And again, there probably isn't need of anything else. >> At least that's my take based on what little info I have. > > Paul > > Henning Schulzrinne wrote: >> James, >> I think your #1 and #2 covers it, in addition to an identifier >> that points to the location element that suffers from the problem >> identified. (The latter was discussed, if I recall correctly, but >> seems to be missing from your syntax proposal.) >> I don't feel strongly about identifying the originator of the >> error, but it might be useful to have an extensible parameter >> list, in standard SIP header fashion, so that we can easily add >> more debugging information later. >> Henning >> On Jul 5, 2007, at 8:22 PM, James M. Polk wrote: >>> Henning >>> >>> Regarding Conveyance -08 and the new Geolocation-Error header >>> that you want to replace the Warning header code(s) function >>> (section 3.4 of the -07 ID)... >>> >>> What fields do you want in the header? >>> >>> #1 error-code, >>> #2 text-string explaining what error it is >>> #? >>> >>> Do you need anything else? >>> >>> Warning had/has the node ID of the sending entity. Do you want >>> that in the new Geolocation-Error header? Do you really see a >>> purpose in having that piece there? >>> >>> Attempting to put the final pieces of -08 together, and this new >>> header is less than straightforward in writing it. >>> >>> Is this viable ABNF for what you want? >>> >>> Geolocation-Error = "Geolocation-Error" HCOLON (locationErrorValue >>> *(COMMA locationErrorValue)) >>> locationErrorValue = numeric-code *(SEMI geoloc-error-param) >>> numeric-code = decimal-string >>> geoloc-error-param = "code" EQUAL error-text-string >>> / generic-param ; (from RFC 3261) >>> error-text-string = string >>> >>> (anyone) let me know what you think >>> >>> Thanks >>> James >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 06 23:25:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I70uw-0006Do-2N; Fri, 06 Jul 2007 23:25:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I70uu-0006Dh-MG for sip-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 23:25:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I70uu-0006DZ-CN for sip@ietf.org; Fri, 06 Jul 2007 23:25:04 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I70up-000227-TQ for sip@ietf.org; Fri, 06 Jul 2007 23:25:04 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 06 Jul 2007 23:24:59 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0KADGkjkZAZnme/2dsb2JhbACIVp82 X-IronPort-AV: i="4.16,510,1175486400"; d="scan'208"; a="64552850:sNHT36091178" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l673Oxw5010650; Fri, 6 Jul 2007 23:24:59 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l673Ox6a002960; Sat, 7 Jul 2007 03:24:59 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 23:24:59 -0400 Received: from [10.86.240.180] ([10.86.240.180]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 23:24:58 -0400 Message-ID: <468F078A.8070604@cisco.com> Date: Fri, 06 Jul 2007 23:24:58 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Sip] Re: Conveyance -08 and Geolocation-Error header References: <81A2A0E9-FDF4-48EC-92E4-C02B6BD05948@cs.columbia.edu> <468E899A.7070806@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2007 03:24:58.0970 (UTC) FILETIME=[65B123A0:01C7C046] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6890; t=1183778699; x=1184642699; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20Re=3A=20Conveyance=20-08=20and=20Geolocation- Error=20header |Sender:=20 |To:=20Henning=20Schulzrinne=20; bh=povjOnkMXREK2vZ10+st+BFncC8WnjVokpb/RYPZcuY=; b=IrTw9VSWU/QQu9bEhPuaQ/Mj5GmaWlW+r9DNWtnma7OogqJzGaDE43v4VzNgwpJZjfkGbtMt +OTTIWOftCBEgIax9sFFHN4ib+2SsUwnN07oDlSQqycqBJ5XBtFJPugu; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: sip@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have no skin in this game, so take my comments with a grain of salt... Is it really reasonable to expect a proxy that inserts a location to remember what location it inserted, in enough detail to diagnose why it might have been messed up? I presume it would have to reconstruct what the location would have been based in information in the response. It may not be possible to reconstruct the exact same value, because the UAC may have moved in the meantime. I guess the inserted location would have to be by reference, but the URL of the reference may itself not be easily reconstructed, and multiple queries of it may not return the same result. IMO it would be much clearer to include the location itself in the response. And if the location had been passed by reference, it might be better to pass it by value in the response, so that there is no possibility of the value changing. OTOH that might result in divulging the location to nodes upstream of the one that included it. If it was passed by reference then the node that had inserted it could remove the reference in the response. But if it is passed back by value that isn't allowed. The alternative is that the proxy will have to retain the location until the completion of the transaction. Maybe that's ok, but if its only to diagnose an occasional glitch I get it doesn't get done. Paul Henning Schulzrinne wrote: > My general take is that the source, on the return trip, should be able > to identify location information it has inserted. Note that a single UA > or proxy could theoretically insert two locations (e.g., geo + civic) or > reference and value, so some additional identification beyond the node > may be necessary. If it weren't for various SBCs mucking with Via's, the > Via solution sounds interesting, but maybe the simple host name is easiest. > > The problem with the host name (or Via) is that the party discovering > the error and the party inserting the location are generally *NOT* the > same. The error is likely to be discovered far downstream, e.g., by the > UAS or the PSAP proxy. The UAS or PSAP proxy has no way to know what > node inserted the location, since the Geolocation header field currently > only says "endpoint" or "server". > > Thus, another variation that allows host identification and avoids this > problem: > > > Just define ;inserted-by to use the host name, and then use the same > parameter in the error indication. > > > Henning > > On Jul 6, 2007, at 2:27 PM, Paul Kyzivat wrote: > >> Hmm. I've been behind on reading. I was having a side conversation >> with James on this, and it looks like some of that would be worth >> sharing here. James was asking me for ideas of how to handle this >> "identifier". >> >> The following is what I last sent to James: >> >> Paul Kyzivat wrote: >>> What do you expect will happen as a result of identifying the source >>> of the error? >>> Do you expect that the source will itself recognize that it has made >>> a mistake and do something about it? Or do you expect some other >>> element to keep notes on which nodes do a bad job of supplying >>> addresses? >>> Also, do you expect the node that inserts the address to remember >>> what address it inserted when it gets the error response? Or some >>> other node other than the one that inserted it to remember it? >>> The answer to these questions impacts the kind of solution that is >>> appropriate. >>> If the UAS is the one to detect the problem, and also the one to log >>> the problem for future use, then it must be possible to actually >>> determine the address of the source of the address. An index into the >>> Via list might be adequate for that. Or, the "inserted-by" could be >>> changed to actually include the address of the node doing the insertion. >>> If the node doing the insertion is responsible for tracking its own >>> failures, then its probably bad to assume that it will remember what >>> it inserted. So the actual offending address should probably be >>> included in the error response. In that case, there is probably >>> something in that address that will allow the offender to recognize >>> that it was the source of the problem. >>> If some other node (other than the UAS and the offending node) is >>> responsible for logging the problem, then it will certainly want the >>> offending address as well. So again it should be included in the >>> response. And again, there probably isn't need of anything else. >>> At least that's my take based on what little info I have. >> >> Paul >> >> Henning Schulzrinne wrote: >>> James, >>> I think your #1 and #2 covers it, in addition to an identifier that >>> points to the location element that suffers from the problem >>> identified. (The latter was discussed, if I recall correctly, but >>> seems to be missing from your syntax proposal.) >>> I don't feel strongly about identifying the originator of the error, >>> but it might be useful to have an extensible parameter list, in >>> standard SIP header fashion, so that we can easily add more debugging >>> information later. >>> Henning >>> On Jul 5, 2007, at 8:22 PM, James M. Polk wrote: >>>> Henning >>>> >>>> Regarding Conveyance -08 and the new Geolocation-Error header that >>>> you want to replace the Warning header code(s) function (section 3.4 >>>> of the -07 ID)... >>>> >>>> What fields do you want in the header? >>>> >>>> #1 error-code, >>>> #2 text-string explaining what error it is >>>> #? >>>> >>>> Do you need anything else? >>>> >>>> Warning had/has the node ID of the sending entity. Do you want that >>>> in the new Geolocation-Error header? Do you really see a purpose in >>>> having that piece there? >>>> >>>> Attempting to put the final pieces of -08 together, and this new >>>> header is less than straightforward in writing it. >>>> >>>> Is this viable ABNF for what you want? >>>> >>>> Geolocation-Error = "Geolocation-Error" HCOLON (locationErrorValue >>>> *(COMMA locationErrorValue)) >>>> locationErrorValue = numeric-code *(SEMI geoloc-error-param) >>>> numeric-code = decimal-string >>>> geoloc-error-param = "code" EQUAL error-text-string >>>> / generic-param ; (from RFC 3261) >>>> error-text-string = string >>>> >>>> (anyone) let me know what you think >>>> >>>> Thanks >>>> James >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 07 08:07:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I793x-00052v-A3; Sat, 07 Jul 2007 08:06:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I793v-00050T-4W for sip-confirm+ok@megatron.ietf.org; Sat, 07 Jul 2007 08:06:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I793u-00050J-Or for sip@ietf.org; Sat, 07 Jul 2007 08:06:54 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I793f-0003QT-GH for sip@ietf.org; Sat, 07 Jul 2007 08:06:54 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l67C65ck017179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 7 Jul 2007 08:06:06 -0400 (EDT) In-Reply-To: <468F078A.8070604@cisco.com> References: <81A2A0E9-FDF4-48EC-92E4-C02B6BD05948@cs.columbia.edu> <468E899A.7070806@cisco.com> <468F078A.8070604@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <83C6385C-BC62-4AB6-AD1B-14020A7CBAD5@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] Re: Conveyance -08 and Geolocation-Error header Date: Sat, 7 Jul 2007 08:06:02 -0400 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sip@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 6, 2007, at 11:24 PM, Paul Kyzivat wrote: > Is it really reasonable to expect a proxy that inserts a location > to remember what location it inserted, in enough detail to diagnose > why it might have been messed up? I presume it would have to > reconstruct what the location would have been based in information > in the response. It may not be possible to reconstruct the exact > same value, because the UAC may have moved in the meantime. I guess > the inserted location would have to be by reference, but the URL of > the reference may itself not be easily reconstructed, and multiple > queries of it may not return the same result. > > IMO it would be much clearer to include the location itself in the > response. And if the location had been passed by reference, it > might be better to pass it by value in the response, so that there > is no possibility of the value changing. > I tend to agree that this would be better. The reference-to-value translation may not always be feasible: If a proxy inserts a location reference and a downstream proxy finds a problem, it can't insert a value (except by the data URL mechanism I have been mentioning...). > OTOH that might result in divulging the location to nodes upstream > of the one that included it. If it was passed by reference then the > node that had inserted it could remove the reference in the > response. But if it is passed back by value that isn't allowed. > > The alternative is that the proxy will have to retain the location > until the completion of the transaction. Maybe that's ok, but if > its only to diagnose an occasional glitch I get it doesn't get done. My assumption was that most locations will be inserted by the UAC rather than a proxy. In those cases, retaining the information is probably not a big deal, since the UAC will generally only have one. In summary, I think returning as much information about the erroneous location information as possible seems best, i.e., both the location information and the party that inserted it. This avoids the "who the heck put that bogus location information in there?" problem. In general, I think we have learned that we should help people with debugging distributed systems with distributed responsibility, as otherwise they'll either struggle or invent private mechanisms to include this information. (See SER for the the latter.) > > Paul > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 07 11:45:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7CTH-0005n9-Nf; Sat, 07 Jul 2007 11:45:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I7CTF-0005mc-Ci for sip-confirm+ok@megatron.ietf.org; Sat, 07 Jul 2007 11:45:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7CTE-0005mT-UT for sip@ietf.org; Sat, 07 Jul 2007 11:45:17 -0400 Received: from an-out-0708.google.com ([209.85.132.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7CTA-00013c-Fk for sip@ietf.org; Sat, 07 Jul 2007 11:45:16 -0400 Received: by an-out-0708.google.com with SMTP id c17so101892anc for ; Sat, 07 Jul 2007 08:45:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=be/Q/+2E1guSqaQ/f08UWye7jGQRJCZz/+GkajUaqaqLqKbZj3mbm/gE8NRj7N/ZMCO5iaISxGcS/KOdJJaCiyHh4IICkJT1dn9+FiiH34vHaw7fzDKj5INaxaF2TDG+i3DPqQ+dFVrFLQBjQ6h2MWLmFJArB9UPxd3TPt5MoQ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=crW6ONtMoye8SG4+KjK+tCpXG4YrWY/P8RQnWvMuBpLvzam5kZSjZV+CdPJzRixvbNlHxKWcSZ88GDADEK72rJF2dT1PUziermX/yLk+eHw0yZY6nFkImAQ4BTzjHrW5VsCgQrk+vCJxjH7YFml7C8yhFC+HFqcqiwnGhjF5En4= Received: by 10.100.189.17 with SMTP id m17mr848563anf.1183823112067; Sat, 07 Jul 2007 08:45:12 -0700 (PDT) Received: by 10.100.124.4 with HTTP; Sat, 7 Jul 2007 08:45:11 -0700 (PDT) Message-ID: <953beacc0707070845s23ce51f3t8d2dcdf3fe40b50f@mail.gmail.com> Date: Sat, 7 Jul 2007 08:45:11 -0700 From: "Rohan Mahy" To: "Erkki.Koivusalo@nokia.com" Subject: Re: [Sip] Keepalive mechanisms and related flags in outbound-09 In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F03DAB59D@esebe103.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <8B1D53AEF7B03449A6D3771B3B7F850F036F845C@esebe103.NOE.Nokia.com> <8B1D53AEF7B03449A6D3771B3B7F850F036F8BC2@esebe103.NOE.Nokia.com> <953beacc0706211056j5b65c646t43088922152b59f2@mail.gmail.com> <8B1D53AEF7B03449A6D3771B3B7F850F03DAB59D@esebe103.NOE.Nokia.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: sip@ietf.org, fluffy@cisco.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Erkki, et al. I hope you are enjoying your summer holiday. I'm assuming that Aki and/or Miguel will join in the thread, per your other email. I was hoping that Fran=E7ois Audet would reply to the time-keepalive part of this thread, but I will reply based on one of the use cases he described to me. I will also talk a bit about keep-stun and keep-crlf. Comments inline. On 6/28/07, Erkki.Koivusalo@nokia.com wrote: > > Hi, > > I have today had a look into the fresh Outbound-09 > to see how it addresses the keepalive issues in comparison > to the proposal I submitted originally in the beginning of > March and resent it yesterday. > > My first questions are related to this statement: > > Clients MUST support this CRLF keepalive. > > If so, what is the value of promoting the TCP Keepalive within > SIP Outbound ? In which circumstancies an UA supporting TCP > Keepalive would instead select sending CRLF keepalive ? If the server did not add "timed-keepalives", and the UA is happy with the value of the TCP keepalive timers, then the UA can use TCP keepalive. > Further on, I like this piece of text within Outbound-09: > > The client needs to perform normal RFC 3263 [4] SIP DNS resolution on > the URI from the outbound-proxy-set to pick a transport. Once a > transport is selected, the UA selects a keepalive approach that is > allowed for that transport ... > > That approach is elegant and consistent with RFC 3263. > > But I still dislike these pieces of text: > > ... and that is allowed by the server based on the tags in the URI > from the outbound-proxy-set. > > User Agents that form flows check if the configured URI they are > connecting to has a 'keep-crlf' URI parameter (defined in > Section 12). If the parameter is present and the UA is not already > performing keepalives using another supported mechanism, the UA can > send keep alives as described in this section. > > User Agents that form flows, check if the configured URI they are > connecting to has a 'keep-stun' URI parameter (defined in > Section 12). If the parameter is present and the UA is not already > performing keepalives using another supported mechanism, the UA can > periodically perform keepalive checks by sending STUN [3] Binding > Requests over the flow as described in Section 8. > > Outbound-09 suggests that configured proxy URIs could contain > 'keep-crlf' or 'keep-stun' parameters, with which the UAs could > check whether the proxy supports the corresponding keepalive > mechanism before starting to send such keepalives. Instead of > all that I simply suggest using the 'ob' parameter for the proxy > URI to indicate that the proxy supports SIP Outbound and all the > keepalive mechanisms defined in SIP Outbound for those transports > the proxy supports according to DNS. > > Rationale: > > 1. SIP Outbound anyway already mandates compliant proxies to > support all keepalive mechanisms (see section 5.4) so there is > no need to define separate flags for each of those mechanisms. > One single flag for Outbound support is sufficient indication. > > 2. The draft has already defined the 'ob' URI parameter and how the > proxy should use it. My proposal is to use the flag as defined > but additionally to bundle the semantics of separate keepalive > flags to this single 'ob' parameter. > > 3. The UA could check the presence of 'ob' parameter within the > proxy URI either > a) within its configured outbound-proxy-set; or > b) Path header received within 200 OK to REGISTER > (like suggested in section 8) > > 4. Simple is better: less flags to be introduced to IANA, > to the URIs or to the implementations. Resulting URIs > would also be shorter with this single and short parameter. The 'ob' parameter is not appropriate if we continue to allow STUN keepalives to be used without outbound. Christer requested this and the WG agreed to move the STUN keepalive definition to a separate section of the draft. We could certainly change 'keep-stun' and 'keep-crlf' to just 'keep' (for example), but we had consensus that supporting keepalives and supporting outbound should be kept orthogonal. In addition, I think using 'ob' in so many contexts would be confusing: - in the first Path header it means that the first Edge Proxy added a flow = token - in the UACs Contact header it means that the UAC registered successfully with outbound. The first Edge Proxy can use this as a hint to add a flow-token to its Record-Route. Then you propose to add this one: - in the outbound-proxy-set URIs it means that keepalives are supported. - in the topmost Path header returned after registration it means that keepalives are supported Having 'keep-stun' and 'keep-crlf' is merely historic and I support merging these into a single 'keep' parameter if we have consensus to do so. > Finally I do not find any value for the 'timed-keepalives' > parameter. It was agreed in IETF68 but I was not attending > the meeting and I have not seen the rationale for it anywhere. > For the proxy point of view what is the difference whether or > not the proxy URI contains this parameter ? If the parameter > is within the URI, the proxy can be sure that it receives > the keepalives with intervals defined in the spec but otherwise > the UA could select longer intervals. However the spec does not > specify any actions for the proxy to check how often it receives > the keepalive messages so what is the point to have such a URI > parameter ? Instead of that I would suggest dropping this > parameter and either: This parameter was a compromise between folks who want the client to be able to send whenever it likes (typically less often, to conserve battery power for example); and folks who want their server to be able to track liveness of their clients. The spec does not define what a proxy using timed-keepalives would do with this information, but below are some examples. 1) The UA is used in a call center. If a certain number of keepalives are missed by a UA, the proxy assumes the UA could be down and only forwards calls to that agent when no "live" clients are available. 2) If several keepalives are missed, the proxy declares the UA down and deletes the flow. 3) Associated with the proxy is a management station that shows the status of each UA connected to it. I am not trying to argue for including these features. I am just providing an explanation of what folks might do with this parameter. I would like to point out that this only works if the EP and the registrar are coordinated at least via configuration. A simple way to do this in a cross-domain environment would be for the EPs to include ;keep in the outbound-proxy-set and for the registrar to add ;timed-keepalives to the Path header for the EP. > a) mandate the UA always to use timers as defined in the draft > or > b) let the UA always to choose any timer values it wants to use > and make the timer values in the draft as recommendations Choice a) certainly does not work well for battery operated devices, and choice b) does not enable the use cases I described above. > Option b) could be better if the UA later on has some > mechanism (like STUN extension etc.) to ask the middleboxes > to adjust their timer behaviour. Discovering the topology between the UA and the EP is easy 90% of the time and practically impossible 1% of the time. The problem is that the UA can't tell which situation it is in. Consequently, I won't hold my breath for a deterministic solution to middlebox timer configuration. > Example of URIs for a proxy supporting all keepalive methods: > > Outbound-09: > sip:pri.example.com;lr;keep-stun;keep-crlf;timed-keepalives;ob > > My proposal: > sip:pri.example.com;lr;ob Your first URI isn't quite correct. If your proxy has no interest in timed-keepalives, then it would omit the parameter. The 'ob' parameter does not appear in the outbound-proxy-set. If we consolidate keep-stun and keep-crlf, the situation looks pretty good. outbound-proxy-set: sip:pri.example.com;lr;keep-stun;keep-crlf OR sip:pri.example.com;lr;keep Path: sip:pri.example.com;lr;keep-stun;keep-crlf;ob sip:pri.example.com;lr;keep;ob I don't think this is quite as daunting. thanks, -rohan > Just guess why I prefer the latter ;-) Any comments ? > > Regards, > > Erkki > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 07 19:26:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7Jey-0005DW-1y; Sat, 07 Jul 2007 19:25:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I7Jew-00059C-VV for sip-confirm+ok@megatron.ietf.org; Sat, 07 Jul 2007 19:25:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7Jew-00056C-IN for sip@ietf.org; Sat, 07 Jul 2007 19:25:50 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7Jew-0006pz-4c for sip@ietf.org; Sat, 07 Jul 2007 19:25:50 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 07 Jul 2007 19:25:25 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAG+9j0ZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,511,1175486400"; d="scan'208"; a="64592063:sNHT32794830" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l67NPPDZ028135; Sat, 7 Jul 2007 19:25:25 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l67NPNs0025244; Sat, 7 Jul 2007 23:25:25 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Jul 2007 19:25:23 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.204]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Jul 2007 19:25:22 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 07 Jul 2007 18:25:20 -0500 To: Henning Schulzrinne , Paul Kyzivat From: "James M. Polk" Subject: Re: [Sip] Re: Conveyance -08 and Geolocation-Error header In-Reply-To: References: <81A2A0E9-FDF4-48EC-92E4-C02B6BD05948@cs.columbia.edu> <468E899A.7070806@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 07 Jul 2007 23:25:22.0823 (UTC) FILETIME=[1740F170:01C7C0EE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6367; t=1183850725; x=1184714725; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20Conveyance=20-08=20and=20Geolocation- Error=20header |Sender:=20 |To:=20Henning=20Schulzrinne=20, =0A=20=20=20=20=20=2 0=20=20Paul=20Kyzivat=20; bh=yKbDS5YeB5OVb4OBYmDQVm+hrQnGGAkeW+lhvVGWj/o=; b=ZaGbhqy0eeDRdpvslQBzhGHrhDu8Jn9zuADfTyhIlEoRHPltNLHK7oUTSIvAzBUi6clQ3C1t dR5HafzhVFJYNS+zst3Swl1j+Au8fTXGb0Ftquw5Mh9KSlmNQvGigHTl; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 08:34 PM 7/6/2007, Henning Schulzrinne wrote: >My general take is that the source, on the return trip, should be >able to identify location information it has inserted. Note that a >single UA or proxy could theoretically insert two locations (e.g., >geo + civic) or reference and value, so some additional >identification beyond the node may be necessary. If it weren't for >various SBCs mucking with Via's, the Via solution sounds interesting, >but maybe the simple host name is easiest. > >The problem with the host name (or Via) is that the party discovering >the error and the party inserting the location are generally *NOT* >the same. The error is likely to be discovered far downstream, e.g., >by the UAS or the PSAP proxy. The UAS or PSAP proxy has no way to >know what node inserted the location, since the Geolocation header >field currently only says "endpoint" or "server". > >Thus, another variation that allows host identification and avoids >this problem: > > >Just define ;inserted-by to use the host name, and then use the same >parameter in the error indication. > wouldn't this run into the same SBCs & B2BUAs mucking it up problem, thereby making this unreliable? I mean there could easily be domain-of-host scrubbing going on at borders, to include this field. I'm not sure either if PSAPs reeeeally care if location was inserted by a UAC or proxy along the way - they just want something. It sounded good when I first came up with the idea, but it is also merely informative in nature, and has zero integrity. Also, if I go with your proposal, which seems easy to add, what strength do I put on the location inserter putting this in? It seems like it ought to be something like "...MUST insert inserter's host-id/name header parameter in the locationValue". Matching this host-id/name into the GeolocationError header's locationErrorValue within the response seems easy then. BTW Paul - there are lots of GeolocationError codes of various flavors, depending on what was wrong with the location when it was discovered. >Henning > >On Jul 6, 2007, at 2:27 PM, Paul Kyzivat wrote: > >>Hmm. I've been behind on reading. I was having a side conversation >>with James on this, and it looks like some of that would be worth >>sharing here. James was asking me for ideas of how to handle this >>"identifier". >> >>The following is what I last sent to James: >> >>Paul Kyzivat wrote: >>>What do you expect will happen as a result of identifying the >>>source of the error? >>>Do you expect that the source will itself recognize that it has >>>made a mistake and do something about it? Or do you expect some >>>other element to keep notes on which nodes do a bad job of >>>supplying addresses? >>>Also, do you expect the node that inserts the address to remember >>>what address it inserted when it gets the error response? Or some >>>other node other than the one that inserted it to remember it? >>>The answer to these questions impacts the kind of solution that is >>>appropriate. >>>If the UAS is the one to detect the problem, and also the one to >>>log the problem for future use, then it must be possible to >>>actually determine the address of the source of the address. An >>>index into the Via list might be adequate for that. Or, the >>>"inserted-by" could be changed to actually include the address of >>>the node doing the insertion. >>>If the node doing the insertion is responsible for tracking its >>>own failures, then its probably bad to assume that it will >>>remember what it inserted. So the actual offending address should >>>probably be included in the error response. In that case, there is >>>probably something in that address that will allow the offender to >>>recognize that it was the source of the problem. >>>If some other node (other than the UAS and the offending node) is >>>responsible for logging the problem, then it will certainly want >>>the offending address as well. So again it should be included in >>>the response. And again, there probably isn't need of anything else. >>>At least that's my take based on what little info I have. >> >> Paul >> >>Henning Schulzrinne wrote: >>>James, >>>I think your #1 and #2 covers it, in addition to an identifier >>>that points to the location element that suffers from the problem >>>identified. (The latter was discussed, if I recall correctly, but >>>seems to be missing from your syntax proposal.) >>>I don't feel strongly about identifying the originator of the >>>error, but it might be useful to have an extensible parameter >>>list, in standard SIP header fashion, so that we can easily add >>>more debugging information later. >>>Henning >>>On Jul 5, 2007, at 8:22 PM, James M. Polk wrote: >>>>Henning >>>> >>>>Regarding Conveyance -08 and the new Geolocation-Error header >>>>that you want to replace the Warning header code(s) function >>>>(section 3.4 of the -07 ID)... >>>> >>>>What fields do you want in the header? >>>> >>>>#1 error-code, >>>>#2 text-string explaining what error it is >>>>#? >>>> >>>>Do you need anything else? >>>> >>>>Warning had/has the node ID of the sending entity. Do you want >>>>that in the new Geolocation-Error header? Do you really see a >>>>purpose in having that piece there? >>>> >>>>Attempting to put the final pieces of -08 together, and this new >>>>header is less than straightforward in writing it. >>>> >>>>Is this viable ABNF for what you want? >>>> >>>>Geolocation-Error = "Geolocation-Error" HCOLON (locationErrorValue >>>> *(COMMA locationErrorValue)) >>>>locationErrorValue = numeric-code *(SEMI geoloc-error-param) >>>>numeric-code = decimal-string >>>>geoloc-error-param = "code" EQUAL error-text-string >>>> / generic-param ; (from RFC 3261) >>>>error-text-string = string >>>> >>>>(anyone) let me know what you think >>>> >>>>Thanks >>>>James >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 07 19:41:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7JuT-0003Es-Bb; Sat, 07 Jul 2007 19:41:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I7JuS-0003En-BO for sip-confirm+ok@megatron.ietf.org; Sat, 07 Jul 2007 19:41:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7JuS-0003Ef-1u for sip@ietf.org; Sat, 07 Jul 2007 19:41:52 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7JuO-00073n-Q3 for sip@ietf.org; Sat, 07 Jul 2007 19:41:52 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l67Nfh9B027186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 7 Jul 2007 19:41:47 -0400 (EDT) In-Reply-To: References: <81A2A0E9-FDF4-48EC-92E4-C02B6BD05948@cs.columbia.edu> <468E899A.7070806@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <981742A7-0056-46BF-AF8B-54A4B6406B0B@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] Re: Conveyance -08 and Geolocation-Error header Date: Sat, 7 Jul 2007 19:41:38 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip@ietf.org, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > wouldn't this run into the same SBCs & B2BUAs mucking it up > problem, thereby making this unreliable? I mean there could easily > be domain-of-host scrubbing going on at borders, to include this > field. > Sure - any information could be removed. It just seems less likely. > I'm not sure either if PSAPs reeeeally care if location was > inserted by a UAC or proxy along the way - they just want > something. It sounded good when I first came up with the idea, but > it is also merely informative in nature, and has zero integrity. I agree that the PSAP doesn't care who inserted the information and there's really not much difference between one inserted by a proxy and the end system, as far as the PSAP is concerned. The only one that cares is probably the caller (UAC), mostly if things go wrong. It can be really frustrating if some crucial information is inserted by some proxy you can't see, and you have no idea who did it and thus don't know if you should talk to your local provider or some other party closer to the destination. I don't know whether this is a realistic issue, given that most location information will be inserted either by the UAC or the outbound proxy. Thus, maybe it would be sufficient to make the suitable extensibility hooks in both the Geolocation header and the error indication so that these can be added later, if we can't agree quickly on a suitable format. > > Also, if I go with your proposal, which seems easy to add, what > strength do I put on the location inserter putting this in? It > seems like it ought to be something like "...MUST insert > inserter's host-id/name header parameter in the locationValue". > > Matching this host-id/name into the GeolocationError header's > locationErrorValue within the response seems easy then. > > BTW Paul - there are lots of GeolocationError codes of various > flavors, depending on what was wrong with the location when it was > discovered. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 07 20:48:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7Kwu-0002OH-Ju; Sat, 07 Jul 2007 20:48:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I7Kwt-0002MN-Eb for sip-confirm+ok@megatron.ietf.org; Sat, 07 Jul 2007 20:48:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7Kwt-0002Jk-0s for sip@ietf.org; Sat, 07 Jul 2007 20:48:27 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7Kwd-0000Av-Ag for sip@ietf.org; Sat, 07 Jul 2007 20:48:26 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 07 Jul 2007 20:47:45 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAIbQj0ZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,511,1175486400"; d="scan'208"; a="125470286:sNHT27633742" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l680liNm010039; Sat, 7 Jul 2007 20:47:44 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l680lis0010650; Sun, 8 Jul 2007 00:47:44 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); Sat, 7 Jul 2007 20:47:44 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.204]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Jul 2007 20:47:44 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 07 Jul 2007 19:47:42 -0500 To: Henning Schulzrinne From: "James M. Polk" Subject: Re: [Sip] Re: Conveyance -08 and Geolocation-Error header In-Reply-To: <981742A7-0056-46BF-AF8B-54A4B6406B0B@cs.columbia.edu> References: <81A2A0E9-FDF4-48EC-92E4-C02B6BD05948@cs.columbia.edu> <468E899A.7070806@cisco.com> <981742A7-0056-46BF-AF8B-54A4B6406B0B@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 08 Jul 2007 00:47:44.0377 (UTC) FILETIME=[98A63E90:01C7C0F9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1768; t=1183855664; x=1184719664; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20Conveyance=20-08=20and=20Geolocation- Error=20header |Sender:=20 |To:=20Henning=20Schulzrinne=20; bh=as1akgoyrvZITQlbEVBvy43UZNqppFEg6z/oz/GTGrw=; b=qnIVZRUkieBpgD1MM5WqJFyAcbGQ1icHcwkpxdGZZkO7auC5DORC2OOuh1IMde/Kb2Url8n9 sXBaYi16i7tyM8OR/Q0Jj2W8bFVwpJjqx6eZhflXdceD6oAfoL5VW5Dy; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 06:41 PM 7/7/2007, Henning Schulzrinne wrote: >>I'm not sure either if PSAPs reeeeally care if location was >>inserted by a UAC or proxy along the way - they just want >>something. It sounded good when I first came up with the idea, but >>it is also merely informative in nature, and has zero integrity. > >I agree that the PSAP doesn't care who inserted the information and >there's really not much difference between one inserted by a proxy >and the end system, as far as the PSAP is concerned. The only one >that cares is probably the caller (UAC), mostly if things go wrong. >It can be really frustrating if some crucial information is inserted >by some proxy you can't see, and you have no idea who did it and thus >don't know if you should talk to your local provider or some other >party closer to the destination. I don't know whether this is a >realistic issue, given that most location information will be >inserted either by the UAC or the outbound proxy. > >Thus, maybe it would be sufficient to make the suitable extensibility >hooks in both the Geolocation header and the error indication so that >these can be added later, if we can't agree quickly on a suitable >format. as much as anything, I'm thinking of going with your proposal to change "inserted-by=endpoint or server" to "inserted-by=host-id/name" so that transaction statefulness of location insertion is easier to recognize in a response. This would blow up the idea of indicating if a locationValue was inserted by a endpoint or server... that was my point. It also gets us away from tracking a sequence number (of what length?) and having to nail down all the parameters of that new value - consensus might be in 2009 on this one with a number _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 09 02:32:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7mmv-0004e6-8o; Mon, 09 Jul 2007 02:32:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I7mmt-0004e1-Dq for sip-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 02:31:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7mmt-0004dt-2B for sip@ietf.org; Mon, 09 Jul 2007 02:31:59 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7mmo-00052b-Ml for sip@ietf.org; Mon, 09 Jul 2007 02:31:59 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.100]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1I7mmj-0006Lr-3p; Mon, 09 Jul 2007 01:31:49 -0500 Message-ID: <4691D71A.7000600@softarmor.com> Date: Mon, 09 Jul 2007 01:35:06 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Certificate authentication in SIP References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com> <46819819.5080107@cisco.com> <4681DA3C.8090607@softarmor.com> <4682CBF1.9000401@cisco.com> <80A444DE-0EFE-4AD9-A340-DB1AD43DE734@softarmor.com> <468B0812.2090003@cisco.com> <791E1028-5F3E-438F-9FCE-28FC97B3A188@softarmor.com> <468D6963.4050104@cisco.com> In-Reply-To: <468D6963.4050104@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: IETF SIP List , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: >>> >>> In a case where your chat provider has no relationship whatsoever >>> with this edge proxy, for what purpose would you be connecting to it >>> in the first place? You should connect directly to your chat provider >>> offering the service. Then, if you have a cert - great - authenticate >>> to it using mutual TLS. >>> >> >> Well, I might be doing "outbound" with my edge proxy in order to get >> some help from it for relaying messaging back through my NAT. > > > Why can't you do that with the edge proxy in your home providers network? You might do that with the edge proxy in your home provider's network. But that doesn't mean thet your 3rd-party service provider trusts the authentication service provided by your home provider's network. >> Or it might be a QoS-controlling proxy ala PacketCable. Or a >> firewall-control-proxy . . . > > > Ah, well QoS control is much better handled through policy server > peering than SIP connectivity. And it works for non-SIP things. Why is > it that SIP is the vehicle for getting QoS in a visited network? Is this > problem not more generic? Probably. But as I recall, PacketCable does it with SIP. > >> >> The chat provider might not just be on the other side of my edge >> proxy, but on the other side of my home serving proxy too. And the >> certificate auth stuff would appear to be able to traverse that proxy >> as well. > > > I don't follow the picture you have in mind. Clearly. Imagine a "home network" consisting of an edge proxy and a home service proxy. Imagine a 3rd party service that is NOT in a trust relationship with the "home network". How does that 3rd party service validate the identity of a user? Options include: 1) Do a conventional SIP authentication using digest or basic, both of which have issues we understand. 2) Trust the P-A-ID (which we've exluded by definition, since we don't trust it). 3) Use AIB (which doesn't exist, and we might have just excluded by definition as well). 4) Use certificate authentication as proposed. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 09 02:35:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7mq7-0000WZ-Ft; Mon, 09 Jul 2007 02:35:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I7mq5-0000PI-Oo for sip-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 02:35:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7mq5-0000Mk-Cw for sip@ietf.org; Mon, 09 Jul 2007 02:35:17 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7mpu-00067t-6L for sip@ietf.org; Mon, 09 Jul 2007 02:35:17 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.100]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1I7mpV-0006MA-3W; Mon, 09 Jul 2007 01:34:41 -0500 Message-ID: <4691D7C4.1080208@softarmor.com> Date: Mon, 09 Jul 2007 01:37:56 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Certificate authentication in SIP References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com><46819819.5080107@cisco.com> <4681DA3C.8090607@softarmor.com> <4682CBF1.9000401@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C62E9B4D@srvxchg3.cablelabs.com> <468B0889.8010005@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C62E9C30@srvxchg3.cablelabs.com> <468D6AC6.80402@cisco.com> In-Reply-To: <468D6AC6.80402@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Steve Dotson , IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > > > Steve Dotson wrote: > >> Maybe this is naïve, but doesn't this alter the operator trust model? >> >> >> I always envisioned P-A-ID (as an example) as a way for a home >> network to tell a 3rd party service "trust this one, they are >> authenticated", as long as the home network and the service had a >> relationship. Having an edge proxy in a visited domain telling the >> home network "trust this one" seems to turn things around. > > > P-A-ID asserts identity between providers with trust, yes that is true. > SIP Identity works with lesser degrees of trust, but if you don't trust > the signing domain, of course it doesn't work. > > However, my point is, one of the two following scenarios always apply: > > 1. the edge proxy is trusted by the home proxy, in which case you can > use mutual TLS to authenticate the client to the edge proxy, and then > P-A-ID or SIP Identity from edge proxy to home proxy, *OR* > > 2. there is no trust at all between visited and home networks. In this > case, you shouldn't be connectign to a visited proxy in the first place. > COnnect to the home proxy in your home network. Then, case 1 applies again. Wrongo. 3) There is no trust between the edge proxy and the point-of-service-delivery (which MIGHT be a proxy, or might not, and we don't know and don't care). But you have to use the edge proxy, because it's the only one that can get you out of your little nat/firewall/whatever administrative island. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 09 02:36:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7mqz-00022x-DQ; Mon, 09 Jul 2007 02:36:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I7mqy-00022p-Hz for sip-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 02:36:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7mqy-00022h-8U for sip@ietf.org; Mon, 09 Jul 2007 02:36:12 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7mqu-0005AB-0e for sip@ietf.org; Mon, 09 Jul 2007 02:36:12 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.100]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1I7mqr-0006MF-U9; Mon, 09 Jul 2007 01:36:05 -0500 Message-ID: <4691D81B.5030302@softarmor.com> Date: Mon, 09 Jul 2007 01:39:23 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rai, Anupam (Anupam)" Subject: Re: [Sip] Certificate authentication in SIP References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com><46819819.5080107@cisco.com><4681DA3C.8090607@softarmor.com> <4682CBF1.9000401@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C62E9B4D@srvxchg3.cablelabs.com><468B0889.8010005@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C62E9C30@srvxchg3.cablelabs.com> <468D6AC6.80402@cisco.com> <166476A2803C3B4994D744DFD57A942F160C08@306181ANEX3.global.avaya.com> In-Reply-To: <166476A2803C3B4994D744DFD57A942F160C08@306181ANEX3.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Steve Dotson , IETF SIP List , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rai, Anupam (Anupam) wrote: > > (2) Edge proxy utilizing TLS offloaders. Also an excellent example, and one I've seen come up in real-world planning discussions. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 09 02:41:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7mwD-0006s0-5K; Mon, 09 Jul 2007 02:41:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I7mwB-0006ja-AS for sip-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 02:41:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7mw9-0006de-Uo for sip@ietf.org; Mon, 09 Jul 2007 02:41:34 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7mw9-0006FO-M9 for sip@ietf.org; Mon, 09 Jul 2007 02:41:33 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.100]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1I7mw7-0006N3-LA; Mon, 09 Jul 2007 01:41:31 -0500 Message-ID: <4691D961.1040003@softarmor.com> Date: Mon, 09 Jul 2007 01:44:49 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Certificate authentication in SIP References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com><46819819.5080107@cisco.com><4681DA3C.8090607@softarmor.com> <4682CBF1.9000401@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C62E9B4D@srvxchg3.cablelabs.com><468B0889.8010005@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C62E9C30@srvxchg3.cablelabs.com> <468D6AC6.80402@cisco.com> <166476A2803C3B4994D744DFD57A942F160C08@306181ANEX3.global.avaya.com> <468D9BBB.4010107@cisco.com> In-Reply-To: <468D9BBB.4010107@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Steve Dotson , IETF SIP List , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: >> (2) Edge proxy utilizing TLS >> offloaders. > > > The offloader would need to pass the identity to the server. If it acted > as a simple SIP proxy in addition to doing TLS offload, it would work > fine. There are other non-standard ways of passing this identity also. > Let's just say that we're aware of commercial TLS concentrators from a certain vendor (who might ostensibly be said to fund your participation in this forum) that are both very popular and that DO NOT HAVE this functionalility and aren't very likely to get it (after all, why would you wish to reduce their performance by a factor of 50 or so to start parsing SIP messages?). Finding a way other than basic or digest to authenticate across them would be very nice, and would be very likely to ramp up the deployment of SIP/TLS. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 09 03:52:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7o2F-000579-SK; Mon, 09 Jul 2007 03:51:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I7o2D-000574-WB for sip-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 03:51:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7o2D-00056w-Lr for sip@ietf.org; Mon, 09 Jul 2007 03:51:53 -0400 Received: from cluster-f.mailcontrol.com ([85.119.2.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7o29-0006dC-8D for sip@ietf.org; Mon, 09 Jul 2007 03:51:53 -0400 Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12]) by rly29f.srv.mailcontrol.com (MailControl) with ESMTP id l697p9lC002631 for ; Mon, 9 Jul 2007 08:51:47 +0100 Received: from ExBE03.nasstar-t1.net ([10.2.10.102]) by exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 08:51:33 +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, 9 Jul 2007 08:51:23 +0100 Message-ID: <165288C2C3E29449AFDE022DD10CC471054D7311@ExBE03.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sip-sips-05.txt - comment on response codes 418 and 419 Thread-Index: Ace49I02RnXl9IBITu22gMFrABvj6QJB4VAg From: "Attila Sipos" To: X-OriginalArrivalTime: 09 Jul 2007 07:51:33.0892 (UTC) FILETIME=[F83C0C40:01C7C1FD] X-Scanned-By: MailControl A-07-07-10 (www.mailcontrol.com) on 10.70.0.139 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Sip] draft-ietf-sip-sips-05.txt - comment on response codes 418 and 419 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This draft specifies two new response codes: 418 SIPS Not Allowed 419 SIPS Required With sipsec around the corner shouldn't we make these headers more generic like we do for other SIP things? For example, if someone uses a method we don't allow then we return "405 Method Not Allowed" and then list the allowed methods in the Allow header. And there is a similar solution for SIP extensions (420 Bad Extension or 421 Extension Required). So how about: 418 URI Scheme Not Allowed Allow-URI: sip 419 URI Scheme Required Require-URI: sips,sipsec In fact, you probably only need one of them as they are almost identical in resultant behaviour. Regards, Attila _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 09 08:54:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7slO-0001lN-E7; Mon, 09 Jul 2007 08:54:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I7slI-0001iK-0x for sip-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 08:54:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7slG-0001h5-SW for sip@ietf.org; Mon, 09 Jul 2007 08:54:43 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7slC-0006Zp-4m for sip@ietf.org; Mon, 09 Jul 2007 08:54:42 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JKW00F1GX6OD3@siemenscomms.co.uk> for sip@ietf.org; Mon, 09 Jul 2007 13:54:24 +0100 (BST) Date: Mon, 09 Jul 2007 13:54:34 +0100 From: "Elwell, John" To: Francois Audet , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D02054B7@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: WGLC comments on sip-sips Thread-Index: AcfCKEx+ncUlBwX5SrqjW0d4TtdWnA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: Subject: [Sip] WGLC comments on sip-sips X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In general this is now in excellent shape. Just some detailed comments. 1. "It also makes normative changes to SIP". If so, then it should state on the front page that it updates RFC 3261. 2. In 3.1.1 "In this model, only the TLS server provides a certificate during the TLS handshake. Often, a proxy (which may or may not be the one terminating the TLS connection) authenticates the client by using the SIP HTTP digest. In this model, the UA is the TLS client side, and the Proxy is the TLS server side." The words "the Proxy" in the third sentence would appear to refer to "a proxy" in the second sentence, but that doesn't make sense. Also I think this is trying to say that the server-provided certificate can only apply between a UA and a proxy and when the UA is the client, so it can't apply between proxies and it can't apply when a proxy is a client. If so, to solve these two issues, perhaps it should say. "In this model, only the TLS server provides a certificate during the TLS handshake. This is applicable only between a UA and a proxy, where the UA is the TLS client and the proxy is the TLS server, and hence the UA uses TLS to authenticate the proxy but the proxy does not use TLS to authenticate the UA. If the proxy needs to authenticate the UA, this can be achieved by SIP HTTP digest authentication." 3. In 3.1.2 "In this model, both the TLS client and the TLS server provide a certificate in the TLS handshake phase. When no TLS connection is in place, the UAC would therefore take on the role of the TLS Client and the UAS would therefore take on the role of the TLS server." This seems to limit mutual TLS (more correctly TLS mutual authentication) to use involving a UA, but it also has an important use between proxies (this is not mentioned until further down). Also the second sentence seems to suggest a direct TLS connection between UAC and UAS, which is possible but not the typical case. Where at least one proxy is involved in the signalling path, if there is not already a TLS connection in place between the UAC and the first proxy, the UAC would take on the role of TLS client and the first proxy would take on the role of TLS server. Likewise, if there is not already a TLS connection in place between the last proxy and the UAS, the last proxy would take on the role of the TLS client and the UA would take on the role of the TLS server. I think this needs to be explained more fully. Perhaps we need to say something like: "In this model, both the TLS client and the TLS server provide a certificate in the TLS handshake phase. When used between a UA and a proxy (or between two UAs), this implies that a UA must be in possession of a certificate. When sending a SIP request when there is not already a suitable TLS connection in place, a UAC takes on the role of TLS client in establishing a new TLS connection. When establishing a TLS connection for receipt of a SIP request, a UAS takes on the role of TLS server." 4. "While guessing a SIPS AOR from a known SIP AOR and using it to initiate a request is a valid thing to do, doing the opposite (i.e., guessing a SIP AOR from a SIPS AOR and using it) is not a valid thing to do as it would be a security downgrade." I would not go as far as saying it is not valid. It is merely undesirable, but if the caller's UA does not support the SIPS scheme, that might be a valid way of contacting the desired user. 5. "Although "downgrading" from SIPS to SIP is disallowed," As mentioned above, I think it is valid but undesirable for a user to downgrade by guessing. However, I think what we are talking about here is downgrading by a proxy, so perhaps that should be made clear by saying: "Although "downgrading" from SIPS to SIP is disallowed at a proxy,". 6. In 4.1 "If a UAS does not wish to be reached with a SIPS URI but only with a SIP URI, it SHOULD respond with a 418 (SIPS Not Allowed)." If the UA does not wish to be reached with a SIPS URI, then surely it would not register a SIPS contact. If the UA has not registered a SIPS contact, it should not normally receive a SIPS request. So presumably this is required only for requests reaching the UA without going through the domain proxy. Correct? If so, perhaps some explanation is needed. 7. "UAS that do not support the SIPS URI scheme altogether "SHOULD reject the request with a 416 (Unsupported URI scheme) response" as described in [RFC3261]/8.2.2.1." Similar - should explain how this can occur. 8. In 4.1.1 "If a UA registers with a SIPS Contact header field, the registrar returning a service route [RFC3608] MUST return a service route consisting of SIP URIs if the intent of the registrar is to allow both SIP and SIPS to be used in requests sent by that client. If a UA registers with a SIPS Contact header field, the registrar returning a service route MUST return a service route consisting of SIPS URIs if the intent of the registrar is to allow only SIPS URIs to be used in requests sent by that UA." Because 4.1.1 is part of 4.1, which deals only with UAs, then it should not contain normative requirements on registrars. Presumably the intention of this is to state that RFC 3608 places such a requirement on registrars. The language needs changing to reflect this. 9. "However, the registrar MUST treat the SIP and SIPS schemes of the AOR the same way (i.e., it MUST not care if it is SIP or SIPS)." This is a requirement on the registrar and does not belong in 4.1. 10. "A registrar MUST only accept a binding to a SIPS Contact header field if all the appropriate URIs are of the SIPS scheme, otherwise there could be an inadvertent binding of a secure resource (SIPS) to an unsecured one (SIP). This includes the Request-URI, the Contacts and all the Path headers, but does not include the From and To headers. If the URIs are not of the proper SIPS scheme, the registrar MUST reject the REGISTER with a 419 (SIPS Required)." These are requirements on the registrar and do not belong in 4.1. 11. In 4.2 "It is RECOMMENDED to use an outbound proxy as per the procedures defined in [I-D.ietf-sip-outbound] for supporting UACs that can not provide a certificate for establishing a TLS connection (i.e., when server-side authentication is used)." This is a recommendation on a UA, not a proxy, so it does not belong as a normative statement in 4.2. 12. In 4.3 "A redirect server would not be usable if server-side authentication is used" This is incorrect. If a UA has a certificate it can provide TLS server-side authentication, yet a redirect server could still be used in this case. I think this is trying to say that a redirect server cannot be used to redirect to an entity (e.g., a UA) that does not have a certificate. 13. "When a redirect server receives a request with a SIP Request-URI, the redirect server MAY redirect with a 3XX response to either a SIP or a SIPS Contact header field. If the target UAS had registered previously using a SIPS Contact header field, the redirect server SHOULD return a SIPS Contact header field if it is in an environment where TLS is usable (as described in the previous paragraph)." This assumes that a redirect server is redirecting directly to a UA, i.e., to a contact. However, a redirect server can also redirect to another AoR that resolves to a domain proxy (or another redirect server). In other words, the redirect server may not have any knowledge of a "target UAS". 14. In 5.2 "Furthermore, the offending SIPS URI(s) may be in any location in the request (e.g., the Request-URI, a Contact header field, a Refer-To URI, etc.)." Shouldn't this say "the offending SIP URI(s)"? 15. In the example in 6.3, proxy A and proxy B violate the recommendation in 4.2 to route SIP requests over TLS. This doesn't seem to be a very good example! It would be better to show routing over TLS from proxy A onwards. 16. "7. Conclusion" Most of the content of this section consists of further considerations, rather than conclusions drawn from previous sections. So perhaps the title should be "Further considerations". 17. NITS - In 6.1 "This call flow". There is no call flow - the flow shows only registration. - There are instances of a SIP method name (e.g. REGISTER) being used alone without being followed by "request". - There are instances of "header" being used instead of "header field". John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 09 12:41:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7wIu-0006rq-Mq; Mon, 09 Jul 2007 12:41:40 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I7wIt-0006rl-Oo for sip-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 12:41:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7wIt-0006rb-Dw for sip@ietf.org; Mon, 09 Jul 2007 12:41:39 -0400 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7wId-0003vA-Kd for sip@ietf.org; Mon, 09 Jul 2007 12:41:39 -0400 Received: from [127.0.0.1] (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id E929F6C022; Mon, 9 Jul 2007 12:40:11 -0400 (EDT) From: Scott Lawrence To: Keith Drage , Dean Willis In-Reply-To: <467C3B4B.3050806@lucent.com> References: <467C3B4B.3050806@lucent.com> Content-Type: text/plain Organization: Pingtel Corp. Date: Mon, 09 Jul 2007 12:40:47 -0400 Message-Id: <1183999247.3633.27.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: IETF SIP List , "Jeffrey, Alan S A \(Alan\)" Subject: [Sip] Updated draft-gurbani-sip-domain-certs-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Fri, 2007-06-22 at 16:12 -0500, Vijay K. Gurbani wrote: > Folks: draft-gurbani-sip-domain-certs-05 has been submitted to > the IETF archives. This version includes the guidance we > got from the pkix WG in Prague. More specifically, this version > focuses strictly on: > > - How to use and interpret the SIP identities in a X.509 certificate. > - How to indicate that this particular certificate is for SIP > usage. We got some excellent late-breaking comments from Stephen Kent, and reissued this as -06 just ahead of the deadline for Chicago. Since such a late submission may take some days to get through the pipeline, you can get it here now: http://svn.resiprocate.org/rep/ietf-drafts/gurbani/domain-certs/draft-gurbani-sip-domain-certs-06.txt http://svn.resiprocate.org/rep/ietf-drafts/gurbani/domain-certs/draft-gurbani-sip-domain-certs-06.html We are on the current agenda for discussion on Tuesday in Chicago; we would like to focus discussion on whether or not this is an appropriate addition as a Working Group item under the existing charter items (and of course on any problems people may see with the content). -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs Chief Technology Officer - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 09 15:37:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7z2q-0000tN-GA; Mon, 09 Jul 2007 15:37:16 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I7z2p-0000t6-5x for sip-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 15:37:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7z2o-0000sx-ST for sip@ietf.org; Mon, 09 Jul 2007 15:37:14 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7z2j-0003d7-Fj for sip@ietf.org; Mon, 09 Jul 2007 15:37:14 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1I7z2i-0007F3-0O; Mon, 09 Jul 2007 14:37:08 -0500 Message-ID: <46928F5F.3080502@softarmor.com> Date: Mon, 09 Jul 2007 14:41:19 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: sip@ietf.org X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" Subject: [Sip] WGLC for draft-ietf-sip-outbound X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'd like to start a long working group last call for: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-09.txt This WGLC period will run through IETF and hopefully close August 6, 2007. Please read the draft and send any comments both to the list and direct to the authors. We'll also have a few minutes on the agenda in Chicago to discuss the issues if any pop up. -- Dean Willis co-chair, SIP _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 09 15:58:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zMo-0007tr-Ml; Mon, 09 Jul 2007 15:57:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I7zMo-0007tj-0L for sip-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 15:57:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zMn-0007tb-MU for sip@ietf.org; Mon, 09 Jul 2007 15:57:53 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7zMi-0007hO-NE for sip@ietf.org; Mon, 09 Jul 2007 15:57:53 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1I7zMa-0007Gw-7f; Mon, 09 Jul 2007 14:57:40 -0500 Message-ID: <46929430.3040306@softarmor.com> Date: Mon, 09 Jul 2007 15:01:52 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: sip@ietf.org X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ext Cullen Jennings Subject: [Sip] Proposed: delete Guidelines for use of SIP Security milestones X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org We have these two milestones in our charter, and neither Keith nor I are exactly sure what they mean: Mar 2007 Guidelines for use of SIP security to WGLC (Informational) Jun 2007 Guidelines for use of SIP security to IESG (Informational) Now we all know that there is a substantial need to better document the usage of and relationships between the many SIP-related security mechanisms, but I'm not aware of having seen a document posted that is making any headway on this problem,. and I'm not even sure we have a consensus on exactly what needs to be done. Plus, we've definitely missed the milestones. So I'd like to propose that we delete these milestones for now, and bring them back only when we have a concrete proposal on the table for what we think we can actually do (and should do) here. Opinions? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 09 16:48:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I80A3-0008Kh-UG; Mon, 09 Jul 2007 16:48:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I80A1-0008Ka-Pq for sip-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 16:48:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I80A1-0008KR-Eb for sip@ietf.org; Mon, 09 Jul 2007 16:48:45 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I80A1-0001gl-4U for sip@ietf.org; Mon, 09 Jul 2007 16:48:45 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 09 Jul 2007 13:48:44 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAN47kkarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,518,1175497200"; d="scan'208"; a="384455307:sNHT28019476" 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 l69Kmind002728; Mon, 9 Jul 2007 13:48:44 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l69KmFnE003442; Mon, 9 Jul 2007 20:48:44 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 Jul 2007 13:48:28 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 13:48:27 -0700 Message-ID: <46929F1F.2040503@cisco.com> Date: Mon, 09 Jul 2007 16:48:31 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Proposed: delete Guidelines for use of SIP Security milestones References: <46929430.3040306@softarmor.com> In-Reply-To: <46929430.3040306@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2007 20:48:27.0864 (UTC) FILETIME=[8053B580:01C7C26A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1687; t=1184014124; x=1184878124; 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=20[Sip]=20Proposed=3A=20delete=20Guidelines=20for=20use =20of=20SIP=20Security=20milestones |Sender:=20; bh=hWrSE1P/5y7wLv9mTo6DGoIGRUqf3JOJ1SUAsd8FxmE=; b=n1nbDFvpucw97UCeNTghlglHI/ocHb9cRMmbXfdkY9TXExLyeTbPN5O81s7WFfCegKuWSP7m aeB/m+uzLVAh4kpplsyuElmlMGQGzOu3NEwQupr2jCtGKYHppQN989lZ; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip@ietf.org, ext Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org When did they get introduced? Seems odd that we got them added when no one is quite sure what they mean. -Jonathan R. Dean Willis wrote: > We have these two milestones in our charter, and neither Keith nor I are > exactly sure what they mean: > > Mar 2007 Guidelines for use of SIP security to WGLC (Informational) > Jun 2007 Guidelines for use of SIP security to IESG (Informational) > > Now we all know that there is a substantial need to better document the > usage of and relationships between the many SIP-related security > mechanisms, but I'm not aware of having seen a document posted that is > making any headway on this problem,. and I'm not even sure we have a > consensus on exactly what needs to be done. > > Plus, we've definitely missed the milestones. > > So I'd like to propose that we delete these milestones for now, and > bring them back only when we have a concrete proposal on the table for > what we think we can actually do (and should do) here. > > Opinions? > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 09 16:50:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I80By-0002Dr-Ph; Mon, 09 Jul 2007 16:50:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I80Bx-0002Dm-TO for sip-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 16:50:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I80Bx-0002DY-Jc for sip@ietf.org; Mon, 09 Jul 2007 16:50:45 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I80Bt-0006N2-7D for sip@ietf.org; Mon, 09 Jul 2007 16:50:45 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 09 Jul 2007 13:50:40 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAM48kkarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,518,1175497200"; d="scan'208"; a="501383149:sNHT183827546" 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 l69KoeqK006334 for ; Mon, 9 Jul 2007 13:50:40 -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.12.10/8.12.6) with ESMTP id l69KoZkg020970 for ; Mon, 9 Jul 2007 20:50:40 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); Mon, 9 Jul 2007 13:50:35 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 13:50:34 -0700 Message-ID: <46929F9F.6040106@cisco.com> Date: Mon, 09 Jul 2007 16:50:39 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2007 20:50:34.0953 (UTC) FILETIME=[CC13F390:01C7C26A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=709; t=1184014240; x=1184878240; 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:=20Hitchhikers=20guide=20to=20sip=3A=20update=20available |Sender:=20; bh=iYttK7EHJwQmhmwk7XylTJ7Sxx1mJ7K4EQn0PpNJLXQ=; b=L2e4dMwPoaXecEsi9fVcxP9ZbEumglBx9j1DY/WMTmBZlvZyIj+hV9anG9GuJ2N/6FRoE6aW fOIaAVQNbX9dVNSG1Ex1N5nK1mqu/ejqO8EFmO+64jb4VWrpIezfyzt1; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] Hitchhikers guide to sip: update available X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I submitted an update to the hitchhikers guide: http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers-guide-03.txt Changes: * connected-identity -> RFC4916 * added record-route-fix and grouped it with fork-loop-fix into a new item under SIP core called "essential corrections" * added subnot-etags under event packages * added sip-sips to core specs -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 09 17:19:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I80dZ-0002td-FW; Mon, 09 Jul 2007 17:19:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I80dY-0002q9-IE for sip-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 17:19:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I80dY-0002q1-8Z for sip@ietf.org; Mon, 09 Jul 2007 17:19:16 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I80dU-00073Z-3C for sip@ietf.org; Mon, 09 Jul 2007 17:19:16 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l69LJAZ8005805; Mon, 9 Jul 2007 16:19:10 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l69LJAa11190; Mon, 9 Jul 2007 16:19:10 -0500 (CDT) Message-ID: <4692A64E.4040405@alcatel-lucent.com> Date: Mon, 09 Jul 2007 16:19:10 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Proposed: delete Guidelines for use of SIP Security milestones References: <46929430.3040306@softarmor.com> In-Reply-To: <46929430.3040306@softarmor.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.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org, ext Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > We have these two milestones in our charter, and neither Keith nor I > are exactly sure what they mean: > > Mar 2007 Guidelines for use of SIP security to WGLC (Informational) > Jun 2007 Guidelines for use of SIP security to IESG (Informational) > > Now we all know that there is a substantial need to better document > the usage of and relationships between the many SIP-related security > mechanisms, but I'm not aware of having seen a document posted that > is making any headway on this problem, Well, way back at the 65th IETF in Dallas (March 2006), I had presented some slides on draft-gurbani-sip-tls-use-00 (slides archived at http://www3.ietf.org/proceedings/06mar/slides/sip-5.pdf). Portions of that work got absorbed elsewhere -- for instance, the URI promotion aspect was then further explored in sip-sips; the test cases from tls-use-00 made it into sip-sec-flows; the mutual authentication aspect made it to domain-certs, etc. tls-use-00 subsequently expired and was not revised, having served some purpose in life. > and I'm not even sure we have a consensus on exactly what needs to be > done Wouldn't drafts like sec-flows, sip-certs, sip-sips, domain-certs all lead towards providing guidelines for the use of SIP security? > So I'd like to propose that we delete these milestones for now, and > bring them back only when we have a concrete proposal on the table > for what we think we can actually do (and should do) here. It looks like the drafts and a substantive body of the work in this area is out there; just needs to be organized for a more amenable deadline. But, I may be mistaken... Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 09 17:20:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I80eU-0004UC-54; Mon, 09 Jul 2007 17:20:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I80eQ-0004Pb-N7 for sip-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 17:20:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I80eQ-0004Na-0j for sip@ietf.org; Mon, 09 Jul 2007 17:20:10 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I80e8-00076J-Td for sip@ietf.org; Mon, 09 Jul 2007 17:20:09 -0400 Received: from [10.31.13.202] (stdhcp-202.va.neustar.com [10.31.13.202]) by ns1.neustar.com (Postfix) with ESMTP id 9A66A26E6E for ; Mon, 9 Jul 2007 21:19:52 +0000 (GMT) Message-ID: <4692A693.2060005@neustar.biz> Date: Mon, 09 Jul 2007 14:20:19 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: IETF SIP List Subject: Re: [Sip] draft-ietf-sip-saml-02 - review by Steffen Fries References: <5D1A7985295922448D5550C94DE291800128C14C@DEEXC1U01.de.lucent.com> <6A18D243963B7447AC1A36583F78EEDA01F7E39B@MCHP7I6A.ww002.siemens.net> In-Reply-To: <6A18D243963B7447AC1A36583F78EEDA01F7E39B@MCHP7I6A.ww002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Fries, Steffen wrote: > > - 1 Introduction (page 3) > > maybe it is worth mentioning in the introduction already that this ID > only considers "call by reference" for the assertions and does not provide > means for sending the assertion directly. Sure, we can do that. Though note that perhaps in the longer term it'll depend on the resolution to the issue of whether the spec remains strictly call-by-reference or evolves to include call-by-value. i.e. see.. [Sip] wrt SIP Saml Review by Jiri Kuthan - "missing scenarios" http://www1.ietf.org/mail-archive/web/sip/current/msg19793.html > - 3.1 SAML assertions (page 7) > "Explaining how the assertion was made, for example. " Sounds like an > example would follow, > which does not. I suggest removing "for example" > > - 4 Specification scope (page 9), in the discussion paragraph: > "However, The ..." -> should be "However, the ..." > "participating entites ..." -> "participating entities ..." > > - 5. Emplying SAML in SIP (page 11) > "seperatey" -> "separately" > > - 6.1.2 Profile Overview (page 14) > "Although this profile is overview is cast in terms of a SIP INVITE > ..." There is something wrong with this sentence > > - 6.1.3.2 (page 19) > procedes -> proceeds I've entered all these editorial comments into the sip-saml tracker (under "bug").. http://www.tschofenig.priv.at:8080/saml-sip/issue?@sort=-activity&@group=priority&@filter=status&@columns=id,activity,title,creator,assignedto,status&status=-1,1,2,3,4,5,6,7 thanks for your review, =JeffH _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 09 17:47:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8156-0001iB-SG; Mon, 09 Jul 2007 17:47:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8151-0001fO-5f for sip-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 17:47:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8150-0001ek-L0 for sip@ietf.org; Mon, 09 Jul 2007 17:47:38 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I814k-0007qP-Of for sip@ietf.org; Mon, 09 Jul 2007 17:47:38 -0400 Received: from [10.31.13.202] (stdhcp-202.va.neustar.com [10.31.13.202]) by ns1.neustar.com (Postfix) with ESMTP id F12D526E9E; Mon, 9 Jul 2007 21:47:21 +0000 (GMT) Message-ID: <4692AD05.6080008@neustar.biz> Date: Mon, 09 Jul 2007 14:47:49 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: SIP IETF , ext Marcos Dytz Subject: Re: [Sip] SIP Saml Review by Marcos Dytz - wrt "clarification" issues References: <0D22E3C1A7D7A843B12BF8C6F0A40758021496CA@MCHP7IDA.ww002.siemens.net> In-Reply-To: <0D22E3C1A7D7A843B12BF8C6F0A40758021496CA@MCHP7IDA.ww002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -------- Original Message -------- > Subject: [Sip] SIP Saml Review by Marcos Dytz > Date: Mon, 18 Jun 2007 10:39:20 +0200 > From: Tschofenig, Hannes > To: SIP IETF > CC: ext Marcos Dytz > > 1) ... (or, at > least, specifying that it can be used to convey attributes, query for > information, etc). yes, we can attempt to clarify this in the draft. > 2) The SAML assertion profile sounds weird, although I never completely > had a complete grasp of its meaning. You're referring to section "6.1.4. Assertion Profile Description" of -sip-saml-02, yes? > I understand that it is connected > with the implementation, but it never actually had any particular use to > me (or I never gave it much attention). I rather see it as details that > developers had to apply in order to have the implementation working and > must be added to the specification in order to avoid interoperability > issues. I called it an "assertion profile" because it "profiles" SAML assertions for use in this particular context. SAML assertions are explicitly tailorable, so each SAML profile needs to do this as well as specify how they are to be conveyed. Since they are security tokens, explicitly defining their content and the semantics thereof is important. > 3) I believe it is worth mentioning that one invalid condition locks the > whole assertion. by "locks" you mean "invalidates"? Sure we can try to clarify this, but in section "6.1.5. Assertion Verification", step 11, we do note that the validity period must be validated -- tho yes we should perhaps explicitly state that an assertion that fails any of the 11 steps MUST be deemed invalid (good catch). > 4) I also believe that is worth mentioning that the Identity-Info is > connected with CERTS and might go through deployment issues. This is tied to our perhaps thorniest open issue, which is discussed here.. [Sip] wrt RFC4474 Identity-Info header field referent issue (was: SIP SAML Review by Richard Barnes) http://www1.ietf.org/mail-archive/web/sip/current/msg19686.html http://www.tschofenig.priv.at:8080/saml-sip/issue12 So, yes, we need to clarify appropriately once we deal with the issue. > 5) Is there something missing on 7.1? Sounded incomplete to me. AFAIK it is complete in a technical sense. I believe some other reviewers had more detailed comments on it, so will likely be looking into it in any case. > 7) The part of the AS as an authenticator and proxy could be further > clarified. which section/paragraph are you referring to? thanks for your review, =JeffH _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 09 18:07:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I81Nu-0002GH-Ld; Mon, 09 Jul 2007 18:07:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I81Ns-0002Fo-8C for sip-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 18:07:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I81Nr-0002FW-JA for sip@ietf.org; Mon, 09 Jul 2007 18:07:07 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I81Nr-0003W7-Cd for sip@ietf.org; Mon, 09 Jul 2007 18:07:07 -0400 Received: from [10.31.13.202] (stdhcp-202.va.neustar.com [10.31.13.202]) by ns4.neustar.com (Postfix) with ESMTP id E690B2ACA7; Mon, 9 Jul 2007 22:06:26 +0000 (GMT) Message-ID: <4692B17D.7000005@neustar.biz> Date: Mon, 09 Jul 2007 15:06:53 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: IETF SIP List , Andreas.Pashalidis@netlab.nec.de Subject: Re: [Sip] SIP SAML Review by Andreas Pashalidis References: <4676E9F3.4030103@gmx.net> In-Reply-To: <4676E9F3.4030103@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hannes Tschofenig wrote: > Here is a review by Andreas Pashalidis: > > ---------------------- > > Here are a few small comments: > > "trait-based" authentication sounds a bit unconventional. Cannot you > just talk about "attribute-based" authorization? That would be better > aligned with SAML terminology. Since this spec is being concocted in the context of the SIP working group, I felt using SIP terminology was/es the way to go, see RFC4484. Though, we could add an entry(ies) to the "2. terminology" section to help clarify items such as this. >> From the description in section 5 and figure 1, it is not always clear > if you talk about an "authentication assertion" or an "attribute > assertion" I kept this deliberatively vague because section 5 is very high level. We could perhaps add a sentence to the effect that a SAML assertion can be used to assert attributes of a subject's authentication event and/or profile attributes. > Figure 2, step 5: is it possible to have multiple attribute statements > in the response? (for example, if possession of multiple attributes is > required?) yes. Also note that a given may assert any number of attributes. > Section 6.1.4.1.4: what does it mean if there is no attribute > statement? good point, the "MAY" in the first sentence arguably should be a "SHOULD". However, some implementation & deployment might be conveying all the information they need with other subelements of the SAML assertion, and so they get all the semantics out of the assertion that they need without a . > is it an authentication assertion then? No, not unless it explicitly contains an . > Section 9.2: it would be nice to have some exaplanation there, without > having to refer to a different spec/document. ok, will think about what we can add there. thanks for your review, =JeffH _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 09 18:38:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I81rf-0004f9-SC; Mon, 09 Jul 2007 18:37:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I81re-0004er-2o for sip-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 18:37:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I81rd-0004ej-PH for sip@ietf.org; Mon, 09 Jul 2007 18:37:53 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I81rZ-0000bM-G7 for sip@ietf.org; Mon, 09 Jul 2007 18:37:53 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Jul 2007 18:37:49 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAABVkkZAZnme/2dsb2JhbACIU516 X-IronPort-AV: i="4.16,519,1175486400"; d="scan'208"; a="125617638:sNHT33302140" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l69MbnUW015936 for ; Mon, 9 Jul 2007 18:37:49 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l69Mbas6025085 for ; Mon, 9 Jul 2007 22:37:48 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); Mon, 9 Jul 2007 18:37:40 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 18:37:40 -0400 Message-ID: <4692B8B2.9010206@cisco.com> Date: Mon, 09 Jul 2007 18:37:38 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] SIP Identity using Media Path References: <061701c7bcda$9ec23a90$2014590a@amer.cisco.com> In-Reply-To: <061701c7bcda$9ec23a90$2014590a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2007 22:37:40.0127 (UTC) FILETIME=[C1C7B2F0:01C7C279] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=554; t=1184020669; x=1184884669; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20SIP=20Identity=20using=20Media=20Path |Sender:=20 |To:=20sip@ietf.org; bh=fsmi6KYkzb9r5tvAe5gipyGelnE6fhc6pEmRlAt9ErI=; b=l30BLATkHHJTB6Ogl0pF7oX9cOmOhGvqtSylzFgQnAAhqmHIZrIlFgs/znYjkFE5kv9UdGkg 5VLAvMYHoCQw+cQuyNkxou2mYUvwVGmdiI7QEpVbiRbO9/OHV/9o9Mpr; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dan, I just took a look at this. I have a few questions: 1) Because you only sign the selected attributes from the SDP, the rest is not secured. That seems like an acceptable restriction if you assume there will be a media-terminating SBC in the path. But what about other body parts? I gather they won't be signed either. That seems like a potential problem as we start to identify need for various extra body parts. 2) What about "offerless" initial INVITEs? 3) What about messages that don't use SDP at all? Thanks, Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 09 18:42:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I81wI-0002P9-25; Mon, 09 Jul 2007 18:42:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I81wG-0002P4-E9 for sip-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 18:42:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I81wG-0002Ow-3C for sip@ietf.org; Mon, 09 Jul 2007 18:42:40 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I81wF-00048P-Rg for sip@ietf.org; Mon, 09 Jul 2007 18:42:40 -0400 Received: from [10.31.13.202] (stdhcp-202.va.neustar.com [10.31.13.202]) by ns4.neustar.com (Postfix) with ESMTP id 5A7C02AC84 for ; Mon, 9 Jul 2007 22:41:49 +0000 (GMT) Message-ID: <4692B9C8.9090002@neustar.biz> Date: Mon, 09 Jul 2007 15:42:16 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: IETF SIP List Subject: Re: [Sip] SIP SAML Review by Richard Barnes - "clarification" items References: <4679F41A.4020805@bbn.com> In-Reply-To: <4679F41A.4020805@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -------- Original Message -------- > Subject: [Sip] SIP SAML Review by Richard Barnes > Date: Wed, 20 Jun 2007 23:44:26 -0400 > From: Richard Barnes > To: IETF SIP List , Hannes Tschofenig > > > Figure 2: > In the INVITE messages, the AoR in the From: header should be > "sip:alice@foo.com" ok. > Section 6.1.2, Step 3: > The AS is supposed to insert "attributes required by Bob's domain". How > is it supposed to know which attributes these are? This is answered by > the following paragraph, which should be moved up to here. ok. > Section 6.1.2, Step 3: > The AS constructs a "HTTP-based SAML URI reference" -- shouldn't this be > a reference according to the binding defined in this document, instead > of the original (SAMLv2) reference standard? nominally yes, will investigate. > Section 6.1.3.3, third paragraph: > This paragraph gives the option of HTTPS or HTTP, but doesn't specify > that one of the two MUST be used. Suggested text: "The AS MUST > construct either an HTTP or HTTPS URI per Section "3.7.5.1 URI Syntax" > of [OASIS.saml-bindings-2.0-os]. It is RECOMMENDED that the AS > construct an HTTPS URI." good catch. > Section 6.1.3.3, fourth paragraph: > This is not technically correct; the URI should be the absoluteURI > portion of the Identity-Info header value. another good catch. > Section 6.1.4: > Through out this section, situations with exceptions are presented as > "SHOULD ... MAY ...". As I read it, this creates a situation without a > mandatory default behavior; I would prefer if these were worded as > MUSTs, with MAYs allowed under specified circumstances. will re-think with eye towards mandatory default behavior. > Section 6.1.4.1.3: > The SHOULDs in this section should be should be MUSTs. nominally agree. > Section 6.1.4.1.4, second paragraph: > This needs to say that the attribute-value pairs MUST pertain to the > subject of the assertion (a concept which needs to be tied to a SIP > entity elsewhere in the document). This may be the entity identified in > the From header, or another identified entity. nominally agree. > Section 7: > This binding doesn't really have anything to do with SIP. agreed. > Could we just > exclude SIP from the name? sure. > Maybe this could be the IETF standard URI > binding of SAML. that's an interesting thought, tho I wonder if it is worth the effort to try to do as an I-D on its own -- it's so small to specify that it can easily be included by-value in other specs, but of course then there might be skew, but would that in actuality be a problem, ... etc. And more precisely it's an http-uri-based one. there could be other needs for schlepping saml assertions via http in other fashions. thanks for your insightful review. =JeffH _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 09 19:25:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I82bu-000647-5x; Mon, 09 Jul 2007 19:25:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I82bs-000642-Pw for sip-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 19:25:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I82bs-00063u-GK for sip@ietf.org; Mon, 09 Jul 2007 19:25:40 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I82bs-0001q7-81 for sip@ietf.org; Mon, 09 Jul 2007 19:25:40 -0400 Received: from [10.31.13.202] (stdhcp-202.va.neustar.com [10.31.13.202]) by ns0.neustar.com (Postfix) with ESMTP id B5BA03292D; Mon, 9 Jul 2007 23:25:09 +0000 (GMT) Message-ID: <4692C3F1.10704@neustar.biz> Date: Mon, 09 Jul 2007 16:25:37 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Willekens, Marc" , sip@ietf.org Subject: Re: [Sip] Comments draft-ietf-sip-saml-02 - marc willekens - "clarification" items References: <67043E463DDBFD4A8087ED940BFF756B017C1FD0@BRU0038A.ww018.siemens.net> In-Reply-To: <67043E463DDBFD4A8087ED940BFF756B017C1FD0@BRU0038A.ww018.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -------- Original Message -------- > Subject: [Sip] Comments draft-ietf-sip-saml-02 > Date: Thu, 21 Jun 2007 16:47:46 +0200 > From: Willekens, Marc > To: > > > [Page 3], Introduction > > Is this document only about assertion for the authorization or also for > the authentication? authorization. > [Page 12] > > Domain name for Alice: example.com or foo.com?? (same comment for other > figures) oops, good catch. foo.com. > Authentication service or Assertion service or both? authentication service -- the term is from rfc4474. > [Page 13], 6.1. Assertion Fetch profile > > Is this the only planned profile or will other profiles be defined and > added later? My personal present thinking is that there are other possible SIP SAML profiles, e.g. see the appendix in -sip-saml-02 of other use cases, but that they should likely be specified separately in their own drafts. > Will there also be a push based model? Will it then be > "pushed" as part of the SIP message? This is something for the WG to think about. One _can_, in theory, have the UAC assert some information and attach a SAML assertion to a SIP request (e.g. Invite) body making such a statement. Thus this approach could only be used by UACs because (1) only UACs may place data in the SIP request body, and (2) there are vociferous objections in the SIP WG to schemes whereby SIP intermediaries may place BLOBs (binary large objects) in SIP header fields. See also.. [Sip] wrt SIP Saml Review by Jiri Kuthan - "missing scenarios" http://www1.ietf.org/mail-archive/web/sip/current/msg19793.html We could specify this for UACs-only, and the other http-uri-based fetch approach for, as it is currently, intermediates or UACs. However, before we go to the effort, what's the in-actuality demand for doing so? Has anyone implemented the rfc4474 authentication service role in the UAC and is it being used? > [Page 13], 6.1.1. URN > > What's the current consensus for the urn? No one has objected to what is in the spec, although no one has commented specifically on it as yet, either. > [Page 17], 6.1.3. > > ...sender and Authentication service (AS) may be separate or... ??? > > How will the AS and sender be combined? See the last paragraph on page 5 of rfc4474.. "This specification allows either a user agent or a proxy server to provide identity services and to verify identities." > [Page 22], 6.1.4.1.4. > > AttributeStatement is indicated. But what about Authentication and > Authorization Decision statement? This particular SIP SAML Profile doesn't specify use of those statements, but they are not explicitly excluded either. Conceivably someone could cook up a use case for them and make use of it in a site-specific manner, or we might find use case and then can specify their use more easily. If we do want to explicitly do this we should perhaps add that such statements MAY be present, but their meaning is defined outside of this profile. > [Page31] > > This RFC draft talks about assertions. But how can an identity be > asserted only by considering a device, e.g. in case a device is stolen > or temporary used by someone else? At VON 2000, H. Schulzrinne has > already indicated that something as fingerprint has to be added for a > device with a changing set of owners. Although a valid thought, that being the question of the nature of the actual authn mechanism between the UAC and the registration service, it is out of scope of this specification. In fact, this draft nowhere states that the subject's identity is asserted only by the device (UAC). thanks for your review, =JeffH _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 09 19:31:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I82hH-0002JP-DH; Mon, 09 Jul 2007 19:31:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I82hG-0002JH-B2 for sip-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 19:31:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I82hF-0002H9-UK for sip@ietf.org; Mon, 09 Jul 2007 19:31:13 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I82hF-0005AD-NR for sip@ietf.org; Mon, 09 Jul 2007 19:31:13 -0400 Received: from [10.31.13.202] (stdhcp-202.va.neustar.com [10.31.13.202]) by ns3.neustar.com (Postfix) with ESMTP id 263DC175E9; Mon, 9 Jul 2007 23:31:13 +0000 (GMT) Message-ID: <4692C55C.10608@neustar.biz> Date: Mon, 09 Jul 2007 16:31:40 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: felis@netlab.nec.de, SIP IETF Subject: Re: [Sip] SIP SAML Draft Review by Sebastian Felis - "clarifications" References: <0D22E3C1A7D7A843B12BF8C6F0A40758021EC8AB@MCHP7IDA.ww002.siemens.net> In-Reply-To: <0D22E3C1A7D7A843B12BF8C6F0A40758021EC8AB@MCHP7IDA.ww002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > ------- Original Message -------- > Subject: [Sip] SIP SAML Draft Review by Sebastian Felis > Date: Wed, 27 Jun 2007 12:02:48 +0200 > From: Tschofenig, Hannes > To: SIP IETF > > > - Another topic is the usage of the term "Authentication Server" which > has the acronym AS. Since the term is originating from the trait-based > authorization draft, well, it's actually from rfc4474 "SIP Identity". > this term should be fine. But from the IMS > perspective, the acronym AS is "Application Server". By today, the SIP > (p)rotocol is more and more associated with IMS and touches the terms of > IMS. Further, the term Authentication Server is not a common term in > SAML. So I propose to use another term, which is more SIP/IMS and/or > SAML conform, e.g. Identity Provider in case of SAML. Well, this draft spec is being concocted in the context of the SIP WG, and so I am trying to have the terminology be as SIP-driven as possible. We can note, though, in the terminology section, that "AS" is "app server" in the IMS world in order to try to head off confusion. thanks for your review, =JeffH _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 09 20:39:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I83kz-00073q-PN; Mon, 09 Jul 2007 20:39:09 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I83ky-00073l-IL for sip-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 20:39:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I83ky-00073d-8k for sip@ietf.org; Mon, 09 Jul 2007 20:39:08 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I83kt-00037F-9V for sip@ietf.org; Mon, 09 Jul 2007 20:39:07 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.100]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1I83kn-0007XA-79; Mon, 09 Jul 2007 19:38:57 -0500 Message-ID: <4692D5E7.10705@softarmor.com> Date: Mon, 09 Jul 2007 19:42:15 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] Proposed: delete Guidelines for use of SIP Security milestones References: <46929430.3040306@softarmor.com> <4692A64E.4040405@alcatel-lucent.com> In-Reply-To: <4692A64E.4040405@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sip@ietf.org, ext Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay K. Gurbani wrote: > Wouldn't drafts like sec-flows, sip-certs, sip-sips, domain-certs > all lead towards providing guidelines for the use of SIP > security? Certainly, and these are all both within the charter of the working group, and individually milestoned when the WG develops a consensus to deliver them. >> So I'd like to propose that we delete these milestones for now, and >> bring them back only when we have a concrete proposal on the table >> for what we think we can actually do (and should do) here. > > > It looks like the drafts and a substantive body of the work in > this area is out there; just needs to be organized for a more > amenable deadline. But, I may be mistaken... Otherwise said, you think the milestones in question were essentially made redundandt by the adoption of the more-focused drafts? If so, then we can just delete the milestones in question, as we know we can add new milestones for new "more focused" drafts under our existing charter. Or do we need something like a meta or framework document that brings all these pieces together into a more coherent structure? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 09 21:49:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I84rD-0008Bt-PY; Mon, 09 Jul 2007 21:49:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I84rB-00082T-St for sip-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 21:49:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I84rB-00080E-DZ for sip@ietf.org; Mon, 09 Jul 2007 21:49:37 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I84r7-0004Id-0k for sip@ietf.org; Mon, 09 Jul 2007 21:49:37 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Jul 2007 21:49:33 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKaCkkZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,519,1175486400"; d="scan'208"; a="125626214:sNHT28809170" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6A1nW2l029350; Mon, 9 Jul 2007 21:49:32 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6A1nOs0028937; Tue, 10 Jul 2007 01:49:24 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 21:49:24 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.188]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 21:49:23 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 09 Jul 2007 20:49:19 -0500 To: Dean Willis , "Vijay K. Gurbani" From: "James M. Polk" Subject: Re: [Sip] Proposed: delete Guidelines for use of SIP Security milestones In-Reply-To: <4692D5E7.10705@softarmor.com> References: <46929430.3040306@softarmor.com> <4692A64E.4040405@alcatel-lucent.com> <4692D5E7.10705@softarmor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 10 Jul 2007 01:49:23.0717 (UTC) FILETIME=[8A743B50:01C7C294] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2150; t=1184032172; x=1184896172; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20Proposed=3A=20delete=20Guidelines=20for=20use =20of=20SIP=0A=20=20Security=09milestones |Sender:=20 |To:=20Dean=20Willis=20, =0A=20=20=20=20=20=20= 20=20=22Vijay=20K.=20Gurbani=22=20; bh=1ozr0qsfFeFQ3mjFQEX6AtHNOq90x1m5epjuB3YerSQ=; b=NYYKkmYtuuTpmkNcOt741n9zT9TAzzf3XMf/uebphfeiULMcP4qyZf6bheSE5Rtb+WgeirSL pY6I8ipLY0Ta5cfFE9mXheXtSqTCsiaCFeIyZrdDE3mulurQioXwKXdO; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: sip@ietf.org, ext Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 07:42 PM 7/9/2007, Dean Willis wrote: >Vijay K. Gurbani wrote: > >>Wouldn't drafts like sec-flows, sip-certs, sip-sips, domain-certs >>all lead towards providing guidelines for the use of SIP >>security? > >Certainly, and these are all both within the charter of the working >group, and individually milestoned when the WG develops a consensus >to deliver them. > >>>So I'd like to propose that we delete these milestones for now, >>>and bring them back only when we have a concrete proposal on the table >>>for what we think we can actually do (and should do) here. >> >>It looks like the drafts and a substantive body of the work in >>this area is out there; just needs to be organized for a more >>amenable deadline. But, I may be mistaken... > >Otherwise said, you think the milestones in question were >essentially made redundandt by the adoption of the more-focused >drafts? If so, then we can just delete the milestones in question, >as we know we can add new milestones for new "more focused" drafts >under our existing charter. > >Or do we need something like a meta or framework document that >brings all these pieces together into a more coherent structure? this meta framework was discussed in Dallas and it was basically, without structure at the time - suggested that SIP ought to get its act together and make SIP Security make sense to everyone else. (Dean, you were too busy 'packing heat' to notice ;-) (everyone else might have been packing their canoe from that storm :-D I'll suggest, if possible, there is a call for volunteers to write such a doc, including what's advanced since 65. Therefore I don't want that milestone removed until we can't find someone to write it. Moving the dates out a year seems prudent though. >-- >Dean > > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 10 02:27:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I89Bj-00080a-B0; Tue, 10 Jul 2007 02:27:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I89Bg-00080S-MU for sip-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 02:27:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I89Bg-00080I-5o for sip@ietf.org; Tue, 10 Jul 2007 02:27:04 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I89Bc-00015d-Qf for sip@ietf.org; Tue, 10 Jul 2007 02:27:04 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 980CA3BEA4; Tue, 10 Jul 2007 08:26:59 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05679-02-84; Tue, 10 Jul 2007 08:26:59 +0200 (CEST) Received: from [193.11.30.13] (dhcp-wavelan-vo-13.publik.su.se [193.11.30.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 093C73BE6F; Tue, 10 Jul 2007 08:26:54 +0200 (CEST) Message-ID: <46932654.3050305@it.su.se> Date: Tue, 10 Jul 2007 08:25:24 +0200 From: Fredrik Thulin User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-09.txt References: <5D1A7985295922448D5550C94DE29180013B65F3@DEEXC1U01.de.lucent.com> <468CDD19.1080602@it.su.se> <953beacc0707051753h56e27db6o9c03136d6a7e862a@mail.gmail.com> In-Reply-To: <953beacc0707051753h56e27db6o9c03136d6a7e862a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.061 tagged_above=-99 required=7 tests=[AWL=0.251, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan Mahy wrote: > Hi Fredrik, > > 1) In this version I added text in the current Security Consideration > to help clarify this. See the diffs in Section 13 here: > > http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip-outbound.diff.html Thanks for pointing that out. > I thought I already sent you a message about this topic, but in any > case I will post my response here. The goal is to make sure that *no > new attacks* are made possible by the introduction of this extension. Ok. Adding complexity can easily lessen security though. I don't agree to the principle of adding something meant for security when you're not sure it actually helps in any case [1], so unless you figure out _why_ the draft needs to say these things (and document that, please) I would opt for removing it from the draft. I will however stop nagging about this now, since you are the document editor and not me. /Fredrik [1] like an unnamed Swedish bank allegedly having seven identically configured firewalls connected serially between the Internet and their internal network _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 10 05:14:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8BnQ-0006QM-F1; Tue, 10 Jul 2007 05:14:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8BnO-0006Q3-LI for sip-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 05:14:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8BnO-0006Pu-A2 for sip@ietf.org; Tue, 10 Jul 2007 05:14:10 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8BnJ-0005Wj-L3 for sip@ietf.org; Tue, 10 Jul 2007 05:14:10 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6A9Dnh2004090; Tue, 10 Jul 2007 04:13:56 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 04:13:54 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 11:13:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Jul 2007 11:13:51 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180013F94BC@DEEXC1U01.de.lucent.com> In-Reply-To: <46928F5F.3080502@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for draft-ietf-sip-outbound Thread-Index: AcfCYI/rOmq4J0mUSLKAB3J6ZMYZlAAcfRQQ References: <46928F5F.3080502@softarmor.com> From: "DRAGE, Keith \(Keith\)" To: "Dean Willis" , X-OriginalArrivalTime: 10 Jul 2007 09:13:52.0493 (UTC) FILETIME=[A24881D0:01C7C2D2] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Cullen Jennings , rohan.mahy@Gmail.com Subject: [Sip] RE: WGLC for draft-ietf-sip-outbound X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A reminder: When making comments, please clearly identify: - the section being commented upon, and therefore impacted by any = resolution (extracted text is also useful) - the level of the comment (NIT, minor technical, major technical) - the comment itself - any suggested resolution We will tabulate any reviews according to the above. Regards Keith =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Monday, July 09, 2007 8:41 PM > To: sip@ietf.org > Cc: Cullen Jennings; DRAGE, Keith (Keith); rohan.mahy@gmail.com > Subject: WGLC for draft-ietf-sip-outbound >=20 > I'd like to start a long working group last call for: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-09.txt >=20 > This WGLC period will run through IETF and hopefully close=20 > August 6, 2007. >=20 > Please read the draft and send any comments both to the list=20 > and direct to the authors. >=20 > We'll also have a few minutes on the agenda in Chicago to=20 > discuss the issues if any pop up. >=20 > -- > Dean Willis > co-chair, SIP >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 10 05:21:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8BuH-0002fe-0i; Tue, 10 Jul 2007 05:21:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8BuE-0002fO-Lc for sip-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 05:21:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8BuE-0002fF-AG; Tue, 10 Jul 2007 05:21:14 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I8Btr-0007oZ-Ea; Tue, 10 Jul 2007 05:21:14 -0400 X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1184059217!3184504!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 13525 invoked from network); 10 Jul 2007 09:20:18 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-7.tower-153.messagelabs.com with SMTP; 10 Jul 2007 09:20:18 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l6A9KHHd012167; Tue, 10 Jul 2007 02:20:17 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l6A9KHRL016771; Tue, 10 Jul 2007 04:20:17 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l6A9KFME016735; Tue, 10 Jul 2007 04:20:16 -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, 10 Jul 2007 17:20:13 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B04CD8662@ZMY16EXM66.ds.mot.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180013F94BC@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 4xx message for informing user of an existing subsription thread-index: AcfCYI/rOmq4J0mUSLKAB3J6ZMYZlAAcfRQQAAAiDCA= X-Priority: 1 Priority: Urgent Importance: high References: <46928F5F.3080502@softarmor.com> <5D1A7985295922448D5550C94DE29180013F94BC@DEEXC1U01.de.lucent.com> From: "Avasarala Ranjit-A20990" To: , X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Sip] 4xx message for informing user of an existing subsription X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Which is the appropriate 4xx message that can be used to inform user of an existing subscription?=20 Consider the following use case: User A sends a subscribe message with a particular event and gets subscribed to the service. Now at a later point of time the user is not sure if he has subscribed for a particular service or not. So he might send subscribe again. So is there a way to inform the user that the subscription for that service for the user already exists? Thanks=20 Regards Ranjit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 10 06:45:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8DDu-0003c4-Er; Tue, 10 Jul 2007 06:45:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8DDt-0003bw-FA for sip-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 06:45:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8DDt-0003bo-5R for sip@ietf.org; Tue, 10 Jul 2007 06:45:37 -0400 Received: from mail.strom.cz ([89.111.70.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8DDp-0007vq-O5 for sip@ietf.org; Tue, 10 Jul 2007 06:45:37 -0400 Received: from exalfa.stromtelecom.cz ([172.16.16.10]) by mail.strom.cz with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 12:45:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Changes to the INVITE transaction to address bug 769 Date: Tue, 10 Jul 2007 12:45:31 +0200 Message-ID: <2DD3CA89774593478BC28081C7392595E54693@exalfa.stromtelecom.cz> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Changes to the INVITE transaction to address bug 769 Thread-Index: Ace5LQ4MMTkYKeXvQyOZPpl9CvOVXwJrilRQ References: From: "Bohaty David" To: "Robert Sparks" , "SIP IETF" X-OriginalArrivalTime: 10 Jul 2007 10:45:32.0128 (UTC) FILETIME=[70523600:01C7C2DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hello, I have 2 more thoughts on the draft: First comment is related to the state machine for INVITE server = transaction in which I would say is missing treatment for the transport = error in the "Accepted" state. On transport error there could be new = transition from "Accepted" to "Terminated" with label "Transport Error = Inform TU". Second comment is related to treatment of responses to INVITEs forked by = a proxy further downstream. In that case multiple dialogs can be = established and we should not just accept from or deliver to TU = different 200-299 responses after the first one have been received, but = also 101-199 which can related to the other early dialogs and depending = on the timing can arrive even after the 200-299 for the first dialog. So = for client transaction in the "Completed" state the label "2xx 2xx to = TU" could be changed to "101-299 101-299 to TU". For the server = transaction in the "Accepted" state the label could be changed from "2xx = from TU send response" to "101-299 from TU send response". The TU should = submit 101-199 to the server transaction in the "Accepted" state only if = it is proxy and only when it is related to different dialog than the = already confirmed one (if it is dialog-stateful proxy). David Bohat=FD System Architect SITRONICS Telecom Solutions, Czech Republic a.s.=20 Tel.: +420 226 532 578, Fax: +420 241 480 899 BB Centrum - Beta, Vyskocilova 1481/4, 140 00 Praha 4, Czech Republic www.sitronicsts.com DISCLAIMER This e-mail may be privileged and/or confidential, and the sender does = not waive any related rights and obligations. Any distribution, use or = copying of this e-mail or the information it contains by other than an = intended recipient is unauthorized. If you received this e-mail in = error, please advise me (by return e-mail or otherwise) immediately -----Original Message----- From: Robert Sparks [mailto:rjsparks@estacado.net]=20 Sent: 28 June 2007 04:35 To: SIP IETF Subject: [Sip] Changes to the INVITE transaction to address bug 769 Everyone - I've put together a proposal for addressing the spec bug captured at http://bugs.sipit.net/show_bug.cgi?id=3D769 Please read through http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-00.txt and comment. RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use = sip-implementors@cs.columbia.edu for questions on current sip Use = sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 10 08:32:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Esp-0004Do-6S; Tue, 10 Jul 2007 08:31:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8Esn-0004Cz-DM for sip-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 08:31:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Esl-0004Cf-BV; Tue, 10 Jul 2007 08:31:56 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8Esl-00043T-40; Tue, 10 Jul 2007 08:31:55 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 Jul 2007 08:31:31 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAKYYk0ZAZnmf/2dsb2JhbACIUZ5X X-IronPort-AV: i="4.16,522,1175486400"; d="scan'208"; a="125654528:sNHT27352394" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6ACVUUo009046; Tue, 10 Jul 2007 08:31:30 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6ACVU6a015505; Tue, 10 Jul 2007 12:31:30 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, 10 Jul 2007 08:31:30 -0400 Received: from [10.86.241.35] ([10.86.241.35]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 08:31:30 -0400 Message-ID: <46937C21.6080406@cisco.com> Date: Tue, 10 Jul 2007 08:31:29 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Avasarala Ranjit-A20990 Subject: Re: [Sip] 4xx message for informing user of an existing subsription References: <46928F5F.3080502@softarmor.com> <5D1A7985295922448D5550C94DE29180013F94BC@DEEXC1U01.de.lucent.com> <750BBC72E178114F9DC4872EBFF29A5B04CD8662@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B04CD8662@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2007 12:31:30.0049 (UTC) FILETIME=[3DEFF710:01C7C2EE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1227; t=1184070690; x=1184934690; c=relaxed/simple; s=rtpdkim2001; 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[Sip]=204xx=20message=20for=20informing=20user=20of=2 0an=20existing=20subsription |Sender:=20 |To:=20Avasarala=20Ranjit-A20990=20; bh=g4v+Hhfl3zf5SwjX0nuSANPRXMjEX48/mX82kN22ldg=; b=GCDea5AO9FuCiOG0LubNIwia1pnpIotXTL5etLa5urFksYmiRMc3hvEP414fmqv+GNysrnWc jO1fSGxBrb2dkyjeSD+2eNI7Oksz1i53Yvd8rCfs0yRPmOKAIHWCxtFt; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip@ietf.org, sipping@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There is no error response for this, because it isn't an error. It is quite legal to establish multiple subscriptions for the same event. While in some cases this might be redundant and silly, it is difficult or impossible for the notifier to distinguish the useful cases from the silly ones. Paul Avasarala Ranjit-A20990 wrote: > Hi > > Which is the appropriate 4xx message that can be used to inform user of > an existing subscription? > > Consider the following use case: User A sends a subscribe message with a > particular event and gets subscribed to the service. Now at a later > point of time the user is not sure if he has subscribed for a particular > service or not. So he might send subscribe again. So is there a way to > inform the user that the subscription for that service for the user > already exists? > > Thanks > > > Regards > Ranjit > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 10 10:48:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8H0a-0007RZ-Qp; Tue, 10 Jul 2007 10:48:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8H0Z-0007RT-J4 for sip-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 10:48:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8H0Z-0007Pi-7V for sip@ietf.org; Tue, 10 Jul 2007 10:48:07 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8H0Y-0006z5-N9 for sip@ietf.org; Tue, 10 Jul 2007 10:48:06 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l6AEjYHs023237; Tue, 10 Jul 2007 09:45:34 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l6AEjOa28000; Tue, 10 Jul 2007 09:45:34 -0500 (CDT) Message-ID: <46939B84.5030508@alcatel-lucent.com> Date: Tue, 10 Jul 2007 09:45:24 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Proposed: delete Guidelines for use of SIP Security milestones References: <46929430.3040306@softarmor.com> <4692A64E.4040405@alcatel-lucent.com> <4692D5E7.10705@softarmor.com> In-Reply-To: <4692D5E7.10705@softarmor.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.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org, ext Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: vkg> It looks like the drafts and a substantive body of the work in vkg> this area is out there; just needs to be organized for a more vkg> amenable deadline. But, I may be mistaken... > > Otherwise said, you think the milestones in question were essentially > made redundandt by the adoption of the more-focused drafts? No; I thought that the focused drafts were *leading* to the milestone. But this may be my mis-interpretation of how a WG is chartered. Is it the case that it is one draft per milestone? Or could a series of drafts satisfy one milestone? If the latter, then sec-flows, sip-sips, sip-certs, domain-certs all go towards fulfilling the to fulfil a general milestone that charters the WG to develop "Guidelines for the use of SIP security." > Or do we need something like a meta or framework document that brings > all these pieces together into a more coherent structure? Doesn't S15 of sip-hitchhikers-guide-03 (http://tools.ietf.org/html/draft-ietf-sip-hitchhikers-guide-03#section-15) come close to providing some structure to the various security- related drafts? Plus, if sip-hitchhikers-guide is the last document that the WG produces, then it will keep up -- thanks to Jonathan -- with newer technologies (SAML), protocols (DTLS) and documents as they are adopted by the WG. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 10 11:51:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8HzR-0002Vf-L7; Tue, 10 Jul 2007 11:51:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8HzQ-0002Uo-4d for sip-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 11:51:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8HzP-0002Ug-RG for sip@ietf.org; Tue, 10 Jul 2007 11:50:59 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8HzP-0000Os-Do for sip@ietf.org; Tue, 10 Jul 2007 11:50:59 -0400 Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-1.cisco.com with ESMTP; 11 Jul 2007 10:24:34 +0530 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAABIk0YKS+ej/2dsb2JhbAA X-IronPort-AV: i="4.16,523,1175452200"; d="scan'208"; a="83733208:sNHT67770708" Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6AFouZo009757 for ; Tue, 10 Jul 2007 23:50:56 +0800 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6AFnIjr007125 for ; Tue, 10 Jul 2007 15:50:56 GMT Received: from xmb-hkg-412.apac.cisco.com ([64.104.123.84]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 23:50:34 +0800 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, 10 Jul 2007 23:50:33 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing mechanism transition history info wanted Thread-Index: AcfAUwQLEN5HIFKkSt2LCy0tbB2BKgCtsXyA From: "Rockson Li \(zhengyli\)" To: X-OriginalArrivalTime: 10 Jul 2007 15:50:34.0433 (UTC) FILETIME=[0D585310:01C7C30A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=908; t=1184082656; x=1184946656; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zhengyli@cisco.com; z=From:=20=22Rockson=20Li=20\(zhengyli\)=22=20 |Subject:=20Routing=20mechanism=20transition=20history=20info=20wanted |Sender:=20; bh=5HdKEzewznwRCgB/NBFzK34ce2jII/V78onGijoMnds=; b=b/El+ghXP0Mp0lUglDLi6PiKEKOtrKbhasIC6N7pF52FrLWlEzMQJhtQ4Rp6FY6GelMbTDSa 0hr6to/b/ml1KB2aJ2ajUd7Ceh4vczyLTzIfsSbSaXj0ydl306H3T0KX6oBtP8FTk2nMxErXjR yo+ozRBEyXdKbMIr4u/4mlUHQ=; Authentication-Results: hkg-dkim-2; header.From=zhengyli@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Sip] Routing mechanism transition history info wanted X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Folks, =20 I am seeking why there's a fundamental transition from strict-routing "RFC2543" to loose-routing "RFC3261". =20 I find some text in draft-sparks-sip-looseroute-00 =20 "Several problems with the strict routing mechanisms already available in SIP were identified, including the endpoint's lack of complete knowledge of what that set of proxies should be and the potential loss of information about the desired target due to the strict replacement of the Request-URI." =20 But there's no detail description on these problems, could some one provide me with some more info (link, email, draft, memo) pls? Sorry if question has been raised before, however, I do not find the explicit answer. =20 Thanks =20 Regards, Rockson Li (Zhengyu Li) Software Engineer Cisco R&D Center, Shanghai, PRC Phone(Office) : (8621) 24057003 Email: zhengyli@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 10 12:14:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ILy-0006Iz-6F; Tue, 10 Jul 2007 12:14:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I72q0-00034u-H8 for sip-confirm+ok@megatron.ietf.org; Sat, 07 Jul 2007 01:28:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I72q0-00033T-6h for sip@ietf.org; Sat, 07 Jul 2007 01:28:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I72L1-0003tu-N1 for sip@ietf.org; Sat, 07 Jul 2007 00:56:07 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I72Km-0003Mx-3z for sip@ietf.org; Sat, 07 Jul 2007 00:56:07 -0400 Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-1.cisco.com with ESMTP; 07 Jul 2007 23:28:17 +0530 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkZAM+4jkYKS+eh/2dsb2JhbAATglGYIA X-IronPort-AV: i="4.16,510,1175452200"; d="scan'208,217"; a="83553753:sNHT67601312" Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l674tOFT014249 for ; Sat, 7 Jul 2007 12:55:24 +0800 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l674tNjT015902 for ; Sat, 7 Jul 2007 04:55:23 GMT Received: from xmb-hkg-412.apac.cisco.com ([64.104.123.84]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Jul 2007 12:55:22 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 7 Jul 2007 12:55:18 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: routing mechanism transition history info wanted Thread-Index: AcfAUwQLEN5HIFKkSt2LCy0tbB2BKg== From: "Rockson Li \(zhengyli\)" To: X-OriginalArrivalTime: 07 Jul 2007 04:55:22.0909 (UTC) FILETIME=[069C8CD0:01C7C053] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3433; t=1183784125; x=1184648125; c=relaxed/simple; s=hkgdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zhengyli@cisco.com; z=From:=20=22Rockson=20Li=20\(zhengyli\)=22=20 |Subject:=20routing=20mechanism=20transition=20history=20info=20wanted |Sender:=20; bh=9TQqCIr4RSPWXg6Kq0xzaAYQTpyvNQr0Plc6X98uanQ=; b=JN2M+fAgsH3ViBnJW57nx0ND9ytyGg8FubZn7w97m200xBGe7oW0QiWa0zJA5LqIZwLmGREs 87FwHsHxMiKJ4kboKmA3VTlCF1IPwcWCnlnF9X6Vm8gpXwMBSwDPXP1uWwC9Vd3vR/ywJS4OIX AwfI4sT8rOlPckELiPuzkGCyI=; Authentication-Results: hkg-dkim-1; header.From=zhengyli@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-TMDA-Confirmed: Sat, 07 Jul 2007 01:28:08 -0400 X-Mailman-Approved-At: Tue, 10 Jul 2007 12:14:16 -0400 Subject: [Sip] routing mechanism transition history info wanted X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0000049421==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0000049421== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C053.067AA7B9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C053.067AA7B9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 I am seeking why there's a fundamental transition from strict-routing "RFC2543" to loose-routing "RFC3261". =20 I find some text in draft-sparks-sip-looseroute-00 =20 "Several problems with the strict routing mechanisms already available in SIP were identified, including the endpoint's lack of complete knowledge of what that set of proxies should be and the potential loss of information about the desired target due to the strict replacement of the Request-URI." =20 But there's no detail description on these problems, could some one provide me with some more info (link, email, draft, memo) pls? =20 thanks =20 Regards, Rockson Li (Zhengyu Li) Software Engineer Cisco R&D Center, Shanghai, PRC Phone(Office) : (8621) 24057003 Email: zhengyli@cisco.com =20 ------_=_NextPart_001_01C7C053.067AA7B9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Folks,
 
I am = seeking why=20 there's a fundamental transition from strict-routing "RFC2543" to = loose-routing=20 "RFC3261".
 
I find = some text in=20 draft-sparks-sip-looseroute-00
 
  =20 "Several problems with
   the strict routing mechanisms = already=20 available in SIP were
   identified, including the = endpoint's lack=20 of complete knowledge of
   what that set of proxies should = be and=20 the potential loss of
   information about the desired = target due=20 to the strict replacement of
   the=20 Request-URI."
 
But = there's no=20 detail description on these problems, could some one provide me with = some more=20 info (link, email, draft, memo) pls?
 
thanks
 
Regards,
Rockson Li (Zhengyu Li)

Software=20 Engineer
Cisco R&D Center, Shanghai, PRC
Phone(Office) : = (8621)=20 24057003
Email: zhengyli@cisco.com
 
------_=_NextPart_001_01C7C053.067AA7B9-- --===============0000049421== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0000049421==-- From sip-bounces@ietf.org Tue Jul 10 13:03:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8J7g-000065-8P; Tue, 10 Jul 2007 13:03:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8J7e-0008He-If for sip-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 13:03:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8J7e-0008Ct-61 for sip@ietf.org; Tue, 10 Jul 2007 13:03:34 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8J7d-0002ru-Od for sip@ietf.org; Tue, 10 Jul 2007 13:03:34 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l6AH3TZ7017993; Tue, 10 Jul 2007 12:03:30 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 12:03:30 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 19:03:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Open issue in the hitchhikers guide - seriously! Relation to essential corrections Date: Tue, 10 Jul 2007 19:03:26 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180013F97B9@DEEXC1U01.de.lucent.com> In-Reply-To: <468D5205.5040705@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Open issue in the hitchhikers guide - seriously! Relation to essential corrections Thread-Index: Ace/QbS7w3Qrhtr4QTSxfhYrOn4VbgD0YtoQ References: <468D5205.5040705@cisco.com> From: "DRAGE, Keith \(Keith\)" To: "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 10 Jul 2007 17:03:27.0269 (UTC) FILETIME=[3BC22550:01C7C314] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Your proposal as to what goes into the hitchhiker's guide sounds = sensible to me.=20 I will take the comment about the file nameing convention into the next = version of my essential-corrections draft. Proposals for a naming = convention welcome; if no alternatives I will use something based on = what Jonathan suggests below. I see only two issues: - we seem to be unable to decide what is a fix and what is not. If we = make a decision that something is a fix after the -00 version, we need = to decide whether the continuity of the existing nameing has priority or = the convention of having -fix in the name. - there are already a number of candidate drafts, which obviously do not = yet follow this convention. Again we need to decide whether to keep the = continuity of the existing naming or not. In regard to the fork-loop-fix, this needs to be rediscussed in the WG = and has agenda time at the forthcoming meeting. We are looking to get a website or WIKI up that clearly indicates what = is in progress. Regards Keith > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Thursday, July 05, 2007 9:18 PM > To: IETF SIP List > Subject: [Sip] Open issue in the hitchhikers guide -=20 > seriously! Relation to essential corrections >=20 > I was working on my regular update to the sip hitchhikers guide: > http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers > -guide-02.txt >=20 > and ran into an issue. We are now pursuing the SIP essential=20 > corrections > process: > http://www.ietf.org/internet-drafts/draft-drage-sip-essential- > correction-01.txt >=20 > which has begun to produce internet drafts, that are=20 > draft-ietf-sip-XXX, which will be tracked and produced by the=20 > working group. The question is, do these drafts get included=20 > into the hitchhikers guide or not. My view on this, is NO,=20 > they do not. The reason is that these drafts will never reach=20 > RFC, only the collected essential correction RFC. So, once=20 > that first RFC is produced, the hitchhikers guide would=20 > reference that, and that would encompass everything. >=20 > So, in the interim, what I'd propose is that the running I-D=20 > version of hitchhikers guide have an "essential corrections"=20 > draft, which in fact references all of the I-Ds currently in=20 > line for essential correction.=20 > Unfortunately, its not clear which drafts those are.=20 > record-route-fix, yes. What about loop-fix? Is that going in?=20 > It would be convenient to have a way of clearly knowing what=20 > drafts are going to be for essential corrections. Is the rule: >=20 > draft-ietf-sip-*-fix >=20 > are drafts targeted for essential correction? If so, I think=20 > that should be clearly stated in the=20 > drage-essential-corrections draft. >=20 > Thanks, > Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 10 14:40:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8KdV-00009z-3I; Tue, 10 Jul 2007 14:40:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8KdS-00009m-96 for sip-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 14:40:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8KdQ-00009K-K8 for sip@ietf.org; Tue, 10 Jul 2007 14:40:29 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8KdQ-0007Nl-90 for sip@ietf.org; Tue, 10 Jul 2007 14:40:28 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6AIeMna024191; Tue, 10 Jul 2007 13:40:22 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 13:40:22 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 20:40:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D Action:draft-ietf-sip-hitchhikers-guide-03.txt Date: Tue, 10 Jul 2007 20:40:18 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180013F97D8@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D Action:draft-ietf-sip-hitchhikers-guide-03.txt Thread-Index: Ace/cuDo5Sq6H+DVReuRCp5KSxT5aADrhSmw References: From: "DRAGE, Keith \(Keith\)" To: , "Jonathan Rosenberg" X-OriginalArrivalTime: 10 Jul 2007 18:40:19.0253 (UTC) FILETIME=[C3F88650:01C7C321] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Two comments on the sigcomp part of this document. While Sigcomp is mentioned in passing, RFC 3320 is referenced and this has been updated by RFC 4896. The ROHC people also consider RFC 4077 an integral part of the Sigcomp package and RFC 4896 assumes this. Additionally draft-ietf-rohc-sigcomp-sip is currently with IESG and this, among other things, defines a SIP Via header parameter and this should probably be referenced as a SIP extension.=20 Regards Keith > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Friday, July 06, 2007 3:10 AM > To: i-d-announce@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D Action:draft-ietf-sip-hitchhikers-guide-03.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol=20 > Working Group of the IETF. >=20 > =20 > =20 > Title : A Hitchhiker's Guide to the Session=20 > Initiation Protocol (SIP) > Author(s) : J. Rosenberg > Filename : draft-ietf-sip-hitchhikers-guide-03.txt > Pages : 32 > Date : 2007-07-05 > =20 > =20 > The Session Initiation Protocol (SIP) is the subject of=20 > numerous specifications that have been produced by the IETF. =20 > It can be difficult to locate the right document, or even to=20 > determine the set of Request for Comments (RFC) about SIP. =20 > This specification serves as a guide to the SIP RFC series. =20 > It lists the specifications under the SIP umbrella, briefly=20 > summarizes each, and groups them into categories. > =20 > =20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers > -guide-03.txt > =20 > =20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > =20 > =20 > =20 > =20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-sip-hitchhikers-guide-03.txt". > =20 > =20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > =20 > =20 > =20 > =20 > Internet-Drafts can also be obtained by e-mail. > =20 > =20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE=20 > /internet-drafts/draft-ietf-sip-hitchhikers-guide-03.txt". > =20 > =20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need=20 > "munpack" or > a MIME-compliant mail reader. Different=20 > MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have=20 > been split > up into multiple messages), so check your local=20 > documentation on > how to manipulate these messages. > =20 > =20 > =20 > =20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. > =20 > =20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 10 15:10:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8L67-0001Ft-PA; Tue, 10 Jul 2007 15:10:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8L66-0001Fi-0C for sip-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 15:10:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8L65-0001FZ-IC for sip@ietf.org; Tue, 10 Jul 2007 15:10:05 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8L65-0006ja-2u for sip@ietf.org; Tue, 10 Jul 2007 15:10:05 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 10 Jul 2007 12:10:05 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAO91k0arR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,523,1175497200"; d="scan'208"; a="384730317:sNHT36719936" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6AJA4sv004996; Tue, 10 Jul 2007 12:10:04 -0700 Received: from dwingwxp ([10.32.240.195]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6AJA3ka021554; Tue, 10 Jul 2007 19:10:03 GMT From: "Dan Wing" To: "'Paul Kyzivat'" , Subject: RE: [Sip] SIP Identity using Media Path Date: Tue, 10 Jul 2007 12:10:03 -0700 Message-ID: <009d01c7c325$ebbd0c70$c3f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4692B8B2.9010206@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfCedaQ3R/kx3kpQnWqHVyyQVn/9wAqZVzQ DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4745; t=1184094604; x=1184958604; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20SIP=20Identity=20using=20Media=20Path |Sender:=20; bh=QlAU/SBBjcg6lRfUGxOQ+w8nGFZE2/fihoq4YidnZ4c=; b=L5IssGKZTggKVA1y8yo+p6Ow6Anhqiv/wa/Fc+fr4Hdd7GisIA9t5vrJqPuSVRWD12wF3uBF CO+UR5j2Lv0QbJNh556ruZ8bA9/0/x/WZrDrLwiRqo3qukbcv1nLp1/R; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > Dan, > > I just took a look at this. Thanks. > I have a few questions: > > 1) Because you only sign the selected attributes from the > SDP, the rest is not secured. That seems like an acceptable > restriction if you assume there will be a media-terminating > SBC in the path. > > But what about other body parts? I gather they won't be > signed either. Right. > That seems like a potential problem as we start to identify > need for various extra body parts. That's a good point, which I hadn't considered. The existing SIP-Identity (RFC4474) could be used to sign such SIP requests, so long as they don't contain any SDP bodyparts (if they contain SDP bodyparts and RFC4474 signs them, you're back at the problems with RFC4474 signatures being broken by SBCs and B2BUAs). So, this doesn't seem to be ideal. What I would suggest, and can write up if it sounds sensical, is to sign each individual non-SDP MIME part. This would be accomplished by creating two new SIP headers, "Identity-part", which contains the Content-IDs of the non-SDP MIME parts that are signed, and Identity-Part-Signature, which contains the signature over those parts. For example, if a SIP UA sent an Invite like this: INVITE ... From: Alice@example.com To: john@example.net Content-Type: multipart/mixed; boundary=X ... --X Content-Type: application/sdp v=0 o=- 6418913922105372816 2105372818 IN IP4 192.0.2.1 s=example2 c=IN IP4 192.0.2.1 t=0 0 m=audio 54113 RTP/SAVP 0 a=setup:active a=connection:new a=fingerprint:SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB --X Content-Type: text/plain John, let's talk about the upcoming press release. --X-- The authentication service would add the SIP headers described in the existing -sip-identity-media-00: Identity-Fingerprints: 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB Identity-Media: "ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U=" and I am proposing it would add the missing Content-Id headers (so that each MIME part can be clearly identified) and two new SIP headers (Identity-Part, Identity-Part-Signature). The Identity-Part-Signature contains a signature over all of the MIME bodyparts listed in the Identity-Part header (shown below with "$" on the left-most column): INVITE ... From: Alice@example.com To: john@example.net Content-Type: multipart/mixed; boundary=X Identity-Fingerprints: 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB Identity-Media: "ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U=" Identity-Part: ab111 Identity-Part-Signature: "ncEjfecq2jefmceejcech3233rjfejncecjkeu3fjefje93jnakjjqknenceuHEc jfeqcnekueri283jfkjfcnencehutiujfe9383mjfejkequie839283jnecneqce q11jfjfkcaqncerEJCEJCMEQMCECEJKEFJEKFjejffke" ... --X Content-Type: application/sdp Content-Id: ab000 v=0 o=- 6418913922105372816 2105372818 IN IP4 192.0.2.1 s=example2 c=IN IP4 192.0.2.1 t=0 0 m=audio 54113 RTP/SAVP 0 a=setup:active a=connection:new a=fingerprint:SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB --X $ Content-Type: text/plain $ Content-Id: ab111 $ $ John, let's talk about the upcoming press release. $ --X-- Thoughts on this approach? We might also consider using the authentication service's S/MIME keys (not the UA's S/MIME keys), which may well be cleaner. > 2) What about "offerless" initial INVITEs? > > 3) What about messages that don't use SDP at all? Both of these situations would be handled in the same way RFC4474 (SIP-Identity) handles them: For offerless invites, you would rely on Connected-Identity to provide the assertion of the initiator's identity. For messages with no SDP, you can sign non-SDP bodyparts (as I describe above). If the message has no body to sign, there isn't any magic we can do using the media path to authenticate the message came from the claimed peer -- because of course there is no media path. Both RFC4474 and RFC3893 (AIB) share this same problem. When there is no body, all you can do is sign headers (including the Date: header) in an effort to prevent replay attacks. This is what SIP-Identity-Media, RFC4474, and RFC3893 (AIB) all do. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 10 17:11:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Mzs-0002AH-Lo; Tue, 10 Jul 2007 17:11:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8Mzr-00028u-Ej for sip-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 17:11:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Mzq-00024E-K3 for sip@ietf.org; Tue, 10 Jul 2007 17:11:46 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Mzm-0003is-AX for sip@ietf.org; Tue, 10 Jul 2007 17:11:46 -0400 Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l6ALBd1T016285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jul 2007 16:11:39 -0500 (CDT) Received: from [135.112.131.41] (volker-hohpc.mh.lucent.com [135.112.131.41]) by umail.lucent.com (8.13.8/TPES) with ESMTP id l6ALBdm6019262 for ; Tue, 10 Jul 2007 16:11:39 -0500 (CDT) Message-ID: <4693F5F9.2010608@bell-labs.com> Date: Tue, 10 Jul 2007 17:11:21 -0400 From: Volker Hilt User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sip] I-D ACTION:draft-hilt-sip-correction-503-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Folks, I've submitted a new version of the "Essential Correction to the Session Initiation Protocol (SIP) 503 (Service Unavailable) Response": http://www.ietf.org/internet-drafts/draft-hilt-sip-correction-503-01.txt Here is a quick change log: - Added a discussion on server maintenance vs. overload control - Proposed an alternative change (alternative 1) that is based on introducing an new response code for overload. All comments, thoughts are very welcome. Thanks, Volker _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 10 17:14:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8N2C-0006E8-0u; Tue, 10 Jul 2007 17:14:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8N2A-0006E0-DV for sip-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 17:14:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8N2A-0006Ds-3f for sip@ietf.org; Tue, 10 Jul 2007 17:14:10 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I8N26-0003lJ-IV for sip@ietf.org; Tue, 10 Jul 2007 17:14:10 -0400 Received: (qmail invoked by alias); 10 Jul 2007 21:14:05 -0000 Received: from p54987F39.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.127.57] by mail.gmx.net (mp002) with SMTP; 10 Jul 2007 23:14:05 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19lASlJ4NBlIS4r+7Lc7FYqlne+ZP8cpbsl/cP2Rt egaTWGCIqpYytz Message-ID: <4693F697.6080204@gmx.net> Date: Tue, 10 Jul 2007 23:13:59 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Jeff Hodges Subject: Re: [Sip] Comments draft-ietf-sip-saml-02 - marc willekens - "clarification" items References: <67043E463DDBFD4A8087ED940BFF756B017C1FD0@BRU0038A.ww018.siemens.net> <4692C3F1.10704@neustar.biz> In-Reply-To: <4692C3F1.10704@neustar.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jeff, Hi Marc, a comment below: Jeff Hodges wrote: > > -------- Original Message -------- > > Subject: [Sip] Comments draft-ietf-sip-saml-02 > > Date: Thu, 21 Jun 2007 16:47:46 +0200 > > From: Willekens, Marc > > To: > > > > > > [Page 3], Introduction > > > > Is this document only about assertion for the authorization or also for > > the authentication? > > authorization. > > > > [Page 12] > > > > Domain name for Alice: example.com or foo.com?? (same comment for other > > figures) > > oops, good catch. foo.com. > > > > Authentication service or Assertion service or both? > > authentication service -- the term is from rfc4474. > > > > [Page 13], 6.1. Assertion Fetch profile > > > > Is this the only planned profile or will other profiles be defined and > > added later? > > My personal present thinking is that there are other possible SIP SAML > profiles, e.g. see the appendix in -sip-saml-02 of other use cases, > but that they should likely be specified separately in their own drafts. > We have investigated other profiles. The SIP SAML profile has the very nice characteristic that it is nicely aligned with SIP Identity -- an already understood and agreed model. > > Will there also be a push based model? Will it then be > > "pushed" as part of the SIP message? > > This is something for the WG to think about. One _can_, in theory, > have the UAC assert some information and attach a SAML assertion to a > SIP request (e.g. Invite) body making such a statement. Thus this > approach could only be used by UACs because (1) only UACs may place > data in the SIP request body, and (2) there are vociferous objections > in the SIP WG to schemes whereby SIP intermediaries may place BLOBs > (binary large objects) in SIP header fields. See also.. > > [Sip] wrt SIP Saml Review by Jiri Kuthan - "missing scenarios" > http://www1.ietf.org/mail-archive/web/sip/current/msg19793.html > > > We could specify this for UACs-only, and the other http-uri-based > fetch approach for, as it is currently, intermediates or UACs. > > However, before we go to the effort, what's the in-actuality demand > for doing so? Has anyone implemented the rfc4474 authentication > service role in the UAC and is it being used? > > With regard to the ability of the SIP UA to attach an assertion there is another document that describes an extension to this SAML profile. See http://tools.ietf.org/html/draft-jennings-sipping-pay-05 > > [Page 13], 6.1.1. URN > > > > What's the current consensus for the urn? > > No one has objected to what is in the spec, although no one has > commented specifically on it as yet, either. > > > > > [Page 17], 6.1.3. > > > > ...sender and Authentication service (AS) may be separate or... ??? > > > > How will the AS and sender be combined? > > See the last paragraph on page 5 of rfc4474.. > > "This specification allows either a user agent or a proxy server to > provide identity services and to verify identities." > But for the use case where the end host attaches the assertion it might be more realistic to assume that the assertion is added to the body of the SIP message. This is currently not provided. This again is described in the SIP Pay draft. > > > [Page 22], 6.1.4.1.4. > > > > AttributeStatement is indicated. But what about Authentication and > > Authorization Decision statement? > > This particular SIP SAML Profile doesn't specify use of those > statements, but they are not explicitly excluded either. Conceivably > someone could cook up a use case for them and make use of it in a > site-specific manner, or we might find use case and then can specify > their use more easily. > > If we do want to explicitly do this we should perhaps add that such > statements MAY be present, but their meaning is defined outside of > this profile. > > We have received this question several times already. I believe we should explicitly enable the support since the AuthStatement provides more information than SIP Identity. > > [Page31] > > > > This RFC draft talks about assertions. But how can an identity be > > asserted only by considering a device, e.g. in case a device is stolen > > or temporary used by someone else? At VON 2000, H. Schulzrinne has > > already indicated that something as fingerprint has to be added for a > > device with a changing set of owners. > > Although a valid thought, that being the question of the nature of the > actual authn mechanism between the UAC and the registration service, > it is out of scope of this specification. In fact, this draft nowhere > states that the subject's identity is asserted only by the device (UAC). > That's clearly outside the scope of this document. > > thanks for your review, > > =JeffH > Ciao Hannes > > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 10 17:44:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8NVL-00076y-QT; Tue, 10 Jul 2007 17:44:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8NVI-00076K-E0 for sip-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 17:44:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8NVI-00076A-4X; Tue, 10 Jul 2007 17:44:16 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8NVG-0005C1-Ue; Tue, 10 Jul 2007 17:44:16 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id E095B329EF; Tue, 10 Jul 2007 21:44:14 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8NVG-0001Pg-Qq; Tue, 10 Jul 2007 17:44:14 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Tue, 10 Jul 2007 17:44:14 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sip@ietf.org Subject: [Sip] Last Call: draft-ietf-sip-answermode (Requesting Answering Modes for the Session Initiation Protocol (SIP)) to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The IESG has received a request from the Session Initiation Protocol WG (sip) to consider the following document: - 'Requesting Answering Modes for the Session Initiation Protocol (SIP) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-08-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-answermode-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14099&rfc_flag=0 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 10 21:24:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8QwT-0007YO-DH; Tue, 10 Jul 2007 21:24:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8QwS-0007YI-35 for sip-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 21:24:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8QwR-0007Y8-Og for sip@ietf.org; Tue, 10 Jul 2007 21:24:31 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8QwR-0002y1-GS for sip@ietf.org; Tue, 10 Jul 2007 21:24:31 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1I8QwQ-0000aE-Ii; Tue, 10 Jul 2007 20:24:30 -0500 Message-ID: <4694324E.8010606@softarmor.com> Date: Tue, 10 Jul 2007 20:28:46 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] Proposed: delete Guidelines for use of SIP Security milestones References: <46929430.3040306@softarmor.com> <4692A64E.4040405@alcatel-lucent.com> <4692D5E7.10705@softarmor.com> <46939B84.5030508@alcatel-lucent.com> In-Reply-To: <46939B84.5030508@alcatel-lucent.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org, ext Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay K. Gurbani wrote: > Dean Willis wrote: > vkg> It looks like the drafts and a substantive body of the work in > vkg> this area is out there; just needs to be organized for a more > vkg> amenable deadline. But, I may be mistaken... >> >> Otherwise said, you think the milestones in question were essentially >> made redundandt by the adoption of the more-focused drafts? > > No; I thought that the focused drafts were *leading* to the milestone. > But this may be my mis-interpretation of how a WG is chartered. Is > it the case that it is one draft per milestone? Or could a series > of drafts satisfy one milestone? Depends on how your milestones are written -- ours are generally structured "one milestone, one draft" rather like riots and Texas Rangers. Usually a charter will have major planks, like "Clarify SIP security" and then milestones (aka "deliverables") will be approved if they support a plank. > Doesn't S15 of sip-hitchhikers-guide-03 > (http://tools.ietf.org/html/draft-ietf-sip-hitchhikers-guide-03#section-15) > come close to providing some structure to the various security- > related drafts? Plus, if sip-hitchhikers-guide is the last document > that the WG produces, then it will keep up -- thanks to Jonathan -- > with newer technologies (SAML), protocols (DTLS) and documents as > they are adopted by the WG. Good question. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 10 21:32:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8R3m-00006k-Od; Tue, 10 Jul 2007 21:32:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8R3l-000061-Li for sip-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 21:32:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8R3l-00005t-CB for sip@ietf.org; Tue, 10 Jul 2007 21:32:05 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8R3h-0001BF-2n for sip@ietf.org; Tue, 10 Jul 2007 21:32:05 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1I8R3g-0000bF-5m; Tue, 10 Jul 2007 20:32:00 -0500 Message-ID: <4694340F.8090902@softarmor.com> Date: Tue, 10 Jul 2007 20:36:15 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: sip@ietf.org X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Sip] Need reviewers for draft-ietf-lemonade-streaming-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is a pretty interesting draft, and I'd like to get a couple of "sip perspective" reviewers to take a look at it and provide feedback to the lemonade working group. http://www.ietf.org/internet-drafts/draft-ietf-lemonade-streaming-02.txt Abstract This document describes a method for streaming multimedia attachments received by a resource constrained and/or mobile device from an IMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio e-mail content. The document describes a profile for making use of the IMAP URLAUTH extension (RFC 4467), the Network Announcement SIP Media Service (RFC 4240), and the Media Server Control Markup Language (RFC 4722). The document also defines a new IMAP METADATA entry. if you're willing to perform a review, please contact myself and Eric Burger. Thanks, -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 11 02:20:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8VYy-00071m-9w; Wed, 11 Jul 2007 02:20:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8VYv-00071c-EF for sip-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 02:20:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8VYv-00071U-3t for sip@ietf.org; Wed, 11 Jul 2007 02:20:33 -0400 Received: from an-out-0708.google.com ([209.85.132.241]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8VYr-00067R-SN for sip@ietf.org; Wed, 11 Jul 2007 02:20:33 -0400 Received: by an-out-0708.google.com with SMTP id c17so328418anc for ; Tue, 10 Jul 2007 23:20:29 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=mZyVnLCyrJcbphh2ScUiW4Lb2nPpxNfVNa+La/th9bYJTEoVai/B+Y8J2IfriyQfI2D6+cboQbtzIYcA2Z1ByAGUzNDkz12QtgfAHg3gXIBhiihzAxfO8C2zAxlU1q7KXkPH6K1+VWbURop8sWQBJDPF1EIDumaTTPxC8Stk3Nc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=TeV5CrG7EFK7hmSh/rK0tbgPthEKE6elKThftpSJyXxzY6EHhnNo6NpUGxvBNfYh01qIGb5rKbx2IKxOmQq3x+2SkdzTTKmjABLOCUo9/T3z3ST4l7C/dDC1sFl6QPvHk2iXMil+/ZtweWRA8L+hgmPABdevPFnAZ93/boPxLJQ= Received: by 10.100.142.12 with SMTP id p12mr2595908and.1184134829459; Tue, 10 Jul 2007 23:20:29 -0700 (PDT) Received: by 10.100.198.15 with HTTP; Tue, 10 Jul 2007 23:20:29 -0700 (PDT) Message-ID: <52a9bccc0707102320j2fdabddav302ae6af31a3eff6@mail.gmail.com> Date: Wed, 11 Jul 2007 11:50:29 +0530 From: "Jagan Mohan" To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Sip] Need clarification on Retry-After header being sent as part of 500 response to second INVITE with lower Cseq number X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, In RFC 3261, Section 14.2, Para 2, it's mentioned that Retry-After header must be sent as part of 500 response to a second INVITE with lower Cseq number. In the same RFC, section 20.1, Table 3, it's mentioned that sending of Retry-After header is optional while sending a 500 response. I feel the statements are contradicting each other. Could you please clarify? If the first case is an exception for sending Retry-After header, then the same should have been mentioned in Table 3 as well. Thanks, Jagan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 11 04:19:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8XQ1-0005kQ-U6; Wed, 11 Jul 2007 04:19:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8XQ0-0005kA-2E for sip-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 04:19:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8XPz-0005k2-JV for sip@ietf.org; Wed, 11 Jul 2007 04:19:27 -0400 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8XPz-0001VE-0n for sip@ietf.org; Wed, 11 Jul 2007 04:19:27 -0400 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1I8XPn-0003H4-6d; Wed, 11 Jul 2007 01:19:15 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Sip] Last Call: draft-ietf-sip-answermode (Requesting Answering Modes for the Session Initiation Protocol (SIP)) to Proposed Standard Date: Wed, 11 Jul 2007 01:18:44 -0700 Message-ID: <0D4E483A0E6E0A46861409E5D6C2011C572ED7@sea02-mxc01.citel.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Last Call: draft-ietf-sip-answermode (Requesting Answering Modes for the Session Initiation Protocol (SIP)) to Proposed Standard Thread-index: AcfDO319DQaC6/NJRYCT9mJqt+6tkAAVw6qA References: From: "Steve Langstaff" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ietf@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Section 4.3.2 states: The Answer-Mode and Priv-Answer-Mode header fields have equivalent functions, except that Priv-Answer-Mode requests a higher level of privilege in granting the answering mode specified by the request. Would it not make sense to have a single header that performs both of these equivalent functions, using a parameter (e.g. 'high' or 'level=3Dhigh') to distinguish between the two? This might have the following benefits: 1) The document would be smaller. 2) The implementation may be simpler. 3) If the need for more than just two levels of privilege were found in the future then this could be easily extended, rather than following the current pattern of needing another header, e.g. Really-High-Priv-Answer-Mode: 4) 'Priv' might be misinterpreted to mean 'private' rather than 'privilege' by the unfamiliar. =20 > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org]=20 > Sent: 10 July 2007 22:44 > To: IETF-Announce > Cc: sip@ietf.org > Subject: [Sip] Last Call: draft-ietf-sip-answermode=20 > (Requesting Answering Modes for the Session Initiation=20 > Protocol (SIP)) to Proposed Standard >=20 > The IESG has received a request from the Session Initiation=20 > Protocol WG > (sip) to consider the following document: >=20 > - 'Requesting Answering Modes for the Session Initiation Protocol =20 > (SIP) ' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and=20 > solicits final comments on this action. Please send=20 > substantive comments to the ietf@ietf.org mailing lists by=20 > 2007-08-05. Exceptionally, comments may be sent to=20 > iesg@ietf.org instead. In either case, please retain the=20 > beginning of the Subject line to allow automated sorting. >=20 > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-sip-answermode-04.txt >=20 >=20 > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dvie > w_id&dTag=3D14099&rfc_flag=3D0 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 11 05:03:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Y6B-0003pj-Rn; Wed, 11 Jul 2007 05:03:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8Y6A-0003pZ-2w for sip-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 05:03:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Y69-0003o8-Jx for sip@ietf.org; Wed, 11 Jul 2007 05:03:01 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I8Y69-0002RT-Ah for sip@ietf.org; Wed, 11 Jul 2007 05:03:01 -0400 Received: (qmail invoked by alias); 11 Jul 2007 09:02:51 -0000 Received: from p54987267.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.114.103] by mail.gmx.net (mp003) with SMTP; 11 Jul 2007 11:02:51 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19/uJUKFkx/uHOO3qjSBRJ3olQFuPYCtCM0VaFRag FKXOIw3Ia6ZFAn Message-ID: <46949CB5.4070703@gmx.net> Date: Wed, 11 Jul 2007 11:02:45 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Sip] SIP SAML IANA Consideration Sction X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I compiled a first version of the IANA consideration section. Please find it here: http://www.tschofenig.priv.at:8080/saml-sip/issue22 Ciao Hannes _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 11 07:25:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8aK0-0000H4-Ff; Wed, 11 Jul 2007 07:25:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8aJz-0000Gi-0W for sip-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 07:25:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8aJy-0000GV-7v for sip@ietf.org; Wed, 11 Jul 2007 07:25:26 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8aJx-0005WB-NQ for sip@ietf.org; Wed, 11 Jul 2007 07:25:26 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 11 Jul 2007 13:25:08 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jul 2007 13:25:08 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [Sip] Updated acr-code Date: Wed, 11 Jul 2007 13:25:07 +0200 Message-Id: <9886E5FCA6D76549A3011068483A4BD41176DC@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <468DA5DB.2070402@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Updated acr-code Thread-Index: Ace/dCB1YlqCQ4zXT7qAzIGdXFudgQEMUALA From: "Jesske, R" To: , X-OriginalArrivalTime: 11 Jul 2007 11:25:08.0307 (UTC) FILETIME=[230C1A30:01C7C3AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dear all, I still have a problem that the "header" privacy value is not included. Due to the lack of a correct description what header privacy means = within RFC3323 my understanding is still that header also includes all = headers that should be deleted or anonymised when the "user" privacy = values is used. And it is also not clear if header includes the "id" privacy or not. With regard to this arguments the ACR Response has also to be sent when = "header" is used. What to do now? Also there is a different understanding what is meant by anonymous = within the world. That is a regulation dependent issue. So From my = understanding the use of the 433 should not to restrictive. If somebody = want to use the header within his domain then let him use it. That is my understanding. So one solution could be that a sentence like based on network policy or = regulatory requirements ACR could also apply based on other indications = sent like the 'header' private value. An other issue is that there should be work started to clarify the use = of RFC 3323, 3325, 4244 and others defining privacy values. Best Regards Roland Deutsche Telekom AG T-Com, Zentrum Technik Einf=FChrung Roland Jesske Gateways, Protokolle, Konvergenz, TE33-6 Deutsche-Telekom-Allee 1, 64295 Darmstadt, Raum 314(Besucheradresse) Postfach, 64307 Darmstadt (Postanschrift) 06151 83-5940 (Tel.) 06151 83-4577 (Fax) E-Mail: r.jesske@t-com.net http://www.t-com.de Registerrechtliche Unternehmensangaben: Deutsche Telekom AG Aufsichtsrat: Dr. Klaus Zumwinkel (Vorsitzender) Vorstand: Ren=E9 Obermann (Vorsitzender),=20 Dr. Karl-Gerhard Eick (stellvertretender=20 Vorsitzender), Hamid Akhavan, Timotheus H=F6ttges, L othar Pauly, Thomas Sattelberger=20 Handelsregister: Amtsgericht Bonn HRB 6794, Sitz der Gesellschaft: Bonn WEEE-Reg.-Nr.: DE50478376 *************************************************************** Deutsche Telekom AG Supervisory Board: Dr. Klaus Zumwinkel (Chairman) Board of Management: Ren=E9 Obermann (Chairman),=20 Dr. Karl-Gerhard Eick (Deputy Chairman), Hamid Akhavan, Timotheus H=F6ttges,=20 Lothar Pauly, Thomas Sattelberger Commercial register: Amtsgericht Bonn HRB 6794, corporate seat: Bonn WEEEreg.no: DE50478376 > -----Urspr=FCngliche Nachricht----- > Von: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Gesendet: Freitag, 6. Juli 2007 04:16 > An: IETF SIP List > Betreff: [Sip] Updated acr-code >=20 >=20 > I've submitted an update to the acr-code draft. You can pick it up at: > http://www.ietf.org/internet-drafts/draft-ietf-sip-acr-code-05.txt >=20 > This draft addresses AD comments raised during AD evaluation. The=20 > primary change is that, previously, the specification=20 > indicated that a=20 > P-A-ID header field with an anonymous URI in it would count as an=20 > anonymous request. However, P-A-ID doesn't reflect what the=20 > user wants,=20 > which is strictly in the From. Consequently, PAID is really=20 > irrelevant=20 > here. So, this condition was removed. >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 11 09:19:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8c6K-0008OT-Q0; Wed, 11 Jul 2007 09:19:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8c6J-0008OM-0y for sip-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 09:19:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8c6I-0008OE-N2 for sip@ietf.org; Wed, 11 Jul 2007 09:19:26 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8c6E-0008Cp-BI for sip@ietf.org; Wed, 11 Jul 2007 09:19:26 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 11 Jul 2007 06:19:22 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKJ1lEarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,526,1175497200"; d="scan'208"; a="384915408:sNHT27123408" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6BDJLR4009198; Wed, 11 Jul 2007 06:19:21 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6BDJLXH002923; Wed, 11 Jul 2007 13:19:21 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); Wed, 11 Jul 2007 06:19:21 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 06:19:21 -0700 Message-ID: <4694D8DD.60106@cisco.com> Date: Wed, 11 Jul 2007 09:19:25 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] I-D Action:draft-ietf-sip-hitchhikers-guide-03.txt References: <5D1A7985295922448D5550C94DE29180013F97D8@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180013F97D8@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2007 13:19:21.0184 (UTC) FILETIME=[17AE2600:01C7C3BE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1204; t=1184159961; x=1185023961; 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[Sip]=20I-D=20Action=3Adraft-ietf-sip-hitchhikers-gui de-03.txt |Sender:=20; bh=fzyPCYIZgqPjTHzbMUweZnSOh4+Km8WWsFCE+RpMyxw=; b=GaEvrFQIgy2e2IDv2rd815RsSlaLTsaiTw/stUZ2DmKgCWB0WmhBe0Z6OARNFKzMZdJh2ptF D9CRgdWA68Xlyek49NRLq+4rSTVHC2SaKfJvHX1aIYPYByAp3/vEsronUSK3NRf0V8dHdq/Y4R oaYa0455flEAhZqR9yDBP1m0I=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. DRAGE, Keith (Keith) wrote: > Two comments on the sigcomp part of this document. > > While Sigcomp is mentioned in passing, RFC 3320 is referenced and this > has been updated by RFC 4896. The ROHC people also consider RFC 4077 an > integral part of the Sigcomp package and RFC 4896 assumes this. I added a reference to 4896 along with 3320 as the reference for sigcomp. However our objective is not to do the hitchhikers guide to sigcomp; so as long as rfc4896 references 4077 people can follow that chain. > > Additionally draft-ietf-rohc-sigcomp-sip is currently with IESG and > this, among other things, defines a SIP Via header parameter and this > should probably be referenced as a SIP extension. What??? Can this be??? Keith - did you let another working group define a SIP extension? ;) Reference added. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 11 09:20:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8c7i-0004WZ-O6; Wed, 11 Jul 2007 09:20:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8c7h-0004WU-Ku for sip-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 09:20:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8c7h-0004WM-AB for sip@ietf.org; Wed, 11 Jul 2007 09:20:53 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8c7g-00007Q-V0 for sip@ietf.org; Wed, 11 Jul 2007 09:20:53 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 11 Jul 2007 06:20:26 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKJ1lEarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,526,1175497200"; d="scan'208"; a="384915756:sNHT27929548" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6BDKPY4018942; Wed, 11 Jul 2007 06:20:25 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6BDKPXH003742; Wed, 11 Jul 2007 13:20:25 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 06:20:25 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 06:20:24 -0700 Message-ID: <4694D91D.6060205@cisco.com> Date: Wed, 11 Jul 2007 09:20:29 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] Open issue in the hitchhikers guide - seriously! Relation to essential corrections References: <468D5205.5040705@cisco.com> <5D1A7985295922448D5550C94DE29180013F97B9@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180013F97B9@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2007 13:20:25.0060 (UTC) FILETIME=[3DC0DA40:01C7C3BE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1326; t=1184160025; x=1185024025; 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=20[Sip]=20Open=20issue=20in=20the=20hitchhikers=20guide =20-=20seriously!=20Relation=0A=20to=20essential=20corrections |Sender:=20; bh=cZFUm2RoUOuNSOf+Ej5OfveWvAafXIGexk+ir4cYbEQ=; b=fFilR+DZKkmzwkY6zQyi3HdIOTYY37zZlpnYS5QzXe/ipG0MxXTBOAYG5ng6+HWZHEUWX/lA 9zM7OeUp30xqbXnG5Erav2KNnR+kIf50+RwbVspi4LVPIKlvwbC+o1S3; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org DRAGE, Keith (Keith) wrote: > Your proposal as to what goes into the hitchhiker's guide sounds > sensible to me. > > I will take the comment about the file nameing convention into the > next version of my essential-corrections draft. Proposals for a > naming convention welcome; if no alternatives I will use something > based on what Jonathan suggests below. I see only two issues: > > - we seem to be unable to decide what is a fix and what is not. If we > make a decision that something is a fix after the -00 version, we > need to decide whether the continuity of the existing nameing has > priority or the convention of having -fix in the name. I think the convention has priority. SO if we decide its not a fix, it gets renamed. > > - there are already a number of candidate drafts, which obviously do > not yet follow this convention. Again we need to decide whether to > keep the continuity of the existing naming or not. I favor the convention. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 11 09:31:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cI1-0007cl-DH; Wed, 11 Jul 2007 09:31:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8cHz-0007V7-6u for sip-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 09:31:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cHy-0007Uw-3u for sip@ietf.org; Wed, 11 Jul 2007 09:31:30 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8cHx-0000Tv-PY for sip@ietf.org; Wed, 11 Jul 2007 09:31:30 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 11 Jul 2007 06:31:28 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHJ4lEarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,526,1175497200"; d="scan'208"; a="502026105:sNHT36715508" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6BDVSPE003498; Wed, 11 Jul 2007 06:31:28 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6BDVSXH013948; Wed, 11 Jul 2007 13:31:28 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); Wed, 11 Jul 2007 06:31:28 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 06:31:28 -0700 Message-ID: <4694DBB4.8020500@cisco.com> Date: Wed, 11 Jul 2007 09:31:32 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Jesske, R" Subject: Re: AW: [Sip] Updated acr-code References: <9886E5FCA6D76549A3011068483A4BD41176DC@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD41176DC@S4DE8PSAAQB.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2007 13:31:28.0109 (UTC) FILETIME=[C8F619D0:01C7C3BF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2431; t=1184160688; x=1185024688; 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=20AW=3A=20[Sip]=20Updated=20acr-code |Sender:=20; bh=WI0zayhXga9JPOeAnKMvezExKS/7tWrQvN7WhHhXIOM=; b=W0w6s1dc6weu2FC/mBw2zw6kOjNIQ8U7XUWvh7WBnE9l5O035qHYJ65JWqQ7KtkNrdB4eXsR vQB+U8PR8UC/sOotbVsQRMI7EXYBOc1+qKyqyKrH3ixCkC4RYACEq++L; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jesske, R wrote: > Dear all, I still have a problem that the "header" privacy value is > not included. Due to the lack of a correct description what header > privacy means within RFC3323 my understanding is still that header > also includes all headers that should be deleted or anonymised when > the "user" privacy values is used. My understanding is different. > > And it is also not clear if header includes the "id" privacy or not. Well, some recent work has attempted to clarify all of this: http://www.ietf.org/internet-drafts/draft-munakata-sip-privacy-guideline-00.txt though I disagree with parts of it, since there is really unclear relationship between these values. Its still not obvious what they mean. Indeed, according to the draft, 'header' does include P-A-ID, but 'user' does not. SO based on that I should include header in the list in acr-code. But I think it needs to be reversed. > > With regard to this arguments the ACR Response has also to be sent > when "header" is used. > > What to do now? Well, one answer is to punt this entirely. Acr-code can define a more abstract normative rule, and then privacy-guideline, should it be adopted, can have text that is very explicit on how it relates to ACR-code. > > Also there is a different understanding what is meant by anonymous > within the world. That is a regulation dependent issue. So From my > understanding the use of the 433 should not to restrictive. If > somebody want to use the header within his domain then let him use > it. That is my understanding. > > So one solution could be that a sentence like based on network policy > or regulatory requirements ACR could also apply based on other > indications sent like the 'header' private value. The danger here is that we could end up with non-interoperable systems. If the UAC things a privacy value is NOT implying user anonymity, but a proxy in the terminating domain does think it means that, and thus it sends a 433, the UAC has no remedy and it thinks an error has occurred. -JOnathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 11 09:32:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cJK-0001tt-Gz; Wed, 11 Jul 2007 09:32:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8cJJ-0001to-7J for sip-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 09:32:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cJI-0001tg-U2 for sip@ietf.org; Wed, 11 Jul 2007 09:32:52 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8cJE-0000DM-EV for sip@ietf.org; Wed, 11 Jul 2007 09:32:52 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l6BDWAwk022203; Wed, 11 Jul 2007 08:32:41 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 08:32:34 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 15:32:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D Action:draft-ietf-sip-hitchhikers-guide-03.txt Date: Wed, 11 Jul 2007 15:32:26 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180013F9B00@DEEXC1U01.de.lucent.com> In-Reply-To: <4694D8DD.60106@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D Action:draft-ietf-sip-hitchhikers-guide-03.txt Thread-Index: AcfDvi46wBYriluLRxm5yeiSjmDAngAAS0Bg References: <5D1A7985295922448D5550C94DE29180013F97D8@DEEXC1U01.de.lucent.com> <4694D8DD.60106@cisco.com> From: "DRAGE, Keith \(Keith\)" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 11 Jul 2007 13:32:28.0245 (UTC) FILETIME=[ECCE2050:01C7C3BF] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan wrote: > DRAGE, Keith (Keith) wrote: > > Two comments on the sigcomp part of this document. > >=20 > > While Sigcomp is mentioned in passing, RFC 3320 is=20 > referenced and this=20 > > has been updated by RFC 4896. The ROHC people also consider=20 > RFC 4077=20 > > an integral part of the Sigcomp package and RFC 4896 assumes this. >=20 > I added a reference to 4896 along with 3320 as the reference=20 > for sigcomp. However our objective is not to do the=20 > hitchhikers guide to sigcomp; so as long as rfc4896=20 > references 4077 people can follow that chain. >=20 Fine. > > Additionally draft-ietf-rohc-sigcomp-sip is currently with IESG and=20 > > this, among other things, defines a SIP Via header=20 > parameter and this=20 > > should probably be referenced as a SIP extension. >=20 > What??? >=20 > Can this be??? >=20 > Keith - did you let another working group define a SIP extension? >=20 > ;) > =20 It followed the IANA registry rules for SIP header parameters, which do = not require it to come to SIP. However in parallel with the ROHC WGLC, = we did issue the WGLC on the SIP list, as we did ask Adam Roach to do a = review as a designated SIP expert. If people want to handle these = differently in the future them please shout. > Reference added. Fine Regards Keith > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Wednesday, July 11, 2007 2:19 PM > To: DRAGE, Keith (Keith) > Cc: sip@ietf.org > Subject: Re: [Sip] I-D Action:draft-ietf-sip-hitchhikers-guide-03.txt >=20 > inline. >=20 > DRAGE, Keith (Keith) wrote: > > Two comments on the sigcomp part of this document. > >=20 > > While Sigcomp is mentioned in passing, RFC 3320 is=20 > referenced and this=20 > > has been updated by RFC 4896. The ROHC people also consider=20 > RFC 4077=20 > > an integral part of the Sigcomp package and RFC 4896 assumes this. >=20 > I added a reference to 4896 along with 3320 as the reference=20 > for sigcomp. However our objective is not to do the=20 > hitchhikers guide to sigcomp; so as long as rfc4896=20 > references 4077 people can follow that chain. >=20 > >=20 > > Additionally draft-ietf-rohc-sigcomp-sip is currently with IESG and=20 > > this, among other things, defines a SIP Via header=20 > parameter and this=20 > > should probably be referenced as a SIP extension. >=20 > What??? >=20 > Can this be??? >=20 > Keith - did you let another working group define a SIP extension? >=20 > ;) >=20 > Reference added. >=20 > -Jonathan R. >=20 >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 11 09:44:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cUQ-0004sB-PY; Wed, 11 Jul 2007 09:44:22 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8cUQ-0004s5-4s for sip-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 09:44:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cUP-0004rx-PZ for sip@ietf.org; Wed, 11 Jul 2007 09:44:21 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8cUP-0000lc-7g for sip@ietf.org; Wed, 11 Jul 2007 09:44:21 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l6BDhKjw026668; Wed, 11 Jul 2007 08:43:22 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 08:43:18 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 15:43:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Updated acr-code Date: Wed, 11 Jul 2007 15:43:14 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180013F9B0E@DEEXC1U01.de.lucent.com> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD41176DC@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Updated acr-code Thread-Index: Ace/dCB1YlqCQ4zXT7qAzIGdXFudgQEMUALAAAbry+A= References: <468DA5DB.2070402@cisco.com> <9886E5FCA6D76549A3011068483A4BD41176DC@S4DE8PSAAQB.mitte.t-com.de> From: "DRAGE, Keith \(Keith\)" To: "Jesske, R" , X-OriginalArrivalTime: 11 Jul 2007 13:43:15.0935 (UTC) FILETIME=[6EDBC6F0:01C7C3C1] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Please note that this document is formally in IESG last call. Therefore = any comments that you want to "stick" should also be made to = ietf@ietf.org in accordance with the following instructions. That = doesn't preclude discussion on this list - just means that they may not = be taken into account. Regards Keith The IESG has received a request from the Session Initiation Protocol WG (sip) to consider the following document: - 'Rejecting Anonymous Requests in the Session Initiation Protocol (SIP) = ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits = final comments on this action. Please send substantive comments to the = ietf@ietf.org mailing lists by 2007-07-19. Exceptionally, comments may = be sent to iesg@ietf.org instead. In either case, please retain the = beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-acr-code-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D14158&rfc_flag=3D0=20 > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net]=20 > Sent: Wednesday, July 11, 2007 12:25 PM > To: jdrosen@cisco.com; sip@ietf.org > Subject: AW: [Sip] Updated acr-code >=20 > Dear all, > I still have a problem that the "header" privacy value is not=20 > included. > Due to the lack of a correct description what header privacy=20 > means within RFC3323 my understanding is still that header=20 > also includes all headers that should be deleted or=20 > anonymised when the "user" privacy values is used. >=20 > And it is also not clear if header includes the "id" privacy or not. >=20 > With regard to this arguments the ACR Response has also to be=20 > sent when "header" is used. >=20 > What to do now? >=20 > Also there is a different understanding what is meant by=20 > anonymous within the world. That is a regulation dependent=20 > issue. So From my understanding the use of the 433 should not=20 > to restrictive. If somebody want to use the header within his=20 > domain then let him use it. > That is my understanding. >=20 > So one solution could be that a sentence like based on=20 > network policy or regulatory requirements ACR could also=20 > apply based on other indications sent like the 'header' private value. >=20 > An other issue is that there should be work started to=20 > clarify the use of RFC 3323, 3325, 4244 and others defining=20 > privacy values. >=20 > Best Regards >=20 > Roland >=20 > Deutsche Telekom AG > T-Com, Zentrum Technik Einf=FChrung > Roland Jesske > Gateways, Protokolle, Konvergenz, TE33-6=20 > Deutsche-Telekom-Allee 1, 64295 Darmstadt, Raum=20 > 314(Besucheradresse) Postfach, 64307 Darmstadt (Postanschrift) > 06151 83-5940 (Tel.) > 06151 83-4577 (Fax) > E-Mail: r.jesske@t-com.net > http://www.t-com.de >=20 > Registerrechtliche Unternehmensangaben: > Deutsche Telekom AG > Aufsichtsrat: Dr. Klaus Zumwinkel (Vorsitzender) > Vorstand: Ren=E9 Obermann (Vorsitzender), Dr. Karl-Gerhard Eick=20 > (stellvertretender Vorsitzender), Hamid Akhavan, Timotheus=20 > H=F6ttges, L othar Pauly, Thomas Sattelberger > Handelsregister: Amtsgericht Bonn HRB 6794, Sitz der=20 > Gesellschaft: Bonn > WEEE-Reg.-Nr.: DE50478376 > *************************************************************** > Deutsche Telekom AG > Supervisory Board: Dr. Klaus Zumwinkel (Chairman) Board of=20 > Management: Ren=E9 Obermann (Chairman), Dr. Karl-Gerhard Eick=20 > (Deputy Chairman), Hamid Akhavan, Timotheus H=F6ttges, Lothar=20 > Pauly, Thomas Sattelberger Commercial register: Amtsgericht=20 > Bonn HRB 6794, corporate seat: Bonn > WEEEreg.no: DE50478376 >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Gesendet: Freitag, 6. Juli 2007 04:16 > > An: IETF SIP List > > Betreff: [Sip] Updated acr-code > >=20 > >=20 > > I've submitted an update to the acr-code draft. You can=20 > pick it up at: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-acr-code-05.txt > >=20 > > This draft addresses AD comments raised during AD evaluation. The=20 > > primary change is that, previously, the specification=20 > indicated that a=20 > > P-A-ID header field with an anonymous URI in it would count as an=20 > > anonymous request. However, P-A-ID doesn't reflect what the user=20 > > wants, which is strictly in the From. Consequently, PAID is really=20 > > irrelevant here. So, this condition was removed. > >=20 > > -Jonathan R. > > --=20 > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ=20 > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 11 10:09:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8csw-0007zk-7L; Wed, 11 Jul 2007 10:09:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8csu-0007zO-2p for sip-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 10:09:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cst-0007zB-7U for sip@ietf.org; Wed, 11 Jul 2007 10:09:39 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8css-0001Lr-P3 for sip@ietf.org; Wed, 11 Jul 2007 10:09:38 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6BE7iYB013254 for ; Wed, 11 Jul 2007 09:07:45 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 09:07:21 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 16:07:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jul 2007 16:07:16 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180013F9B3A@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Hop limit diagnostics Thread-Index: AcfDxMmAH4k0yTi8Q9i3/pvfpjBfaA== From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 11 Jul 2007 14:07:17.0613 (UTC) FILETIME=[CA2A61D0:01C7C3C4] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Sip] Hop limit diagnostics X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) We have a couple of related milestones on our charter that we are stuck on: Jul 2007 Diagnostic Responses for SIP Errors to WGLC (PS) =20 Nov 2007 Diagnostic Responses for SIP Errors to IESG (PS)=20 The draft associated with this expired some way back, but you can find it at: http://tools.ietf.org/html/draft-ietf-sip-hop-limit-diagnostics-03 The charter item is for a more general document that covers other error situations as well as hop limit issues. However the editor's hit the intractable problem in that any transport decision is made on the request on any particular hop, and if UDP is used on the request, it will also be used on the response on any particular hop. This was specified based on the assumption that any response would not be significantly larger than the request, but as soon as we start putting lots of useful diagnostic information in the response, this no longer applies. So we are now looking for the way forward. Options include: A) It is not worth the extra cycles - delete the milestone. B) Limit the diagnostic information (to say around 100 bytes in the worst case). If so will it contain enough useful information to make it usable. C) Solve the transport problem. And no, we do not have a debate here on deprecating UDP. We've been there and done that. Unless people can come up with something that looks achievable, the working group chairs are currently favouring A) above. Comments please. Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 11 10:14:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cxh-0006K3-Ms; Wed, 11 Jul 2007 10:14:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8cxg-0006Jx-Bz for sip-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 10:14:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cxg-0006Jp-2X for sip@ietf.org; Wed, 11 Jul 2007 10:14:36 -0400 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8cxc-0001Kd-Pw for sip@ietf.org; Wed, 11 Jul 2007 10:14:36 -0400 Received: from [127.0.0.1] (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id D79EA6C017; Wed, 11 Jul 2007 10:13:53 -0400 (EDT) Subject: Re: [Sip] Proposed: delete Guidelines for use of SIP Security milestones From: Scott Lawrence To: Dean Willis In-Reply-To: <4694324E.8010606@softarmor.com> References: <46929430.3040306@softarmor.com> <4692A64E.4040405@alcatel-lucent.com> <4692D5E7.10705@softarmor.com> <46939B84.5030508@alcatel-lucent.com> <4694324E.8010606@softarmor.com> Content-Type: text/plain Organization: Pingtel Corp. Date: Wed, 11 Jul 2007 10:14:29 -0400 Message-Id: <1184163269.3516.1.camel@scott.skrb.org> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sip@ietf.org, ext Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Tue, 2007-07-10 at 20:28 -0500, Dean Willis wrote: > Vijay K. Gurbani wrote: > > Dean Willis wrote: > > vkg> It looks like the drafts and a substantive body of the work in > > vkg> this area is out there; just needs to be organized for a more > > vkg> amenable deadline. But, I may be mistaken... > >> > >> Otherwise said, you think the milestones in question were essentially > >> made redundandt by the adoption of the more-focused drafts? > > > > No; I thought that the focused drafts were *leading* to the milestone. > > But this may be my mis-interpretation of how a WG is chartered. Is > > it the case that it is one draft per milestone? Or could a series > > of drafts satisfy one milestone? > > Depends on how your milestones are written -- ours are generally > structured "one milestone, one draft" rather like riots and Texas Rangers. Well, I think that the drafts Vijay listed are all parts of that picture. Perhaps what is needed is to get a volunteer to edit a document that pulls them all together into a single document to address the deliverable? -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs Chief Technology Officer - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 11 11:07:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dmO-0005sQ-ES; Wed, 11 Jul 2007 11:07:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8dmN-0005sL-3V for sip-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 11:06:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dmM-0005sD-QJ for sip@ietf.org; Wed, 11 Jul 2007 11:06:58 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8dmI-0002c8-Dk for sip@ietf.org; Wed, 11 Jul 2007 11:06:58 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6BF6l6R059080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Jul 2007 10:06:51 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <5D1A7985295922448D5550C94DE29180013F9B3A@DEEXC1U01.de.lucent.com> References: <5D1A7985295922448D5550C94DE29180013F9B3A@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <221D492E-F8B7-4B1F-8F15-F0381CB20EAD@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Hop limit diagnostics Date: Wed, 11 Jul 2007 10:06:42 -0500 To: "DRAGE, Keith \(Keith\)" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org For completeness - haven't we also talked about requests in the opposite direction and diagnostics by indirection? I know each of those have their own thorny problems, but the tradeoff against really large responses may make them the least unpalatable. And I remember conversations, but not much list traffic about a series of best-effort provisionals to carry the information. I still think its worth figuring out, but won't throw fits if the WG decides to put it off to the indefinite future. RjS On Jul 11, 2007, at 9:07 AM, DRAGE, Keith ((Keith)) wrote: > (As WG chair) > > We have a couple of related milestones on our charter that we are > stuck > on: > > Jul 2007 Diagnostic Responses for SIP Errors to WGLC (PS) > Nov 2007 Diagnostic Responses for SIP Errors to IESG (PS) > > The draft associated with this expired some way back, but you can find > it at: > > http://tools.ietf.org/html/draft-ietf-sip-hop-limit-diagnostics-03 > > The charter item is for a more general document that covers other > error > situations as well as hop limit issues. > > However the editor's hit the intractable problem in that any transport > decision is made on the request on any particular hop, and if UDP is > used on the request, it will also be used on the response on any > particular hop. This was specified based on the assumption that any > response would not be significantly larger than the request, but as > soon > as we start putting lots of useful diagnostic information in the > response, this no longer applies. > > So we are now looking for the way forward. Options include: > > A) It is not worth the extra cycles - delete the milestone. > > B) Limit the diagnostic information (to say around 100 bytes in the > worst case). If so will it contain enough useful information to > make it > usable. > > C) Solve the transport problem. And no, we do not have a debate > here on deprecating UDP. We've been there and done that. > > Unless people can come up with something that looks achievable, the > working group chairs are currently favouring A) above. > > Comments please. > > > Keith > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 11 12:16:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8erD-0001qR-6i; Wed, 11 Jul 2007 12:16:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8er3-0001SX-4j for sip-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 12:15:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8er2-0001S9-L2; Wed, 11 Jul 2007 12:15:52 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8er2-0004oa-DQ; Wed, 11 Jul 2007 12:15:52 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 3D4A52AC7F; Wed, 11 Jul 2007 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8eqD-0005oh-TR; Wed, 11 Jul 2007 12:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 11 Jul 2007 12:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-location-conveyance-08.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Location Conveyance for the Session Initiation Protocol Author(s) : J. Polk, B. Rosen Filename : draft-ietf-sip-location-conveyance-08.txt Pages : 38 Date : 2007-7-11 This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The extension covers end to end conveyance as well as location-based routing, where proxy servers make routing decisions based on the location of the SIP user agents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-location-conveyance-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-location-conveyance-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-11112608.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-location-conveyance-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-location-conveyance-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-11112608.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Wed Jul 11 12:46:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8fKU-0000GT-Dc; Wed, 11 Jul 2007 12:46:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8fKS-0000GJ-I5 for sip-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 12:46:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8fKS-0000GB-7H; Wed, 11 Jul 2007 12:46:16 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8fKR-0006U4-W4; Wed, 11 Jul 2007 12:46:16 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 5126E2AC84; Wed, 11 Jul 2007 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8eqE-0005p0-1a; Wed, 11 Jul 2007 12:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 11 Jul 2007 12:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-certs-04.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Certificate Management Service for The Session Initiation Protocol (SIP) Author(s) : C. Jennings, et al. Filename : draft-ietf-sip-certs-04.txt Pages : 30 Date : 2007-7-11 This draft defines a Credential Service that allows Session Initiation Protocol (SIP) User Agents (UAs) to use a SIP package to discover the certificates of other users. This mechanism allows user agents that want to contact a given Address-of-Record (AOR) to retrieve that AOR's certificate by subscribing to the Credential Service, which returns an authenticated response containing that certificate. The Credential Service also allows users to store and retrieve their own certificates and private keys. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-certs-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-certs-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-certs-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-11115257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-certs-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-certs-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-11115257.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Wed Jul 11 14:15:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8gj0-0006hp-SK; Wed, 11 Jul 2007 14:15:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8giN-0005ZN-Ve for sip-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 14:15:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8giN-0005YB-9s; Wed, 11 Jul 2007 14:15:03 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8giN-0001F9-1M; Wed, 11 Jul 2007 14:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 9B6D317610; Wed, 11 Jul 2007 18:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8giM-0003D9-5Q; Wed, 11 Jul 2007 14:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 11 Jul 2007 14:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-e2m-sec-06.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : End-to-middle Security in the Session Initiation Protocol (SIP) Author(s) : K. Ono, S. Tachimoto Filename : draft-ietf-sip-e2m-sec-06.txt Pages : 30 Date : 2007-7-11 Some services provided by intermediaries depend on their ability to inspect a message body in the Session Initiation Protocol (SIP). When sensitive information is included in the message body, a SIP User Agent (UA) needs to protect it from other intermediaries than those that the UA agreed to disclose it to. This document proposes a mechanism for securing information passed between an end user and intermediaries using S/MIME. It also proposes mechanisms for a UA to discover intermediaries which need to inspect an S/MIME-secured message body, or to receive the message body with data integrity This specification is approved at the proposed standards level due to the IANA registration requirements. Is is of sufficient quality for that level, however, the use of this mechanism in this specification are considered experimental. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-e2m-sec-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-e2m-sec-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-e2m-sec-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-11133452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-e2m-sec-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-e2m-sec-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-11133452.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Wed Jul 11 14:33:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8gzk-0001ah-Js; Wed, 11 Jul 2007 14:33:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8gzj-0001ZQ-JX for sip-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 14:32:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8gzi-0001YQ-Sn for sip@ietf.org; Wed, 11 Jul 2007 14:32:58 -0400 Received: from mail7.exchange.microsoft.com ([131.107.1.27] helo=mail.exchange.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8gze-0002P5-FL for sip@ietf.org; Wed, 11 Jul 2007 14:32:58 -0400 Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) by DF-GWY-07.exchange.corp.microsoft.com (157.54.63.164) with Microsoft SMTP Server (TLS) id 8.1.154.1; Wed, 11 Jul 2007 11:32:53 -0700 Received: from df-mlt-04.exchange.corp.microsoft.com (157.54.68.219) by df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) with Microsoft SMTP Server (TLS) id 8.1.154.1; Wed, 11 Jul 2007 11:32:53 -0700 Received: from DF-MASTIFF-MSG.exchange.corp.microsoft.com ([157.54.61.165]) by df-mlt-04.exchange.corp.microsoft.com ([157.54.68.219]) with mapi; Wed, 11 Jul 2007 11:32:39 -0700 From: Sean Olson To: "DRAGE, Keith (Keith)" , "sip@ietf.org" Date: Wed, 11 Jul 2007 11:32:39 -0700 Thread-Topic: Hop limit diagnostics Thread-Index: AcfDxMmAH4k0yTi8Q9i3/pvfpjBfaAAJOeSQ Message-ID: <4C1596FBF66C67478BCFE7B3F81FC1E01D45BAC556@DF-MASTIFF-MSG.exchange.corp.microsoft.com> References: <5D1A7985295922448D5550C94DE29180013F9B3A@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180013F9B3A@DEEXC1U01.de.lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Subject: [Sip] RE: Hop limit diagnostics X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Why not: D) Define a diagnostic information mechanism that works with TCP and accept= that it will not work with UDP -----Original Message----- From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] Sent: Wednesday, July 11, 2007 7:07 AM To: sip@ietf.org Subject: [Sip] Hop limit diagnostics (As WG chair) We have a couple of related milestones on our charter that we are stuck on: Jul 2007 Diagnostic Responses for SIP Errors to WGLC (PS) Nov 2007 Diagnostic Responses for SIP Errors to IESG (PS) The draft associated with this expired some way back, but you can find it at: http://tools.ietf.org/html/draft-ietf-sip-hop-limit-diagnostics-03 The charter item is for a more general document that covers other error situations as well as hop limit issues. However the editor's hit the intractable problem in that any transport decision is made on the request on any particular hop, and if UDP is used on the request, it will also be used on the response on any particular hop. This was specified based on the assumption that any response would not be significantly larger than the request, but as soon as we start putting lots of useful diagnostic information in the response, this no longer applies. So we are now looking for the way forward. Options include: A) It is not worth the extra cycles - delete the milestone. B) Limit the diagnostic information (to say around 100 bytes in the worst case). If so will it contain enough useful information to make it usable. C) Solve the transport problem. And no, we do not have a debate here on deprecating UDP. We've been there and done that. Unless people can come up with something that looks achievable, the working group chairs are currently favouring A) above. Comments please. Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 11 15:42:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8i5I-000222-PR; Wed, 11 Jul 2007 15:42:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8i5G-0001vQ-Ez for sip-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 15:42:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8i5E-0001nR-Jf for sip@ietf.org; Wed, 11 Jul 2007 15:42:44 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8i56-0005Yk-UT for sip@ietf.org; Wed, 11 Jul 2007 15:42:44 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l6BJg2hv026136; Wed, 11 Jul 2007 14:42:17 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 14:42:17 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 21:42:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: Conveyance -08 and Geolocation-Error header Date: Wed, 11 Jul 2007 21:42:13 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180013F9C26@DEEXC1U01.de.lucent.com> In-Reply-To: <83C6385C-BC62-4AB6-AD1B-14020A7CBAD5@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: Conveyance -08 and Geolocation-Error header Thread-Index: AcfAj16OAf9htMBtTbeixDBxk18ppwDY/56A References: <81A2A0E9-FDF4-48EC-92E4-C02B6BD05948@cs.columbia.edu><468E899A.7070806@cisco.com><468F078A.8070604@cisco.com> <83C6385C-BC62-4AB6-AD1B-14020A7CBAD5@cs.columbia.edu> From: "DRAGE, Keith \(Keith\)" To: "Henning Schulzrinne" , "Paul Kyzivat" X-OriginalArrivalTime: 11 Jul 2007 19:42:14.0527 (UTC) FILETIME=[94DC18F0:01C7C3F3] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: sip@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org You wrote: > In general, I think we have learned that we should help=20 > people with debugging distributed systems with distributed=20 > responsibility, as otherwise they'll either struggle or=20 > invent private mechanisms to include this information. (See=20 > SER for the the latter.)=20 If we are not careful here we end up back in the issue of responses being significantly larger than the request sent on a particular hop, and therefore the old problem of what happens on UDP when this occurs. Regards Keith > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Sent: Saturday, July 07, 2007 1:06 PM > To: Paul Kyzivat > Cc: sip@ietf.org; James M. Polk > Subject: Re: [Sip] Re: Conveyance -08 and Geolocation-Error header >=20 >=20 > On Jul 6, 2007, at 11:24 PM, Paul Kyzivat wrote: >=20 > > Is it really reasonable to expect a proxy that inserts a=20 > location to=20 > > remember what location it inserted, in enough detail to=20 > diagnose why=20 > > it might have been messed up? I presume it would have to=20 > reconstruct=20 > > what the location would have been based in information in the=20 > > response. It may not be possible to reconstruct the exact=20 > same value,=20 > > because the UAC may have moved in the meantime. I guess the=20 > inserted=20 > > location would have to be by reference, but the URL of the=20 > reference=20 > > may itself not be easily reconstructed, and multiple=20 > queries of it may=20 > > not return the same result. > > > > IMO it would be much clearer to include the location itself in the=20 > > response. And if the location had been passed by reference,=20 > it might=20 > > be better to pass it by value in the response, so that there is no=20 > > possibility of the value changing. > > >=20 > I tend to agree that this would be better. The=20 > reference-to-value translation may not always be feasible: If=20 > a proxy inserts a location reference and a downstream proxy=20 > finds a problem, it can't insert a value (except by the data=20 > URL mechanism I have been mentioning...). >=20 >=20 > > OTOH that might result in divulging the location to nodes=20 > upstream of=20 > > the one that included it. If it was passed by reference=20 > then the node=20 > > that had inserted it could remove the reference in the=20 > response. But=20 > > if it is passed back by value that isn't allowed. > > > > The alternative is that the proxy will have to retain the location=20 > > until the completion of the transaction. Maybe that's ok,=20 > but if its=20 > > only to diagnose an occasional glitch I get it doesn't get done. >=20 > My assumption was that most locations will be inserted by the=20 > UAC rather than a proxy. In those cases, retaining the=20 > information is probably not a big deal, since the UAC will=20 > generally only have one. >=20 > In summary, I think returning as much information about the=20 > erroneous location information as possible seems best, i.e.,=20 > both the location information and the party that inserted it.=20 > This avoids the "who the heck put that bogus location=20 > information in there?" problem. >=20 > In general, I think we have learned that we should help=20 > people with debugging distributed systems with distributed=20 > responsibility, as otherwise they'll either struggle or=20 > invent private mechanisms to include this information. (See=20 > SER for the the latter.) >=20 >=20 > > > > Paul > > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 11 17:39:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8juC-0001uQ-Rh; Wed, 11 Jul 2007 17:39:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8juB-0001uA-1a for sip-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 17:39:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8juA-0001u2-Nq for sip@ietf.org; Wed, 11 Jul 2007 17:39:26 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8ju6-0008MQ-2h for sip@ietf.org; Wed, 11 Jul 2007 17:39:26 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 11 Jul 2007 14:39:21 -0700 X-IronPort-AV: i="unknown"; a="385094912:sNHT0" 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 l6BLdLGe023835; Wed, 11 Jul 2007 14:39:21 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6BLd2l4007479; Wed, 11 Jul 2007 21:39:21 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 17:39:12 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.20.175]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 17:39:12 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 11 Jul 2007 16:39:04 -0500 To: "DRAGE, Keith \(Keith\)" , "Henning Schulzrinne" , "Paul Kyzivat" From: "James M. Polk" Subject: RE: [Sip] Re: Conveyance -08 and Geolocation-Error header In-Reply-To: <5D1A7985295922448D5550C94DE29180013F9C26@DEEXC1U01.de.luce nt.com> References: <81A2A0E9-FDF4-48EC-92E4-C02B6BD05948@cs.columbia.edu> <468E899A.7070806@cisco.com> <468F078A.8070604@cisco.com> <83C6385C-BC62-4AB6-AD1B-14020A7CBAD5@cs.columbia.edu> <5D1A7985295922448D5550C94DE29180013F9C26@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 11 Jul 2007 21:39:12.0139 (UTC) FILETIME=[EBAEB5B0:01C7C403] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4873; t=1184189961; x=1185053961; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Sip]=20Re=3A=20Conveyance=20-08=20and=20Geolocation- Error=20header |Sender:=20; bh=6sovK7pjjI2aqEUHo7058OEgGIMpgqBOn1Z+sYGEnww=; b=ZYxI2HKbXIbGh+KuUXWqym0c3FQzAP+MWNSruIDlMVxL2xIdyCuws/mp11Ykv//SDmxMLkXt e1BRFeqEBrI80JiPKCzyq+yqhemf6sI2LaDhS8rRHVLzVXfzzkUc94MiPPpChvIRhV3FRt5b6B +vx58/kCn4E9dWpeMlfAe36ps=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 02:42 PM 7/11/2007, DRAGE, Keith \(Keith\) wrote: >You wrote: > > > In general, I think we have learned that we should help > > people with debugging distributed systems with distributed > > responsibility, as otherwise they'll either struggle or > > invent private mechanisms to include this information. (See > > SER for the the latter.) > >If we are not careful here we end up back in the issue of responses >being significantly larger than the request sent on a particular hop, >and therefore the old problem of what happens on UDP when this occurs. one crazy (or stupid?) idea is - now that there is a more robust Geolocation-Error header in responses (verses a Reason or Warning header), a *(SEMI CAType) could be added to it to allow a Location Recipient to include each CAType it had a problem with or wasn't there that was considered necessary to use the location in the first place. This idea doesn't include the element values, just the elements - which saves bytes, and doesn't reveal the element values either. It also doesn't include a message body in the response. I think this is more information than is presently there, making for better decisions by location inserters or for troubleshooting. The only security risk I see with this is the listing of some of the CAtypes that were in the original request. Presumably there were other elements in the request, so little (if anything) can be extracted from this knowledge if intercepted. >Regards > >Keith > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Saturday, July 07, 2007 1:06 PM > > To: Paul Kyzivat > > Cc: sip@ietf.org; James M. Polk > > Subject: Re: [Sip] Re: Conveyance -08 and Geolocation-Error header > > > > > > On Jul 6, 2007, at 11:24 PM, Paul Kyzivat wrote: > > > > > Is it really reasonable to expect a proxy that inserts a > > location to > > > remember what location it inserted, in enough detail to > > diagnose why > > > it might have been messed up? I presume it would have to > > reconstruct > > > what the location would have been based in information in the > > > response. It may not be possible to reconstruct the exact > > same value, > > > because the UAC may have moved in the meantime. I guess the > > inserted > > > location would have to be by reference, but the URL of the > > reference > > > may itself not be easily reconstructed, and multiple > > queries of it may > > > not return the same result. > > > > > > IMO it would be much clearer to include the location itself in the > > > response. And if the location had been passed by reference, > > it might > > > be better to pass it by value in the response, so that there is no > > > possibility of the value changing. > > > > > > > I tend to agree that this would be better. The > > reference-to-value translation may not always be feasible: If > > a proxy inserts a location reference and a downstream proxy > > finds a problem, it can't insert a value (except by the data > > URL mechanism I have been mentioning...). > > > > > > > OTOH that might result in divulging the location to nodes > > upstream of > > > the one that included it. If it was passed by reference > > then the node > > > that had inserted it could remove the reference in the > > response. But > > > if it is passed back by value that isn't allowed. > > > > > > The alternative is that the proxy will have to retain the location > > > until the completion of the transaction. Maybe that's ok, > > but if its > > > only to diagnose an occasional glitch I get it doesn't get done. > > > > My assumption was that most locations will be inserted by the > > UAC rather than a proxy. In those cases, retaining the > > information is probably not a big deal, since the UAC will > > generally only have one. > > > > In summary, I think returning as much information about the > > erroneous location information as possible seems best, i.e., > > both the location information and the party that inserted it. > > This avoids the "who the heck put that bogus location > > information in there?" problem. > > > > In general, I think we have learned that we should help > > people with debugging distributed systems with distributed > > responsibility, as otherwise they'll either struggle or > > invent private mechanisms to include this information. (See > > SER for the the latter.) > > > > > > > > > > Paul > > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 11 17:58:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8kCJ-00007i-6A; Wed, 11 Jul 2007 17:58:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8kCH-00007U-UT for sip-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 17:58:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8kCH-00007L-Kc; Wed, 11 Jul 2007 17:58:09 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8kCD-0000TV-BN; Wed, 11 Jul 2007 17:58:09 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.101]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1I8kCC-0001vU-J5; Wed, 11 Jul 2007 16:58:04 -0500 Message-ID: <46955265.6080808@softarmor.com> Date: Wed, 11 Jul 2007 16:57:57 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Steve Langstaff Subject: Re: [Sip] Last Call: draft-ietf-sip-answermode (Requesting Answering Modes for the Session Initiation Protocol (SIP)) to Proposed Standard References: <0D4E483A0E6E0A46861409E5D6C2011C572ED7@sea02-mxc01.citel.com> In-Reply-To: <0D4E483A0E6E0A46861409E5D6C2011C572ED7@sea02-mxc01.citel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: sip@ietf.org, ietf@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks for the feedback. Steve Langstaff wrote: > Section 4.3.2 states: > > The Answer-Mode and Priv-Answer-Mode header fields have equivalent > functions, except that Priv-Answer-Mode requests a higher level of > privilege in granting the answering mode specified by the request. > > Would it not make sense to have a single header that performs both of > these equivalent functions, using a parameter (e.g. 'high' or > 'level=high') to distinguish between the two? Sure would. If I recall correctly, that approach was taken by an earlier version of the draft, about ten revisions back. For some reason I never fully understood, people argued that distinct header field names made for less of a security issue than having parameterized privilege levels. Since we don't have separate option tags for negotiating support for the header fields independently, it strikes me as making no difference either way. Argument went back and forth for a while, and the WG seemed to develop consensus around the approach as documented (different header field names) > This might have the following benefits: > > 1) The document would be smaller. True. > 2) The implementation may be simpler. Probably not. > 3) If the need for more than just two levels of privilege were found in > the future then this could be easily extended, rather than following the > current pattern of needing another header, e.g. > Really-High-Priv-Answer-Mode: Also true, but the effort of documenting another header field name is no higher than that required to document a new parameter value on a header field name. > 4) 'Priv' might be misinterpreted to mean 'private' rather than > 'privilege' by the unfamiliar. Also true, but it's shorter. The WG settled on this syntax as a compromise between readability and compactness. -- dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 11 20:33:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8mci-0000ye-Vl; Wed, 11 Jul 2007 20:33:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8mch-0000yR-DE for sip-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 20:33:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8mch-0000yG-39 for sip@ietf.org; Wed, 11 Jul 2007 20:33:35 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8mcd-0004ZL-N7 for sip@ietf.org; Wed, 11 Jul 2007 20:33:35 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6C0XKeN027384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 11 Jul 2007 20:33:21 -0400 (EDT) In-Reply-To: References: <81A2A0E9-FDF4-48EC-92E4-C02B6BD05948@cs.columbia.edu> <468E899A.7070806@cisco.com> <468F078A.8070604@cisco.com> <83C6385C-BC62-4AB6-AD1B-14020A7CBAD5@cs.columbia.edu> <5D1A7985295922448D5550C94DE29180013F9C26@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] Re: Conveyance -08 and Geolocation-Error header Date: Wed, 11 Jul 2007 20:33:17 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: sip@ietf.org, Paul Kyzivat , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This could be done, but requires a mapping from XML tags to CAtypes at the proxy, which seems somewhat unnatural. Generally speaking, it seems likely that only one or two tags contradict each other or are "wrong", so that the saving is likely to be rather modest, particularly given that many of the civic XML tags are only two or three characters long. Thus, you might realize a saving of one or two bytes in most cases. My major concern is identifying the source of insertion of the LI. This would be a domain name, typically 50 bytes or so, so I don't think this is a major issue. On Jul 11, 2007, at 5:39 PM, James M. Polk wrote: > At 02:42 PM 7/11/2007, DRAGE, Keith \(Keith\) wrote: >> You wrote: >> >> > In general, I think we have learned that we should help >> > people with debugging distributed systems with distributed >> > responsibility, as otherwise they'll either struggle or >> > invent private mechanisms to include this information. (See >> > SER for the the latter.) >> >> If we are not careful here we end up back in the issue of responses >> being significantly larger than the request sent on a particular hop, >> and therefore the old problem of what happens on UDP when this >> occurs. > > one crazy (or stupid?) idea is > > - now that there is a more robust Geolocation-Error header in > responses (verses a Reason or Warning header), a *(SEMI CAType) > could be added to it to allow a Location Recipient to include each > CAType it had a problem with or wasn't there that was considered > necessary to use the location in the first place. This idea > doesn't include the element values, just the elements - which saves > bytes, and doesn't reveal the element values either. It also > doesn't include a message body in the response. > > I think this is more information than is presently there, making > for better decisions by location inserters or for troubleshooting. > The only security risk I see with this is the listing of some of > the CAtypes that were in the original request. Presumably there > were other elements in the request, so little (if anything) can be > extracted from this knowledge if intercepted. > > >> Regards >> >> Keith >> >> > -----Original Message----- >> > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> > Sent: Saturday, July 07, 2007 1:06 PM >> > To: Paul Kyzivat >> > Cc: sip@ietf.org; James M. Polk >> > Subject: Re: [Sip] Re: Conveyance -08 and Geolocation-Error header >> > >> > >> > On Jul 6, 2007, at 11:24 PM, Paul Kyzivat wrote: >> > >> > > Is it really reasonable to expect a proxy that inserts a >> > location to >> > > remember what location it inserted, in enough detail to >> > diagnose why >> > > it might have been messed up? I presume it would have to >> > reconstruct >> > > what the location would have been based in information in the >> > > response. It may not be possible to reconstruct the exact >> > same value, >> > > because the UAC may have moved in the meantime. I guess the >> > inserted >> > > location would have to be by reference, but the URL of the >> > reference >> > > may itself not be easily reconstructed, and multiple >> > queries of it may >> > > not return the same result. >> > > >> > > IMO it would be much clearer to include the location itself in >> the >> > > response. And if the location had been passed by reference, >> > it might >> > > be better to pass it by value in the response, so that there >> is no >> > > possibility of the value changing. >> > > >> > >> > I tend to agree that this would be better. The >> > reference-to-value translation may not always be feasible: If >> > a proxy inserts a location reference and a downstream proxy >> > finds a problem, it can't insert a value (except by the data >> > URL mechanism I have been mentioning...). >> > >> > >> > > OTOH that might result in divulging the location to nodes >> > upstream of >> > > the one that included it. If it was passed by reference >> > then the node >> > > that had inserted it could remove the reference in the >> > response. But >> > > if it is passed back by value that isn't allowed. >> > > >> > > The alternative is that the proxy will have to retain the >> location >> > > until the completion of the transaction. Maybe that's ok, >> > but if its >> > > only to diagnose an occasional glitch I get it doesn't get done. >> > >> > My assumption was that most locations will be inserted by the >> > UAC rather than a proxy. In those cases, retaining the >> > information is probably not a big deal, since the UAC will >> > generally only have one. >> > >> > In summary, I think returning as much information about the >> > erroneous location information as possible seems best, i.e., >> > both the location information and the party that inserted it. >> > This avoids the "who the heck put that bogus location >> > information in there?" problem. >> > >> > In general, I think we have learned that we should help >> > people with debugging distributed systems with distributed >> > responsibility, as otherwise they'll either struggle or >> > invent private mechanisms to include this information. (See >> > SER for the the latter.) >> > >> > >> > > >> > > Paul >> > > >> > >> > >> > >> > _______________________________________________ >> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP Protocol Use >> > sip-implementors@cs.columbia.edu for questions on current sip >> > Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 11 21:03:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8n5E-00017i-O1; Wed, 11 Jul 2007 21:03:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8n5D-00013c-1t for sip-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 21:03:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8n5C-00013U-Oc for sip@ietf.org; Wed, 11 Jul 2007 21:03:02 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8n58-0005PK-3e for sip@ietf.org; Wed, 11 Jul 2007 21:03:02 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 11 Jul 2007 18:02:57 -0700 X-IronPort-AV: i="unknown"; a="385146437:sNHT0" 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 l6C12uOo025612; Wed, 11 Jul 2007 18:02:56 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6C12umo007121; Thu, 12 Jul 2007 01:02:56 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 21:02:55 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.20.175]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 21:02:55 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 11 Jul 2007 20:02:55 -0500 To: Henning Schulzrinne From: "James M. Polk" Subject: Re: [Sip] Re: Conveyance -08 and Geolocation-Error header In-Reply-To: References: <81A2A0E9-FDF4-48EC-92E4-C02B6BD05948@cs.columbia.edu> <468E899A.7070806@cisco.com> <468F078A.8070604@cisco.com> <83C6385C-BC62-4AB6-AD1B-14020A7CBAD5@cs.columbia.edu> <5D1A7985295922448D5550C94DE29180013F9C26@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 12 Jul 2007 01:02:55.0363 (UTC) FILETIME=[614AAD30:01C7C420] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6573; t=1184202176; x=1185066176; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20Conveyance=20-08=20and=20Geolocation- Error=20header |Sender:=20; bh=GBr/gQqqnVfXJ6TVoiu+Bv1Z3wgUoc58wLjAlqwTBr0=; b=OpcPVfL1wQkn7edIDdE/C+xxgaA+WeFplXa3KgPMfnRCdg4//zUtkhw7/kOJZYQ997vibVZD JV2baC4ADj/5eXRlV5GCqv8EKu1rmACNbv1utphHW/3catgZTySc4W7Y; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: sip@ietf.org, Paul Kyzivat , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 07:33 PM 7/11/2007, Henning Schulzrinne wrote: >This could be done, but requires a mapping from XML tags to CAtypes >at the proxy, which seems somewhat unnatural. Generally speaking, it >seems likely that only one or two tags contradict each other or are >"wrong", so that the saving is likely to be rather modest, >particularly given that many of the civic XML tags are only two or >three characters long. Thus, you might realize a saving of one or two >bytes in most cases. but I was comparing the savings of having only one or two (as you said) "CAType=" added to the Geolocation-Error header verses having a full PIDF-LO added to a message body in the response. I think you'll agree that the size/bytes savings in comparison is substantial - and goes towards Keith's point of UDP. This also is consistent with most folks thinking that location shouldn't be in a response. I think this proposal can get us a long way towards what you want, without saying "you said you were at N Main St., which doesn't exist, instead of NW Main St, which does". The CAType for prefix street name would be what's included in the response, because it was the part of the civic location that was bad. >My major concern is identifying the source of insertion of the LI. >This would be a domain name, typically 50 bytes or so, so I don't >think this is a major issue. > >On Jul 11, 2007, at 5:39 PM, James M. Polk wrote: > >>At 02:42 PM 7/11/2007, DRAGE, Keith \(Keith\) wrote: >>>You wrote: >>> >>> > In general, I think we have learned that we should help >>> > people with debugging distributed systems with distributed >>> > responsibility, as otherwise they'll either struggle or >>> > invent private mechanisms to include this information. (See >>> > SER for the the latter.) >>> >>>If we are not careful here we end up back in the issue of responses >>>being significantly larger than the request sent on a particular hop, >>>and therefore the old problem of what happens on UDP when this >>>occurs. >> >>one crazy (or stupid?) idea is >> >>- now that there is a more robust Geolocation-Error header in >>responses (verses a Reason or Warning header), a *(SEMI CAType) >>could be added to it to allow a Location Recipient to include each >>CAType it had a problem with or wasn't there that was considered >>necessary to use the location in the first place. This idea >>doesn't include the element values, just the elements - which saves >>bytes, and doesn't reveal the element values either. It also >>doesn't include a message body in the response. >> >>I think this is more information than is presently there, making >>for better decisions by location inserters or for troubleshooting. >>The only security risk I see with this is the listing of some of >>the CAtypes that were in the original request. Presumably there >>were other elements in the request, so little (if anything) can be >>extracted from this knowledge if intercepted. >> >> >>>Regards >>> >>>Keith >>> >>> > -----Original Message----- >>> > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>> > Sent: Saturday, July 07, 2007 1:06 PM >>> > To: Paul Kyzivat >>> > Cc: sip@ietf.org; James M. Polk >>> > Subject: Re: [Sip] Re: Conveyance -08 and Geolocation-Error header >>> > >>> > >>> > On Jul 6, 2007, at 11:24 PM, Paul Kyzivat wrote: >>> > >>> > > Is it really reasonable to expect a proxy that inserts a >>> > location to >>> > > remember what location it inserted, in enough detail to >>> > diagnose why >>> > > it might have been messed up? I presume it would have to >>> > reconstruct >>> > > what the location would have been based in information in the >>> > > response. It may not be possible to reconstruct the exact >>> > same value, >>> > > because the UAC may have moved in the meantime. I guess the >>> > inserted >>> > > location would have to be by reference, but the URL of the >>> > reference >>> > > may itself not be easily reconstructed, and multiple >>> > queries of it may >>> > > not return the same result. >>> > > >>> > > IMO it would be much clearer to include the location itself in >>>the >>> > > response. And if the location had been passed by reference, >>> > it might >>> > > be better to pass it by value in the response, so that there >>>is no >>> > > possibility of the value changing. >>> > > >>> > >>> > I tend to agree that this would be better. The >>> > reference-to-value translation may not always be feasible: If >>> > a proxy inserts a location reference and a downstream proxy >>> > finds a problem, it can't insert a value (except by the data >>> > URL mechanism I have been mentioning...). >>> > >>> > >>> > > OTOH that might result in divulging the location to nodes >>> > upstream of >>> > > the one that included it. If it was passed by reference >>> > then the node >>> > > that had inserted it could remove the reference in the >>> > response. But >>> > > if it is passed back by value that isn't allowed. >>> > > >>> > > The alternative is that the proxy will have to retain the >>>location >>> > > until the completion of the transaction. Maybe that's ok, >>> > but if its >>> > > only to diagnose an occasional glitch I get it doesn't get done. >>> > >>> > My assumption was that most locations will be inserted by the >>> > UAC rather than a proxy. In those cases, retaining the >>> > information is probably not a big deal, since the UAC will >>> > generally only have one. >>> > >>> > In summary, I think returning as much information about the >>> > erroneous location information as possible seems best, i.e., >>> > both the location information and the party that inserted it. >>> > This avoids the "who the heck put that bogus location >>> > information in there?" problem. >>> > >>> > In general, I think we have learned that we should help >>> > people with debugging distributed systems with distributed >>> > responsibility, as otherwise they'll either struggle or >>> > invent private mechanisms to include this information. (See >>> > SER for the the latter.) >>> > >>> > >>> > > >>> > > Paul >>> > > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> > This list is for NEW development of the core SIP Protocol Use >>> > sip-implementors@cs.columbia.edu for questions on current sip >>> > Use sipping@ietf.org for new developments on the application of sip >>> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 12 03:31:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8t8k-00033a-8v; Thu, 12 Jul 2007 03:31:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8t8i-00033K-K2 for sip-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 03:31:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8t8i-00033C-1T for sip@ietf.org; Thu, 12 Jul 2007 03:31:04 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8t8d-0001Zi-OW for sip@ietf.org; Thu, 12 Jul 2007 03:31:04 -0400 Received: from unknown (HELO up-smtp.jnpr.net) ([172.26.192.132]) by smtpa.juniper.net with ESMTP; 12 Jul 2007 00:30:59 -0700 X-IronPort-AV: i="4.16,530,1175497200"; d="scan'208"; a="35390696:sNHT39187052" Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 Jul 2007 08:30:57 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP Identity using Media Path Date: Thu, 12 Jul 2007 08:30:56 +0100 Message-ID: <0E48B768805E4D44A70709C8AE092090BE6E20@EMAILEMEA3.jnpr.net> In-Reply-To: <1dc301c7be60$8ff64dd0$2014590a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Identity using Media Path Thread-Index: Ace+X1T3kIrHpOPTRcCFDOsCexxANwAARVfAAX019JA= References: <1183569234.6837.5.camel@localhost.localdomain> <1dc301c7be60$8ff64dd0$2014590a@amer.cisco.com> From: "Gilad Shaham" To: "Dan Wing" , "Hans Persson" X-OriginalArrivalTime: 12 Jul 2007 07:30:57.0689 (UTC) FILETIME=[96A3B090:01C7C456] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org, ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Dan Wing Wrote: > > > > Section 4.1, item about Contact: > > > > > > > > How can the Contact header usefully be used in the > > signing process? An > > > > SBC along the message path will happily replace it. > > > > > > I have removed that in -01 (which isn't yet published, of > > course). There > > > was some thought it was necessary, but I agree it should be removed > > > from the signature. > > > > > > On a similar note, I am considering removing CallId from > > the signature. > > > Oftentimes the Call Id value contains an IP address (in > > dotted decimal > > > or hex), and an SBC or B2BUA may also want to rewrite such > > a CallId. I > > > have made a note of that in -01 so this can be discussed. > > > > I thought about that as well, but apparently I forgot about > > adding it to > > my mail. I think it would be a good idea to take Call-ID out as well. >=20 > Ok, thanks. >=20 I agree with this, but keep in mind that the call-id serves as a nonce in RFC 4474. It might require introducing a new header/parameter to be the nonce. Regards, Gilad _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 12 05:26:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8uwF-00052C-6i; Thu, 12 Jul 2007 05:26:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8uwC-0004vo-Jo for sip-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 05:26:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8uwC-0004vb-5Y for sip@ietf.org; Thu, 12 Jul 2007 05:26:16 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8uwB-00043X-Kl for sip@ietf.org; Thu, 12 Jul 2007 05:26:15 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l6C9O5mG005435; Thu, 12 Jul 2007 04:24:07 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 04:23:56 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 11:23:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Hop limit diagnostics Date: Thu, 12 Jul 2007 11:23:51 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180013F9D8C@DEEXC1U01.de.lucent.com> In-Reply-To: <221D492E-F8B7-4B1F-8F15-F0381CB20EAD@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Hop limit diagnostics Thread-Index: AcfDzSi5PkqxzFucQMilth82sbXX8wAmHq0g References: <5D1A7985295922448D5550C94DE29180013F9B3A@DEEXC1U01.de.lucent.com> <221D492E-F8B7-4B1F-8F15-F0381CB20EAD@nostrum.com> From: "DRAGE, Keith \(Keith\)" To: "Robert Sparks" X-OriginalArrivalTime: 12 Jul 2007 09:23:52.0486 (UTC) FILETIME=[5CBBAC60:01C7C466] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I believe content-indirection was looked at and also sending a new request in the reverse direction. I believe the issue with content indirection was the issue of if the sender of the original request cannot construct a routeable SIP query, will they be able to construct a routeable HTTP query to get to the content indirection server. Would welcome a fuller explanation or correction here.=20 The problem with issuing a new request falls into two parts: - it does not solve the problem of standalone transactions like MESSAGE. - will a new request in the reverse direction reach the original sender given that the routeing path can be totally independent of the original request. Again would welcome a fuller explanation or correction here.=20 Regards Keith > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 > Sent: Wednesday, July 11, 2007 4:07 PM > To: DRAGE, Keith (Keith) > Cc: sip@ietf.org > Subject: Re: [Sip] Hop limit diagnostics >=20 > For completeness - haven't we also talked about requests in=20 > the opposite direction and diagnostics by indirection? I know=20 > each of those have their own thorny problems, but the=20 > tradeoff against really large responses may make them the=20 > least unpalatable. >=20 > And I remember conversations, but not much list traffic about=20 > a series of best-effort provisionals to carry the information. >=20 > I still think its worth figuring out, but won't throw fits if=20 > the WG decides to put it off to the indefinite future. >=20 > RjS >=20 >=20 > On Jul 11, 2007, at 9:07 AM, DRAGE, Keith ((Keith)) wrote: >=20 > > (As WG chair) > > > > We have a couple of related milestones on our charter that we are=20 > > stuck > > on: > > > > Jul 2007 Diagnostic Responses for SIP Errors to WGLC (PS) > > Nov 2007 Diagnostic Responses for SIP Errors to IESG (PS) > > > > The draft associated with this expired some way back, but=20 > you can find=20 > > it at: > > > > http://tools.ietf.org/html/draft-ietf-sip-hop-limit-diagnostics-03 > > > > The charter item is for a more general document that covers other=20 > > error situations as well as hop limit issues. > > > > However the editor's hit the intractable problem in that=20 > any transport=20 > > decision is made on the request on any particular hop, and=20 > if UDP is=20 > > used on the request, it will also be used on the response on any=20 > > particular hop. This was specified based on the assumption that any=20 > > response would not be significantly larger than the request, but as=20 > > soon as we start putting lots of useful diagnostic=20 > information in the=20 > > response, this no longer applies. > > > > So we are now looking for the way forward. Options include: > > > > A) It is not worth the extra cycles - delete the milestone. > > > > B) Limit the diagnostic information (to say around 100 bytes in the > > worst case). If so will it contain enough useful=20 > information to make=20 > > it usable. > > > > C) Solve the transport problem. And no, we do not have a debate > > here on deprecating UDP. We've been there and done that. > > > > Unless people can come up with something that looks achievable, the=20 > > working group chairs are currently favouring A) above. > > > > Comments please. > > > > > > Keith > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 12 07:09:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8wY5-00089y-K5; Thu, 12 Jul 2007 07:09:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8wY4-00089o-4p for sip-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 07:09:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8wY3-00089f-Nu for sip@ietf.org; Thu, 12 Jul 2007 07:09:27 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8wXz-0006xp-9w for sip@ietf.org; Thu, 12 Jul 2007 07:09:27 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l6CB8YnG018399; Thu, 12 Jul 2007 06:09:19 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 06:09:03 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 13:09:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP SAML IANA Consideration Sction Date: Thu, 12 Jul 2007 13:09:01 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180013F9E36@DEEXC1U01.de.lucent.com> In-Reply-To: <46949CB5.4070703@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP SAML IANA Consideration Sction Thread-Index: AcfDmlV6pFQGGHsxQPSWLARxo9aLlwA2e5tg References: <46949CB5.4070703@gmx.net> From: "DRAGE, Keith \(Keith\)" To: "Hannes Tschofenig" , "IETF SIP List" X-OriginalArrivalTime: 12 Jul 2007 11:09:02.0096 (UTC) FILETIME=[0D8DC100:01C7C475] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Two points on this list of response code definitions: 1) Instead of using "It is used when..." and defining the sender = condition, can we write it if a form of the semantics the receiver = should understand from receiving it. The sender conditions should be = covered by normative statements along the lines of "If then = the UAS MUST/SHOULD send a 4xx (xxx) response" elsewhere in the = document. 2) A question to which I do not have an answer. This defines 3 new = response codes. Are these allocated in sufficiently generic a form. For = example the first could be just "Assertion required of Identity header" = and the fact that it is a SAML assertion contained in a new header = field. I would like at some point to see some list discussion on this. Regards Keith > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Wednesday, July 11, 2007 10:03 AM > To: IETF SIP List > Subject: [Sip] SIP SAML IANA Consideration Sction >=20 > I compiled a first version of the IANA consideration section. > Please find it here: http://www.tschofenig.priv.at:8080/saml-sip/issue22 >=20 > Ciao > Hannes >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 12 08:10:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8xUb-00089G-TH; Thu, 12 Jul 2007 08:09:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8xUZ-00088q-Fg for sip-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 08:09:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8xUZ-00088f-4q for sip@ietf.org; Thu, 12 Jul 2007 08:09:55 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8xUY-0007gG-Ij for sip@ietf.org; Thu, 12 Jul 2007 08:09:54 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6CC7gCw023286; Thu, 12 Jul 2007 07:07:44 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 07:07:43 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 14:07:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Open issue in the hitchhikers guide - seriously! Relation to essential corrections Date: Thu, 12 Jul 2007 14:07:39 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180013F9EA0@DEEXC1U01.de.lucent.com> In-Reply-To: <4694D91D.6060205@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Open issue in the hitchhikers guide - seriously! Relation to essential corrections Thread-Index: AcfDvkJfjPPmOoHBStqwNl9p8Kys1wAvuJWQ References: <468D5205.5040705@cisco.com> <5D1A7985295922448D5550C94DE29180013F97B9@DEEXC1U01.de.lucent.com> <4694D91D.6060205@cisco.com> From: "DRAGE, Keith \(Keith\)" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 12 Jul 2007 12:07:40.0502 (UTC) FILETIME=[3EAFE760:01C7C47D] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I will be following this in the next version of = draft-drage-sip-essential-correction unless I hear otherwise from the = list. Keith=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Wednesday, July 11, 2007 2:20 PM > To: DRAGE, Keith (Keith) > Cc: IETF SIP List > Subject: Re: [Sip] Open issue in the hitchhikers guide -=20 > seriously! Relation to essential corrections >=20 >=20 >=20 > DRAGE, Keith (Keith) wrote: > > Your proposal as to what goes into the hitchhiker's guide sounds=20 > > sensible to me. > >=20 > > I will take the comment about the file nameing convention into the=20 > > next version of my essential-corrections draft. Proposals=20 > for a naming=20 > > convention welcome; if no alternatives I will use something=20 > based on=20 > > what Jonathan suggests below. I see only two issues: > >=20 > > - we seem to be unable to decide what is a fix and what=20 > is not. If we > > make a decision that something is a fix after the -00=20 > version, we need=20 > > to decide whether the continuity of the existing nameing=20 > has priority=20 > > or the convention of having -fix in the name. >=20 > I think the convention has priority. SO if we decide its not=20 > a fix, it gets renamed. >=20 > >=20 > > - there are already a number of candidate drafts, which=20 > obviously do > > not yet follow this convention. Again we need to decide whether to=20 > > keep the continuity of the existing naming or not. >=20 > I favor the convention. >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 12 09:25:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8yf4-00043m-0k; Thu, 12 Jul 2007 09:24:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8yf3-00043T-2x for sip-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 09:24:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8yf2-00043K-N4 for sip@ietf.org; Thu, 12 Jul 2007 09:24:48 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8yf2-0000tY-5g for sip@ietf.org; Thu, 12 Jul 2007 09:24:48 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6CDNI0o023697; Thu, 12 Jul 2007 08:23:19 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 08:23:18 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 15:23:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Jul 2007 15:23:15 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180013F9F21@DEEXC1U01.de.lucent.com> In-Reply-To: <4C1596FBF66C67478BCFE7B3F81FC1E01D45BAC556@DF-MASTIFF-MSG.exchange.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Hop limit diagnostics Thread-Index: AcfDxMmAH4k0yTi8Q9i3/pvfpjBfaAAJOeSQACdjHQA= References: <5D1A7985295922448D5550C94DE29180013F9B3A@DEEXC1U01.de.lucent.com> <4C1596FBF66C67478BCFE7B3F81FC1E01D45BAC556@DF-MASTIFF-MSG.exchange.corp.microsoft.com> From: "DRAGE, Keith \(Keith\)" To: "Sean Olson" , X-OriginalArrivalTime: 12 Jul 2007 13:23:16.0048 (UTC) FILETIME=[CE154D00:01C7C487] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Subject: [Sip] RE: Hop limit diagnostics X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org So to explore further.=20 If the final hop is TCP and a preceding hop is UDP, does it just get thrown away at the transport protocol boundary in this solution. Regards Keith =20 > -----Original Message----- > From: Sean Olson [mailto:Sean.Olson@microsoft.com]=20 > Sent: Wednesday, July 11, 2007 7:33 PM > To: DRAGE, Keith (Keith); sip@ietf.org > Subject: RE: Hop limit diagnostics >=20 > Why not: >=20 > D) Define a diagnostic information mechanism that works with=20 > TCP and accept that it will not work with UDP >=20 >=20 >=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Wednesday, July 11, 2007 7:07 AM > To: sip@ietf.org > Subject: [Sip] Hop limit diagnostics >=20 > (As WG chair) >=20 > We have a couple of related milestones on our charter that we=20 > are stuck > on: >=20 > Jul 2007 Diagnostic Responses for SIP Errors to WGLC (PS) > Nov 2007 Diagnostic Responses for SIP Errors to IESG (PS) >=20 > The draft associated with this expired some way back, but you=20 > can find it at: >=20 > http://tools.ietf.org/html/draft-ietf-sip-hop-limit-diagnostics-03 >=20 > The charter item is for a more general document that covers=20 > other error situations as well as hop limit issues. >=20 > However the editor's hit the intractable problem in that any=20 > transport decision is made on the request on any particular=20 > hop, and if UDP is used on the request, it will also be used=20 > on the response on any particular hop. This was specified=20 > based on the assumption that any response would not be=20 > significantly larger than the request, but as soon as we=20 > start putting lots of useful diagnostic information in the=20 > response, this no longer applies. >=20 > So we are now looking for the way forward. Options include: >=20 > A) It is not worth the extra cycles - delete the milestone. >=20 > B) Limit the diagnostic information (to say around 100=20 > bytes in the > worst case). If so will it contain enough useful information=20 > to make it usable. >=20 > C) Solve the transport problem. And no, we do not have a debate > here on deprecating UDP. We've been there and done that. >=20 > Unless people can come up with something that looks=20 > achievable, the working group chairs are currently favouring A) above. >=20 > Comments please. >=20 >=20 > Keith >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 12 09:55:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8z94-000702-15; Thu, 12 Jul 2007 09:55:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I8z92-0006w4-RD for sip-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 09:55:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8z92-0006vu-Hc for sip@ietf.org; Thu, 12 Jul 2007 09:55:48 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8z8y-0002vt-3i for sip@ietf.org; Thu, 12 Jul 2007 09:55:48 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6CDthnV021644; Thu, 12 Jul 2007 08:55:43 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l6CDtha11480; Thu, 12 Jul 2007 08:55:43 -0500 (CDT) Message-ID: <469632DF.9090601@alcatel-lucent.com> Date: Thu, 12 Jul 2007 08:55:43 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] Hop limit diagnostics References: <5D1A7985295922448D5550C94DE29180013F9B3A@DEEXC1U01.de.lucent.com> <221D492E-F8B7-4B1F-8F15-F0381CB20EAD@nostrum.com> <5D1A7985295922448D5550C94DE29180013F9D8C@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180013F9D8C@DEEXC1U01.de.lucent.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.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org DRAGE, Keith (Keith) wrote: > The problem with issuing a new request falls into two parts: > > - it does not solve the problem of standalone transactions like > MESSAGE. > > - will a new request in the reverse direction reach the original > sender given that the routeing path can be totally independent of the > original request. > > Again would welcome a fuller explanation or correction here. A bit of the latter was explored in S4.3 of a now expired, though still archived draft on handling large UDP responses. See http://tools.ietf.org/html/draft-gurbani-sip-large-udp-response-00. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 12 12:17:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91ME-0008EE-Ct; Thu, 12 Jul 2007 12:17:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I91KR-0003xT-2v for sip-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 12:15:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91KP-0003uc-2v; Thu, 12 Jul 2007 12:15:41 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I91KO-0007O1-RI; Thu, 12 Jul 2007 12:15:41 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id BD04C32A35; Thu, 12 Jul 2007 16:15:10 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I91Jt-0003G0-UQ; Thu, 12 Jul 2007 12:15:10 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 12 Jul 2007 12:15:09 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-10.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Managing Client Initiated Connections in the Session Initiation Protocol (SIP) Author(s) : C. Jennings, R. Mahy Filename : draft-ietf-sip-outbound-10.txt Pages : 42 Date : 2007-7-12 The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections and send asynchronous UDP datagrams to User Agents in order to deliver requests. However, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs), prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-outbound-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-outbound-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-12111827.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-outbound-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-outbound-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-12111827.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Thu Jul 12 13:32:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I92WC-0004xB-Sb; Thu, 12 Jul 2007 13:31:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I92WB-0004wg-9y for sip-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 13:31:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I92W9-0004wS-Ta for sip@ietf.org; Thu, 12 Jul 2007 13:31:53 -0400 Received: from alnrmhc15.comcast.net ([206.18.177.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I92W9-0000X0-M1 for sip@ietf.org; Thu, 12 Jul 2007 13:31:53 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc15) with ESMTP id <20070712173112b1500cemege>; Thu, 12 Jul 2007 17:31:12 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6CHVC8t007860 for ; Thu, 12 Jul 2007 13:31:12 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6CHVCbV007856; Thu, 12 Jul 2007 13:31:12 -0400 Date: Thu, 12 Jul 2007 13:31:12 -0400 Message-Id: <200707121731.l6CHVCbV007856@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <4693F5F9.2010608@bell-labs.com> (volkerh@bell-labs.com) Subject: Re: [Sip] I-D ACTION:draft-hilt-sip-correction-503-01.txt References: <4693F5F9.2010608@bell-labs.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Volker Hilt I've submitted a new version of the "Essential Correction to the Session Initiation Protocol (SIP) 503 (Service Unavailable) Response": http://www.ietf.org/internet-drafts/draft-hilt-sip-correction-503-01.txt This work is important, but I don't see how it fits in the category "essential correction", as a SIP system can function without it. Perhaps you could add a section explaining why it is an essential correction. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 12 13:52:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I92q2-00058r-Ld; Thu, 12 Jul 2007 13:52:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I92q0-00057C-Rp for sip-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 13:52:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I92q0-00056R-FT for sip@ietf.org; Thu, 12 Jul 2007 13:52:24 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I92q0-0001HM-6d for sip@ietf.org; Thu, 12 Jul 2007 13:52:24 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc11) with ESMTP id <20070712175139m11009el55e>; Thu, 12 Jul 2007 17:51:43 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6CHpc8t009334 for ; Thu, 12 Jul 2007 13:51:38 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6CHpcTN009330; Thu, 12 Jul 2007 13:51:38 -0400 Date: Thu, 12 Jul 2007 13:51:38 -0400 Message-Id: <200707121751.l6CHpcTN009330@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <750BBC72E178114F9DC4872EBFF29A5B04CD8662@ZMY16EXM66.ds.mot.com> (ranjit@motorola.com) Subject: Re: [Sip] 4xx message for informing user of an existing subsription References: <46928F5F.3080502@softarmor.com> <5D1A7985295922448D5550C94DE29180013F94BC@DEEXC1U01.de.lucent.com> <750BBC72E178114F9DC4872EBFF29A5B04CD8662@ZMY16EXM66.ds.mot.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Avasarala Ranjit-A20990" Which is the appropriate 4xx message that can be used to inform user of an existing subscription? As others have said, it's not an error, so there is no error response. Consider the following use case: User A sends a subscribe message with a particular event and gets subscribed to the service. Now at a later point of time the user is not sure if he has subscribed for a particular service or not. So he might send subscribe again. So is there a way to inform the user that the subscription for that service for the user already exists? That isn't quite the way to look at it. Given that NOTIFYs are always sent within a dialog, if the UA has truly forgotten about any possible subscription, it will have also forgotten the Call-Id of the dialog, and will have no context to recognize that an incoming NOTIFY is relevent to its subscription. So the old subscription must perforce be abandoned (and it will eventually time out), and the UA must create a new subscription. On the other hand, if the UA knows the Call-Id of a past subscription but doesn't know if the subscription is still valid, it can send a re-SUBSCRIBE, and the notifier will respond 200 (if it is still valid) or 481 (if not). Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 12 14:09:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I936T-00022B-F5; Thu, 12 Jul 2007 14:09:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I936S-000226-Bx for sip-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 14:09:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I936R-00021y-Qc for sip@ietf.org; Thu, 12 Jul 2007 14:09:23 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I936N-0007MH-HM for sip@ietf.org; Thu, 12 Jul 2007 14:09:23 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1I936K-0003Hv-Lh; Thu, 12 Jul 2007 13:09:16 -0500 Message-ID: <46966F52.9040004@softarmor.com> Date: Thu, 12 Jul 2007 13:13:38 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: Dean Willis References: <46928F5F.3080502@softarmor.com> In-Reply-To: <46928F5F.3080502@softarmor.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: sip@ietf.org, Cullen Jennings , "DRAGE, Keith \(Keith\)" Subject: [Sip] Correction: WGLC for draft-ietf-sip-outbound X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > I'd like to start a long working group last call for: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-09.txt > My error. This should have referred to draft-ietf-sip-outbound-10, not -09. It was busy working its way through the posting system and I grabbed a pointer to the wrong one. Sorry about that, folks. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 12 14:43:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I93dr-0006ku-52; Thu, 12 Jul 2007 14:43:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I93dq-0006jr-6B for sip-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 14:43:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I93dp-0006jH-R2 for sip@ietf.org; Thu, 12 Jul 2007 14:43:53 -0400 Received: from mail7.exchange.microsoft.com ([131.107.1.27] helo=mail.exchange.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I93dp-0003mi-G9 for sip@ietf.org; Thu, 12 Jul 2007 14:43:53 -0400 Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) by DF-GWY-07.exchange.corp.microsoft.com (157.54.63.164) with Microsoft SMTP Server (TLS) id 8.1.154.1; Thu, 12 Jul 2007 11:43:28 -0700 Received: from df-mlt-04.exchange.corp.microsoft.com (157.54.68.219) by df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) with Microsoft SMTP Server (TLS) id 8.1.154.1; Thu, 12 Jul 2007 11:43:28 -0700 Received: from DF-MASTIFF-MSG.exchange.corp.microsoft.com ([157.54.61.165]) by df-mlt-04.exchange.corp.microsoft.com ([157.54.68.219]) with mapi; Thu, 12 Jul 2007 11:43:12 -0700 From: Sean Olson To: "DRAGE, Keith (Keith)" , "sip@ietf.org" Date: Thu, 12 Jul 2007 11:43:11 -0700 Thread-Topic: Hop limit diagnostics Thread-Index: AcfDxMmAH4k0yTi8Q9i3/pvfpjBfaAAJOeSQACdjHQAAC0pwAA== Message-ID: <4C1596FBF66C67478BCFE7B3F81FC1E01D45BAC958@DF-MASTIFF-MSG.exchange.corp.microsoft.com> References: <5D1A7985295922448D5550C94DE29180013F9B3A@DEEXC1U01.de.lucent.com> <4C1596FBF66C67478BCFE7B3F81FC1E01D45BAC556@DF-MASTIFF-MSG.exchange.corp.microsoft.com> <5D1A7985295922448D5550C94DE29180013F9F21@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180013F9F21@DEEXC1U01.de.lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Subject: [Sip] RE: Hop limit diagnostics X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yes, I think that would be appropriate. I hate to throw out features/impro= vement just because they don't work over UDP. -----Original Message----- From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] Sent: Thursday, July 12, 2007 6:23 AM To: Sean Olson; sip@ietf.org Subject: RE: Hop limit diagnostics So to explore further. If the final hop is TCP and a preceding hop is UDP, does it just get thrown away at the transport protocol boundary in this solution. Regards Keith > -----Original Message----- > From: Sean Olson [mailto:Sean.Olson@microsoft.com] > Sent: Wednesday, July 11, 2007 7:33 PM > To: DRAGE, Keith (Keith); sip@ietf.org > Subject: RE: Hop limit diagnostics > > Why not: > > D) Define a diagnostic information mechanism that works with > TCP and accept that it will not work with UDP > > > > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Wednesday, July 11, 2007 7:07 AM > To: sip@ietf.org > Subject: [Sip] Hop limit diagnostics > > (As WG chair) > > We have a couple of related milestones on our charter that we > are stuck > on: > > Jul 2007 Diagnostic Responses for SIP Errors to WGLC (PS) > Nov 2007 Diagnostic Responses for SIP Errors to IESG (PS) > > The draft associated with this expired some way back, but you > can find it at: > > http://tools.ietf.org/html/draft-ietf-sip-hop-limit-diagnostics-03 > > The charter item is for a more general document that covers > other error situations as well as hop limit issues. > > However the editor's hit the intractable problem in that any > transport decision is made on the request on any particular > hop, and if UDP is used on the request, it will also be used > on the response on any particular hop. This was specified > based on the assumption that any response would not be > significantly larger than the request, but as soon as we > start putting lots of useful diagnostic information in the > response, this no longer applies. > > So we are now looking for the way forward. Options include: > > A) It is not worth the extra cycles - delete the milestone. > > B) Limit the diagnostic information (to say around 100 > bytes in the > worst case). If so will it contain enough useful information > to make it usable. > > C) Solve the transport problem. And no, we do not have a debate > here on deprecating UDP. We've been there and done that. > > Unless people can come up with something that looks > achievable, the working group chairs are currently favouring A) above. > > Comments please. > > > Keith > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 12 20:45:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I99HK-0004Lt-Jz; Thu, 12 Jul 2007 20:45:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I99HI-0004Li-Hc for sip-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 20:45:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I99HI-0004La-7k for sip@ietf.org; Thu, 12 Jul 2007 20:45:00 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I99HD-0002o8-TO for sip@ietf.org; Thu, 12 Jul 2007 20:45:00 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 12 Jul 2007 17:44:55 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAIJnlkarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,534,1175497200"; d="scan'208"; a="181281586:sNHT41784309" 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 l6D0itF2018371; Thu, 12 Jul 2007 17:44:55 -0700 Received: from dwingwxp (dhcp-171-70-208-123.cisco.com [171.70.208.123]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6D0iska000935; Fri, 13 Jul 2007 00:44:54 GMT From: "Dan Wing" To: "'Gilad Shaham'" , "'Hans Persson'" Subject: RE: [Sip] SIP Identity using Media Path Date: Thu, 12 Jul 2007 17:44:54 -0700 Message-ID: <025601c7c4e7$07c32ef0$f6e046ab@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ace+X1T3kIrHpOPTRcCFDOsCexxANwAARVfAAX019JAAJFqdwA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <0E48B768805E4D44A70709C8AE092090BE6E20@EMAILEMEA3.jnpr.net> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1540; t=1184287495; x=1185151495; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20SIP=20Identity=20using=20Media=20Path |Sender:=20; bh=XTtAJMrwj/zBqEALLombuA9UqefUjWojjulMNdMiCP4=; b=pO74qz+aKHtkHZH1o2Gwcm6QccxV/lkY6BLy2qS81JM4HjvKAHqxI8tCDBq9cQj/N3yD33zl ObfUW0TyS8xiZ3ZlMO37AqprmxIeHzDInKMs/L6Rp8JCbeLRQ50N0CZA; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sip@ietf.org, ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Dan Wing Wrote: > > > > > Section 4.1, item about Contact: > > > > > > > > > > How can the Contact header usefully be used in the > > > > > signing process? An > > > > > SBC along the message path will happily replace it. > > > > > > > > I have removed that in -01 (which isn't yet published, of > > > > course). There > > > > was some thought it was necessary, but I agree it should be > > > > removed from the signature. > > > > > > > > On a similar note, I am considering removing CallId from > > > > the signature. > > > > Oftentimes the Call Id value contains an IP address (in > > > > dotted decimal > > > > or hex), and an SBC or B2BUA may also want to rewrite such > > > > a CallId. I > > > > have made a note of that in -01 so this can be discussed. > > > > > > I thought about that as well, but apparently I forgot about > > > adding it to > > > my mail. I think it would be a good idea to take Call-ID out as > > > well. > > > > Ok, thanks. > > > > I agree with this, but keep in mind that the call-id serves as a nonce > in RFC 4474. It might require introducing a new header/parameter to be > the nonce. Thanks for that reminder. You're right, and I agree that having the authentication service add its own nonce is the best way to do it; such a nonce need only be a random number, as it's already qualified by the authentication service's domain (and certificate). Thus, SBCs won't need to also destroy it. I'll include that in my working revision to sip-identity-media. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 13 06:47:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Ig3-0001JG-6e; Fri, 13 Jul 2007 06:47:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I9Ig2-0001J8-EH for sip-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 06:47:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Ig2-0001Is-1s for sip@ietf.org; Fri, 13 Jul 2007 06:47:10 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I9Ig0-0004yA-Cg for sip@ietf.org; Fri, 13 Jul 2007 06:47:09 -0400 Received: (qmail invoked by alias); 13 Jul 2007 10:46:43 -0000 Received: from p54984A98.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.74.152] by mail.gmx.net (mp038) with SMTP; 13 Jul 2007 12:46:43 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/6wYNPTmH6NRtYivkRsP/P6ek/Eo610UCIj7IRxw vC+I5FyXBmFOyk Message-ID: <46975810.1080000@gmx.net> Date: Fri, 13 Jul 2007 12:46:40 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Sip] draft-ietf-sip-consent-framework-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi all, draft-ietf-sip-consent-framework-02.txt is not a typical framework document. Most framework documents I know are informational. This document, however, seems to have the intended status "Standards Track" Correct? Ciao Hannes _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 13 07:02:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Iv9-00062L-Kt; Fri, 13 Jul 2007 07:02:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I9Iv7-0005uu-NK for sip-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 07:02:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Iv7-0005rx-AW for sip@ietf.org; Fri, 13 Jul 2007 07:02:45 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9Iv6-0005Y6-HZ for sip@ietf.org; Fri, 13 Jul 2007 07:02:45 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l6DB1BC2000159 for ; Fri, 13 Jul 2007 06:01:53 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 06:01:16 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 13:01:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Jul 2007 13:01:12 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001435B59@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Publication request for draft-ietf-sip-consent-framework-02.txt Thread-Index: AcfFPSAvaPNehEgOQAaiZexfgDp4VQ== From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 13 Jul 2007 11:01:13.0673 (UTC) FILETIME=[20C3D390:01C7C53D] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Subject: [Sip] Publication request for draft-ietf-sip-consent-framework-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) I have just requested publication of: http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-14.txt The next stage for submitting comments is therefore the IESG last call. The PROTO writeup submitted with the publication request is as follows. Please feel free to respond if you consider any of the information incorrect. Regards Keith ------------------------------------------------------------------------ --- PROTO writeup for http://www.ietf.org/internet-drafts/draft-ietf-sip-consent-framework- 02.txt: "A Framework for Consent-Based Communications in the Session Initiation Protocol=20 (SIP)" (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Keith Drage The document has been reviewed and is ready for forwarding to IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Document history: - draft-rosenberg-sipping-consent-framework-00 was submitted 8th July 2004 and=20 expired 6th January 2005. - draft-ietf-sipping-consent-framework-00 was submitted 18th October 2004 and=20 expired 18th April 2005. - draft-ietf-sipping-consent-framework-01 was submitted 20th February 2005 and=20 expired 21st August 2005. - draft-ietf-sipping-consent-framework-02 was submitted 18th July 2005 and expired=20 19th January 2006. - draft-ietf-sipping-consent-framework-03 was submitted 5th October 2005 and=20 expired 8th April 2006. - draft-ietf-sipping-consent-framework-04 was submitted 25th February 2006 and=20 expired 29th August 2006. - draft-ietf-sipping-consent-framework-05 was submitted 12th June 2006 and expired=20 14th December 2006. - draft-ietf-sip-consent-framework-00 was submitted 17th September 2006 and expired=20 21st March 2007. - draft-ietf-sip-consent-framework-01 was submitted 26th November 2006 and expired=20 30th May 2007. - draft-ietf-sip-consent-framework-02 was submitted 5th July 2007 and expires 6th=20 January 2007. WGLC was initiated in the SIP WG on draft-ietf-sip-consent-framework-00 on 25th September=20 2006 with comments requested by 17th October 2006. Review was made and comments were received from: Jeroen van Bemmel, Shida Schubert, Ben=20 Campbell, AC Mahendran, Mary Barnes. During the course of the work comments have also=20 been made by: Dean Willis, Andrew Allen, Cullen Jennings, Paul Kyzivat, Adam Roach,=20 Geoffrey Dawirs, Miguel Garcia. The document was moved from the SIPPING WG to the SIP WG in conformance with RFC 3427=20 because it defines new header fields and a response code. Prior review and discussion=20 therefore took place in the SIPPING group. Key discussions have taken place about which methods to use for various parts of the=20 consent framework. The document is closely related with: - draft-ietf-sipping-consent-format-03; - draft-ietf-sipping-pending-additions-02; - draft-ietf-sipping-uri-services-06; - draft-ietf-sip-uri-list-message-01; - draft-ietf-sip-uri-list-subscribe-01; - draft-ietf-sip-uri-list-conferencing-01; - draft-ietf-sip-multiple-refer-01. Both OMA and 3GPP use the uri-list documents (as documented in their PROTO writeups). As=20 these documents have a mandatory normative dependence on the consent framework, then=20 they also need the consent framework. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? The document defines mechanisms that are entirely internal to the Session Initiation=20 Protocol (SIP). The document shepherd considers that no external review from an external=20 specialist is necessary, apart from as follows. While the document was generated as a result of a request from security advisers=20 concerning the original uri-list documents (see above), the document has not had a=20 separate security review, and that should there occur. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. The document defines a new SIP protocol extension for a particular purpose in a form=20 that has been used for many other extensions. The document shepherd has no concerns with=20 the document. There have been no IPR disclosures on this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? While the document has been reviewed by appropriate SIP experts, the level of readership=20 of the SIP working group has apparently been low. This may lead one to assume that the=20 contents for this solution are correct, but potentially there could have been other=20 solutions out there that have been missed. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document has been reviewed against the guidelines in RFC 4485 and it is believed=20 that the document is conformant with those guidelines. While the document defines a new SIP response code, and two new SIP header fields, these=20 have been performed as a SIP working group item, and therefore this draft is in=20 conformance with RFC 3427. For ID-NITS the checks against idnits 2.04.09 report no NITS found. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has separate sections for normative and informative references. The=20 normative references have been checked and found to be normative. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The document defines the following values that require registration: * Trigger-Consent header field * Permission-Missing header field * target-uri header field parameter to Trigger-Consent header field * 470 response code Section 6 of the document provides the IANA considerations section, and this defines the=20 above. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document defines two items in ABNF (Trigger-Consent and Permission-Missing). These=20 augment the ABNF defined in RFC 3261. Both these items pass Bill Fenner's ABNF parser in the tools webpage. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' Technical summary. The Session Initiation Protocol (SIP) supports communications across many media types,=20 including real-time audio, video, text, instant messaging, and presence. In its current=20 form, it allows session invitations, instant messages, and other requests to be=20 delivered from one party to another without requiring explicit consent of the recipient. =20 Without such consent, it is possible for SIP to be used for malicious purposes,=20 including amplification, and DoS (Denial of Service) attacks. This document identifies=20 a framework for consent-based communications in SIP. Working group summary. There is consensus in the working group to publish this document. The document came=20 about due to security area concerns about the need to protect against denial of service=20 attacks and amplification attacks when various relay and uri-list mechanisms are used in=20 SIP. Document Quality There has been no indication of implementation. Personnel The document shepherd for this document was Keith Drage. The responsible Area Director=20 was Cullen Jennings. 'The IANA Expert(s) for the registries in this document are . ---------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 13 07:25:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9JHB-00018L-Ah; Fri, 13 Jul 2007 07:25:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I9JH9-000179-CW for sip-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 07:25:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9JH9-00016U-1M for sip@ietf.org; Fri, 13 Jul 2007 07:25:31 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9JH8-00068R-HW for sip@ietf.org; Fri, 13 Jul 2007 07:25:30 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6DBNeU3019520; Fri, 13 Jul 2007 06:23:42 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 06:23:40 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 13:23:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-consent-framework-02.txt Date: Fri, 13 Jul 2007 13:23:35 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001435B7B@DEEXC1U01.de.lucent.com> In-Reply-To: <46975810.1080000@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-consent-framework-02.txt Thread-Index: AcfFO0KqxARsHqUvTM6HHj0dwasItAABEy8Q References: <46975810.1080000@gmx.net> From: "DRAGE, Keith \(Keith\)" To: "Hannes Tschofenig" , "IETF SIP List" X-OriginalArrivalTime: 13 Jul 2007 11:23:36.0211 (UTC) FILETIME=[40FADE30:01C7C540] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The charter milestones are: Done Consent-Based Communications WGLC (PS) =20 Jun 2007 Consent-Based Communications to IESG (PS) =20 These quite clearly say we are working on a standards track document. Moreover it defines certain SIP constructs for which the IANA = registration requirements are standards track.=20 I guess as well as being the framework document that groups all the = underlying work together, it is in its own right a SIP extension = document.=20 As we already have 7 or 8 documents covering this issue, I suggest we = don't perform a split to create another one. If you look at the = dependent reference tree it is a nightmare. Regards Keith=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Friday, July 13, 2007 11:47 AM > To: IETF SIP List > Subject: [Sip] draft-ietf-sip-consent-framework-02.txt >=20 > Hi all, >=20 > draft-ietf-sip-consent-framework-02.txt is not a typical=20 > framework document. Most framework documents I know are informational. > This document, however, seems to have the intended status=20 > "Standards Track" >=20 > Correct? >=20 > Ciao > Hannes >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 13 07:35:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9JR9-0006N0-Dt; Fri, 13 Jul 2007 07:35:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I9JR7-0006Mm-Oc for sip-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 07:35:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9JR7-0006ME-DO for sip@ietf.org; Fri, 13 Jul 2007 07:35:49 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I9JR6-0006RK-Vz for sip@ietf.org; Fri, 13 Jul 2007 07:35:49 -0400 Received: (qmail invoked by alias); 13 Jul 2007 11:35:15 -0000 Received: from p54984A98.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.74.152] by mail.gmx.net (mp044) with SMTP; 13 Jul 2007 13:35:15 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX188NEpLLuw8zAd6tQcPaRxsHYkbhvDHgOvXJWNnZC sEis1tl2lRHNVq Message-ID: <46976370.9010608@gmx.net> Date: Fri, 13 Jul 2007 13:35:12 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] draft-ietf-sip-consent-framework-02.txt References: <46975810.1080000@gmx.net> <5D1A7985295922448D5550C94DE2918001435B7B@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918001435B7B@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I am not suggesting a document split or anything like that. Typically, documents indicate the status. When I open a document that says "framework" in the subject header then I just do not expect it todo anything else other than describing the big picture. Ciao Hannes DRAGE, Keith (Keith) wrote: > The charter milestones are: > > Done Consent-Based Communications WGLC (PS) > Jun 2007 Consent-Based Communications to IESG (PS) > > These quite clearly say we are working on a standards track document. > > Moreover it defines certain SIP constructs for which the IANA registration requirements are standards track. > > I guess as well as being the framework document that groups all the underlying work together, it is in its own right a SIP extension document. > > As we already have 7 or 8 documents covering this issue, I suggest we don't perform a split to create another one. If you look at the dependent reference tree it is a nightmare. > > Regards > > Keith > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Friday, July 13, 2007 11:47 AM >> To: IETF SIP List >> Subject: [Sip] draft-ietf-sip-consent-framework-02.txt >> >> Hi all, >> >> draft-ietf-sip-consent-framework-02.txt is not a typical >> framework document. Most framework documents I know are informational. >> This document, however, seems to have the intended status >> "Standards Track" >> >> Correct? >> >> Ciao >> Hannes >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 13 09:51:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9LY7-0001XD-R2; Fri, 13 Jul 2007 09:51:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I9LY5-0001VS-OR for sip-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 09:51:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9LY4-0001VF-T9 for sip@ietf.org; Fri, 13 Jul 2007 09:51:08 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9LXz-00081P-Rg for sip@ietf.org; Fri, 13 Jul 2007 09:51:08 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6DDokh9012211 for ; Fri, 13 Jul 2007 08:51:03 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 08:50:34 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 15:50:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Jul 2007 15:50:31 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001435C93@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Publication request for draft-ietf-sip-consent-framework-02.txt Thread-Index: AcfFPSAvaPNehEgOQAaiZexfgDp4VQAF5SvA From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 13 Jul 2007 13:50:31.0840 (UTC) FILETIME=[C7811A00:01C7C554] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608 Subject: [Sip] RE: Publication request for draft-ietf-sip-consent-framework-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org And before anyone else responds on the first bit of the message below, it should be:=20 http://www.ietf.org/internet-drafts/draft-ietf-sip-consent-framework-02. txt Keith=20 > -----Original Message----- > From: DRAGE, Keith (Keith)=20 > Sent: Friday, July 13, 2007 12:01 PM > To: sip@ietf.org > Subject: Publication request for=20 > draft-ietf-sip-consent-framework-02.txt >=20 > (As WG chair) >=20 > I have just requested publication of: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-14.txt >=20 > The next stage for submitting comments is therefore the IESG=20 > last call. >=20 > The PROTO writeup submitted with the publication request is=20 > as follows. >=20 > Please feel free to respond if you consider any of the=20 > information incorrect. >=20 > Regards >=20 > Keith >=20 >=20 > -------------------------------------------------------------- > ------------- > PROTO writeup for=20 > http://www.ietf.org/internet-drafts/draft-ietf-sip-consent-framework- > 02.txt: "A Framework for Consent-Based Communications in the=20 > Session Initiation Protocol (SIP)" >=20 > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? >=20 > Keith Drage >=20 > The document has been reviewed and is ready for forwarding to=20 > IESG for publication. >=20 > (1.b) Has the document had adequate review both from key=20 > WG members > and from key non-WG members? Does the Document=20 > Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? >=20 > Document history: >=20 > - draft-rosenberg-sipping-consent-framework-00 was=20 > submitted 8th July 2004 and=20 > expired 6th January 2005. > - draft-ietf-sipping-consent-framework-00 was submitted=20 > 18th October 2004 and=20 > expired 18th April 2005. > - draft-ietf-sipping-consent-framework-01 was submitted=20 > 20th February 2005 and=20 > expired 21st August 2005. > - draft-ietf-sipping-consent-framework-02 was submitted=20 > 18th July 2005 and expired=20 > 19th January 2006. > - draft-ietf-sipping-consent-framework-03 was submitted=20 > 5th October 2005 and=20 > expired 8th April 2006. > - draft-ietf-sipping-consent-framework-04 was submitted=20 > 25th February 2006 and=20 > expired 29th August 2006. > - draft-ietf-sipping-consent-framework-05 was submitted=20 > 12th June 2006 and expired=20 > 14th December 2006. > - draft-ietf-sip-consent-framework-00 was submitted 17th=20 > September 2006 and expired=20 > 21st March 2007. > - draft-ietf-sip-consent-framework-01 was submitted 26th=20 > November 2006 and expired=20 > 30th May 2007. > - draft-ietf-sip-consent-framework-02 was submitted 5th=20 > July 2007 and expires 6th=20 > January 2007. >=20 > WGLC was initiated in the SIP WG on=20 > draft-ietf-sip-consent-framework-00 on 25th September > 2006 with comments requested by 17th October 2006. >=20 > Review was made and comments were received from: Jeroen van=20 > Bemmel, Shida Schubert, Ben Campbell, AC Mahendran, Mary=20 > Barnes. During the course of the work comments have also been=20 > made by: Dean Willis, Andrew Allen, Cullen Jennings, Paul=20 > Kyzivat, Adam Roach, Geoffrey Dawirs, Miguel Garcia. >=20 > The document was moved from the SIPPING WG to the SIP WG in=20 > conformance with RFC 3427 because it defines new header=20 > fields and a response code. Prior review and discussion=20 > therefore took place in the SIPPING group. >=20 > Key discussions have taken place about which methods to use=20 > for various parts of the consent framework. >=20 > The document is closely related with: >=20 > - draft-ietf-sipping-consent-format-03; > - draft-ietf-sipping-pending-additions-02; > - draft-ietf-sipping-uri-services-06; > - draft-ietf-sip-uri-list-message-01; > - draft-ietf-sip-uri-list-subscribe-01; > - draft-ietf-sip-uri-list-conferencing-01; > - draft-ietf-sip-multiple-refer-01. >=20 > Both OMA and 3GPP use the uri-list documents (as documented=20 > in their PROTO writeups). As these documents have a mandatory=20 > normative dependence on the consent framework, then they also=20 > need the consent framework. >=20 > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone=20 > familiar with > AAA, internationalization, or XML? >=20 > The document defines mechanisms that are entirely internal to=20 > the Session Initiation Protocol (SIP). The document shepherd=20 > considers that no external review from an external specialist=20 > is necessary, apart from as follows. >=20 > While the document was generated as a result of a request=20 > from security advisers concerning the original uri-list=20 > documents (see above), the document has not had a separate=20 > security review, and that should there occur. >=20 > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the=20 > document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has=20 > indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to=20 > this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. >=20 > The document defines a new SIP protocol extension for a=20 > particular purpose in a form that has been used for many=20 > other extensions. The document shepherd has no concerns with=20 > the document. >=20 > There have been no IPR disclosures on this document. >=20 > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole=20 > understand and > agree with it? >=20 > While the document has been reviewed by appropriate SIP=20 > experts, the level of readership of the SIP working group has=20 > apparently been low. This may lead one to assume that the=20 > contents for this solution are correct, but potentially there=20 > could have been other solutions out there that have been missed. >=20 > (1.f) Has anyone threatened an appeal or otherwise=20 > indicated extreme > discontent? If so, please summarize the areas of=20 > conflict in > separate email messages to the Responsible Area=20 > Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) >=20 > None indicated. >=20 > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/.) Boilerplate=20 > checks are > not enough; this check needs to be thorough. Has=20 > the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type, and URI type reviews? If the document > does not already indicate its intended status at the top of > the first page, please indicate the intended status here. >=20 > The document has been reviewed against the guidelines in RFC=20 > 4485 and it is believed that the document is conformant with=20 > those guidelines. >=20 > While the document defines a new SIP response code, and two=20 > new SIP header fields, these have been performed as a SIP=20 > working group item, and therefore this draft is in=20 > conformance with RFC 3427. >=20 > For ID-NITS the checks against idnits 2.04.09 report no NITS found. >=20 > (1.h) Has the document split its references into normative and > informative? Are there normative references to=20 > documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative=20 > references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. >=20 > The document has separate sections for normative and=20 > informative references. The normative references have been=20 > checked and found to be normative. >=20 > (1.i) Has the Document Shepherd verified that the document's IANA > Considerations section exists and is consistent=20 > with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See=20 > [RFC2434]. If the > document describes an Expert Review process, has=20 > the Document > Shepherd conferred with the Responsible Area=20 > Director so that > the IESG can appoint the needed Expert during IESG=20 > Evaluation? >=20 > The document defines the following values that require registration: >=20 > * Trigger-Consent header field > * Permission-Missing header field > * target-uri header field parameter to Trigger-Consent=20 > header field > * 470 response code >=20 > Section 6 of the document provides the IANA considerations=20 > section, and this defines the above. >=20 > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate=20 > correctly in > an automated checker? >=20 > The document defines two items in ABNF (Trigger-Consent and=20 > Permission-Missing). These augment the ABNF defined in RFC 3261. >=20 > Both these items pass Bill Fenner's ABNF parser in the tools webpage. >=20 > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up. Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: >=20 > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. >=20 > Working Group Summary > Was there anything in the WG process that is=20 > worth noting? > For example, was there controversy about=20 > particular points > or were there decisions where the consensus was > particularly rough? >=20 > Document Quality > Are there existing implementations of the=20 > protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any=20 > reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive=20 > issues? If > there was a MIB Doctor, Media Type, or other=20 > Expert Review, > what was its course (briefly)? In the case of a=20 > Media Type > Review, on what date was the request posted? >=20 > Personnel > Who is the Document Shepherd for this document? =20 > Who is the > Responsible Area Director? If the document requires IANA > experts(s), insert 'The IANA Expert(s) for the registries > in this document are .' >=20 > Technical summary. >=20 > The Session Initiation Protocol (SIP) supports communications=20 > across many media types, including real-time audio, video,=20 > text, instant messaging, and presence. In its current form,=20 > it allows session invitations, instant messages, and other=20 > requests to be delivered from one party to another without=20 > requiring explicit consent of the recipient. =20 > Without such consent, it is possible for SIP to be used for=20 > malicious purposes, including amplification, and DoS (Denial=20 > of Service) attacks. This document identifies a framework=20 > for consent-based communications in SIP. >=20 > Working group summary. >=20 > There is consensus in the working group to publish this=20 > document. The document came about due to security area=20 > concerns about the need to protect against denial of service=20 > attacks and amplification attacks when various relay and=20 > uri-list mechanisms are used in SIP. >=20 > Document Quality >=20 > There has been no indication of implementation. >=20 > Personnel >=20 > The document shepherd for this document was Keith Drage. The=20 > responsible Area Director was Cullen Jennings. 'The IANA=20 > Expert(s) for the registries in this document are ADDED BY THE AD>. > -------------------------------------------------------------- > -------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 13 10:48:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9MRp-0008GC-ET; Fri, 13 Jul 2007 10:48:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I9MRo-0008Fi-7h for sip-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 10:48:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9MRn-0008FY-S8 for sip@ietf.org; Fri, 13 Jul 2007 10:48:43 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9MRm-0004Sf-VP for sip@ietf.org; Fri, 13 Jul 2007 10:48:43 -0400 Received: from ind-dkim-2.cisco.com ([64.104.140.59]) by ind-iport-1.cisco.com with ESMTP; 14 Jul 2007 09:22:33 +0530 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAH4tl0ZAaIw7/2dsb2JhbACCMjE X-IronPort-AV: i="4.16,537,1175452200"; d="scan'208,217"; a="83973601:sNHT67229134" Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6DEmGLu032254 for ; Fri, 13 Jul 2007 20:18:16 +0530 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6DEmFqf017930 for ; Fri, 13 Jul 2007 14:48:15 GMT Received: from xmb-blr-418.apac.cisco.com ([64.104.140.147]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 20:18:15 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 13 Jul 2007 20:18:14 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Implication of Privacy header (rfc 3323/3325) to the REFER message Thread-Index: AcfFXNdunKZP0w1fQ0GNS6SCmLHTLw== From: "Rajeev Narang (ranarang)" To: X-OriginalArrivalTime: 13 Jul 2007 14:48:15.0159 (UTC) FILETIME=[D7CDA470:01C7C55C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4091; t=1184338096; x=1185202096; c=relaxed/simple; s=inddkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ranarang@cisco.com; z=From:=20=22Rajeev=20Narang=20(ranarang)=22=20 |Subject:=20Implication=20of=20Privacy=20header=20(rfc=203323/3325)=20to= 20the=20REFER=20message |Sender:=20; bh=njsonE2A+b7pr7YD25mG3Fh2KDcSicATmwSkzTuWNuQ=; b=z6Kxd0mDJGxgGjaLmMAX8AjvReMRBOaGIOhdORomMrAQ5dKbY5SS/MWQFanWOU7n06uQKTpa MvA9i5dTPpluLTcYanHSrfVc1RWDivJ7TQcC/teNcdEaQgyweXZwVk6P; Authentication-Results: ind-dkim-2; header.From=ranarang@cisco.com; dkim=pass ( sig from cisco.com/inddkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Subject: [Sip] Implication of Privacy header (rfc 3323/3325) to the REFER message X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0753497909==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0753497909== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C55D.1AB798FE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C55D.1AB798FE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 In the RFC 3323 section 4.2, the REFER message isn't listed for implication due to Privacy header. =20 In the following scenario, will it make sense to interpret the Privacy header for doing the display restriction to the refer-to party. =20 A-------- | B------B2BUA--------------C =20 C sends a OOD REFER to establish a call from A to B (refer-to). Say, REFER carries a Privacy:id header. =20 Should B2BUA try to use the info from Privacy header in REFER header while establishing a call from A to B. If say B is not trusted, should B2BUA restricts the caller A's info for sending to B by not sending the PAI header and having the From header with anonymous data. =20 Thanks & Regards, Rajeev =20 =20 ------_=_NextPart_001_01C7C55D.1AB798FE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
In the = RFC 3323=20 section 4.2, the REFER message isn't listed for implication due to = Privacy=20 header.
 
In the = following=20 scenario, will it make sense to interpret the Privacy header for doing = the=20 display restriction to the refer-to party.
 
A--------
       &nbs= p;=20 |
B------B2BUA--------------C
 
C = sends a OOD REFER=20 to establish a call from A to B=20 (refer-to).
Say, = REFER carries a=20 Privacy:id header.
 
Should B2BUA=20 try to use the info from Privacy header in REFER header while = establishing a=20 call from A to B. If say B is not = trusted, should=20 B2BUA restricts the caller A's info for sending to B by not sending the = PAI=20 header and having the From header with anonymous=20 data.
 
Thanks = &=20 Regards,
Rajeev
 
 
------_=_NextPart_001_01C7C55D.1AB798FE-- --===============0753497909== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0753497909==-- From sip-bounces@ietf.org Fri Jul 13 12:35:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9O79-0004z7-Bf; Fri, 13 Jul 2007 12:35:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I9O76-0004x5-Bo for sip-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 12:35:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9O76-0004wx-1u for sip@ietf.org; Fri, 13 Jul 2007 12:35:28 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9O71-00060i-Hw for sip@ietf.org; Fri, 13 Jul 2007 12:35:28 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Jul 2007 12:35:23 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJNGl0ZAZnmf/2dsb2JhbACCMjE X-IronPort-AV: i="4.16,537,1175486400"; d="scan'208,217"; a="125994293:sNHT89367896" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6DGZNU6005777 for ; Fri, 13 Jul 2007 12:35:23 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6DGZE6g025947 for ; Fri, 13 Jul 2007 16:35:23 GMT Received: from xmb-rtp-215.amer.cisco.com ([64.102.31.124]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 12:35:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Implication of Privacy header (rfc 3323/3325) to the REFERmessage Date: Fri, 13 Jul 2007 12:35:11 -0400 Message-ID: <8983EC086A9D954BA74D9763E853CF3E038547F1@xmb-rtp-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Implication of Privacy header (rfc 3323/3325) to the REFERmessage Thread-Index: AcfFXNdunKZP0w1fQ0GNS6SCmLHTLwADsdcQ From: "Sanjay Sinha \(sanjsinh\)" To: "Rajeev Narang \(ranarang\)" , X-OriginalArrivalTime: 13 Jul 2007 16:35:14.0128 (UTC) FILETIME=[C9CE9500:01C7C56B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5374; t=1184344523; x=1185208523; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20\(sanjsinh\)=22=20 |Subject:=20RE=3A=20[Sip]=20Implication=20of=20Privacy=20header=20(rfc=20 3323/3325)=20to=20the=20REFERmessage |Sender:=20 |To:=20=22Rajeev=20Narang=20\(ranarang\)=22=20, =20; bh=gAPcEBgmvSII6ym3iMEKUzj1lpCgU02J5IonjPFZwEQ=; b=OfD8al6SdfOlkxKB+w74SqAUlAIN15h7+1sV7ZGYNl2FabN5E8ssvN9FMXjrZfrnw3elHgoa UA0rSuycTFKTSMDnT5Y7HJ51mLY4TmcColMrt0ncuo1cY048R7SSYyYA; Authentication-Results: rtp-dkim-2; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0351537402==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0351537402== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C56B.C909E2BB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C56B.C909E2BB Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I think B2BUA is providing privacy service for C, so if B is not, it should not send A's identity in Invite request to it. ________________________________ From: Rajeev Narang (ranarang)=20 Sent: Friday, July 13, 2007 10:48 AM To: sip@ietf.org Subject: [Sip] Implication of Privacy header (rfc 3323/3325) to the REFERmessage =09 =09 Hi, =20 In the RFC 3323 section 4.2, the REFER message isn't listed for implication due to Privacy header. =20 In the following scenario, will it make sense to interpret the Privacy header for doing the display restriction to the refer-to party. =20 A-------- | B------B2BUA--------------C =20 C sends a OOD REFER to establish a call from A to B (refer-to). Say, REFER carries a Privacy:id header. =20 Should B2BUA try to use the info from Privacy header in REFER header while establishing a call from A to B. If say B is not trusted, should B2BUA restricts the caller A's info for sending to B by not sending the PAI header and having the From header with anonymous data. =20 Thanks & Regards, Rajeev =20 =20 ------_=_NextPart_001_01C7C56B.C909E2BB Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I think B2BUA is providing privacy service = for C, so if=20 B is not, it should not send A's identity in Invite request to=20 it.

From: Rajeev Narang (ranarang)=20
Sent: Friday, July 13, 2007 10:48 AM
To:=20 sip@ietf.org
Subject: [Sip] Implication of Privacy header = (rfc=20 3323/3325) to the REFERmessage

Hi,
 
In = the RFC 3323=20 section 4.2, the REFER message isn't listed for implication due to = Privacy=20 header.
 
In = the following=20 scenario, will it make sense to interpret the Privacy header for doing = the=20 display restriction to the refer-to party.
 
A--------
       &nbs= p;=20 |
B------B2BUA--------------C
 
C = sends a OOD=20 REFER to establish a call from A to B = (refer-to).
Say, = REFER carries=20 a Privacy:id header.
 
Should B2BUA=20 try to use the info from Privacy header in REFER header while = establishing a=20 call from A to B. If say B is not = trusted,=20 should B2BUA restricts the caller A's info for sending to B by not = sending the=20 PAI header and having the From header with anonymous=20 data.
 
Thanks &=20 Regards,
Rajeev
 
 
------_=_NextPart_001_01C7C56B.C909E2BB-- --===============0351537402== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0351537402==-- From sip-bounces@ietf.org Fri Jul 13 16:30:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Rmt-0005hi-S0; Fri, 13 Jul 2007 16:30:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I9Rmr-0005aF-8D for sip-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 16:30:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Rmq-0005XM-Q8 for sip@ietf.org; Fri, 13 Jul 2007 16:30:48 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9Rmn-0008E7-U1 for sip@ietf.org; Fri, 13 Jul 2007 16:30:48 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 13 Jul 2007 13:30:32 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAB9+l0arR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,537,1175497200"; d="scan'208"; a="181809182:sNHT420904485" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6DKUWqi019794 for ; Fri, 13 Jul 2007 13:30:32 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6DKUWSf003323 for ; Fri, 13 Jul 2007 20:30:32 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); Fri, 13 Jul 2007 13:30:31 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 13:26:09 -0700 Message-ID: <4697DFE6.2020003@cisco.com> Date: Fri, 13 Jul 2007 16:26:14 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2007 20:26:09.0536 (UTC) FILETIME=[0C461000:01C7C58C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1118; t=1184358632; x=1185222632; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20comments=20on=20draft-sparks-sip-invfix-00.txt |Sender:=20; bh=47cVC9tln9eRxph24OBmCSLDHvRd/A3Bj0r6kn24b3k=; b=Qv2dQTCd8TX5FMFf29GYpYER8mhoOP/vHsbOM84MA9CCYmOurjrUUKxM1NMzh9C2unjMLA0u 7hFK8yzkm0OXp2g+FwXG4FqtTbnjyQlxMWbAcqQ7+1FNBAogzO/D21aR; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Sip] comments on draft-sparks-sip-invfix-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I support this fix. On a procedural note, its great that Robert has done the work of building the actual patch to be made to RFC 3261. However, I'm not sure if thats the form that the essential corrections spec will actually take. Its actually quite hard to read in this form. Indeed my main comment is, certainly for consideration by the working group, it would be better to document the actual change in a summarized form rather than the specific paragraph changes. That will help in our evaluation of it. Perhaps the biggest change in here is that stray responses are no longer forwarded upstream; I don't think this is emphasized enough and is arguably a bigger problem than the request retransmit problem, which is more of a corner case I would say. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 13 16:32:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9RoH-0000rB-IN; Fri, 13 Jul 2007 16:32:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I9RoE-0000qV-BJ for sip-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 16:32:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9RoD-0000qN-73 for sip@ietf.org; Fri, 13 Jul 2007 16:32:13 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9Rny-0008Ek-5z for sip@ietf.org; Fri, 13 Jul 2007 16:32:13 -0400 Received: from unknown (HELO up-smtp.jnpr.net) ([172.26.192.132]) by smtpa.juniper.net with ESMTP; 13 Jul 2007 13:31:00 -0700 X-IronPort-AV: i="4.16,537,1175497200"; d="scan'208"; a="36448970:sNHT36840556" Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jul 2007 21:30:56 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP Identity using Media Path Date: Fri, 13 Jul 2007 21:30:54 +0100 Message-ID: <0E48B768805E4D44A70709C8AE092090BE6FE3@EMAILEMEA3.jnpr.net> In-Reply-To: <025601c7c4e7$07c32ef0$f6e046ab@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Identity using Media Path Thread-Index: Ace+X1T3kIrHpOPTRcCFDOsCexxANwAARVfAAX019JAAJFqdwAApRS2Q References: <0E48B768805E4D44A70709C8AE092090BE6E20@EMAILEMEA3.jnpr.net> <025601c7c4e7$07c32ef0$f6e046ab@amer.cisco.com> From: "Gilad Shaham" To: "Dan Wing" , "Hans Persson" X-OriginalArrivalTime: 13 Jul 2007 20:30:56.0553 (UTC) FILETIME=[B7596190:01C7C58C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: sip@ietf.org, ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hmmm... I have seen SBCs out there that remove the authentication header as well and not all SBCs generate authenticate challenges (for example, they rely on a softswitch later on to do it). Also, there is the issue of a change in Nonce in the middle of the call when a new request gets a challenge with "stale=3Dtrue". I'm not sure we can refrain from introducing a new value generated by the SBC. > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Friday, July 13, 2007 3:45 AM > To: Gilad Shaham; 'Hans Persson' > Cc: sip@ietf.org; ietf-rtpsec@imc.org > Subject: RE: [Sip] SIP Identity using Media Path >=20 > > Dan Wing Wrote: > > > > > > Section 4.1, item about Contact: > > > > > > > > > > > > How can the Contact header usefully be used in the > > > > > > signing process? An > > > > > > SBC along the message path will happily replace it. > > > > > > > > > > I have removed that in -01 (which isn't yet published, of > > > > > course). There > > > > > was some thought it was necessary, but I agree it should be > > > > > removed from the signature. > > > > > > > > > > On a similar note, I am considering removing CallId from > > > > > the signature. > > > > > Oftentimes the Call Id value contains an IP address (in > > > > > dotted decimal > > > > > or hex), and an SBC or B2BUA may also want to rewrite such > > > > > a CallId. I > > > > > have made a note of that in -01 so this can be discussed. > > > > > > > > I thought about that as well, but apparently I forgot about > > > > adding it to > > > > my mail. I think it would be a good idea to take Call-ID out as > > > > well. > > > > > > Ok, thanks. > > > > > > > I agree with this, but keep in mind that the call-id serves as a nonce > > in RFC 4474. It might require introducing a new header/parameter to be > > the nonce. >=20 > Thanks for that reminder. You're right, and I agree that having the > authentication service add its own nonce is the best way to do it; such > a nonce need only be a random number, as it's already qualified by the > authentication service's domain (and certificate). Thus, SBCs won't > need to also destroy it. I'll include that in my working revision > to sip-identity-media. >=20 > -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 13 16:43:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Ryz-0007sF-7z; Fri, 13 Jul 2007 16:43:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I9Ryx-0007l2-Vd for sip-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 16:43:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Ryw-0007fb-R2 for sip@ietf.org; Fri, 13 Jul 2007 16:43:19 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9Ryw-000091-C5 for sip@ietf.org; Fri, 13 Jul 2007 16:43:18 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 13 Jul 2007 13:43:08 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAIGAl0arR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,537,1175497200"; d="scan'208"; a="181815424:sNHT723987855" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6DKh8VC004168; Fri, 13 Jul 2007 13:43:08 -0700 Received: from dwingwxp (dhcp-171-70-208-227.cisco.com [171.70.208.227]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6DKh8A0008948; Fri, 13 Jul 2007 20:43:08 GMT From: "Dan Wing" To: "'Gilad Shaham'" , "'Hans Persson'" Subject: RE: [Sip] SIP Identity using Media Path Date: Fri, 13 Jul 2007 13:43:08 -0700 Message-ID: <032f01c7c58e$6b94a4c0$e3d046ab@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <0E48B768805E4D44A70709C8AE092090BE6FE3@EMAILEMEA3.jnpr.net> Thread-Index: Ace+X1T3kIrHpOPTRcCFDOsCexxANwAARVfAAX019JAAJFqdwAApRS2QAABxi5A= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3685; t=1184359388; x=1185223388; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20SIP=20Identity=20using=20Media=20Path |Sender:=20; bh=aBHaRX5sUsaebchO4Au6OQpctPiejMgA1Uwf7AmpsZA=; b=BgnYMMAIk/F0EOOl9B5AdPd9NZ/MJExIWeawW+TPWvUSXgnM/b/oW28VWmJ9nui3dwKZz9Hl kB+SaUEumBrx+UPbEf45/ZRLGu9rA6tds+CRu3ej5HJ1oXLFhY3CZBrR; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: sip@ietf.org, ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Hmmm... I have seen SBCs out there that remove the > authentication header You're referring to the RFC4474 Identity and Identity-Info headers? Or to something else? Yes, I fully believe and expect SBCs and many B2BUAs would remove those. There isn't much harm in removing them, though, especially for an SBC, because the SBC's modification of the SDP's m/c lines will invalidate the RFC4474 signature anyway. > as well and not all SBCs generate authenticate challenges > (for example, they rely on a softswitch later on to do it). I don't follow; what do you mean by 'generate authenticate challenge'? > Also, there is the issue of a change in Nonce in the middle of the > call when a new request gets a challenge with "stale=true". What I intend on doing in the next version is extend Identity-Fingerprints so it contains the nonce, something like this (highlighted with "<<"): ... Identity-Fingerprints: nonce=1234 <<<<<<<<<< 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB ... v=0 ... m=audio 54113 RTP/SAVP 0 a=setup:active a=connection:new a=fingerprint:SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB The contents of the Identity-Fingerprints header (which contains the nonce generated by the authentication service and the a=fingerprint values from the SDP), is signed by the requestor's authentication service (if an enterprise, that would typically be your enterprise's authentication service; if you're using a service provider, it's your SP's authentication service). > I'm not sure we can refrain from introducing a new value generated by > the SBC. -d > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Friday, July 13, 2007 3:45 AM > > To: Gilad Shaham; 'Hans Persson' > > Cc: sip@ietf.org; ietf-rtpsec@imc.org > > Subject: RE: [Sip] SIP Identity using Media Path > > > > > Dan Wing Wrote: > > > > > > > Section 4.1, item about Contact: > > > > > > > > > > > > > > How can the Contact header usefully be used in the > > > > > > > signing process? An > > > > > > > SBC along the message path will happily replace it. > > > > > > > > > > > > I have removed that in -01 (which isn't yet published, of > > > > > > course). There > > > > > > was some thought it was necessary, but I agree it should be > > > > > > removed from the signature. > > > > > > > > > > > > On a similar note, I am considering removing CallId from > > > > > > the signature. > > > > > > Oftentimes the Call Id value contains an IP address (in > > > > > > dotted decimal > > > > > > or hex), and an SBC or B2BUA may also want to rewrite such > > > > > > a CallId. I > > > > > > have made a note of that in -01 so this can be discussed. > > > > > > > > > > I thought about that as well, but apparently I forgot about > > > > > adding it to > > > > > my mail. I think it would be a good idea to take > Call-ID out as > > > > > well. > > > > > > > > Ok, thanks. > > > > > > > > > > I agree with this, but keep in mind that the call-id serves as a > nonce > > > in RFC 4474. It might require introducing a new > header/parameter to > be > > > the nonce. > > > > Thanks for that reminder. You're right, and I agree that having the > > authentication service add its own nonce is the best way to do it; > such > > a nonce need only be a random number, as it's already > qualified by the > > authentication service's domain (and certificate). Thus, SBCs won't > > need to also destroy it. I'll include that in my working revision > > to sip-identity-media. > > > > -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 13 17:05:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9SK1-0005Qw-HH; Fri, 13 Jul 2007 17:05:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I9SK0-0005I8-2h for sip-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 17:05:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9SJz-0005F5-Jg for sip@ietf.org; Fri, 13 Jul 2007 17:05:03 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9SJv-0007pd-7d for sip@ietf.org; Fri, 13 Jul 2007 17:05:03 -0400 Received: from unknown (HELO emailfeemea2.jnpr.net) ([172.26.192.142]) by smtpa.juniper.net with ESMTP; 13 Jul 2007 14:04:58 -0700 X-IronPort-AV: i="4.16,537,1175497200"; d="scan'208"; a="36462859:sNHT41966672" Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 22:04:56 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP Identity using Media Path Date: Fri, 13 Jul 2007 22:04:53 +0100 Message-ID: <0E48B768805E4D44A70709C8AE092090BE6FE5@EMAILEMEA3.jnpr.net> In-Reply-To: <032f01c7c58e$6b94a4c0$e3d046ab@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Identity using Media Path Thread-Index: Ace+X1T3kIrHpOPTRcCFDOsCexxANwAARVfAAX019JAAJFqdwAApRS2QAABxi5AAAN6CEA== References: <0E48B768805E4D44A70709C8AE092090BE6FE3@EMAILEMEA3.jnpr.net> <032f01c7c58e$6b94a4c0$e3d046ab@amer.cisco.com> From: "Gilad Shaham" To: "Dan Wing" , "Hans Persson" X-OriginalArrivalTime: 13 Jul 2007 21:04:56.0906 (UTC) FILETIME=[777E8AA0:01C7C591] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: sip@ietf.org, ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sorry, I misinterpreted what you meant in the previous response. You can safely ignore my last comment. > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Friday, July 13, 2007 11:43 PM > To: Gilad Shaham; 'Hans Persson' > Cc: sip@ietf.org; ietf-rtpsec@imc.org > Subject: RE: [Sip] SIP Identity using Media Path >=20 > > Hmmm... I have seen SBCs out there that remove the > > authentication header >=20 > You're referring to the RFC4474 Identity and Identity-Info headers? Or to > something else? Yes, I fully believe and expect SBCs and many B2BUAs > would > remove those. There isn't much harm in removing them, though, especially > for an SBC, because the SBC's modification of the SDP's m/c lines will > invalidate the RFC4474 signature anyway. >=20 > > as well and not all SBCs generate authenticate challenges > > (for example, they rely on a softswitch later on to do it). >=20 > I don't follow; what do you mean by 'generate authenticate challenge'? >=20 > > Also, there is the issue of a change in Nonce in the middle of the > > call when a new request gets a challenge with "stale=3Dtrue". >=20 > What I intend on doing in the next version is extend Identity-Fingerprints > so it contains the nonce, something like this (highlighted with "<<"): >=20 > ... > Identity-Fingerprints: > nonce=3D1234 <<<<<<<<<< > 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB > ... > v=3D0 > ... > m=3Daudio 54113 RTP/SAVP 0 > a=3Dsetup:active > a=3Dconnection:new > a=3Dfingerprint:SHA-1 > 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB >=20 >=20 > The contents of the Identity-Fingerprints header (which contains > the nonce generated by the authentication service and the > a=3Dfingerprint values from the SDP), is signed by the requestor's > authentication service (if an enterprise, that would typically > be your enterprise's authentication service; if you're using > a service provider, it's your SP's authentication service). >=20 > > I'm not sure we can refrain from introducing a new value generated by > > the SBC. >=20 > -d >=20 > > > -----Original Message----- > > > From: Dan Wing [mailto:dwing@cisco.com] > > > Sent: Friday, July 13, 2007 3:45 AM > > > To: Gilad Shaham; 'Hans Persson' > > > Cc: sip@ietf.org; ietf-rtpsec@imc.org > > > Subject: RE: [Sip] SIP Identity using Media Path > > > > > > > Dan Wing Wrote: > > > > > > > > Section 4.1, item about Contact: > > > > > > > > > > > > > > > > How can the Contact header usefully be used in the > > > > > > > > signing process? An > > > > > > > > SBC along the message path will happily replace it. > > > > > > > > > > > > > > I have removed that in -01 (which isn't yet published, of > > > > > > > course). There > > > > > > > was some thought it was necessary, but I agree it should be > > > > > > > removed from the signature. > > > > > > > > > > > > > > On a similar note, I am considering removing CallId from > > > > > > > the signature. > > > > > > > Oftentimes the Call Id value contains an IP address (in > > > > > > > dotted decimal > > > > > > > or hex), and an SBC or B2BUA may also want to rewrite such > > > > > > > a CallId. I > > > > > > > have made a note of that in -01 so this can be discussed. > > > > > > > > > > > > I thought about that as well, but apparently I forgot about > > > > > > adding it to > > > > > > my mail. I think it would be a good idea to take > > Call-ID out as > > > > > > well. > > > > > > > > > > Ok, thanks. > > > > > > > > > > > > > I agree with this, but keep in mind that the call-id serves as a > > nonce > > > > in RFC 4474. It might require introducing a new > > header/parameter to > > be > > > > the nonce. > > > > > > Thanks for that reminder. You're right, and I agree that having the > > > authentication service add its own nonce is the best way to do it; > > such > > > a nonce need only be a random number, as it's already > > qualified by the > > > authentication service's domain (and certificate). Thus, SBCs won't > > > need to also destroy it. I'll include that in my working revision > > > to sip-identity-media. > > > > > > -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 13 18:32:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Tgx-0008NS-9c; Fri, 13 Jul 2007 18:32:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I9Tgu-0008Kp-7f for sip-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 18:32:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Tgt-0008Kh-TR for sip@ietf.org; Fri, 13 Jul 2007 18:32:47 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9Tgo-0002Jc-4z for sip@ietf.org; Fri, 13 Jul 2007 18:32:47 -0400 Received: from [172.17.2.60] ([172.17.2.60]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l6DMWXbT010098 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Jul 2007 17:32:34 -0500 (CDT) (envelope-from bcampen@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) To: Rohan Mahy , Cullen Jennings Message-Id: <13EAACE5-E13C-4F07-8751-F3774160A5D7@estacado.net> From: Byron Campen Date: Fri, 13 Jul 2007 17:32:29 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: fa183e2955b1d12e35b5783ab5b4f6df Cc: SIP IETF Subject: [Sip] Review of draft-ietf-sip-outbound-10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0974282875==" Errors-To: sip-bounces@ietf.org --===============0974282875== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-13--99677071; protocol="application/pkcs7-signature" --Apple-Mail-13--99677071 Content-Type: multipart/alternative; boundary=Apple-Mail-12--99680838 --Apple-Mail-12--99680838 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Here's the notes from my first pass. NITS/editorial: Sec 3.2 "The UA can also include a reg-id parameter which..." Are we not assuming the UA is trying to do outbound? Sec 4.2 "This specification assumes the set is determined via any of a number of configuration mechanisms, and future specifications can define additional mechanisms such as using DNS to discover this set." Seems like this sentence is unnecessary. If you really feel the need to explicitly call out the fact that multiple mechanisms may exist, and that these mechanisms will be defined in future standards, you could maybe say something like: "The mechanism or mechanisms used to configure UAs are outside the scope of this specification, and will be defined in future specifications." If you feel the need to mention a configuration mechanism based on DNS, you might want to move it away from the statement that says "out of scope" ;) Sec 4.2.1 It is probably obvious that third-party registrations cannot use outbound, but it helps the flow if you lead off with this statement. Sec 4.3 "Unless there are privacy reason not to include an instance-id," Mixing singular and plural. Sec 4.4 "For UDP, the upper bound of 29 seconds was selected so that multiple STUN packets could be sent before 30 seconds based on information that many NATs have UDP timeouts as low as 30 seconds. " Kinda awkward. I think you could trim out the "so that multiple STUN packets could be sent before 30 seconds" without sacrificing clarity. eg. "For UDP, the upper bound of 29 seconds was selected based on information that many NATs have UDP timeouts as low as 30 seconds. " Sec 4.5 "...at least one consecutive keepalive response was received." "...at least two consecutive keepalive responses were received."? Sec 5.1 " When an Edge Proxy receives a registration request with a reg-id header parameter in the Contact header field, it needs to determine if it (the edge proxy) will have to be visited for any subsequent requests sent to the user agent identified in the Contact header field, or not. If the Edge Proxy determines that this is the case, it inserts its URI in a Path header field value as described in RFC 3327 [5]. If the Edge Proxy is the first SIP node after the UAC, it either MUST store a "flow token"--containing information about the flow from the previous hop--in its Path URI, or reject the request. The flow token MUST be an identifier that is unique to this network flow. The flow token MAY be placed in the userpart of the URI. In addition, the first node MUST include an 'ob' URI parameter in its Path header field value. If the Edge Proxy is not the first SIP node after the UAC it MUST NOT place an 'ob' URI parameter in a Path header field value. The Edge Proxy can determine if it is the first hop by examining the Via header field. " This is a little awkward/rambling. Here's my shot at making it easier to read. " When an Edge Proxy receives a registration request with a reg-id header parameter in the Contact header field, it must determine whether it is the first SIP node after the UAC. The Edge Proxy can determine if it is the first hop by examining the Via header field. If the edge proxy is the first SIP node after the UAC, it MUST insert a Path header field value, whose URI MUST contain both a flow-token and an 'ob' parameter, or it MUST reject the request. The flow token MUST be a unique identifier for the network flow from the previous hop, and MAY be placed in the userpart of the URI. If the Edge Proxy is not the first SIP node after the UAC, it MAY still insert a Path header field value as described in RFC 3327 [5], but this value MUST NOT contain an 'ob' URI param. " Sec 6, para 7 "The Registrar MUST include the 'outbound' option-tag (defined in Section (Section 12.1)) " Looks like an xref is not doing what you intended. Sec 6, para 7 "Furthermore, the Registrar MUST NOR include this option-tag..." Sec 6, para 7 "Note that the requirements in this section applies to... " Mixing singlar and plural. Sec 6, para 8 "To be compliant with this specification, registrars which can receive SIP requests directly from a UAC without intervening edge proxies MUST implement STUN NAT Keepalives on its SIP UDP ports as described in Section 8 and when it receives a double-CRLF sequence on a connection oriented transport such as TCP or SCTP, it MUST immediately respond with a single CRLF over the same connection." Awkward, how about: " Registrars that can receive SIP requests directly from a UAC (ie, without intervening edge proxies) are required to implement the same keepalive mechanisms as edge proxies (see Sec 5.4). " Sec 6, as a whole It felt like the logic for determining whether outbound processing should be done was excessively spread out in this section. I could propose alternate text if you like. Sec 7 " The proxy uses normal forwarding rules looking at the next-hop target of the message and the value of any stored Path header field vector in the registration binding to decide how to forward the request and populate the Route header in the request. If the proxy stored information about the flow over which it received the REGISTER for the binding, then the proxy MUST send the request over the same 'logical flow' saved with the binding that is known to deliver data to the specific target UA instance. " Awkward. How about: " When the Authoritative Proxy doubles as a registrar, targets may have flow information associated with them (see Sec 6). When forwarding a request to a target that is associated with a flow, the proxy MUST send the request over said flow. Otherwise, the proxy will forward the request as it would normally. " Minor technical: (Where should this go?) Probably should mention that an endpoint using outbound will not be able to target-refresh if the edge proxy uses Record-Routes to store flow-tokens (provided the Dialog was established over a flow). This is because the edge proxy would end up routing according to flow- tokens in the Route-Set, which is invariant (ie, not effected by a target-refresh at all). Sec 4.4.3 What if STUN requests are not answered? How many unanswered STUN requests must go by before the UA considers the flow dead? Will the occasional dropped UDP packet be sufficient evidence that the flow is dead? Sec 8 "When a URI is created that refers to a SIP node that supports STUN as described in this section, the 'keep-stun' URI parameter, as defined in Section 12 MUST be added to the URI." This can be interpreted as saying "If your server element supports STUN, every single URI you create that refers to it needs to have a keep-stun param." I don't know if this is what you intended. There might be valid reasons for not wanting to advertise STUN support on every URI you mint (indeed, not every such URI will be useful; what good will having 'keep-stun' in a Route header be, for example?) Sec 8.1 "When STUN is used together with SigComp [24] compressed SIP messages over the same flow, how the STUN messages are sent depends on the transport protocol. For UDP flows, the STUN messages are simply sent uncompressed, "outside" of SigComp." Since STUN is only used over UDP, we can get rid of the "depends on transport protocol" stuff. Major technical: No problems. Best regards, Byron Campen --Apple-Mail-12--99680838 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Here's = the notes from my first pass.

NITS/editorial:
<= DIV>
Sec = 3.2
"The UA can also include a reg-id parameter = which..."

Are = we not assuming the UA is trying to do outbound?

Sec = 4.2
"This specification assumes the set
=A0=A0 = is determined via any of a number of configuration mechanisms, = and
=A0=A0 future specifications can define additional = mechanisms such as using
=A0=A0 DNS to discover this = set."

Seems = like this sentence is unnecessary. If you really feel the need to = explicitly call out the fact that multiple mechanisms may exist, and = that these mechanisms will be defined in future standards, you could = maybe say something like:

"The mechanism or = mechanisms used to configure UAs are outside the scope of this = specification, and will be defined in future = specifications."

If you feel the need to = mention a configuration mechanism based on DNS, you might want to move = it away from the statement that says "out of scope" ;)

Sec = 4.2.1
It is probably obvious that third-party = registrations cannot use outbound, but it helps the flow if you lead off = with this statement.

Sec = 4.3
"Unless there are
=A0=A0 privacy reason = not to include an instance-id,"
Mixing singular and = plural.

Sec = 4.4
"For UDP, the upper bound of 29
=A0 =A0 =A0= seconds was selected so that multiple STUN packets could be = sent
=A0 =A0 =A0 before 30 seconds based on information that = many NATs have UDP
=A0 =A0 =A0 timeouts as low as 30 seconds.=A0= "

Kinda = awkward. I think you could trim out the "so that multiple STUN packets = could be sent before 30 seconds" without sacrificing = clarity.

eg.
"For UDP, the = upper bound of 29
=A0 =A0 =A0 seconds was selected based on = information that many NATs have UDP
=A0 =A0 =A0 timeouts as = low as 30 seconds. "

Sec = 4.5
"...at least one consecutive keepalive response was = received."

"...at least two = consecutive keepalive responses were received."?

Sec = 5.1
"=A0=A0 When an Edge Proxy receives a registration = request with a reg-id
=A0=A0 header parameter in the Contact = header field, it needs to determine
=A0=A0 if it (the edge = proxy) will have to be visited for any subsequent
=A0=A0 = requests sent to the user agent identified in the Contact = header
=A0=A0 field, or not.=A0 If the Edge Proxy determines = that this is the case,
=A0=A0 it inserts its URI in a Path = header field value as described in RFC
=A0=A0 3327 [5].=A0 If = the Edge Proxy is the first SIP node after the UAC, it
=A0=A0 = either MUST store a "flow token"--containing information about = the
=A0=A0 flow from the previous hop--in its Path URI, or = reject the request.
=A0=A0 The flow token MUST be an = identifier that is unique to this network
=A0=A0 flow.=A0 The = flow token MAY be placed in the userpart of the URI.=A0 In
=A0=A0= addition, the first node MUST include an 'ob' URI parameter in = its
=A0=A0 Path header field value.=A0 If the Edge Proxy is = not the first SIP node
=A0=A0 after the UAC it MUST NOT place = an 'ob' URI parameter in a Path
=A0=A0 header field value.=A0 = The Edge Proxy can determine if it is the first
=A0=A0 hop by = examining the Via header field.
"

This is a little = awkward/rambling. Here's my shot at making it easier to = read.

"=A0=A0 = When an Edge Proxy receives a registration request with a = reg-id
=A0=A0 header parameter in the Contact header field, it = must determine
=A0=A0 whether it is the first SIP node after = the UAC. The Edge Proxy can
=A0=A0 determine if it is the = first hop by examining the Via header field.
=A0=A0 =
=A0=A0 If the edge proxy is the first SIP node after the UAC, = it MUST insert
=A0=A0 a Path header field value, whose URI = MUST contain both a flow-token
=A0=A0 and an 'ob' parameter, = or it MUST reject the request. The flow token
=A0=A0 MUST be = a unique identifier for the network flow from the previous
=A0=A0= hop, and MAY be placed in the userpart of the URI.
=A0=A0 =
=A0=A0 If the Edge Proxy is not the first SIP node after the = UAC, it MAY
=A0=A0 still insert a Path header field value as = described in RFC 3327 [5],
=A0=A0 but this value MUST NOT = contain an 'ob' URI param.
=A0=A0 "

Sec 6, = para 7
"The Registrar MUST include the 'outbound' = option-tag (defined in
=A0=A0 Section (Section 12.1)) = "

Looks like = an xref is not doing what you intended.

Sec 6, = para 7
"Furthermore, = the Registrar MUST NOR
=A0=A0 include this = option-tag..."

Sec 6, = para 7
"Note that the requirements in this = section
=A0=A0 applies to... "
Mixing singlar and = plural.

Sec 6, = para 8
"To be compliant with this specification, = registrars which can receive
=A0=A0 SIP requests directly from = a UAC without intervening edge proxies
=A0=A0 MUST implement = STUN NAT Keepalives on its SIP UDP ports as described
=A0=A0 = in Section 8 and when it receives a double-CRLF sequence on = a
=A0=A0 connection oriented transport such as TCP or SCTP, it = MUST
=A0=A0 immediately respond with a single CRLF over the = same connection."

Awkward, how = about:

"
Registrars that = can receive SIP requests directly from a UAC (ie,
without = intervening edge proxies) are required to implement the same =
keepalive mechanisms as edge proxies (see Sec = 5.4).
"

Sec 6, = as a whole

It felt like the logic for = determining whether outbound processing should be done was excessively = spread out in this section. I could propose alternate text if you like.=A0= =A0 =A0=A0 =A0

Sec = 7
"
=A0=A0 The proxy uses normal forwarding = rules looking at the next-hop target
=A0=A0 of the message and = the value of any stored Path header field vector
=A0=A0 in the = registration binding to decide how to forward the request = and
=A0=A0 populate the Route header in the request.=A0 If the = proxy stored
=A0=A0 information about the flow over which it = received the REGISTER for
=A0=A0 the binding, then the proxy = MUST send the request over the same
=A0=A0 'logical flow' = saved with the binding that is known to deliver data
=A0=A0 to = the specific target UA instance.
"

Awkward. How = about:

"
=A0=A0 When the = Authoritative Proxy doubles as a registrar, targets may have =
=A0=A0 flow information associated with them (see Sec 6). = When forwarding a
=A0=A0 request to a target that is = associated with a flow, the proxy MUST
=A0=A0 send the = request over said flow. Otherwise, the proxy will forward
=A0=A0= the request as it would normally.
"

Minor = technical:

(Where should this = go?)
Probably should mention that an endpoint using outbound = will not be able to target-refresh if the edge proxy uses Record-Routes = to store flow-tokens (provided the Dialog was established over a flow). = This is because the edge proxy would end up routing according to = flow-tokens in the Route-Set, which is invariant (ie, not effected by a = target-refresh at all).

Sec = 4.4.3
What if STUN requests are not answered? How many = unanswered STUN requests must go by before the UA considers the flow = dead? Will the occasional dropped UDP packet be sufficient evidence that = the flow is dead?

Sec = 8
"When a URI is created that refers to a SIP node that = supports STUN as
=A0=A0 described in this section, the = 'keep-stun' URI parameter, as defined
=A0=A0 in Section 12 = MUST be added to the URI."

This can be interpreted as = saying "If your server element supports STUN, every single URI you = create that refers to it needs to have a keep-stun param." I don't know = if this is what you intended. There might be valid reasons for not = wanting to advertise STUN support on every URI you mint (indeed, not = every such URI will be useful; what good will having 'keep-stun' in a = Route header be, for example?)

Sec = 8.1
"When STUN is used together with SigComp [24] = compressed SIP messages
=A0=A0 over the same flow, how the = STUN messages are sent depends on the
=A0=A0 transport = protocol.=A0 For UDP flows, the STUN messages are simply = sent
=A0=A0 uncompressed, "outside" of SigComp."

Since STUN is only used = over UDP, we can get rid of the "depends on transport protocol" = stuff.


Major = technical:

No problems.


Best = regards,
Byron Campen

= --Apple-Mail-12--99680838-- --Apple-Mail-13--99677071 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGKTCCAuIw ggJLoAMCAQICEAda7Ce+sudhzrOd9CS5wJQwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDkyNTE0NDUzNloXDTA3MDkyNTE0NDUz NlowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWxjwykU0M R1yTjA3db2wzExKsMhLa/mc2ekFkBP9BVXi4OHacKSZM3a9T0bWvPcw97ycBfDZX3q2prMRsPUep svJWA0wbiWyOtLzuQGWaQQ6rYbvYlRxil/teAJb1fAKdfFXIXXsiqcdHkhbFn/J7oSn1BCz6v9/v M1zgGNeMPIR34bo9A0hW+QZJxwkSg4KZHdaQ50WcKXtdHdBg46s+0bvDqNmmt7eP91UJk9aiyxyw ZdWVNxzF1oj+nfsnsaHv1py6l62Je82mHsvIZwdSAic1PtXVpU8QmkLJHPmkBEVtN/uHMQ95xgxi eFO5hbYuAT9f7V0ZGe7pUJBR3KwdAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGJjYW1wZW5AZXN0YWNh ZG8ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAeJC75lz4KrtNdPOovb3fkqzD i2HXuOtYHCTOPMc5xJGLdqSF5sc8bwd4mIfevi9Ji4Ccj85A6qINQM/v4OjAvxPkwRwXey/YN6kl 19Te3Eh/t9l4zo2wPdbHTipyc8YJ0GAtT4/fwWiboW3+aquk8DGc7ityr9cdAYY1jAud7d0wggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWls QHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB AMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO 3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gE f6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNy bDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYv wPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bG CE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEAda7Ce+sudhzrOd9CS5wJQwCQYFKw4D AhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNzEz MjIzMjI5WjAjBgkqhkiG9w0BCQQxFgQUxFHnApu8XOZ6dKZewasJDUTG+tcwgYUGCSsGAQQBgjcQ BDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHWuwnvrLn Yc6znfQkucCUMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAhAHWuwnvrLnYc6znfQkucCUMA0GCSqGSIb3DQEBAQUABIIBALwjt/lI f7W7zVqg4EynVfcYPX29Djhl4CxvgEB33KWVZ1eC55cKk685VMAsZqHVcxntDdoL/f2DdtX8kVP6 vvYAYm/+qE7LFbE22P4crzTJleJSs7KkWb83CXXL9O6vkJMtgeMetKvFC/h1EotYtXMHsBCVrzs6 6v4sIgCHVlcH6KoQ1QIfH1yNR3TOhKSUfR1jRuNjvy9ZAfcJ7ARrx9JN18nJdhj2NdLrJgDFxT5A jLssp65lfa5haRB/EUlmFvzBd5oESJSv8oEUhAxlnjJpRWEKLWRWxlGlTmBzJOYWdScML5zKOMdo kB/9KsgZMoQgCbupkddx/HF/zpusaVYAAAAAAAA= --Apple-Mail-13--99677071-- --===============0974282875== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0974282875==-- From sip-bounces@ietf.org Fri Jul 13 22:19:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9XEM-0007M4-PR; Fri, 13 Jul 2007 22:19:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I9XEL-0007Lz-Gj for sip-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 22:19:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9XEK-0007Lp-Uh for sip@ietf.org; Fri, 13 Jul 2007 22:19:33 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9XEK-0001XU-D5 for sip@ietf.org; Fri, 13 Jul 2007 22:19:32 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Jul 2007 22:19:23 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CADjPl0ZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,538,1175486400"; d="scan'208"; a="65159869:sNHT35032510" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6E2JN9T013647 for ; Fri, 13 Jul 2007 22:19:23 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6E2JQWI013572 for ; Sat, 14 Jul 2007 02:19:26 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 22:19:23 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.21.41]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 22:19:22 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 13 Jul 2007 21:19:21 -0500 To: sip@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 14 Jul 2007 02:19:22.0896 (UTC) FILETIME=[64802900:01C7C5BD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8764; t=1184379563; x=1185243563; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20SIP=20Location=20Conveyance-08=20is=20available=20 |Sender:=20 |To:=20sip@ietf.org; bh=QpFuW1EGWFJ85XVh/7ZL+sdXbl7pci6qKgqTF1NwQRs=; b=sMvppdNtW0vBfkaMyfsNjIoZTddAv+0xpnTZRqqCFhOl+c/m++qVlRtVvOwiOSVJnuktI2YU fQ0Y5l4dwNv/rXwTazWKFLfbjQFgno8ZAvZb6wEBTcuVvSyWzrysOV5i; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Subject: [Sip] SIP Location Conveyance-08 is available X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org SIP WG I have updated Location Conveyance to -08. http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-08.txt Venture below for the list of changes, already know issues with -08, and what I know I'm adding (unless told otherwise ;-) >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Session Initiation Protocol Working >Group of the IETF. > > Title : Location Conveyance for the Session > Initiation Protocol > Author(s) : J. Polk, B. Rosen > Filename : draft-ietf-sip-location-conveyance-08.txt > Pages : 38 > Date : 2007-7-11 > >This document defines an extension to the Session Initiation > Protocol (SIP) to convey geographic location information from one > SIP entity to another SIP entity. The extension covers end to end > conveyance as well as location-based routing, where proxy servers > make routing decisions based on the location of the SIP user agents. The following is a brief listing of the (numerous) changes made: - made clear the original intention of the doc to show that this is for sending location of a Target, and not limited to sending location of the UAC, as I've read in several messages to the various lists about this ID's purpose. Each PIDF-LO has an identifier in it. This means more than one PIDF-LO can be in the same SIP request *but* each can be for their own Target. This means more than one Target location can be in the same request. That said, only one Target can be in one PIDF-LO. Meaning, all location information contained within a single PIDF-LO must point at the location of the identified Target of that PIDF-LO, regardless of the internal formats used within the PIDF-LO. This allows, for example, the mixing of civic and geo/coordinate location XML elements - because they all apply to the ONE location of the Target. - I cleaned up the text to make Target, Location Recipient, Location Server, Location Object consistent. - I changed references from "routing" a message to "retargeting" a message whenever the location in a request was used to determine where to forward the message (by a SIP server). - Changed error reporting in a response from a Warning code to a new Geolocation-Error header in a (meaning any) response. Kept the 424 (Bad Location Information) error for times in which a request's included location was the reason the request was rejected. - Added text stating that a transaction can be either successful or have another response (other than 424) and still have a Geolocation-Error header. - added a Geolocation header parameter "recipient=" to indication which SIP entity type a particular locationValue is intended for. OPEN ISSUE here: what does a Location Recipient do if more than one locationValue point to it? (i.e., the case in which the UAS receives 2 locations and both state "recipient=endpoint") - elaborated on the existing header parameters within the Geolocation header "inserted-by=", "used-for-routing" (and the new "recipient=" parameter). The text makes it clearer than any or all 3 of these of these parameters can be present in a locationValue. - expanded the list of Methods that can optionally have the Geolocation header to every one *but* ACK and CANCEL. I left off PRACK from the list, but that was by mistake - and will be corrected in -09. - Geolocation-Error can appear in the same Methods as the Geolocation header. - there can be one or more locationErrorValues in a response, allowing each location in a request to be identified as have bad parts, and giving the Location Recipient the ability to telling each location inserter what was wrong with their inserted location. - because each locationErrorValue in a response has exactly one "inserter=" entity identified, this creates the ability for each response receiver to know of a particular locationErrorValue was meant for them, and to ignore all others. This solves the spoken requirement of if an error is received, how does the receiver know that response was meant for them (since more than one entity can insert location into the request along the path). - The ID RECOMMENDS now that a second locationValue not be added to a request that already has one for a given Target. This will lead to confusion by the Location Recipient. There has been no consensus what to do if this situation would occur - though many have voiced opinions this should be addressed. The only way I know how to address this is either to prioritize the locationValues based on which entity inserted them (trusting one over the other). For example, trusting a UA inserter over a Proxy inserter. This cuts into the concept of Geopriv Sighting (RFC3693). What about trusting LbyR over LbyV. Unfortunately this doesn't give any notion of which entity inserted either location type... - clarified that the "used-for-routing" header parameter of a locationValue is to be kept in the locationValue even if a subsequent proxy routes the request again, but on a different locationValue within the request. This will help a Location Recipient determine how the request got to this destination (used more for after the fact troubleshooting). OPEN ISSUE here: I added text here stating something unusual in SIP, the concept of inserting header values in a certain order to ensure a path of hops could be determined. Robert Sparks has already pointed out there is another, more consistent way to solve this. I will take his direction to be more consistent here... - Clarified the rough consensus stance that location not be carried in any response. This is for fragmentations reasons, as well as the inability to error that locationValue. - increased the number of IANA registrations to include the locationValue header parameters, and given brief definitions to the Geolocation-Error codes (similar to what Warning has); also registered the new Geolocation-Error header. - Appendix B was all the "changes since last version". It is now an INVITE request with an S/MIME protected PIDF-LO using the civic format. This location position is the same as the (x/y) Coordinate position in section 4.1. - plus cleaned up a bunch of other little nits throughout doc What I already know is missing or in error in -08 (that will be fixed in -09) - there is no event package for the fetch function the SUB/NOT to dereference an initial PIDF-LO of the Target. This event package will be (something like) location-fetch, for one-time only fetches of location of the Target, not for pending subscriptions or location tracking or anything like that. Someone wanting that capability will need to wrote a new doc for that, cuz it's not going in this doc. - I missed changing the Geolocation-Error examples from the format of the Warning header, that used SPACE between header values, where the BNF of the Geolocation-Error called for a SEMI between values. This is an artifact from changing this error reporting from Reason to Warning to a new header.... I got the 1st example right, then missed the remaining ones (oops!) - Need to fix the BNF of the Geolocation-Error header wrt to the host name - to be equivalent to the "sent-by" FQDN of the Via, identifying the location inserting entity of a particular locationValue (that had an error in it). - I need to get a solution idea for and then consensus of the two OPEN ISSUES listed above... What I'm planning on adding (until rough consensus tells me not to) is the following: - the ability for the Geolocation-Error locationErrorValue to contain each CAType that the Location Recipient had a problem with (from the request). The CAType values will *NOT* be sent, just the CATypes themselves. This greatly adds to the information about the location error experienced by the Location Recipient (to the Location inserter) in the response. - I might break out the text regarding the number of locations in a request, and what those limitations are; because I've had a lot of discussion about how this facet is interpreted - and more than a few don't get it right - meaning I'm not being clear enough. This means there is a lack of clarity in the text. A separate subsection might be necessary. comments (or questions) are appreciated James _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 13 22:27:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9XLk-0000oM-R0; Fri, 13 Jul 2007 22:27:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I9XLg-0000fq-Ub for sip-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 22:27:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9XLg-0000fL-Jx for sip@ietf.org; Fri, 13 Jul 2007 22:27:08 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9XLc-0001cz-9I for sip@ietf.org; Fri, 13 Jul 2007 22:27:08 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Jul 2007 22:26:55 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAI7Rl0ZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,538,1175486400"; d="scan'208"; a="65160063:sNHT178044368" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6E2QtsH015010 for ; Fri, 13 Jul 2007 22:26:55 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6E2QtEb006471 for ; Sat, 14 Jul 2007 02:26:55 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); Fri, 13 Jul 2007 22:26:55 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.21.41]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 22:26:55 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 13 Jul 2007 21:26:54 -0500 To: sip@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 14 Jul 2007 02:26:55.0304 (UTC) FILETIME=[72282480:01C7C5BE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1212; t=1184380015; x=1185244015; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Update=20to=20draft-polk-sip-rph-new-namespaces-01.txt=20 |Sender:=20 |To:=20sip@ietf.org; bh=NSrW/qwly/dzSudU9E96kWJCw3rTsFiLyI8MlzeVbwE=; b=Nh19BmUxBH66ptx1pa39GtUOVtU8DTuSKqPQU3+4j4OyWKRLBoQvgMYoj0TPXQI3wnPg8ugq bbnMgV4m9RjB3mLMh6clIeJBRDVFP8anuFxmiPRhylsZLjFGR72D8ddQ; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Sip] Update to draft-polk-sip-rph-new-namespaces-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org SIP WG I've updated this ID for your consideration. I've cleaned up the number of new namespaces, as well as the number of priority-values per namespace. This is a very simple IANA registration document with a very small update to RFC 4412 included, which is adding a delimiter in RPH namespaces to enable sub-namespaces. The requirement for this is old from a very large customer, and has already been codified by most (all?) willing vendors of this customer. Comments are appreciated James >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-polk-sip-rph-new-namespaces-01.txt > > Title : New Session Initiation Protocol > Resource-Priority Header Namespaces for the Defense Information Systems Agency > Author(s) : J. Polk > Filename : draft-polk-sip-rph-new-namespaces-01.txt > Pages : 12 > Date : 2007-7-13 > >This document creates additional Session Initiation Protocol > Resource-Priority header namespaces, to be IANA registered. This > document intends to update RFC 4412, as a Proposed Standard document > if published by the RFC-Editor. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 14 00:36:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9ZN6-0005x3-9Z; Sat, 14 Jul 2007 00:36:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I9ZN4-0005vZ-VB for sip-confirm+ok@megatron.ietf.org; Sat, 14 Jul 2007 00:36:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9ZN4-0005vO-Ia for sip@ietf.org; Sat, 14 Jul 2007 00:36:42 -0400 Received: from mail85.messagelabs.com ([216.82.240.99]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I9ZN4-0004yE-4h for sip@ietf.org; Sat, 14 Jul 2007 00:36:42 -0400 X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-5.tower-85.messagelabs.com!1184387750!32604047!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [20.137.52.151] Received: (qmail 15908 invoked from network); 14 Jul 2007 04:35:51 -0000 Received: from amer-mta07.csc.com (HELO amer-mta07.csc.com) (20.137.52.151) by server-5.tower-85.messagelabs.com with AES256-SHA encrypted SMTP; 14 Jul 2007 04:35:51 -0000 Received: from amer-gw05.amer.csc.com (amer-gw05.amer.csc.com [20.6.39.241]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id l6E4a5Ao013915 for ; Sat, 14 Jul 2007 00:36:05 -0400 (EDT) In-Reply-To: To: "James M. Polk" Subject: Re: [Sip] Update to draft-polk-sip-rph-new-namespaces-01.txt MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Sat, 14 Jul 2007 00:35:47 -0400 X-MIMETrack: Serialize by Router on AMER-GW05/SRV/CSC(Release 7.0.2FP1 HF180|March 29, 2007) at 07/14/2007 12:35:10 AM, Serialize complete at 07/14/2007 12:35:10 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0824702213==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0824702213== Content-Type: multipart/alternative; boundary="=_alternative 00193F8085257318_=" This is a multipart message in MIME format. --=_alternative 00193F8085257318_= Content-Type: text/plain; charset="US-ASCII" Mainly editorial comments. It is a little confusing that section 2.1 refers to "dsn-usarmy dsn-usnavy dsn-usairforce dsn-usmarines" but those are not among the new namespaces being created in this document. It would be clearer if you used the actual proposed namespaces (e.g., dsn-000000 dsn-000010 dsn-000020 dsn-000030) in the discussion of section 2.1. When I was explaining the earlier version to someone, we got off on an extended tangent about whether or not DISA "would separate army calls from navy calls". If the example used the numerical "sub domains", that confusion would be avoided. If I am understanding correctly, there is (or a least may be) a one-to-one correspondence between the "domain-subdomain" as defined here, and the "domain-subdomain" defined in draft-polk-tsvwg-signaled-domain-id-00. draft-polk-tsvwg-signaled-domain-id-00 mentions this relationship. Would it make sense to mention the relationship here as well? Janet "James M. Polk" wrote on 07/13/2007 10:26:54 PM: > SIP WG > > I've updated this ID for your consideration. > > I've cleaned up the number of new namespaces, as well as the number > of priority-values per namespace. > > This is a very simple IANA registration document with a very small > update to RFC 4412 included, which is adding a delimiter in RPH > namespaces to enable sub-namespaces. > > The requirement for this is old from a very large customer, and has > already been codified by most (all?) willing vendors of this customer. > > Comments are appreciated > > James > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-polk-sip-rph-new-namespaces-01.txt > > > > Title : New Session Initiation Protocol > > Resource-Priority Header Namespaces for the Defense Information > Systems Agency > > Author(s) : J. Polk > > Filename : draft-polk-sip-rph-new-namespaces-01.txt > > Pages : 12 > > Date : 2007-7-13 > > > >This document creates additional Session Initiation Protocol > > Resource-Priority header namespaces, to be IANA registered. This > > document intends to update RFC 4412, as a Proposed Standard document > > if published by the RFC-Editor. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --=_alternative 00193F8085257318_= Content-Type: text/html; charset="US-ASCII"
Mainly editorial comments.

It is a little  confusing that section 2.1 refers to
"dsn-usarmy
dsn-usnavy
dsn-usairforce
dsn-usmarines"

but those are not among the new namespaces being created in this document.  It would be clearer if you used the actual proposed namespaces (e.g.,dsn-000000      dsn-000010      dsn-000020      dsn-000030) in the discussion of section 2.1.

When I was explaining the earlier version to someone, we got off on an extended tangent about whether or not DISA "would separate army calls from navy calls".  If the example  used the numerical "sub domains", that confusion would be avoided.

If I am understanding correctly, there is (or a least may be) a one-to-one correspondence between the "domain-subdomain" as defined here, and the "domain-subdomain"  defined in draft-polk-tsvwg-signaled-domain-id-00.  draft-polk-tsvwg-signaled-domain-id-00 mentions this relationship.  Would it make sense to mention the relationship here as well?

Janet

"James M. Polk" <jmpolk@cisco.com> wrote on 07/13/2007 10:26:54 PM:

> SIP WG
>
> I've updated this ID for your consideration.
>
> I've cleaned up the number of new namespaces, as well as the number
> of priority-values per namespace.
>
> This is a very simple IANA registration document with a very small
> update to RFC 4412 included, which is adding a delimiter in RPH
> namespaces to enable sub-namespaces.
>
> The requirement for this is old from a very large customer, and has
> already been codified by most (all?) willing vendors of this customer.
>
> Comments are appreciated
>
> James
>
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-polk-sip-rph-new-namespaces-01.txt
> >
> >         Title           : New Session Initiation Protocol
> > Resource-Priority Header Namespaces for the Defense Information
> Systems Agency
> >         Author(s)       : J. Polk
> >         Filename        : draft-polk-sip-rph-new-namespaces-01.txt
> >         Pages           : 12
> >         Date            : 2007-7-13
> >
> >This document creates additional Session Initiation Protocol
> >    Resource-Priority header namespaces, to be IANA registered.  This
> >    document intends to update RFC 4412, as a Proposed Standard document
> >    if published by the RFC-Editor.
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
 --=_alternative 00193F8085257318_=-- --===============0824702213== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0824702213==-- From sip-bounces@ietf.org Sun Jul 15 18:22:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IACSo-0003q3-Bw; Sun, 15 Jul 2007 18:21:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IACSl-0003pq-O5 for sip-confirm+ok@megatron.ietf.org; Sun, 15 Jul 2007 18:21:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IACSl-0003oo-Bf for sip@ietf.org; Sun, 15 Jul 2007 18:21:11 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IACSk-0003ql-Ch for sip@ietf.org; Sun, 15 Jul 2007 18:21:11 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 15 Jul 2007 18:21:10 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPY5mkZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,540,1175486400"; d="scan'208"; a="65221649:sNHT29724826" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6FML8cQ017093; Sun, 15 Jul 2007 18:21:08 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6FML8EZ027325; Sun, 15 Jul 2007 22:21:08 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jul 2007 18:21:08 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.20.44]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jul 2007 18:21:07 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 15 Jul 2007 17:21:06 -0500 To: Janet P Gunn From: "James M. Polk" Subject: Re: [Sip] Update to draft-polk-sip-rph-new-namespaces-01.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 15 Jul 2007 22:21:08.0013 (UTC) FILETIME=[70E99DD0:01C7C72E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3685; t=1184538068; x=1185402068; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20Update=20to=20draft-polk-sip-rph-new-namespac es-01.txt |Sender:=20 |To:=20Janet=20P=20Gunn=20; bh=B38skzwj++R4X4SyEm69xPc04j7r0xCF86Z2nHSLJtY=; b=ZV3XqdfMmExxrqWBvRnf2U8I6+xB6Oz2i5m3zSivrb9FOw3BYHowbDdcJy6BZh62Y4mHRk2F EVrx+4ABd3zUPwTFDvLrSCyK/SqZYhCjn9mMeU8NOxKE5R5jUXKaVHwH; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 11:35 PM 7/13/2007, Janet P Gunn wrote: >Mainly editorial comments. > >It is a little confusing that section 2.1 refers to >"dsn-usarmy >dsn-usnavy >dsn-usairforce >dsn-usmarines" > >but those are not among the new namespaces being created in this >document. It would be clearer if you used the actual proposed >namespaces >(e.g.,dsn-000000 dsn-000010 dsn-000020 dsn-000030) in >the discussion of section 2.1. I suppose I could use example that are being registered, but the idea of a division of a domain by recognized service boundaries is something that I thought would help readers understand the concept better with. >When I was explaining the earlier version to someone, we got off on >an extended tangent about whether or not DISA "would separate army >calls from navy calls". well.... they have had us vendors plan and codify for this for more than 2 years, so it's a reality. >If the example used the numerical "sub domains", that confusion >would be avoided. what would you change the description to? DSN is a domain. Divide it up into several subsets of domains and one c/would logically come up with the term sub-domain -- mean part of the larger, which each is in this case. >If I am understanding correctly, there is (or a least may be) a >one-to-one correspondence between the "domain-subdomain" as defined >here, and the "domain-subdomain" defined in >draft-polk-tsvwg-signaled-domain-id-00. this *can* be a configuration, but it does not have to be - so this relationship (as you mention) isn't a hard-and-fast rule to be universally applied to either doc. >draft-polk-tsvwg-signaled-domain-id-00 mentions this >relationship. Would it make sense to mention the relationship here as well? I can mention draft-polk-tsvwg-signaled-domain-id-00 as an informative reference in this doc, yes. James >Janet > > >"James M. Polk" wrote on 07/13/2007 10:26:54 PM: > > > SIP WG > > > > I've updated this ID for your consideration. > > > > I've cleaned up the number of new namespaces, as well as the number > > of priority-values per namespace. > > > > This is a very simple IANA registration document with a very small > > update to RFC 4412 included, which is adding a delimiter in RPH > > namespaces to enable sub-namespaces. > > > > The requirement for this is old from a very large customer, and has > > already been codified by most (all?) willing vendors of this customer. > > > > Comments are appreciated > > > > James > > > > >A URL for this Internet-Draft is: > > >http://www.ietf.org/internet-drafts/draft-polk-sip-rph-new-namesp > aces-01.txt > > > > > > Title : New Session Initiation Protocol > > > Resource-Priority Header Namespaces for the Defense Information > > Systems Agency > > > Author(s) : J. Polk > > > Filename : draft-polk-sip-rph-new-namespaces-01.txt > > > Pages : 12 > > > Date : 2007-7-13 > > > > > >This document creates additional Session Initiation Protocol > > > Resource-Priority header namespaces, to be IANA registered. This > > > document intends to update RFC 4412, as a Proposed Standard document > > > if published by the RFC-Editor. > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 15 18:59:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAD45-0006eO-Oc; Sun, 15 Jul 2007 18:59:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAD44-0006eJ-Sb for sip-confirm+ok@megatron.ietf.org; Sun, 15 Jul 2007 18:59:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAD44-0006eB-Hf for sip@ietf.org; Sun, 15 Jul 2007 18:59:44 -0400 Received: from mail130.messagelabs.com ([216.82.250.163]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IAD3p-0004WE-59 for sip@ietf.org; Sun, 15 Jul 2007 18:59:44 -0400 X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-8.tower-130.messagelabs.com!1184540302!30077960!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [20.137.52.151] Received: (qmail 6083 invoked from network); 15 Jul 2007 22:58:23 -0000 Received: from amer-mta07.csc.com (HELO amer-mta07.csc.com) (20.137.52.151) by server-8.tower-130.messagelabs.com with AES256-SHA encrypted SMTP; 15 Jul 2007 22:58:23 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id l6FMwbFf007442 for ; Sun, 15 Jul 2007 18:58:37 -0400 (EDT) In-Reply-To: To: "James M. Polk" Subject: Re: [Sip] Update to draft-polk-sip-rph-new-namespaces-01.txt MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Sun, 15 Jul 2007 18:58:18 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1 HF180|March 29, 2007) at 07/15/2007 06:57:05 PM, Serialize complete at 07/15/2007 06:57:05 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0124915399==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0124915399== Content-Type: multipart/alternative; boundary="=_alternative 007E2F8485257319_=" This is a multipart message in MIME format. --=_alternative 007E2F8485257319_= Content-Type: text/plain; charset="US-ASCII" "James M. Polk" wrote on 07/15/2007 06:21:06 PM: > At 11:35 PM 7/13/2007, Janet P Gunn wrote: > > >Mainly editorial comments. > > > >It is a little confusing that section 2.1 refers to > >"dsn-usarmy > >dsn-usnavy > >dsn-usairforce > >dsn-usmarines" > > > >but those are not among the new namespaces being created in this > >document. It would be clearer if you used the actual proposed > >namespaces > >(e.g.,dsn-000000 dsn-000010 dsn-000020 dsn-000030) in > >the discussion of section 2.1. > ... > > what would you change the description to? > > DSN is a domain. Divide it up into several subsets of domains and one > c/would logically come up with the term sub-domain -- mean part of > the larger, which each is in this case. Probably, I would just add a sentence saying something like "These examples illustrate the principle of the domain and subdomain within a namespace but are not the actual namespaces being registered." Janet --=_alternative 007E2F8485257319_= Content-Type: text/html; charset="US-ASCII"



"James M. Polk" <jmpolk@cisco.com> wrote on 07/15/2007 06:21:06 PM:

> At 11:35 PM 7/13/2007, Janet P Gunn wrote:
>
> >Mainly editorial comments.
> >
> >It is a little  confusing that section 2.1 refers to
> >"dsn-usarmy
> >dsn-usnavy
> >dsn-usairforce
> >dsn-usmarines"
> >
> >but those are not among the new namespaces being created in this
> >document.  It would be clearer if you used the actual proposed
> >namespaces
> >(e.g.,dsn-000000      dsn-000010      dsn-000020      dsn-000030) in
> >the discussion of section 2.1.
>
...
>
> what would you change the description to?
>
> DSN is a domain. Divide it up into several subsets of domains and one
> c/would logically come up with the term sub-domain -- mean part of
> the larger, which each is in this case.
Probably, I would just add a sentence  saying something like
"These examples illustrate the principle of the domain and subdomain within a namespace but are not the actual namespaces being registered."

Janet --=_alternative 007E2F8485257319_=-- --===============0124915399== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0124915399==-- From sip-bounces@ietf.org Sun Jul 15 19:18:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IADLn-0003mo-KW; Sun, 15 Jul 2007 19:18:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IADLl-0003mh-U5 for sip-confirm+ok@megatron.ietf.org; Sun, 15 Jul 2007 19:18:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IADLl-0003mZ-KU for sip@ietf.org; Sun, 15 Jul 2007 19:18:01 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IADLh-000876-Aq for sip@ietf.org; Sun, 15 Jul 2007 19:18:01 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 15 Jul 2007 19:17:56 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAENImkZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,540,1175486400"; d="scan'208"; a="65223130:sNHT26514524" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6FNHunR027097; Sun, 15 Jul 2007 19:17:56 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6FNHuWI001937; Sun, 15 Jul 2007 23:17:56 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jul 2007 19:17:56 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.20.44]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jul 2007 19:17:56 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 15 Jul 2007 18:17:55 -0500 To: Janet P Gunn From: "James M. Polk" Subject: Re: [Sip] Update to draft-polk-sip-rph-new-namespaces-01.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 15 Jul 2007 23:17:56.0332 (UTC) FILETIME=[606DD2C0:01C7C736] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1156; t=1184541476; x=1185405476; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20Update=20to=20draft-polk-sip-rph-new-namespac es-01.txt |Sender:=20 |To:=20Janet=20P=20Gunn=20; bh=d9IHi3iEjv0ErqZCM5LxpS3MT2nmswX0DuNyVeb850o=; b=LF9swVu5gfabgLTtYdmT5U43L0x+puwqi+AnTx0lTuoOeB+xyfMnxCe3oOJSMcqiVlf5bkKs K1kTJVkzcW3RWIb4udRoCUXGhmTgsmvu2AF1A9tfgwRsKUcOIMFRg2RA; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 05:58 PM 7/15/2007, Janet P Gunn wrote: >"James M. Polk" wrote on 07/15/2007 06:21:06 PM: > > > At 11:35 PM 7/13/2007, Janet P Gunn wrote: > > > > >Mainly editorial comments. > > > > > >It is a little confusing that section 2.1 refers to > > >"dsn-usarmy > > >dsn-usnavy > > >dsn-usairforce > > >dsn-usmarines" > > > > > >but those are not among the new namespaces being created in this > > >document. It would be clearer if you used the actual proposed > > >namespaces > > >(e.g.,dsn-000000 dsn-000010 dsn-000020 dsn-000030) in > > >the discussion of section 2.1. > > >... > > > > what would you change the description to? > > > > DSN is a domain. Divide it up into several subsets of domains and one > > c/would logically come up with the term sub-domain -- mean part of > > the larger, which each is in this case. > >Probably, I would just add a sentence saying something like >"These examples illustrate the principle of the domain and subdomain >within a namespace but are not the actual namespaces being registered." something like this is easy to add, so I will. >Janet _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 16 04:20:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IALol-0001GY-9S; Mon, 16 Jul 2007 04:20:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IALoi-0001G9-Uv for sip-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 04:20:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IALoi-0001Fy-Hj for sip@ietf.org; Mon, 16 Jul 2007 04:20:28 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IALod-0002O0-Lx for sip@ietf.org; Mon, 16 Jul 2007 04:20:28 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL9006QFJ47AQ@szxga03-in.huawei.com> for sip@ietf.org; Mon, 16 Jul 2007 16:19:19 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL90095PJ47T6@szxga03-in.huawei.com> for sip@ietf.org; Mon, 16 Jul 2007 16:19:19 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL900HZZJ43PG@szxml03-in.huawei.com> for sip@ietf.org; Mon, 16 Jul 2007 16:19:19 +0800 (CST) Date: Mon, 16 Jul 2007 16:19:15 +0800 From: Qian Sun To: Aki.Niemi@nokia.com Message-id: <002b01c7c781$ff8b0d00$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Thread-index: AcfHgf9Kufd6Gj0oRQWR3ajZH6bOCA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sip@ietf.org Subject: [Sip] Comments on draft-ietf-sip-subnot-etags-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, As this draft mentioned, the presence rules may affect the views of the resource state. If the presence rules of presentity are modified, all of etags for this presentity have to be abandoned. Or the PS has to evaluate whether each etag still is valid. For filtering, there is similar problem: http://www1.ietf.org/mail-archive/web/sip/current/msg19724.html These are difference between HTTP and SIP events framework. Cheers, Qian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 16 04:29:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IALxB-0000CT-Ca; Mon, 16 Jul 2007 04:29:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IALx9-0000CI-DR for sip-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 04:29:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IALx9-0000CA-1z for sip@ietf.org; Mon, 16 Jul 2007 04:29:11 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IALwt-00079U-IN for sip@ietf.org; Mon, 16 Jul 2007 04:29:10 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E6AB021AF0; Mon, 16 Jul 2007 10:28:22 +0200 (CEST) X-AuditID: c1b4fb3e-b0034bb0000007e1-86-469b2c26640e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B51472114D; Mon, 16 Jul 2007 10:28:22 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 10:28:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] UA Loose Routing Date: Mon, 16 Jul 2007 10:25:53 +0200 Message-ID: <7374777208BDC7449D5620EF94232567072B6598@esealmw113.eemea.ericsson.se> In-Reply-To: <468D6BF5.4090801@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] UA Loose Routing Thread-Index: Ace/URNnrbQJYenaQfC5hXiFOb+uwAAaiMGg References: <466F5E26.2000709@cisco.com> <5D1A7985295922448D5550C94DE29180012C9836@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF9423256705397552@esealmw113.eemea.ericsson.se> <5D1A7985295922448D5550C94DE29180012C99F6@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF94232567054171DC@esealmw113.eemea.ericsson.se> <5D1A7985295922448D5550C94DE29180012C9A19@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF94232567054174B3@esealmw113.eemea.ericsson.se> <468B0FE7.7040908@cisco.com> <7374777208BDC7449D5620EF9423256706F9BF74@esealmw113.eemea.ericsson.se> <468D6BF5.4090801@cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 16 Jul 2007 08:28:22.0309 (UTC) FILETIME=[4571FD50:01C7C783] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: IETF SIP List , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>>My objective was to reduce this count. Indeed I was hopeful that=20 >>>UA-loose-route would allow us to deprecate P-Called-Party-ID, not the >>>other way around. WIth UA-loose-route, we end up with: >>>=20 >>>Request-URI: identifies the target Route: tells you how to get to the >>>target To: tells you the original target History info: sequence of=20 >>>identities of targets >>=20 >>If people can't explain to their implementors the meaning of different >>SIP headers maybe THAT is something we should concentrate on, and if=20 >>needed write a draft about. >=20 >Its not a question of documentation. Its that we would in=20 >fact have multiple headers which mean the same thing. So, for my clarification, which headers would mean the same thing using P-Called-Party-ID? >>>which is much cleaner. >>=20 >>If we would re-do SIP I am sure lots of things could be done cleaner. >>=20 >>=20 >>P-Called-Party-ID does not change the current routing mechanism, and=20 >>it does not have the potential issue with proxies (and possible also >>SBCs) that you have mentioned. And the proxy re-writing the R-URI can=20 >>use the mechanism no matter if the UA supports it or not. >=20 >Sure, but its useless unless the UA supports it. So my point=20 >is, in all cases, we are talking about changes to UA and to=20 >proxy to do something useful here. The UA-loose-route=20 >mechanism doesn't require any changes beyond those two. The P-Called-Party-ID solution doesn't require any changes to proxies at all. And, even if a proxy wouldn't have a problem with the loose routing solution as such, in some environments the proxies processes the P-Called-Party-ID header. So, you would still need to update those proxies, if you want to replace the P- header mechanism with something else. =20 >>>So, functionally, P-Called-Party-ID could work. Any number of things *can* work. >>=20 >>Yes, but P-Called-Party-ID is a standardized mechanism, made for this purpose, which most likely does work. >=20 >We have lots of P-headers that already exist. That doesn't mean we shouldn't bother to provide an architecturally better=20 >solution. I don't think a solution based on a P- header automatically is a "bad" solution. In this case the main purpose is to provide a URI, and a header (whether it's a P- header or not is not relevant) is perfectly ok for that I think. And, in general I think we give the market the wrong picture if we make changes that may affect existing deployments and systems (the P-Called-Party header has been part of IMS for a realtively long time) - especailly when nothing is broken with the current systems. Yes, maybe there are things we think could have been done cleaner, but in some cases we just have to accept the fact that things have been defined in a specific way. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 16 09:26:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAQb4-0005Sq-9b; Mon, 16 Jul 2007 09:26:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAQb3-0005Sj-5T for sip-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 09:26:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAQb2-0005SV-RV for sip@ietf.org; Mon, 16 Jul 2007 09:26:40 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAQay-00029h-A1 for sip@ietf.org; Mon, 16 Jul 2007 09:26:40 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A80C52055C; Mon, 16 Jul 2007 15:26:35 +0200 (CEST) X-AuditID: c1b4fb3c-b1e82bb0000007e1-1d-469b720b1b11 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 874B9203E2; Mon, 16 Jul 2007 15:26:35 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 15:26:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP Identity using Media Path Date: Mon, 16 Jul 2007 15:26:34 +0200 Message-ID: <7374777208BDC7449D5620EF942325670730AA22@esealmw113.eemea.ericsson.se> In-Reply-To: <1dbc01c7be59$fbd62270$2014590a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Identity using Media Path Thread-Index: Ace+Gd+1mZGbB63fSbi5GA3N5+TpCwAPyvDwAlSiz8A= References: <1183539618.30723.44.camel@eeek.ingate.se> <1dbc01c7be59$fbd62270$2014590a@amer.cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Dan Wing" , "Hans Persson" , X-OriginalArrivalTime: 16 Jul 2007 13:26:35.0213 (UTC) FILETIME=[EE7277D0:01C7C7AC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Dan,=20 >>Section 4.1, item about Contact: >>=20 >>How can the Contact header usefully be used in the signing process? An >>SBC along the message path will happily replace it. >=20 >I have removed that in -01 (which isn't yet published, of=20 >course). There was some thought it was necessary, but I=20 >agree it should be removed from the signature. >=20 >On a similar note, I am considering removing CallId from the=20 >signature. >Oftentimes the Call Id value contains an IP address (in=20 >dotted decimal or hex), and an SBC or B2BUA may also want to=20 >rewrite such a CallId. I have made a note of that in -01 so=20 >this can be discussed. An SBC can modify almost any header. Looking at chapter 4.1, I would say that at least the To- and From headers are in the "risk zone" (EVEN if you only use the addr-spec part). The CSeq (at least the digit portion) may also be modified, for example if there has been some "dialog piggybacked" requests sent between the SBC and another entity, but not end-to-end. In that case the the SBC may have to increase the CSeq before forwarding the request, if the digit portion value has already been used in a request sent by the SBC in the same direction. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 16 10:15:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IARLp-0002sR-W8; Mon, 16 Jul 2007 10:15:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IARLo-0002qK-KT for sip-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 10:15:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IARLo-0002qB-Au for sip@ietf.org; Mon, 16 Jul 2007 10:15:00 -0400 Received: from mail.tataelxsi.co.in ([203.200.1.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IARLj-0004nP-TC for sip@ietf.org; Mon, 16 Jul 2007 10:15:00 -0400 Received: (from mail.tataelxsi.co.in [220.227.120.66]) by mail.tataelxsi.co.in (MOS 3.8.4-GA) with HTTP/1.1 id ABJ27529 (AUTH rathod); Mon, 16 Jul 2007 19:44:53 +0530 (IST) From: Rathod Subhashchandra To: sip@ietf.org X-Mailer: Mirapoint Webmail Direct 3.8.4-GA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20070716194453.ABJ27529@mail.tataelxsi.co.in> Date: Mon, 16 Jul 2007 19:44:53 +0530 (IST) X-Junkmail-Status: score=10/50, host=mail.tataelxsi.co.in X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090209.469B7D5C.0128,ss=1,fgs=0, ip=0.0.0.0, so=2007-03-13 10:31:19, dmn=5.3.14/2007-05-31 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ietf-rtpsec@imc.org Subject: [Sip] Sending SIP packet over TCP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Guys, I am facing a problem in following scenario on WinCE 5.0. Please let me know if you got an answer for this ASAP. In SIP Client 1. I have opened server TCP and UDP on 5060 port for polling responses aswell as request 2. To send a SIP packet, I have opened a TCP client socket 5060 for destination. I got a socket descriptor as 9 SIP request goes on dest port as 5060, src port as 1997. Server is responding on src port 1997. Hence my polling is failing as it is for TCP and UDP sockets. Src port 1997 is not constant. It is just random. for me to poll, I need socket descriptor. How to get this logical port number given TCP? If I can get this, I can create a socket and get the descriptor and add to polling list Waiting a quick response if possible. Thanks ! Rathod. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 16 10:41:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IARlm-0003xq-W8; Mon, 16 Jul 2007 10:41:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IARll-0003x6-9R for sip-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 10:41:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IARlk-0003wy-Tt for sip@ietf.org; Mon, 16 Jul 2007 10:41:48 -0400 Received: from cluster-f.mailcontrol.com ([85.119.2.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IARlk-0000S8-F3 for sip@ietf.org; Mon, 16 Jul 2007 10:41:48 -0400 Received: from rly34f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly34f.srv.mailcontrol.com (MailControl) with ESMTP id l6GEfIr8032145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Jul 2007 15:41:18 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly34f.srv.mailcontrol.com (MailControl) id l6GEfBZF031644 for sip@ietf.org; Mon, 16 Jul 2007 15:41:11 +0100 Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12]) by rly34f-eth0.srv.mailcontrol.com (envelope-sender attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id l6GEdJhn023887; Mon, 16 Jul 2007 15:41:11 +0100 (BST) Received: from ExBE03.nasstar-t1.net ([10.2.10.102]) by exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 15:39:06 +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" Subject: RE: [Sip] Sending SIP packet over TCP Date: Mon, 16 Jul 2007 15:38:52 +0100 Message-ID: <165288C2C3E29449AFDE022DD10CC47105AEB456@ExBE03.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Sending SIP packet over TCP Thread-Index: AcfHs8cTB4vv5gckTBSWAU5T66iPeAAAppUg From: "Attila Sipos" To: "Rathod Subhashchandra" , X-OriginalArrivalTime: 16 Jul 2007 14:39:06.0348 (UTC) FILETIME=[0FECFAC0:01C7C7B7] X-Scanned-By: MailControl A-07-07-10 (www.mailcontrol.com) on 10.70.1.144 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org If you got socket descriptor 9 when creating the socket, and to poll you need the socket descriptor (and if you really need to poll) then poll socket descriptor 9. Or is this not possible? Regards, Attila =20 -----Original Message----- From: Rathod Subhashchandra [mailto:rathod@tataelxsi.co.in]=20 Sent: 16 July 2007 15:15 To: sip@ietf.org Cc: ietf-rtpsec@imc.org Subject: [Sip] Sending SIP packet over TCP Hi Guys, I am facing a problem in following scenario on WinCE 5.0. Please let me know if you got an answer for this ASAP. In SIP Client 1. I have opened server TCP and UDP on 5060 port for polling responses aswell as request 2. To send a SIP packet, I have opened a TCP client socket 5060 for destination. I got a socket descriptor as 9 SIP request goes on dest port as 5060, src port as 1997. Server is responding on src port 1997. Hence my polling is failing as it is for TCP and UDP sockets. Src port 1997 is not constant. It is just random. for me to poll, I need socket descriptor. How to get this logical port number given TCP? If I can get this, I can create a socket and get the descriptor and add to polling list Waiting a quick response if possible. Thanks ! Rathod. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 16 12:17:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IATGa-0004vr-Or; Mon, 16 Jul 2007 12:17:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IATGY-0004uc-Gy for sip-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 12:17:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IATGY-0004t2-5j for sip@ietf.org; Mon, 16 Jul 2007 12:17:42 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IATGI-0003ad-U5 for sip@ietf.org; Mon, 16 Jul 2007 12:17:42 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 16 Jul 2007 09:17:26 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAG02m0arR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,542,1175497200"; d="scan'208"; a="182901237:sNHT26710110" 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 l6GGHQg3011141; Mon, 16 Jul 2007 09:17:26 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l6GGHP4w008917; Mon, 16 Jul 2007 16:17:25 GMT From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" , "'Hans Persson'" , Subject: RE: [Sip] SIP Identity using Media Path Date: Mon, 16 Jul 2007 09:17:25 -0700 Message-ID: <01af01c7c7c4$cc62e860$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7374777208BDC7449D5620EF942325670730AA22@esealmw113.eemea.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace+Gd+1mZGbB63fSbi5GA3N5+TpCwAPyvDwAlSiz8AABWk4IA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1214; t=1184602646; x=1185466646; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20SIP=20Identity=20using=20Media=20Path |Sender:=20; bh=8BRHP7wtA6+C63K0sAzuR++Nd9FHBVQ60cbyb+Y3LKM=; b=FcSNFpyWMbfJdCN2H3CruN0IzJ/W3cG4usiQLkO52z5SnLqqBL9VHpzPtaHQLETZhTmaHdVw LN6wgDnH9rKjs4p7f6wPi71GEYUpQuQMUBACHochVKZdz45bKlsey1Q4; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > An SBC can modify almost any header. Yes. > Looking at chapter 4.1, > I would say that at least the To- and From headers are in > the "risk zone" (EVEN if you only use the addr-spec part). If the From header is modified, the identity is broken anyway. Such modifications of the From header are discussed in the Background section of draft-wing-sip-identity-media-00. Allowing modifications of the To header creates the opportunity for an attacker to launch a replay attack by substituting the To address and replaying the message until the Date: header is old enough that receiving authentication servers reject the Date: header out of hand. > The CSeq (at least the digit portion) may also be modified, > for example if there has been some "dialog piggybacked" requests > sent between the SBC and another entity, but not end-to-end. In > that case the the SBC may have to increase the CSeq before > forwarding the request, if the digit portion value has already > been used in a request sent by the SBC in the same direction. That seems like a good opportunity, within that trust domain between the SBC and the other entity, to use P-Asserted-Identity. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 16 13:24:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUIf-0000rq-FO; Mon, 16 Jul 2007 13:23:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAUIe-0000rY-9u for sip-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 13:23:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUId-0000rQ-W0 for sip@ietf.org; Mon, 16 Jul 2007 13:23:56 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAUId-0005xc-MP for sip@ietf.org; Mon, 16 Jul 2007 13:23:55 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 09AF420427; Mon, 16 Jul 2007 19:23:47 +0200 (CEST) X-AuditID: c1b4fb3e-af032bb0000007e1-00-469ba9a29e71 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DDE2020078; Mon, 16 Jul 2007 19:23:46 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 19:23:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP Identity using Media Path Date: Mon, 16 Jul 2007 19:21:46 +0200 Message-ID: <7374777208BDC7449D5620EF942325674B244E@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Identity using Media Path Thread-Index: Ace+Gd+1mZGbB63fSbi5GA3N5+TpCwAPyvDwAlSiz8AABWk4IAADI3Cr References: <01af01c7c7c4$cc62e860$c4f0200a@amer.cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Dan Wing" , "Hans Persson" , X-OriginalArrivalTime: 16 Jul 2007 17:23:46.0424 (UTC) FILETIME=[10E8EF80:01C7C7CE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >>The CSeq (at least the digit portion) may also be modified, >>for example if there has been some "dialog piggybacked" requests >>sent between the SBC and another entity, but not end-to-end. In >>that case the the SBC may have to increase the CSeq before >>forwarding the request, if the digit portion value has already >>been used in a request sent by the SBC in the same direction. > >That seems like a good opportunity, within that trust domain >between the SBC and the other entity, to use >P-Asserted-Identity. I am not sure I understand. How could the P-A-I header be used instead = of the CSeq? Regards, =20 Christer =20 =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 16 13:40:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUYR-0005I2-Lh; Mon, 16 Jul 2007 13:40:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAUYQ-0005He-KC for sip-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 13:40:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUYQ-0005HU-9V for sip@ietf.org; Mon, 16 Jul 2007 13:40:14 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAUYP-0006Pq-Tj for sip@ietf.org; Mon, 16 Jul 2007 13:40:14 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 16 Jul 2007 10:40:09 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAD9Jm0arR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,542,1175497200"; d="scan'208"; a="182945383:sNHT29298645" 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 l6GHe9jq000560; Mon, 16 Jul 2007 10:40:09 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l6GHe8Tb002667; Mon, 16 Jul 2007 17:40:08 GMT From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" , "'Hans Persson'" , Subject: RE: [Sip] SIP Identity using Media Path Date: Mon, 16 Jul 2007 10:40:08 -0700 Message-ID: <025201c7c7d0$5ad0d930$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7374777208BDC7449D5620EF942325674B244E@esealmw113.eemea.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace+Gd+1mZGbB63fSbi5GA3N5+TpCwAPyvDwAlSiz8AABWk4IAADI3CrAACLdkA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1044; t=1184607609; x=1185471609; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20SIP=20Identity=20using=20Media=20Path |Sender:=20; bh=sL60IKAUM2G42z+LP+izTWqb7BINMwUN/qjhmUOyqYM=; b=TUTpA4gWb06i1rNo+YiIRREXGZZRnYfSf6OG1fLp5nzXo4VLHgh2J8AjuI47Kgmebo+arCeI 4ebwexoZZlZUA3zg+689QeBf8LwGWbbHrC2XBvmiGS/x3mzJ8TXxC1vQ; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > >>The CSeq (at least the digit portion) may also be modified, > >>for example if there has been some "dialog piggybacked" requests > >>sent between the SBC and another entity, but not end-to-end. In > >>that case the the SBC may have to increase the CSeq before > >>forwarding the request, if the digit portion value has already > >>been used in a request sent by the SBC in the same direction. > > > >That seems like a good opportunity, within that trust domain > >between the SBC and the other entity, to use > >P-Asserted-Identity. > > I am not sure I understand. How could the P-A-I header be > used instead of the CSeq? The SBC that wants to interfere with the CSeq when doing 'dialog piggybacking' can go ahead and do that. Doing that will destroy the validity of the SIP-Identity-Media signature for the 'dialog piggybacked' request. Because the SBC and the 'other entity' (which is receiving the 'dialog piggybacked' message) are both in the same trust domain, they can use P-A-I between themselves. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 16 13:55:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUmn-0004Bk-RP; Mon, 16 Jul 2007 13:55:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAUmm-0004BV-6s for sip-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 13:55:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUml-0004BN-T3 for sip@ietf.org; Mon, 16 Jul 2007 13:55:03 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAUml-0006us-LH for sip@ietf.org; Mon, 16 Jul 2007 13:55:03 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6GHs7j07618; Mon, 16 Jul 2007 17:54:08 GMT 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 Subject: RE: [Sip] WGLC for draft-ietf-sip-sips-05.txt (v.minor error) Date: Mon, 16 Jul 2007 12:54:06 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1145EA6A@zrc2hxm0.corp.nortel.com> In-reply-to: <165288C2C3E29449AFDE022DD10CC471052017A6@ExBE03.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC for draft-ietf-sip-sips-05.txt (v.minor error) Thread-Index: Ace6W/KAZqEG8GHOThiz27zcp4oxvAC/Q4uAAp5SHDA= References: <165288C2C3E29449AFDE022DD10CC471052017A6@ExBE03.nasstar-t1.net> From: "Francois Audet" To: "Attila Sipos" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks. I will correct.=20 > -----Original Message----- > From: Attila Sipos [mailto:attila.sipos@vegastream.com]=20 > Sent: Tuesday, July 03, 2007 03:15 > To: sip@ietf.org > Subject: RE: [Sip] WGLC for draft-ietf-sip-sips-05.txt (v.minor error) >=20 >=20 >=20 > See flows sections 6.3 and 6.4. >=20 > F13' shows an INVITE to Bob's PC but the INVITE message shows: > INVITE sip:bob@bobphone.example.com >=20 > it should be: > INVITE sip:bob@bobpc.example.com >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 16 14:03:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUvB-00052t-0X; Mon, 16 Jul 2007 14:03:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAUvA-00052Q-6W for sip-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 14:03:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUv9-00052H-TD for sip@ietf.org; Mon, 16 Jul 2007 14:03:43 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAUv5-0005mS-IC for sip@ietf.org; Mon, 16 Jul 2007 14:03:43 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6GI3Mx20775; Mon, 16 Jul 2007 18:03:22 GMT 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 Subject: RE: [Sip] WGLC for draft-ietf-sip-sips-05.txt Date: Mon, 16 Jul 2007 13:03:16 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1145EA9E@zrc2hxm0.corp.nortel.com> In-reply-to: <1183627498.10598.23.camel@eeek.ingate.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC for draft-ietf-sip-sips-05.txt Thread-Index: Ace+5nRZn5C/O2DySXasfq52VLL+BgI7Rrqg References: <3D4B049E-23D0-459D-AD58-3D8AF2AB8BE7@softarmor.com> <1183627498.10598.23.camel@eeek.ingate.se> From: "Francois Audet" To: "Hans Persson" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: IETF SIP , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks.=20 I will make all those changes.=20 > -----Original Message----- > From: Hans Persson [mailto:hasse@ingate.com]=20 > Sent: Thursday, July 05, 2007 02:25 > To: Audet, Francois (SC100:3055) > Cc: Dean Willis; IETF SIP > Subject: Re: [Sip] WGLC for draft-ietf-sip-sips-05.txt >=20 > fre 2007-06-29 klockan 09:42 -0500 skrev Dean Willis: >=20 > > I'm pleased to announce that the authors think that the=20 > SIPS draft is=20 > > ready for working group last call. This draft has had the=20 > privilege of=20 > > more review prior to WGLC than most of our other efforts,=20 > so perhaps=20 > > it won't be too controversial. > >=20 > > Please make a final read through the draft and bring any=20 > comments back=20 > > to this list. >=20 >=20 > I've gone through the diff between the current version and=20 > the last one > I read, and on the whole it looks good to me.=20 >=20 > Some editorial nits are listed below. >=20 >=20 > Section 3.1.1, para 1: >=20 > > the Proxy is the TLS server side. This directionality implies that >=20 > "proxy" >=20 > > directions (e..g, an incoming call), the UA must keep the TLS >=20 > "e.g." >=20 >=20 > Section 3.1.1, para 2: >=20 > > connection also solves the NAT and Firewall problem as it ensures >=20 > "firewall" >=20 >=20 > Section 3.1.2, para 1: >=20 > > place, the UAC would therefore take on the role of the TLS=20 > Client and >=20 > "client" >=20 > > SIP, a UA or a Proxy act both as UAC and UAS depending on=20 > if they are >=20 > "proxy" >=20 > > is very convenient. This allows for TLS connections to be set-up or >=20 > "set up" >=20 >=20 > Section 3.1.2, para 3: >=20 > > most residential SIP deployments for example. Mutual TLS=20 > can be used >=20 > Insert comma after "deployments". >=20 > > in those environments, but only if the connection is always=20 > stated by >=20 > "stated" is a strange word here. Do you mean "started"? >=20 >=20 > Section 3.1.2, last para: >=20 > > For this reasons, mutual TLS is mostly used in server-to-server >=20 > "this" -> "these" >=20 >=20 > Section 3.1.3, para 4: >=20 > > message (From, To, Request-URI, Contact header field, Route, etc.). >=20 > Why "Contact header field" and not just "Contact" like for the others? >=20 >=20 > Section 3.4, para 6: >=20 > > allowed, which would preclude the use of NATs or Firewalls. >=20 > "firewalls" >=20 >=20 > Section 4.1, para 3: >=20 > > SIP URI, it SHOULD respond with a 418 (SIPS Not Allowed). UAS that > > do not support the SIPS URI scheme altogether "SHOULD reject the >=20 > "UAS" would be more readable as "UASs". >=20 > Change "altogether" to "at all". >=20 >=20 > Section 4.1, last para: >=20 > > response code 419 (SIPS Required) >=20 > Missing period at end of sentence. >=20 >=20 > Section 4.1.2, para 8: >=20 > > reject requests using the SIP Scheme with 419 (SIPS Required). A UA >=20 > "scheme" >=20 >=20 > Section 4.2, para 5: >=20 > > response, it MUST NOT recurse on it. The Proxy SHOULD forward the >=20 > "proxy" >=20 >=20 > Section 4.3, para 1: >=20 > > Using a Redirect Server with TLS instead of using a Proxy has some >=20 > "redirect server", "proxy" >=20 > > established connection between the Proxy and the UAS (such as with >=20 > "proxy" >=20 >=20 > Section A.3: >=20 > > (similar to what the transport=3Dtls used to mean) has been = suggested >=20 > Remove "the". >=20 >=20 > Hans >=20 > --=20 > Hans Persson Ingate - Firewalls with SIP & NAT > Ingate Systems AB +46 13 210857 http://www.ingate.com/ >=20 > Private: http://www.lysator.liu.se/~unicorn/ >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 16 14:06:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUxf-00070O-Ck; Mon, 16 Jul 2007 14:06:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAUxe-00070F-Tp for sip-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 14:06:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUxe-0006zo-Jr for sip@ietf.org; Mon, 16 Jul 2007 14:06:18 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAUxa-0005wP-72 for sip@ietf.org; Mon, 16 Jul 2007 14:06:18 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l6GI6CmN017884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Jul 2007 11:06:13 -0700 Received: from [76.102.92.155] (vpn-10-50-16-13.qualcomm.com [10.50.16.13]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l6GI6ANs026812; Mon, 16 Jul 2007 11:06:11 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 16 Jul 2007 11:06:09 -0700 To: "James M. Polk" , sip@ietf.org From: Ted Hardie Subject: Re: [Sip] SIP Location Conveyance-08 is available Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi James, > >- added a Geolocation header parameter "recipient=" to indication which SIP entity type a particular locationValue is intended for. > > OPEN ISSUE here: what does a Location Recipient > do if more than one locationValue point to it? (i.e., > the case in which the UAS receives 2 locations > and both state "recipient=endpoint") First a couple of nits, then a question on the open issue. Section 3.2 says: the "recipient=" to allow recipients to infer what SIP element type this locationValue was intended to be for. The types are "endpoint", meaning the ultimate destination UAS; "routing-entity", meaning SIP servers; and "both" meaning this locationValue is to be viewed by both types of SIP entities. The example in 4.2, though, has "recipient=server". That should get shifted to "routing-entity", if I understand things correctly. The document also points to 3261 for Absolute URI, which appears to derive that from RFC 2396, Section 5. Would it be a problem to update that to RFC 3986, Section 4.3, since 3986 is now a full standard? So, the open issue you raise is what a routing-entity or endpoint does when it receives multiple locationValues for which it is the recipient. For the endpoint, I believe that the answer is application specific. For some uses, the most recently added may get used; for others, the first added; for others, all of them may get evaluated and some other application-specific judgement call made (an application might prefer the most precise, a specific address type, or something else). I think, though, that this document can stay silent about the endpoint's selection beyond the error code text describing 424. For the routing-entity, though, I think that silence is probably not workable. I would personally say that a routing-entity receiving multiple locationValues should always use the most recently added unless that location would generate a 424; in that case, it can examine the previously asserted locations in reverse order of addition until it finds one that is valid or generates the 424. Would that make sense to you? regards, Ted _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 16 16:50:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAXVw-0008AJ-80; Mon, 16 Jul 2007 16:49:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAXVu-00088U-Dq for sip-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 16:49:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAXVu-00087t-2n for sip@ietf.org; Mon, 16 Jul 2007 16:49:50 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAXVt-000381-Pg for sip@ietf.org; Mon, 16 Jul 2007 16:49:50 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6GKmrx27174; Mon, 16 Jul 2007 20:48:53 GMT 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 Subject: RE: [Sip] draft-ietf-sip-sips-05.txt - comment on response codes 418 and 419 Date: Mon, 16 Jul 2007 15:48:51 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1145EE35@zrc2hxm0.corp.nortel.com> In-reply-to: <165288C2C3E29449AFDE022DD10CC471054D7311@ExBE03.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05.txt - comment on response codes 418 and 419 Thread-Index: Ace49I02RnXl9IBITu22gMFrABvj6QJB4VAgAXtSRuA= References: <165288C2C3E29449AFDE022DD10CC471054D7311@ExBE03.nasstar-t1.net> From: "Francois Audet" To: "Attila Sipos" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My personal opinion is that those are good suggestions. But it does mean 2 new headers as well. I also like the idea of having only one response code (i.e., 418 Invalid URI scheme). Any other opinions? I will flag this as a remaining issue in Chicago. > -----Original Message----- > From: Attila Sipos [mailto:attila.sipos@vegastream.com]=20 > Sent: Monday, July 09, 2007 00:51 > To: sip@ietf.org > Subject: [Sip] draft-ietf-sip-sips-05.txt - comment on=20 > response codes 418 and 419 >=20 >=20 > This draft specifies two new response codes: >=20 > 418 SIPS Not Allowed > 419 SIPS Required >=20 > With sipsec around the corner shouldn't we make these headers=20 > more generic like we do for other SIP things? >=20 > For example, if someone uses a method we don't allow then we=20 > return "405 Method Not Allowed" and then list the allowed=20 > methods in the Allow header. > And there is a similar solution for SIP extensions (420 Bad=20 > Extension or 421 Extension Required). >=20 > So how about: > 418 URI Scheme Not Allowed > Allow-URI: sip >=20 > 419 URI Scheme Required > Require-URI: sips,sipsec >=20 > In fact, you probably only need one of them as they are=20 > almost identical in resultant behaviour. >=20 > Regards, >=20 > Attila >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 16 17:43:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAYLb-0007h6-9m; Mon, 16 Jul 2007 17:43:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAYLZ-0007gb-Pu for sip-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 17:43:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAYLZ-0007dR-Cz for sip@ietf.org; Mon, 16 Jul 2007 17:43:13 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAYLZ-0004gV-2P for sip@ietf.org; Mon, 16 Jul 2007 17:43:13 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 16 Jul 2007 14:43:12 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAMqCm0arR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,543,1175497200"; d="scan'208"; a="166845997:sNHT28507536" 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 l6GLhCwl007092; Mon, 16 Jul 2007 14:43:12 -0700 Received: from dwingwxp (dhcp-128-107-100-125.cisco.com [128.107.100.125]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6GLhA6C010404; Mon, 16 Jul 2007 21:43:12 GMT From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" Subject: RE: [Sip] SIP Identity using Media Path Date: Mon, 16 Jul 2007 14:43:09 -0700 Message-ID: <00c601c7c7f2$4e90e440$7d646b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: Ace+Gd+1mZGbB63fSbi5GA3N5+TpCwAPyvDwAlSiz8AABWk4IAADI3CrAACLdkAACEqfUA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2438; t=1184622192; x=1185486192; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20SIP=20Identity=20using=20Media=20Path |Sender:=20; bh=zA/qw57twxKxAqSasNm1e3Tx3278kMUwj4WUq26l4H8=; b=aBDEVT0N+j4cU9bdJ0E1ZOtbgaD666qfqLcTvrZz6nNtfHr0lnm+Eyr6tSWIurV0HX25LrAV NdwyVpzDT9/qATvWylSAshdpS3dL1cvKhyB0NOgNXv/3esJ5NRiKc+Ru; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: sip@ietf.org, ietf-rtpsec@imc.org, 'Hans Persson' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I wrote: > > >>The CSeq (at least the digit portion) may also be modified, > > >>for example if there has been some "dialog piggybacked" requests > > >>sent between the SBC and another entity, but not end-to-end. In > > >>that case the the SBC may have to increase the CSeq before > > >>forwarding the request, if the digit portion value has already > > >>been used in a request sent by the SBC in the same direction. > > > > > >That seems like a good opportunity, within that trust domain > > >between the SBC and the other entity, to use > > >P-Asserted-Identity. > > > > I am not sure I understand. How could the P-A-I header be > > used instead of the CSeq? > > The SBC that wants to interfere with the CSeq when doing 'dialog > piggybacking' can go ahead and do that. Doing that will destroy > the validity of the SIP-Identity-Media signature for the 'dialog > piggybacked' request. Because the SBC and the 'other entity' > (which is receiving the 'dialog piggybacked' message) are both > in the same trust domain, they can use P-A-I between themselves. I sketched out what you had said, and I now understand what you were saying. The case is like this: +----+ | +------CSeq=2--(dialog piggybacked request--> -CSeq=1---->+ SBC| | +------CSeq=1--(request)--> +----+ What I had suggested was that the piggybacked request (the one with CSeq=2) could be sent with P-A-I (created by the SBC), as it was being sent to another entity within the same trust domain as the SBC. The difficulty you were describing was that when the next request arrives, it may be using CSeq=2: +----+ | +--> -CSeq=2---->+ SBC| | +--> +----+ the SBC would need to disambiguate the newly-arrived CSeq from the piggybacked (spoofed) request the SBC created from the previous request. The easy solution to this is to not sign the CSeq's sequence number, but just the method. For replay protection we would rely on the nonce created by the signing service (which I described in http://www1.ietf.org/mail-archive/web/sip/current/msg19883.html). I can't read the tea leaves of RFC4474 to understand why RFC4474 signs CSeq's sequence number. Let me know if removing CSeq's sequence number from the signature would resolve the problem you brought up. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 16 18:38:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAZCz-0002aG-Qm; Mon, 16 Jul 2007 18:38:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAZCz-0002a8-1P for sip-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 18:38:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAZCy-0002a0-O5; Mon, 16 Jul 2007 18:38:24 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAZCu-0004qh-3T; Mon, 16 Jul 2007 18:38:24 -0400 Received: from source ([192.150.20.142]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Mon, 16 Jul 2007 15:38:17 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6GMcAWs027869; Mon, 16 Jul 2007 15:38:11 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6GMaHI9020725; Mon, 16 Jul 2007 15:36:17 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 15:38:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jul 2007 15:38:05 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICE deployment data before LC for RFC Thread-Index: AcfH+cwnIETVFFZtTmCLWopMWLu+LA== From: "Henry Sinnreich" To: , X-OriginalArrivalTime: 16 Jul 2007 22:38:09.0551 (UTC) FILETIME=[FC35B1F0:01C7C7F9] X-Spam-Score: 0.0 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Cc: Cullen Jennings , jon.peterson@neustar.biz Subject: [Sip] ICE deployment data before LC for RFC X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0661100463==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0661100463== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C7F9.FBAEDB66" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C7F9.FBAEDB66 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable The work on ICE is truly impressive and so are the numerous I-Ds associated with ICE. =20 However, before sending the I-D for LC to the IESG, it would be prudent and responsible to the industry (that spends considerable resources on ICE in good faith) implementing ICE, to either (1) make it an informational RFC or (2) publish some deployment data showing such items as: =20 * NAT scenarios that have been tested, * The % of success, * Performance, such as call setup delay using SIP. =20 I have not seen any such public data on ICE deployment, for example with SIP. A private report has raised my concern about the performance of ICE. =20 In the best IETF tradition, it would also help to have open source code available for ICE, before declaring it a standard. =20 ICE is too important for the IETF (good work Jonathan and other authors!) not to publish (1) deployment results and (2) publish open source code as well. The various nits discussed on the lists are only of secondary importance to the LC compared to the above and would get resolved with such a process anyway. =20 These are my personal two cents. Henry Sinnreich =20 ------_=_NextPart_001_01C7C7F9.FBAEDB66 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

The work on ICE is truly impressive and so are the = numerous I-Ds associated with ICE.

 

However, before sending the <ice-17> I-D for LC = to the IESG, it would be prudent and responsible to the industry (that spends considerable resources on ICE in good faith) implementing ICE, to either = (1) make it an informational RFC or (2) publish some deployment data showing = such items as:

 

  • NAT scenarios that = have been tested,
  • The % of = success,
  • Performance, such as = call setup delay using SIP.

 

I have not seen any such public data on ICE = deployment, for example with SIP. A private report has raised my concern about the = performance of ICE.

 

In the best IETF tradition, it would also help to = have open source code available for ICE, before declaring it a = standard.

 

ICE is too important for the IETF (good work Jonathan = and other authors!) not to publish (1) deployment results and (2) publish = open source code as well.

The various nits discussed on the lists are only of secondary importance to the LC compared to the above and would get = resolved with such a process anyway.

 

These are my personal two = cents.

Henry = Sinnreich


 

------_=_NextPart_001_01C7C7F9.FBAEDB66-- --===============0661100463== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0661100463==-- From sip-bounces@ietf.org Mon Jul 16 19:13:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAZlL-0008Jp-VG; Mon, 16 Jul 2007 19:13:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAZlK-0008Jk-6E for sip-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 19:13:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAZlJ-0008Jc-Qa for sip@ietf.org; Mon, 16 Jul 2007 19:13:53 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAZl4-0006q2-AC for sip@ietf.org; Mon, 16 Jul 2007 19:13:53 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6GNCdx24968; Mon, 16 Jul 2007 23:12:39 GMT 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, 16 Jul 2007 18:12:31 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF114C985A@zrc2hxm0.corp.nortel.com> In-reply-to: <0D5F89FAC29E2C41B98A6A762007F5D02054B7@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments on sip-sips Thread-Index: AcfCKEx+ncUlBwX5SrqjW0d4TtdWnAF0OYBA References: <0D5F89FAC29E2C41B98A6A762007F5D02054B7@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: Subject: [Sip] RE: WGLC comments on sip-sips X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Monday, July 09, 2007 05:55 > To: Audet, Francois (SC100:3055); sip@ietf.org > Subject: WGLC comments on sip-sips >=20 > In general this is now in excellent shape. Just some detailed=20 > comments. >=20 > 1. "It also makes normative changes to SIP". If so, then it=20 > should state on the front page that it updates RFC 3261. Agreed. Will change. > 2. In 3.1.1 "In this model, only the TLS server provides a=20 > certificate during the > TLS handshake. Often, a proxy (which may or may not be the one > terminating the TLS connection) authenticates the client=20 > by using the > SIP HTTP digest. In this model, the UA is the TLS client side, and > the Proxy is the TLS server side." > The words "the Proxy" in the third sentence would appear to=20 > refer to "a proxy" in the second sentence, but that doesn't=20 > make sense. Also I think this is trying to say that the=20 > server-provided certificate can only apply between a UA and a=20 > proxy and when the UA is the client, so it can't apply=20 > between proxies and it can't apply when a proxy is a client. > If so, to solve these two issues, perhaps it should say. > "In this model, only the TLS server provides a certificate=20 > during the TLS handshake. This is applicable only between a=20 > UA and a proxy, where the UA is the TLS client and the proxy=20 > is the TLS server, and hence the UA uses TLS to authenticate=20 > the proxy but the proxy does not use TLS to authenticate the=20 > UA. If the proxy needs to authenticate the UA, this can be=20 > achieved by SIP HTTP digest authentication." Yes, much clearer. I'll fix. > 3. In 3.1.2 "In this model, both the TLS client and the TLS=20 > server provide a > certificate in the TLS handshake phase. When no TLS=20 > connection is in > place, the UAC would therefore take on the role of the TLS=20 > Client and > the UAS would therefore take on the role of the TLS server." > This seems to limit mutual TLS (more correctly TLS mutual > authentication) to use involving a UA, but it also has an=20 > important use between proxies (this is not mentioned until=20 > further down). Also the second sentence seems to suggest a=20 > direct TLS connection between UAC and UAS, which is possible=20 > but not the typical case. Where at least one proxy is=20 > involved in the signalling path, if there is not already a=20 > TLS connection in place between the UAC and the first proxy,=20 > the UAC would take on the role of TLS client and the first=20 > proxy would take on the role of TLS server. Likewise, if=20 > there is not already a TLS connection in place between the=20 > last proxy and the UAS, the last proxy would take on the role=20 > of the TLS client and the UA would take on the role of the=20 > TLS server. I think this needs to be explained more fully.=20 > Perhaps we need to say something like: > "In this model, both the TLS client and the TLS server=20 > provide a certificate in the TLS handshake phase. When used=20 > between a UA and a proxy (or between two UAs), this implies=20 > that a UA must be in possession of a certificate. When=20 > sending a SIP request when there is not already a suitable=20 > TLS connection in place, a UAC takes on the role of TLS=20 > client in establishing a new TLS connection. When=20 > establishing a TLS connection for receipt of a SIP request, a=20 > UAS takes on the role of TLS server." Yes, much clearer. I'll fix (but I'll keep the last sentence of the paragraph). > 4. "While guessing a SIPS AOR from a known SIP > AOR and using it to initiate a request is a valid thing to=20 > do, doing > the opposite (i.e., guessing a SIP AOR from a SIPS AOR and=20 > using it) > is not a valid thing to do as it would be a security downgrade." > I would not go as far as saying it is not valid. It is merely=20 > undesirable, but if the caller's UA does not support the SIPS=20 > scheme, that might be a valid way of contacting the desired user. Ok, will change. > 5. "Although "downgrading" from SIPS to SIP is disallowed," > As mentioned above, I think it is valid but undesirable for a=20 > user to downgrade by guessing. However, I think what we are=20 > talking about here is downgrading by a proxy, so perhaps that=20 > should be made clear by > saying: "Although "downgrading" from SIPS to SIP is=20 > disallowed at a proxy,". Ok, will change. > 6. In 4.1 "If a UAS does not wish to be reached with a SIPS=20 > URI but only with a > SIP URI, it SHOULD respond with a 418 (SIPS Not Allowed)." > If the UA does not wish to be reached with a SIPS URI, then=20 > surely it would not register a SIPS contact. If the UA has=20 > not registered a SIPS contact, it should not normally receive=20 > a SIPS request. So presumably this is required only for=20 > requests reaching the UA without going through the domain=20 > proxy. Correct? If so, perhaps some explanation is needed. The main use case is for endpoints that don't register (e.g., gateways). Furthermore, this is written from the UA point of view and thus it could happen in error scenarios.=20 I'm not sure explaining this will help, but I can add it if=20 the groups feels it is necessary (I personally think it will just make the text even more heavy). > 7. "UAS that > do not support the SIPS URI scheme altogether "SHOULD reject the > request with a 416 (Unsupported URI scheme) response" as=20 > described in > [RFC3261]/8.2.2.1." > Similar - should explain how this can occur. Same as above. > 8. In 4.1.1 "If a UA registers with a SIPS Contact header=20 > field, the registrar > returning a service route [RFC3608] MUST return a service route > consisting of SIP URIs if the intent of the registrar is to allow > both SIP and SIPS to be used in requests sent by that client. If a > UA registers with a SIPS Contact header field, the registrar > returning a service route MUST return a service route consisting of > SIPS URIs if the intent of the registrar is to allow only SIPS URIs > to be used in requests sent by that UA." > Because 4.1.1 is part of 4.1, which deals only with UAs, then=20 > it should not contain normative requirements on registrars.=20 > Presumably the intention of this is to state that RFC 3608=20 > places such a requirement on registrars. The language needs=20 > changing to reflect this. Actually, Registrars are "a special type of UAS" according to RFC 3261 p. 56. This is why it's in this section. > 9. "However, the registrar MUST treat the SIP and SIPS=20 > schemes of the AOR > the same way (i.e., it MUST not care if it is SIP or SIPS)." > This is a requirement on the registrar and does not belong in 4.1. Same as 8. > 10. "A registrar MUST only accept a binding to a SIPS Contact=20 > header field > if all the appropriate URIs are of the SIPS scheme, otherwise there > could be an inadvertent binding of a secure resource (SIPS) to an > unsecured one (SIP). This includes the Request-URI, the=20 > Contacts and > all the Path headers, but does not include the From and To headers. > If the URIs are not of the proper SIPS scheme, the registrar MUST > reject the REGISTER with a 419 (SIPS Required)." > These are requirements on the registrar and do not belong in 4.1. Same as 8. > 11. In 4.2 "It is RECOMMENDED to use an outbound proxy as per=20 > the procedures > defined in [I-D.ietf-sip-outbound] for supporting UACs that can not > provide a certificate for establishing a TLS connection (i.e., when > server-side authentication is used)." > This is a recommendation on a UA, not a proxy, so it does not=20 > belong as a normative statement in 4.2. I'm not sure I agree on this. Seems like the decision to use or not the=20 procedures of sip-outbound in a proxy is a proxy requirement, not a UA=20 requirement. > 12. In 4.3 "A > redirect server would not be usable if server-side=20 > authentication is > used" > This is incorrect. If a UA has a certificate it can provide=20 > TLS server-side authentication, yet a redirect server could=20 > still be used in this case. I think this is trying to say=20 > that a redirect server cannot be used to redirect to an=20 > entity (e.g., a UA) that does not have a certificate. Correct. I'll fix. > 13. "When a redirect server receives a request with a SIP=20 > Request-URI, the > redirect server MAY redirect with a 3XX response to either=20 > a SIP or a > SIPS Contact header field. If the target UAS had registered > previously using a SIPS Contact header field, the redirect server > SHOULD return a SIPS Contact header field if it is in an=20 > environment > where TLS is usable (as described in the previous paragraph)." > This assumes that a redirect server is redirecting directly=20 > to a UA, i.e., to a contact. However, a redirect server can=20 > also redirect to another AoR that resolves to a domain proxy=20 > (or another redirect server). In other words, the redirect=20 > server may not have any knowledge of a "target UAS". >=20 > 14. In 5.2 "Furthermore, the offending SIPS URI(s) may be in any > location in the request (e.g., the Request-URI, a Contact header > field, a Refer-To URI, etc.)." > Shouldn't this say "the offending SIP URI(s)"? Yes, I'll fix. > 15. In the example in 6.3, proxy A and proxy B violate the=20 > recommendation in 4.2 to route SIP requests over TLS. This=20 > doesn't seem to be a very good example! It would be better to=20 > show routing over TLS from proxy A onwards. I'll put some wording around this (i.e., go look at 6.4). > 16. "7. Conclusion" > Most of the content of this section consists of further=20 > considerations, rather than conclusions drawn from previous=20 > sections. So perhaps the title should be "Further considerations". Ok. I'll change it. > 17. NITS >=20 > - In 6.1 "This call flow". There is no call flow - the flow=20 > shows only registration. >=20 > - There are instances of a SIP method name (e.g. REGISTER)=20 > being used alone without being followed by "request". >=20 > - There are instances of "header" being used instead of=20 > "header field". I'll fix the nits. > John >=20 >=20 >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 16 21:23:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAbn1-0003Y7-Ku; Mon, 16 Jul 2007 21:23:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAbmz-0003VP-AG for sip-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 21:23:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAbmy-0003Ut-DQ; Mon, 16 Jul 2007 21:23:44 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAbmt-0000YJ-W2; Mon, 16 Jul 2007 21:23:44 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 16 Jul 2007 18:23:39 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANO2m0arR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,544,1175497200"; d="scan'208"; a="503820034:sNHT29354616" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6H1Nc7k013165; Mon, 16 Jul 2007 18:23:38 -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.12.10/8.12.6) with ESMTP id l6H1NcTb021446; Tue, 17 Jul 2007 01:23:38 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 18:23:38 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 18:23:38 -0700 Message-ID: <469C1A1F.2090102@cisco.com> Date: Mon, 16 Jul 2007 21:23:43 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF SIP List , IETF Sipping List , IETF MMUSIC WG , Behave WG , P2PSIP WG , rai@ietf.org, "'avt@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2007 01:23:38.0346 (UTC) FILETIME=[1A3B94A0:01C7C811] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1845; t=1184635418; x=1185499418; 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:=20ICE=20tutorial=20in=20Chicago=20[DO=20NOT=20REPLY]=20-=20PLEA SE=20ADVISE=20IF=20YOU=20WILL=0A=20ATTEND! |Sender:=20; bh=2mEMezIhgSd4fQtdetbfRv0w1jcLg1hf4bgHjST7IQc=; b=E8JzvIKOXdm/coVCa8PMIpZSSHcW1xP7WCAHJJydd1KTAo4rHvwnnmQbFu0sgmYA2MXhXiTZ 5mrrLKb6+K2doFKdUhVSQSvfLQ1cG+MRM5jN63ABURvqDhDJUyb32NZD; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [Sip] ICE tutorial in Chicago [DO NOT REPLY] - PLEASE ADVISE IF YOU WILL ATTEND! X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've gotten very few responses indicating interest. If I don't get more acceptances I'll have to cancel. Please, if you do plan on attending, send me mail per the instructions below if you have not done so. (Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-16.txt) [-17 should be available shortly] WHEN: Tuesday, July 24, 2007, 1145-1245 (lunch logistics are in progress and will be announced ASAP) WHERE: Red Lacquar WHO: Anyone that would like to learn more about ICE. WHY: ICE, developed by the mmusic working group, has been defined as the IETF tool for NAT traversal for SIP-based media. It is also seeing increased usage for traversal for other kinds of application traffic - anything worrying about any-to-any communications. In this tutorial, we will overview the background of the problem, consider the requirements driving ICE, and provide an overview of how ICE works. An understanding of SIP is not required. The tutorial will be based on the pending -17 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice) so I can get a count of the number of participants for lunch purposes. !DO NOT REPLY TO THIS NOTE! -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 17 00:32:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAejc-0003xW-De; Tue, 17 Jul 2007 00:32:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAejY-0003wT-5G for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 00:32:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAejV-0003w3-Cy for sip@ietf.org; Tue, 17 Jul 2007 00:32:22 -0400 Received: from mu-out-0910.google.com ([209.85.134.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAejQ-0006PH-HO for sip@ietf.org; Tue, 17 Jul 2007 00:32:21 -0400 Received: by mu-out-0910.google.com with SMTP id w8so1838515mue for ; Mon, 16 Jul 2007 21:32:15 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=BPvN5tBJYrMk8eXeQI0y6oV8I0fz+2BDKaFV2cH6+pEsjWmiaHFwat6hrjRuRPQo+6i+afQ1JHAvIcnOlv7SKfjJywqy66LxMBMMMU+akip1LJwV66JLTq1r9GA9Z2JyOfETqDq2Gz5mLVwy9SjQ3AUuXVVNIEYZoGicvkp0v1Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=ue+M4pbIPtnlzpK3FkvToHhkMLppxrh4M9tAXmkVylyhjIDg/ssIKqysQ+zuNsm9Ljqg7pEPAW/viD4g2zWutaV/tJm+kgSlBXrfixckNE4NdmZAtZo4xOp+2hOQazrBo4pfwwKECEEv8+FmgPvndI/qabFLr6pYKsb/S9CpOm0= Received: by 10.82.112.16 with SMTP id k16mr11352buc.1184646735722; Mon, 16 Jul 2007 21:32:15 -0700 (PDT) Received: by 10.82.178.13 with HTTP; Mon, 16 Jul 2007 21:32:15 -0700 (PDT) Message-ID: Date: Tue, 17 Jul 2007 10:02:15 +0530 From: "Samir Saklikar" To: sip@ietf.org, sipping@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Cc: Subject: [Sip] CFP - International Conference on IP Multimedia Subsystem Architecture and Applications X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0117609741==" Errors-To: sip-bounces@ietf.org --===============0117609741== Content-Type: multipart/alternative; boundary="----=_Part_59991_13423587.1184646735680" ------=_Part_59991_13423587.1184646735680 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline International Conference on IP Multimedia Subsystems Architecture and Applications-2007 (IMSAA-2007), http://www.iiitb.ac.in/imsaa2007/index.html , 6th-8th December 2007, Bangalore, India, by IEEE Bangalore-Section and International Institute of Information Technology =96 Bangalore (iiit-b). *Call for Papers*: http://www.iiitb.ac.in/imsaa2007/callforpapers.html *Important Dates:* *Last Date for Registration of Paper (Title and Abstract): *31st July, 2007 *Last Date for* *Complete Paper Submission*: 6th August, 2007 Paper review reports: 15th September 2007 Submission of the Camera ready papers: 5th October 2007 The IMSAA 2007 technical program committee is soliciting papers addressing the research challenges and advances towards a world of converged and intelligent services, based on novel applications and extensions to the IMS framework. Papers must present original and previously unpublished work, validated by experimentation, simulation, or analysis. Practical experiences and experimental efforts, including submissions from industry, including both telecom providers and device vendors, addressing both successes and limitations with IMS, are particularly welcome. Topics of interest include, but are not limited to the following: - Architectures and Runtimes for IMS Elements - Application Server Architectures and Converged Containers - Architectures for Rich and Scalable Presence - Service Mediation and Billing Platforms - IMS Core Services - Real-time Service Support: (voice, video calls, multimedia conferencing, multiplayer gaming) - Content/Context-aware services: (Location, presence, social and community context) - Service Creation Environments (IMS, SCIM, Service Delivery Platforms, Integrated environments) - Device, Subscriber, Service and Network Management - Provisioning and management (Handsets, PDA's, Set top Box, Home Gateway) - Subscriber and User Profile Management - Managing the quality of the user experience (QoE, QoS) - End to end Performance Measurement and modeling (signaling, media, services) - Operator Network Planning - Routing and Load Balancing - Redundancy and Fault Tolerance - MVNO Operations and Support - Novel IMS-based Applications - Gaming and mixed-reality - Environmental and Sensor Monitoring - Multimedia Content Sharing - Converged IN - Converged Home Network - IPTV over IMS - Security, Identity Management and Privacy - Privacy and Security in Composite Applications - Privacy in LBS - IMS and Alternative Technologies - P2P and IMS (VoIP, Instant Messaging, Gaming) - Integrating IMS and Web2.0 services (Mashups, Rich Internet Applications) - User-generated Services and Content - Case Studies and Status of IMS deployment - Interoperability Testing - IMS Support in Vendor Products - Benchmarking IMS Services and Applications - Testbeds and Software Tools - Service Test and Validation Platforms - Open Source Initiatives - Benchmarking IMS Services and Applications - IMS Clients and Devices - IMS-aware consumer devices - Media/communication platform s *Paper Submission Format:* Papers must be submitted in IEEE format (.pdf file). The EDAS Website for uploading the paper is http://edas.info/newPaper.php?c=3D5595. Papers for review: Double-column, 11pt IEEE format and no longer than 7 pages (including all figures and references). Camera ready paper: It will be in double-column, IEEE format, but in 10 pt font, and no longer than 6 pages (including all figures and references). Technical Committee: http://www.iiitb.ac.in/imsaa2007/technicalcomm.html ----------------------------------------------------------------------- ------=_Part_59991_13423587.1184646735680 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

 

International Conference on IP Multimedia Subsystems Architecture and Applications-2007 (IMSAA-2007),

http://www.iii= tb.ac.in/imsaa2007/index.html ,

6th-8th December 2007, Bangalore, India, <= br>

by IEEE Bangalore-Section and International Institute of Information Technology =96 Bangalore (iiit-b).
Call for Papers: http://www.iiitb.ac.in/imsaa2007/callforpapers.html=

 

Important Dates:

Last= Date for Registration of Paper (Title and Abstract): 31st July, 2007
Last Date for Complete Paper Submission:&nbs= p; 6th August, 2007
Paper review reports: 15th September 2007
Submission of the Camera ready papers: 5th October 2007

The IMSAA 2007 technical program committee is soliciting papers
addressing the research challenges and advances towards a world of
converged and intelligent services, based on novel applications and
extensions to the IMS framework. Papers must present original and
previously unpublished work, validated by experimentation, simulation,
or analysis. Practical experiences and experimental efforts, including
submissions from industry, including both telecom providers and device
vendors, addressing both successes and limitations with IMS, are
particularly welcome. Topics of interest include, but are not limited to the following:


  • Architectures and Runtimes for IMS Elements
    • Application Server Architectures and Converged Containers=  
    • Architectures for Rich and Scalable Presence=20
    • Service Mediation and Billing Platforms
  • IMS Core Services
    • Real-time Service Support: (voice, video calls, mult= imedia conferencing, multiplayer gaming)
    • Content/Context-aware services: (Location, presence= , social and community context)
    • Service Creation Environments (IMS, SCIM, Service Delive= ry Platforms, Integrated environments)
  • Device,  Subscriber, Service and Network Management
    • Provisioning and management (Handsets, PDA's, Set top= Box, Home Gateway)
    • Subscriber and User Profile Management=20
    • Managing  the quality of the user experience (QoE, = QoS)
    • End to end Performance Measurement  and modeling&nb= sp; (signaling, media, services)
  • Operator Network Planning 
    • Routing and Load Balancing
    • Redundancy and Fault Tolerance=20
    • MVNO Operations and Support
  • Novel IMS-based Applications
    • Gaming and mixed-reality=20
    • Environmental and Sensor Monitoring=20
    • Multimedia Content Sharing=20
    • Converged IN=20
    • Converged Home Network=20
    • IPTV over IMS
  • Security, Identity  Management and Privacy 
      • Privacy and Security in Composite Applications=20
      • Privacy in LBS
    • IMS and Alternative Technologies
      • P2P and IMS (VoIP, Instant Messaging, Gaming)=20
      • Integrating IMS and Web2.0 services  (Mashups, Rich= Internet Applications)
      • User-generated Services and Content
    • Case S= tudies and Status of IMS deployment
      • Interoperability Testing=20
      • IMS Support in Vendor Products
      • Benchmarking IMS Services and Applications
      • Testbeds and Software Tools
        • Service Test and Validation Platforms=20
        • Open Source Initiatives=20
        • Benchmarking IMS Services and Applications
        • IMS Clients and Devices
          • IMS-aware consumer devices=20
          • Media/communication platform s

        Paper Submission Format:
        Papers must be submitted in IEEE format (.pdf file). The EDAS Website
        for uploading the paper is http://edas.info/newPaper.php?c=3D5595.  Papers
        for review: Double-column, 11pt IEEE format and no longer than 7 pages
        (including all figures and references). Camera ready paper: It will be
        in double-column, IEEE format, but in 10 pt font, and no longer than 6
        pages (including all figures and references).

         Technical Committee: <= a href=3D"http://www.iiitb.ac.in/imsaa2007/technicalcomm.html">http://www.i= iitb.ac.in/imsaa2007/technicalcomm.html
        -----------------------------------------------------------------------

        ------=_Part_59991_13423587.1184646735680-- --===============0117609741== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0117609741==-- From sip-bounces@ietf.org Tue Jul 17 02:07:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAgDQ-0005PY-SW; Tue, 17 Jul 2007 02:07:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAgDO-0005PO-0a for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 02:07:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAgDN-0005PG-La for sip@ietf.org; Tue, 17 Jul 2007 02:07:17 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAgDN-0002ed-0I for sip@ietf.org; Tue, 17 Jul 2007 02:07:17 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C42A120DE5; Tue, 17 Jul 2007 08:06:11 +0200 (CEST) X-AuditID: c1b4fb3c-b1681bb0000007e1-f4-469c5c53051c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9D8E120054; Tue, 17 Jul 2007 08:06:11 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 08:06:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP Identity using Media Path Date: Tue, 17 Jul 2007 08:06:10 +0200 Message-ID: <7374777208BDC7449D5620EF942325670730B11C@esealmw113.eemea.ericsson.se> In-Reply-To: <00c601c7c7f2$4e90e440$7d646b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Identity using Media Path Thread-Index: Ace+Gd+1mZGbB63fSbi5GA3N5+TpCwAPyvDwAlSiz8AABWk4IAADI3CrAACLdkAACEqfUAARPsog References: <00c601c7c7f2$4e90e440$7d646b80@amer.cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Dan Wing" X-OriginalArrivalTime: 17 Jul 2007 06:06:11.0389 (UTC) FILETIME=[9308A6D0:01C7C838] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: sip@ietf.org, ietf-rtpsec@imc.org, Hans Persson X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Dan, I was planning to provide an example myself, but you seem to have done the work for me :) >>>>>The CSeq (at least the digit portion) may also be modified, for example if there has been some "dialog piggybacked"=20 >>>>>requests sent between the SBC and another entity, but not end-to-end. In that case the the SBC may have to increase the CSeq before=20 >>>>>forwarding the request, if the digit portion value has already been used in a request sent by the SBC in the same direction. >>>> >>>>That seems like a good opportunity, within that trust domain=20 >>>>between the SBC and the other entity, to use P-Asserted-Identity. >>>=20 >>>I am not sure I understand. How could the P-A-I header be used instead of the CSeq? >>=20 >>The SBC that wants to interfere with the CSeq when doing 'dialog=20 >>piggybacking' can go ahead and do that. Doing that will destroy the=20 >>validity of the SIP-Identity-Media signature for the 'dialog=20 >>piggybacked' request. Because the SBC and the 'other entity' >>(which is receiving the 'dialog piggybacked' message) are both in the=20 >>same trust domain, they can use P-A-I between themselves. >=20 >I sketched out what you had said, and I now understand what=20 >you were saying. The case is like this: >=20 > +----+ > | +------CSeq=3D2--(dialog piggybacked request--> > -CSeq=3D1---->+ SBC| > | +------CSeq=3D1--(request)--> > +----+ >=20 >What I had suggested was that the piggybacked request (the=20 >one with CSeq=3D2) could be sent with P-A-I (created by the=20 >SBC), as it was being sent to another entity within the same=20 >trust domain as the SBC. >=20 >The difficulty you were describing was that when the next=20 >request arrives, it may be using CSeq=3D2: >=20 > +----+ > | +--> > -CSeq=3D2---->+ SBC| > | +--> > +----+ >=20 >the SBC would need to disambiguate the newly-arrived CSeq=20 >from the piggybacked (spoofed) request the SBC created from=20 >the previous request. Yes. The SBC would need for forward the request with an increased CSeq value, e.g. Cseq=3D3. Having said that, I think it's quite unlikely that the SBC would piggyback anything before it receives the initial INVITE, so for that request it is maybe possible to assume that the CSeq will stay unchanged. But, during the dialog the SBC may have to change the Cseq digit value, and I've also seen use-cases where the method is changed. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 17 02:34:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAgdk-0004SW-Fa; Tue, 17 Jul 2007 02:34:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAgdh-0004SA-IF for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 02:34:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAgde-0004Rw-0h for sip@ietf.org; Tue, 17 Jul 2007 02:34:28 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAgdd-0003T4-8T for sip@ietf.org; Tue, 17 Jul 2007 02:34:25 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A6FD220E2B; Tue, 17 Jul 2007 08:34:16 +0200 (CEST) X-AuditID: c1b4fb3c-afe7ebb0000007e1-f6-469c62e84ff0 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7FA8220E21; Tue, 17 Jul 2007 08:34:16 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 08:34:16 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 08:34:15 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9B40724C0; Tue, 17 Jul 2007 09:34:15 +0300 (EEST) Message-ID: <469C62E7.6010401@ericsson.com> Date: Tue, 17 Jul 2007 09:34:15 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Qian Sun References: <002c01c7c786$19d60530$7c6c460a@china.huawei.com> In-Reply-To: <002c01c7c786$19d60530$7c6c460a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 17 Jul 2007 06:34:15.0738 (UTC) FILETIME=[7EFBE9A0:01C7C83C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: miguel.an.garcia@nokia.com, RjS@xten.com, sip , Aki.Niemi@nokia.com, Markus.Isomaki@nokia.com Subject: [Sip] Re: [Sipping] RE: Comments on draft-ietf-sip-multiple-refer-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, [moving this thread from the SIPPING list to this one (SIP) because this=20 is a SIP document now.] You are right. It is not trivial to use Referred-By with multiple REFER.=20 My suggestion is that, the same way as Referred-By is specified as an=20 extension of refer, you go ahead specify (if you are interested) how to=20 use Referred-by with multiple REFER in a different spec. The body that the referrer would add to its REFER (which is what the=20 refer target would get) could be an XML list with the recipients (those=20 that can be disclosed) of the multiple REFER (plus the referrer).=20 Something similar to what recipients get after a relay processes a list=20 with copyControl attributes=20 (draft-ietf-sipping-capacity-attribute-04.txt)... in any case, since=20 multiple REFER is only used within a context of a service, you need to=20 think whether having a general Referred-By mechanism is needed or if=20 such functionality can be achieved in a different way within the=20 services multiple REFER is used in (e.g., conferencing). Cheers, Gonzalo Qian Sun wrote: > Hello, Gonzalo >=20 > RFC3892 says: > The sipfrag inside a Referred-By token MUST contain copies of the > Refer-To, Referred-By, and Date header fields from the REFER request= . >=20 > In multiple refer case, the Refer-To header field includes content id,=20 > not the REFER-Target' URI. The content id is meaningless to the=20 > REFER-Targets, so the Referred-By token has to include the URI-List. >=20 > Cheers, > Qian >=20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Monday, July 16, 2007 4:23 PM > To: Qian Sun > Cc: Aki.Niemi@nokia.com; Markus.Isomaki@nokia.com;=20 > miguel.an.garcia@nokia.com; hisham.khartabil@gmail.com; sipping@ietf.or= g > Subject: Re: Comments on draft-ietf-sip-multiple-refer-01.txt >=20 > Hi, >=20 > thanks for your comments. Answers inline: >=20 > Qian Sun wrote: > > Some comments on the draft... > > > > 1. I think it might be a good idea to talk something on "Referred-By= "=20 > in this draft. Referred-By mechanism is still very useful for the=20 > multiple refer case. Maybe Refer-To related to a URI List with "bcc" or= =20 > "anonymize" is a trouble. "Referred-BY=E2=80=9D in the message header i= s to=20 > identify the initial REFER-Issuer. This information may be encrypted=20 > together with "refer-to" URI list, including the copy control level suc= h=20 > as to/cc/bcc to the end user, i.e. REFER-Target, where the information=20 > will be decrypted by the REFER-Target. In this case the REFER-Recipient= =20 > won=E2=80=99t be able to get rid of the "bcc" URI from the URI list, an= d the=20 > "bcc" URI will be sent to other REFER-Targets along with normal to/cc.=20 > This will be a problem to destroy the blind cc function. > > However, the REFER-issuer may opt to not include a Referred-By token= .=20 > For example: > > REFER sip:conf-123@example.com;gruu;opaque=3Dhha9s8d-999a SIP/2.= 0 > > Refer-To: > > Referred-By: Carol > > Content-Type: application/resource-lists+xml > > Content-Disposition: recipient-list > > Content-Length: 362 > > Content-ID: > > > > > > > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"> > > > > > > > > > > > > > > > > When the URI list has no "bcc" or "anonymize" URI, REFER-issuer may=20 > include the Referred-By token in the REFER body. >=20 > The way Referred-By works is not affected by what this draft says. > Therefore, I do not see the need to talk about it. >=20 > > > > 2. Nested refer in multiple refer is very interesting, I believe it=20 > could be a good idea to enroll a "multiple nested refer" example into=20 > this draft. Just for an example: > > REFER sip:list-service@example.com;gruu;opaque=3Dhha9s8d-999a SI= P/2.0 > > Refer-To: > > Content-ID: > > > > > > > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"> > > > > uri=3D"sip:bill@example.com?method=3DREFER%3FRefer-To%3Dsip:conf-123%40= shenzhen.example.com"=20 > /> > > uri=3D"sip:tom@example.com?method=3DREFER%3FRefer-To%3Dsip:conf-123%40s= henzhen.example.com"=20 > /> > > > > > > In this case, the REFER-Recipient acts as a Refer List service, has=20 > the similar function to the MESSAGE List service, i.e. receives a REFER= =20 > with URI-List and distributes some REFERs to each address in the URI-Li= st. > > Note that, there is only one final REFER-Target in above "nested=20 > multiple refer" example, not multiple REFER-Targets. In some situations= ,=20 > this convergent feature is useful. >=20 > The draft says the following: >=20 > Additionally, REFER-Recipients SHOULD only accept REFER requests > within the context of an application the server understands (e.g., = a > conferencing application). >=20 > this text was added to avoid relays being used as random traffic > forwarders. Therefore, since a relay needs to understand what is going > on (e.g., a multiple REFER to trigger BYEs towards several conference > attendees) and currently there is no service that uses nested refers, I > do not think we need to talk about it. >=20 > > > > 3. I guess it might be a typo in Figure 2 "8. 200K OK", maybe you=20 > meant "200 OK"? >=20 > yes, thanks for pointing it out. We will fix it. >=20 > Thanks, >=20 > Gonzalo >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 17 02:42:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAglQ-0003dx-Gb; Tue, 17 Jul 2007 02:42:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAglP-0003di-BO for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 02:42:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAglP-0003da-1a for sip@ietf.org; Tue, 17 Jul 2007 02:42:27 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAglK-00021s-Jv for sip@ietf.org; Tue, 17 Jul 2007 02:42:27 -0400 Received: by py-out-1112.google.com with SMTP id f31so4634512pyh for ; Mon, 16 Jul 2007 23:42:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=e7F+3Tc7BFWzpqNGBKaC1vGvA1DEOwk6q37CofYXCDPT4bvboSADhVU8np5PkU9mx7uyGYrZ2k3BIf4id2UpKFYluBhruvfmFsrwu0K+ZaOoo6iPJP7LeXk1Cptec2yeqdFnxFxf8o+wZBl1wolFFJV0g9Hs3EBVXsD6UKpbDDA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=p94rBjA2qEpIQ9gscEWrwLZF/OL12HZ+pxqR79wIhVABQ8tF1hZQUq1w2JbgwjG+jqoC22CCGdB2tsEVbjLNHijvJH+7Qpy8tSXiR4w5eeBedvLUVakpBcgpIM9xUGyr0eSmF9Ji2ggaslfr/jrOKVNjQsyjsz4fbWFC7oEMw1A= Received: by 10.35.85.1 with SMTP id n1mr191359pyl.1184654542249; Mon, 16 Jul 2007 23:42:22 -0700 (PDT) Received: by 10.35.65.10 with HTTP; Mon, 16 Jul 2007 23:42:21 -0700 (PDT) Message-ID: <21964a950707162342h65f14291i605eb2c5da7fda33@mail.gmail.com> Date: Mon, 16 Jul 2007 23:42:21 -0700 From: "Nasir Khan" To: "Robert Sparks" Subject: Re: [Sip] Changes to the INVITE transaction to address bug 769 In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0830415077==" Errors-To: sip-bounces@ietf.org --===============0830415077== Content-Type: multipart/alternative; boundary="----=_Part_44997_14005978.1184654541302" ------=_Part_44997_14005978.1184654541302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Robert, I have 3 comments / suggestions w.r.t this ID. Comment-1 ---------------- Should there be any change with respect to receiving CANCEL in Accepted state? Hitherto the UAC was getting a 481/CANCEL in such cases. Now we will get 200/CANCEL with no effect on IST. The reason for this question is backwards compatibility, however I can myself argue both ways on this one. What do you think? Comment-2 ----------------- In section 6.7 of the ID about the Timer-L you say - "and the amount of time this (or any downstream) UAS core might be retransmitting the 2xx while waiting for an ACK. " How does 2xx retransmission timer affect the choice of Timer L? Comment-3 ----------------- Shouldnt the Timer L be set to T4 which represents the amount of time the network will take to clear messages between client and server transactions? Since 2xx is sent reliably anyway, IMHO we do not need to link Timer L to Timer B. Thanks Nasir Khan BEA Systems Inc. On 6/27/07, Robert Sparks wrote: > > Everyone - > > I've put together a proposal for addressing the spec bug captured at > http://bugs.sipit.net/show_bug.cgi?id=769 > > Please read through > http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-00.txt > and comment. > > RjS > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Discuss SIP Servlets at http://groups.google.com/group/sipservlets/ ------=_Part_44997_14005978.1184654541302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Robert,

        I have 3 comments / suggestions w.r.t this ID.

        Comment-1
        ----------------
        Should there be any change with respect to receiving CANCEL in Accepted state? Hitherto the UAC was getting a 481/CANCEL in such cases. Now we will get 200/CANCEL with no effect on IST.
        The reason for this question is backwards compatibility, however I can myself argue both ways on this one. What do you think?


        Comment-2
        -----------------
        In section 6.7 of the ID about the Timer-L you say - "and the amount of time this (or any downstream) UAS core might be retransmitting the 2xx while waiting for an ACK. "

        How does 2xx retransmission timer affect the choice of Timer L?


        Comment-3
        -----------------
        Shouldnt the Timer L be set to T4 which represents the amount of time the network will take to clear messages between client and server transactions?
        Since 2xx is sent reliably anyway, IMHO we do not need to link Timer L to Timer B.

        Thanks

        Nasir Khan
        BEA Systems Inc.


        On 6/27/07, Robert Sparks <rjsparks@estacado.net> wrote:
        Everyone -

        I've put together a proposal for addressing the spec bug captured at
        http://bugs.sipit.net/show_bug.cgi?id=769

        Please read through
        http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-00.txt
        and comment.

        RjS


        _______________________________________________
        Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
        This list is for NEW development of the core SIP Protocol
        Use sip-implementors@cs.columbia.edu for questions on current sip
        Use sipping@ietf.org for new developments on the application of sip



        --
        Discuss SIP Servlets at http://groups.google.com/group/sipservlets/ ------=_Part_44997_14005978.1184654541302-- --===============0830415077== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0830415077==-- From sip-bounces@ietf.org Tue Jul 17 03:55:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAhtD-0005br-0L; Tue, 17 Jul 2007 03:54:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAhtA-0005bR-PA for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 03:54:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAhtA-0005bE-CB for sip@ietf.org; Tue, 17 Jul 2007 03:54:32 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAht9-0005qe-Un for sip@ietf.org; Tue, 17 Jul 2007 03:54:32 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3C23121B46; Tue, 17 Jul 2007 09:53:59 +0200 (CEST) X-AuditID: c1b4fb3e-af032bb0000007e1-f0-469c7597c633 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1D56B21B0C; Tue, 17 Jul 2007 09:53:59 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 09:53:58 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 09:53:58 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6E17F24C0; Tue, 17 Jul 2007 10:53:58 +0300 (EEST) Message-ID: <469C7596.8090709@ericsson.com> Date: Tue, 17 Jul 2007 10:53:58 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Linyi Tian Subject: Re: [Sip] Comments and questions todraft-ietf-sip-uri-list-conferencing-01.txt References: <002c01c7bd53$7945a0d0$7f6c460a@china.huawei.com> In-Reply-To: <002c01c7bd53$7945a0d0$7f6c460a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2007 07:53:58.0458 (UTC) FILETIME=[A1B511A0:01C7C847] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Linyi, > (1) On section "5. Conference Server Procedures" > Many conference servers have restriction to maximum number of attendees > for conference. If the users of 'recipient-list' exceeds the limitation, > what status code should be returned? I would return a 403 (Too many recipients). > --------------------------------------- > 7. Security Considerations > This document discusses setup of SIP conferences using a > request-contained URI-list. Both conferencing and URI-lists services > have specific security requirements which will be summarized here. > Conferences generally have authorization rules about who can or cannot > join a conference, what type of media can or cannot be used, etc. This > information is used by the focus to admit or deny participation in a > conference. It is RECOMMENDED that these types of authorization rules > be used to provide security for a SIP conference. > ---------------------------------------- > (2) When and how the authorization rules are specified and applied to > the conference? Before the conference creation seems not possible since > Conf-URI is not assigned. If specified after the conference creation, it > seems there is a risk after conf is created but rules are not ready. > Some attendees may do something bad which is out of control during that > period. They are applied at conference creation. The server receives the request, creates the conference with its rules, and only adds the participants in the list if those rules allow it to do it. This is already implemented in the OMA PoC (Push-to-talk over Cellular) service. Thanks for your comments, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 17 05:01:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAivv-00016q-P0; Tue, 17 Jul 2007 05:01:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAivu-00011B-DS for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 05:01:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAivt-0000zQ-Ra for sip@ietf.org; Tue, 17 Jul 2007 05:01:25 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAivt-0007qc-8G for sip@ietf.org; Tue, 17 Jul 2007 05:01:25 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JLB00L0LFPLZT@siemenscomms.co.uk> for sip@ietf.org; Tue, 17 Jul 2007 10:00:57 +0100 (BST) Date: Tue, 17 Jul 2007 10:01:09 +0100 From: "Elwell, John" In-reply-to: <1ECE0EB50388174790F9694F77522CCF114C985A@zrc2hxm0.corp.nortel.com> To: Francois Audet , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D02059C8@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: WGLC comments on sip-sips Thread-Index: AcfCKEx+ncUlBwX5SrqjW0d4TtdWnAF0OYBAABTOSsA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D02054B7@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF114C985A@zrc2hxm0.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Subject: [Sip] RE: WGLC comments on sip-sips X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois, More below. I have stripped out the comments that have been satisfactorily dealt with. John > > > 6. In 4.1 "If a UAS does not wish to be reached with a SIPS > > URI but only with a > > SIP URI, it SHOULD respond with a 418 (SIPS Not Allowed)." > > If the UA does not wish to be reached with a SIPS URI, then > > surely it would not register a SIPS contact. If the UA has > > not registered a SIPS contact, it should not normally receive > > a SIPS request. So presumably this is required only for > > requests reaching the UA without going through the domain > > proxy. Correct? If so, perhaps some explanation is needed. > > The main use case is for endpoints that don't register (e.g., > gateways). Furthermore, this is written from the UA point of view > and thus it could happen in error scenarios. > > I'm not sure explaining this will help, but I can add it if > the groups feels it is necessary (I personally think it will just > make the text even more heavy). [JRE] OK, I can live with that. > > > 7. "UAS that > > do not support the SIPS URI scheme altogether "SHOULD reject the > > request with a 416 (Unsupported URI scheme) response" as > > described in > > [RFC3261]/8.2.2.1." > > Similar - should explain how this can occur. > > Same as above. [JRE] Ditto. > > > 8. In 4.1.1 "If a UA registers with a SIPS Contact header > > field, the registrar > > returning a service route [RFC3608] MUST return a service route > > consisting of SIP URIs if the intent of the registrar is to allow > > both SIP and SIPS to be used in requests sent by that > client. If a > > UA registers with a SIPS Contact header field, the registrar > > returning a service route MUST return a service route > consisting of > > SIPS URIs if the intent of the registrar is to allow > only SIPS URIs > > to be used in requests sent by that UA." > > Because 4.1.1 is part of 4.1, which deals only with UAs, then > > it should not contain normative requirements on registrars. > > Presumably the intention of this is to state that RFC 3608 > > places such a requirement on registrars. The language needs > > changing to reflect this. > > Actually, Registrars are "a special type of UAS" according to RFC 3261 > p. 56. This is why it's in this section. [JRE] OK, I don't like it, but I suppose you are correct. However, you didn't respond to the second part of my comment, concerning the need for a change of language. Thinking about this further, I now see that we are in fact updating RFC 3608 - correct? If so, then don't we need to state this up front, and also mention it in the Introduction section where we mention RFC 3261? > > > 11. In 4.2 "It is RECOMMENDED to use an outbound proxy as per > > the procedures > > defined in [I-D.ietf-sip-outbound] for supporting UACs > that can not > > provide a certificate for establishing a TLS connection > (i.e., when > > server-side authentication is used)." > > This is a recommendation on a UA, not a proxy, so it does not > > belong as a normative statement in 4.2. > > I'm not sure I agree on this. Seems like the decision to use > or not the > procedures of sip-outbound in a proxy is a proxy requirement, > not a UA > requirement. [JRE] The words "It is RECOMMENDED to use an outbound proxy" sound to me like a recommendation on a UA, i.e., a recommendation that the UA be configured to use an outbound proxy. Perhaps what we are trying to say is "It is RECOMMENDED that a proxy be able to behave as an outbound proxy as per the procedures...", in which case it would indeed belong in this section. > > > 13. "When a redirect server receives a request with a SIP > > Request-URI, the > > redirect server MAY redirect with a 3XX response to either > > a SIP or a > > SIPS Contact header field. If the target UAS had registered > > previously using a SIPS Contact header field, the redirect server > > SHOULD return a SIPS Contact header field if it is in an > > environment > > where TLS is usable (as described in the previous paragraph)." > > This assumes that a redirect server is redirecting directly > > to a UA, i.e., to a contact. However, a redirect server can > > also redirect to another AoR that resolves to a domain proxy > > (or another redirect server). In other words, the redirect > > server may not have any knowledge of a "target UAS". [JRE] You didn't answer this or make any changes. Do you consider that no change is necessary? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 17 05:53:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAjjo-0000xg-RK; Tue, 17 Jul 2007 05:53:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAjjk-0000hZ-WA for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 05:52:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAjjk-0000gG-Kf for sip@ietf.org; Tue, 17 Jul 2007 05:52:56 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAjjk-0000v6-6b for sip@ietf.org; Tue, 17 Jul 2007 05:52:56 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6H9qmm3016584; Tue, 17 Jul 2007 12:52:49 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 12:52:43 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 12:52:43 +0300 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.1830); Tue, 17 Jul 2007 12:52:42 +0300 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6H9qfce006304; Tue, 17 Jul 2007 12:52:41 +0300 Received: from [172.21.40.62] (esdhcp04062.research.nokia.com [172.21.40.62]) by kusti.research.nokia.com (Postfix) with ESMTP id 6708E93B83; Tue, 17 Jul 2007 12:52:41 +0300 (EEST) Message-ID: <469C9168.4060907@nokia.com> Date: Tue, 17 Jul 2007 12:52:40 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: ext Qian Sun Subject: Re: [Sip] Comments on draft-ietf-sip-subnot-etags-00 References: <004d01c7be12$9bdd9f70$7c6c460a@china.huawei.com> In-Reply-To: <004d01c7be12$9bdd9f70$7c6c460a@china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2007 09:52:42.0564 (UTC) FILETIME=[38016040:01C7C858] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Qian, And sorry for a late answer to your comment. I have been on vacation enjoying the beautiful Finnish summer. ;) ext Qian Sun wrote: > Hi, I am not sure whether the following description in this draft is > enough for the usage of Entity-tags with filtering. > > "5.1. Generating Entity-tags The views might correspond to different > groups of users that have varying levels of access rights to the > resource state, or to subscribers that have modified their > subscription using event notification filtering [11]." > > My consideration is: If a subscriber has a subscription with filter > F1, the current corresponding entity-tag is E1. Then the same > subscriber MUST NOT send SUBSCRIBE with a new filter F2 and the > entity-tag E1 in the conditional header field. i.e., if a subscriber > changes filter for an event state, the Suppress-XXX-If-Match should > not be used. The client of subscriber has to record the last filter > for event state and compare filters. If I understand your concern correctly, the problem is with filtering and not with subnot-etags. I think a subscription that installs a filter, or disables/removes it could effectively be an action that itself changes the event state, and causes an if-match condition to fail. But this all depends on the actual implementation of the filtering system. In other words, this seems like an implementation detail of the filtering system. At the moment, I am not aware of any existing filtering implementations, so I'm reluctant to adding any specific text to the draft either. If this becomes a problem, we can always write an update to the filtering specifications. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 17 06:23:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAkDF-0004sn-Bm; Tue, 17 Jul 2007 06:23:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAkDE-0004rr-7a for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 06:23:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAkDD-0004rM-TJ for sip@ietf.org; Tue, 17 Jul 2007 06:23:23 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAkDD-0001yq-FU for sip@ietf.org; Tue, 17 Jul 2007 06:23:23 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6HALbwL022040 for ; Tue, 17 Jul 2007 05:21:46 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 05:21:41 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 12:21:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jul 2007 12:21:37 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001436436@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC on draft-ietf-sip-sips Thread-Index: AcfIXEJGTtoU72HSRkWT3r3x153dEQ== From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 17 Jul 2007 10:21:38.0722 (UTC) FILETIME=[42D61020:01C7C85C] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Sip] WGLC on draft-ietf-sip-sips X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) We reached the end of the time when WGLC comments were requested on Monday. If there are any last comments sitting out there that you have been meaning to submit, can I suggest you get them in an quickly as possible. Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 17 06:31:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAkL0-0001s8-CW; Tue, 17 Jul 2007 06:31:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAkKx-0001pb-KR for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 06:31:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAkKx-0001oc-9J for sip@ietf.org; Tue, 17 Jul 2007 06:31:23 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAkKw-0002MB-Ba for sip@ietf.org; Tue, 17 Jul 2007 06:31:23 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6HAUqxQ000380; Tue, 17 Jul 2007 13:31:05 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 13:30:18 +0300 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 13:30:18 +0300 Received: from [172.21.40.62] ([172.21.40.62]) by esebe106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 13:30:17 +0300 Message-ID: <469C9A39.4060608@nokia.com> Date: Tue, 17 Jul 2007 13:30:17 +0300 From: Aki Niemi Organization: Nokia User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: ext Qian Sun References: <002b01c7c781$ff8b0d00$7c6c460a@china.huawei.com> In-Reply-To: <002b01c7c781$ff8b0d00$7c6c460a@china.huawei.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2007 10:30:17.0643 (UTC) FILETIME=[78231FB0:01C7C85D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: sip@ietf.org Subject: [Sip] Re: Comments on draft-ietf-sip-subnot-etags-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Qian, ext Qian Sun wrote: > Hi, > > As this draft mentioned, the presence rules may affect the views of > the resource state. If the presence rules of presentity are modified, > all of etags for this presentity have to be abandoned. Or the PS has > to evaluate whether each etag still is valid. I'm not sure I understand what it is that should be added to the draft to clarify this issue. There are all sorts of events that drive the internal state machine of the PS, or more generally the server of any event package. For instance, authorization rules might change, the resource state might change, and those changes might or might not be visible to the subscriber. However, those details are of no concern of the subnot-etags draft, IMO. All that matters is that if the resource to which the subscriber subscribed changes, then the entity-tag changes as well. What "change" means here should be an implementation detail for every event package to figure out. IOW, I don't think it belongs in the subnot-etags draft. > For filtering, there is similar problem: > http://www1.ietf.org/mail-archive/web/sip/current/msg19724.html > > These are difference between HTTP and SIP events framework. Even HTTP resources can be dynamically generated, their access controlled using an authorization framework of considerable complexity and have many different views for different agents that access them. So I don't think HTTP resources and SIP resources are that much different in this respect. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 17 06:55:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAkhq-000505-1j; Tue, 17 Jul 2007 06:55:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAkhm-0004zV-1s for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 06:54:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAkhl-0004zL-9w for sip@ietf.org; Tue, 17 Jul 2007 06:54:57 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAkhl-000365-0D for sip@ietf.org; Tue, 17 Jul 2007 06:54:57 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JLB003CZKYBH5@siemenscomms.co.uk> for sip@ietf.org; Tue, 17 Jul 2007 11:54:11 +0100 (BST) Date: Tue, 17 Jul 2007 11:54:23 +0100 From: "Elwell, John" To: Mayumi Munakata , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D02059E4@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: Comment on draft-munakata-sip-privacy-new Thread-Index: AcfIYNWViGAcINjFTJSEvzN9gtFq7A== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Sip] Comment on draft-munakata-sip-privacy-new X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Mayumi, "If the "temp-gruu" URI parameter and value exist within the REGISTER response, the user agent SHOULD use the value of the "temp-gruu" as an anonymous URI representing the originator. This URI SHOULD be used for Contact and From, for example, wherever the originator of the URI is required." I have not heard of using a temp GRUU in the From header field before. Normally the From header field contains the AoR, not the contact URI, and where anonymity is required if contains a value such as sip:anonymous@example.com or a domain part of "anonymous.invalid". Of course, a temp GRUU does provide anonymity (given that you are prepared to disclose the domain), so I suppose it might work. There may be one or two side effects: 1. A UAS that simply displays the From URI would display the temp GRUU rather than something like "sip:anonymous@example.com". 2. If the outbound proxy provides an Authentication Service, it would need to recognise that this is a temporary GRUU and sign the Identity header field even though the From URI does not match the identity in the Proxy-Authorization header field. I would like to hear opinions on this. John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 17 09:02:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAmgs-0003XS-TU; Tue, 17 Jul 2007 09:02:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAk5Z-0005N2-Oh for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 06:15:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAk5Y-0005Mq-HX; Tue, 17 Jul 2007 06:15:28 -0400 Received: from anode.atosc.org ([195.154.245.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAk5T-0000BB-2L; Tue, 17 Jul 2007 06:15:28 -0400 Received: from anode.atosc.org (localhost.localdomain [127.0.0.1]) by internal.atosc.org (Postfix) with ESMTP id EF016FA6B; Tue, 17 Jul 2007 12:06:37 +0200 (CEST) Received: from antisip.antisip.com (unknown [77.197.73.102]) by anode.atosc.org (Postfix) with ESMTP id 9F3EFFA66; Tue, 17 Jul 2007 12:06:37 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by antisip.antisip.com (Postfix) with ESMTP id 41C4E1FE33; Tue, 17 Jul 2007 12:15:19 +0200 (CEST) X-Virus-Scanned: by hand at fauche.org Received: from antisip.antisip.com ([127.0.0.1]) by localhost (antisip.antisip.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFQjivmrBdDq; Tue, 17 Jul 2007 12:15:15 +0200 (CEST) Received: by antisip.antisip.com (Postfix, from userid 1000) id 89DE41FE4D; Tue, 17 Jul 2007 12:15:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by antisip.antisip.com (Postfix) with ESMTP id 877411FE33; Tue, 17 Jul 2007 12:15:15 +0200 (CEST) Date: Tue, 17 Jul 2007 12:15:15 +0200 (CEST) From: Aymeric Moizard X-X-Sender: jack@sip2 To: Henry Sinnreich Subject: Re: [Sip] ICE deployment data before LC for RFC In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> Message-ID: References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on anode.atosc.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=ALL_TRUSTED autolearn=failed version=3.0.3 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Tue, 17 Jul 2007 09:02:09 -0400 Cc: sip@ietf.org, Cullen Jennings , mmusic@ietf.org, jon.peterson@neustar.biz X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Henry, On Mon, 16 Jul 2007, Henry Sinnreich wrote: > In the best IETF tradition, it would also help to have open source code > available for ICE, before declaring it a standard. To answer one of your question: I have implemented ICE in open source software (around version 8... not 17): It's available through oRTP and mediastreamer2 library (not used in any open source final application) and still miss only TURN capability. I'm more or less waiting for an RFC before updating to the latest ICE specification... Regards, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 17 09:13:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAmrz-0000FK-Lp; Tue, 17 Jul 2007 09:13:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAmrx-0000Ee-Sp for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 09:13:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAmrx-0000EU-Hw for sip@ietf.org; Tue, 17 Jul 2007 09:13:37 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAmrv-0007qD-Kj for sip@ietf.org; Tue, 17 Jul 2007 09:13:36 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6HDDH5p002359; Tue, 17 Jul 2007 08:13:34 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 08:12:40 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 15:12:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] CFP - International Conference on IP Multimedia SubsystemArchitecture and Applications Date: Tue, 17 Jul 2007 15:12:35 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001436570@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] CFP - International Conference on IP Multimedia SubsystemArchitecture and Applications Thread-Index: AcfIK4vIq9owljh/Qba1rT5TyY3xzQAR2qqQ References: From: "DRAGE, Keith \(Keith\)" To: "Samir Saklikar" , X-OriginalArrivalTime: 17 Jul 2007 13:12:36.0791 (UTC) FILETIME=[251F2C70:01C7C874] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On the SIP list, we generally try and discourage conference postings, = as: - there are plenty of other channels for such postings to be made. - none of us have the bandwidth for every possible conference and = seminar on voice over IP issues that would otherwise get posted. We strongly suggest that if you have such a posting, you consult with = the chairs first before making such a posting. What we want to hear = before accepting such a posting, is how such a posting supports the = general aims of the SIP WG. Conferences that are focussed on identifying = and presenting new SIP techniques may well be acceptable; applying SIP = into IMS is quite possibly not within scope. Regards Keith ________________________________ From: Samir Saklikar [mailto:ssaklikar@gmail.com]=20 Sent: Tuesday, July 17, 2007 5:32 AM To: sip@ietf.org; sipping@ietf.org Subject: [Sip] CFP - International Conference on IP Multimedia = SubsystemArchitecture and Applications =09 =09 =20 International Conference on IP Multimedia Subsystems Architecture and = Applications-2007 (IMSAA-2007),=20 =09 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 17 10:39:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAoCW-0002ot-AK; Tue, 17 Jul 2007 10:38:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAoCV-0002oj-91 for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 10:38:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAoCU-0002oa-IN for sip@ietf.org; Tue, 17 Jul 2007 10:38:54 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAoCS-0002K4-TT for sip@ietf.org; Tue, 17 Jul 2007 10:38:54 -0400 Received: from [172.17.1.65] ([172.17.1.65]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l6HEcoAv043092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Jul 2007 09:38:50 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: <21964a950707162342h65f14291i605eb2c5da7fda33@mail.gmail.com> References: <21964a950707162342h65f14291i605eb2c5da7fda33@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <54DA9005-F247-467B-BDE1-8E3FF2FBB2C5@estacado.net> From: Robert Sparks Subject: Re: [Sip] Changes to the INVITE transaction to address bug 769 Date: Tue, 17 Jul 2007 09:38:40 -0500 To: "Nasir Khan" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1231694194==" Errors-To: sip-bounces@ietf.org --===============1231694194== Content-Type: multipart/alternative; boundary=Apple-Mail-25-217490059 --Apple-Mail-25-217490059 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jul 17, 2007, at 1:42 AM, Nasir Khan wrote: > Hi Robert, > > I have 3 comments / suggestions w.r.t this ID. > > Comment-1 > ---------------- > Should there be any change with respect to receiving CANCEL in > Accepted state? Hitherto the UAC was getting a 481/CANCEL in such > cases. Now we will get 200/CANCEL with no effect on IST. > The reason for this question is backwards compatibility, however I > can myself argue both ways on this one. What do you think? I don't see any issue here. The UAC already has to be prepared for either response. > > > Comment-2 > ----------------- > In section 6.7 of the ID about the Timer-L you say - "and the > amount of time this (or any downstream) UAS core might be > retransmitting the 2xx while waiting for an ACK. " > > How does 2xx retransmission timer affect the choice of Timer L? > > > Comment-3 > ----------------- > Shouldnt the Timer L be set to T4 which represents the amount of > time the network will take to clear messages between client and > server transactions? > Since 2xx is sent reliably anyway, IMHO we do not need to link > Timer L to Timer B. For both of these comments - Timer L is keeping the transaction in place while the TU on top of this server transaction finishes its job of retrasmitting 200s until it gets an ACK. It's not just clearing messages that are already in the network. Remember that those 200s might get lost, and timers on the UAC's side will cause the INVITE request to be retransmitted. This Timer makes sure the server transaction is still there to receive that retransmitted INVITE. Does this clear up the questions you had? > > Thanks > > Nasir Khan > BEA Systems Inc. > > > On 6/27/07, Robert Sparks wrote: > Everyone - > > I've put together a proposal for addressing the spec bug captured at > http://bugs.sipit.net/show_bug.cgi?id=769 > > Please read through > http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-00.txt > and comment. > > RjS > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > > -- > Discuss SIP Servlets at http://groups.google.com/group/sipservlets/ > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --Apple-Mail-25-217490059 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
        On Jul 17, 2007, = at 1:42 AM, Nasir Khan wrote:

        Hi = Robert,

        I have 3 comments / suggestions w.r.t this ID.
        =
        Comment-1
        ----------------
        Should there be any change with = respect to receiving CANCEL in Accepted state? Hitherto the UAC was = getting a 481/CANCEL in such cases. Now we will get 200/CANCEL with no = effect on IST.
        The reason for this question is backwards = compatibility, however I can myself argue both ways on this one. What do = you think?

        I don't see any issue here. The = UAC already has to be prepared for either = response.=A0
        =A0


        = Comment-2
        -----------------
        In section 6.7 of the ID about the = Timer-L you say - "and the amount of time this (or any downstream) UAS = core might be retransmitting the 2xx while waiting for an ACK. "
        =
        How does 2xx retransmission timer affect the choice of Timer = L?=A0


        = Comment-3
        -----------------
        Shouldnt the Timer L be set to T4 = which represents the amount of time the network will take to clear = messages between client and server transactions?
        Since 2xx is sent = reliably anyway, IMHO we do not need to link Timer L to Timer = B.

        For = both of these comments - Timer L is keeping the transaction in place = while the TU on top of this server transaction finishes = its
        job of retrasmitting 200s until it gets an ACK. It's not = just clearing messages that are already in the network. Remember that = those
        200s might get lost, and timers on the UAC's side will = cause the INVITE request to be retransmitted. This Timer makes sure = the
        server transaction is still there to receive that = retransmitted INVITE.=A0 Does this clear up the questions you = had?



        Thanks

        Nasir Khan
        BEA Systems Inc.
        =

        On 6/27/07, Robert Sparks <rjsparks@estacado.net> = wrote:
        Everyone -

        I've put together a proposal for addressing the = spec bug captured at
        http://bugs.sipit.net= /show_bug.cgi?id=3D769

        Please read through
        http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-00.txtand = comment.

        RjS


        ___________________________________________= ____
        Sip mailing list=A0=A0https://www1.ietf.org/= mailman/listinfo/sip
        This list is for NEW development of the core = SIP Protocol
        Use = sip-implementors@cs.columbia.edu for questions on current sip
        Use = sipping@ietf.org for new = developments on the application of sip



        --
        Discuss SIP Servlets at http://groups.google.= com/group/sipservlets/
        This list is = for NEW development of the core SIP Protocol
        Use sip-implementors@cs.colum= bia.edu for questions on current sip
        Use sipping@ietf.org for new = developments on the application of sip
        =

        = --Apple-Mail-25-217490059-- --===============1231694194== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1231694194==-- From sip-bounces@ietf.org Tue Jul 17 10:43:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAoH3-0006q2-DJ; Tue, 17 Jul 2007 10:43:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAoGz-0006j0-Gq for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 10:43:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAoGy-0006gH-Lo for sip@ietf.org; Tue, 17 Jul 2007 10:43:33 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAoGw-00020n-R2 for sip@ietf.org; Tue, 17 Jul 2007 10:43:32 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6HEhJNt043246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Jul 2007 09:43:19 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <469C62E7.6010401@ericsson.com> References: <002c01c7c786$19d60530$7c6c460a@china.huawei.com> <469C62E7.6010401@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <2057023F-B93F-443C-9762-9B1388C119E9@nostrum.com> Content-Transfer-Encoding: quoted-printable From: Robert Sparks Subject: Re: [Sip] Re: [Sipping] RE: Comments on draft-ietf-sip-multiple-refer-01.txt Date: Tue, 17 Jul 2007 09:43:10 -0500 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: Miguel Garcia , sip , "Markus.Isomaki@nokia.com> , Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org As much as I like the Referred-By mechanism, before investing too =20 much time into extending Referred-by for this case, ask yourself =20 seriously if there is a customer for the work. AFAIK, there are no =20 implementations of the AIB part of Referred-by on the planet (please =20 speak up if you have one) and I know of no-one who plans to build it. Unless that =20 changes, I think we'd all be better off spending our time working on =20 things that people will actually use. RjS On Jul 17, 2007, at 1:34 AM, Gonzalo Camarillo wrote: > Hi, > > [moving this thread from the SIPPING list to this one (SIP) because =20= > this is a SIP document now.] > > You are right. It is not trivial to use Referred-By with multiple =20 > REFER. My suggestion is that, the same way as Referred-By is =20 > specified as an extension of refer, you go ahead specify (if you =20 > are interested) how to use Referred-by with multiple REFER in a =20 > different spec. > > The body that the referrer would add to its REFER (which is what =20 > the refer target would get) could be an XML list with the =20 > recipients (those that can be disclosed) of the multiple REFER =20 > (plus the referrer). Something similar to what recipients get after =20= > a relay processes a list with copyControl attributes (draft-ietf-=20 > sipping-capacity-attribute-04.txt)... in any case, since multiple =20 > REFER is only used within a context of a service, you need to think =20= > whether having a general Referred-By mechanism is needed or if such =20= > functionality can be achieved in a different way within the =20 > services multiple REFER is used in (e.g., conferencing). > > Cheers, > > Gonzalo > > > Qian Sun wrote: >> Hello, Gonzalo >> RFC3892 says: >> The sipfrag inside a Referred-By token MUST contain copies of the >> Refer-To, Referred-By, and Date header fields from the REFER =20 >> request. >> In multiple refer case, the Refer-To header field includes content =20= >> id, not the REFER-Target' URI. The content id is meaningless to =20 >> the REFER-Targets, so the Referred-By token has to include the URI-=20= >> List. >> Cheers, >> Qian >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >> Sent: Monday, July 16, 2007 4:23 PM >> To: Qian Sun >> Cc: Aki.Niemi@nokia.com; Markus.Isomaki@nokia.com; =20 >> miguel.an.garcia@nokia.com; hisham.khartabil@gmail.com; =20 >> sipping@ietf.org >> Subject: Re: Comments on draft-ietf-sip-multiple-refer-01.txt >> Hi, >> thanks for your comments. Answers inline: >> Qian Sun wrote: >> > Some comments on the draft... >> > >> > 1. I think it might be a good idea to talk something on =20 >> "Referred-By" in this draft. Referred-By mechanism is still very =20 >> useful for the multiple refer case. Maybe Refer-To related to a =20 >> URI List with "bcc" or "anonymize" is a trouble. "Referred-BY=94 in =20= >> the message header is to identify the initial REFER-Issuer. This =20 >> information may be encrypted together with "refer-to" URI list, =20 >> including the copy control level such as to/cc/bcc to the end =20 >> user, i.e. REFER-Target, where the information will be decrypted =20 >> by the REFER-Target. In this case the REFER-Recipient won=92t be =20 >> able to get rid of the "bcc" URI from the URI list, and the "bcc" =20 >> URI will be sent to other REFER-Targets along with normal to/cc. =20 >> This will be a problem to destroy the blind cc function. >> > However, the REFER-issuer may opt to not include a Referred-By =20 >> token. For example: >> > REFER sip:conf-123@example.com;gruu;opaque=3Dhha9s8d-999a SIP/=20= >> 2.0 >> > Refer-To: >> > Referred-By: Carol >> > Content-Type: application/resource-lists+xml >> > Content-Disposition: recipient-list >> > Content-Length: 362 >> > Content-ID: >> > >> > >> > > > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"> >> > >> > >> > >> > >> > >> > >> > >> > When the URI list has no "bcc" or "anonymize" URI, REFER-issuer =20= >> may include the Referred-By token in the REFER body. >> The way Referred-By works is not affected by what this draft says. >> Therefore, I do not see the need to talk about it. >> > >> > 2. Nested refer in multiple refer is very interesting, I =20 >> believe it could be a good idea to enroll a "multiple nested =20 >> refer" example into this draft. Just for an example: >> > REFER sip:list-service@example.com;gruu;opaque=3Dhha9s8d-999a =20= >> SIP/2.0 >> > Refer-To: >> > Content-ID: >> > >> > >> > > > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"> >> > >> > > 3Dsip:conf-123%40shenzhen.example.com" /> >> > > 3Dsip:conf-123%40shenzhen.example.com" /> >> > >> > >> > In this case, the REFER-Recipient acts as a Refer List service, =20= >> has the similar function to the MESSAGE List service, i.e. =20 >> receives a REFER with URI-List and distributes some REFERs to each =20= >> address in the URI-List. >> > Note that, there is only one final REFER-Target in above =20 >> "nested multiple refer" example, not multiple REFER-Targets. In =20 >> some situations, this convergent feature is useful. >> The draft says the following: >> Additionally, REFER-Recipients SHOULD only accept REFER requests >> within the context of an application the server understands =20 >> (e.g., a >> conferencing application). >> this text was added to avoid relays being used as random traffic >> forwarders. Therefore, since a relay needs to understand what is =20 >> going >> on (e.g., a multiple REFER to trigger BYEs towards several conference >> attendees) and currently there is no service that uses nested =20 >> refers, I >> do not think we need to talk about it. >> > >> > 3. I guess it might be a typo in Figure 2 "8. 200K OK", maybe =20 >> you meant "200 OK"? >> yes, thanks for pointing it out. We will fix it. >> Thanks, >> Gonzalo >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 17 13:00:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAqP3-0006Ew-HQ; Tue, 17 Jul 2007 13:00:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAqP1-00066I-LT for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 12:59:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAqP1-00064v-8y; Tue, 17 Jul 2007 12:59:59 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAqOz-0007Y5-Sz; Tue, 17 Jul 2007 12:59:59 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 17 Jul 2007 09:59:57 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4HAPaRnEarR7O6/2dsb2JhbAAs X-IronPort-AV: i="4.16,546,1175497200"; d="scan'208"; a="504085217:sNHT36300100" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6HGxuDa031702; Tue, 17 Jul 2007 09:59:56 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6HGxqA0005709; Tue, 17 Jul 2007 16:59:52 GMT From: "Dan Wing" To: "'Henry Sinnreich'" , , Date: Tue, 17 Jul 2007 09:59:51 -0700 Message-ID: <037501c7c893$e6c64650$7d646b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> Thread-Index: AcfH+cwnIETVFFZtTmCLWopMWLu+LAAl5b7A DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3066; t=1184691596; x=1185555596; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[MMUSIC]=20ICE=20deployment=20data=20before=20LC=20fo r=20RFC |Sender:=20; bh=/nNmvvhgV9svjXnuOjir+NdlamMt0qgJt53653K2IJc=; b=IBq5sIK9zxdR5Ic0Bk+yF1cwDrEMnJ0/MVY1k9ZOmoZnEk3N6uZxUpQ5PyHMbTfO1puZa+tm dbgV8rk702HhNsoJWxu05sw1VtcEaU8uuOit9hpUdvr+F3li1iynAY/Q; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: 'Cullen Jennings' , jon.peterson@neustar.biz Subject: [Sip] RE: [MMUSIC] ICE deployment data before LC for RFC X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Monday, July 16, 2007 3:38 PM > To: mmusic@ietf.org; sip@ietf.org > Cc: Cullen Jennings; jon.peterson@neustar.biz > Subject: [MMUSIC] ICE deployment data before LC for RFC > > The work on ICE is truly impressive and so are the numerous > I-Ds associated with ICE. > > > > However, before sending the I-D for LC to the IESG, > it would be prudent and responsible to the industry (that > spends considerable resources on ICE in good faith) > implementing ICE, to either (1) make it an informational RFC > or To my knowledge, IETF only requires such deployment details and analysis when promoting a Proposed Standard to Draft Standard, and promoting Draft Standard to Internet Standard. Many Internet Drafts don't have deployment results, because they aren't yet deployed nor deployable until they achieve RFC status. As was well witnessed by the many substantive changes to ICE during its development, it is unreasonable to create interoperable implementations with an Internet Draft while that Internet Draft is undergoing substantial and substantive revision. I don't see the value to the community to deny ICE as a standards-track document. Making ICE an Informational document, as you suggest, will only further delay interoperation and deployment of ICE. If ICE had a competing, incrementally- deployable NAT traversal technique, I could see a desire to make one of those techniques a standards track document and the other an informational document; however, there is no such competing, incrementally-deployable NAT traversal technique. ICE should be a standards-track document. > (2) publish some deployment data showing such items as: > > > > * NAT scenarios that have been tested, > * The % of success, > * Performance, such as call setup delay using SIP. > > > > I have not seen any such public data on ICE deployment, for > example with SIP. A private report has raised my concern > about the performance of ICE. I do agree that publishing information, such as what you requested in (2), would be very useful. But publishing such information is not necessary for ICE to be published as a standard-track RFC. > In the best IETF tradition, it would also help to have open > source code available for ICE, before declaring it a standard. I see that already there have been two followups to your request for publicly-available code, pointing at three implementations (NICE, PJSIP, and oRTP/mediastreamer2). > ICE is too important for the IETF (good work Jonathan and > other authors!) not to publish (1) deployment results and (2) > publish open source code as well. > > The various nits discussed on the lists are only of secondary > importance to the LC compared to the above and would get > resolved with such a process anyway. -d > > > > These are my personal two cents. > > Henry Sinnreich > > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 17 13:51:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArCT-0005U0-Ue; Tue, 17 Jul 2007 13:51:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IArCT-0005Te-3J for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 13:51:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArCS-0005TL-N9; Tue, 17 Jul 2007 13:51:04 -0400 Received: from dencfw1.jabber.com ([207.182.164.5] helo=wrk225.corp.jabber.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IArCP-0000id-1m; Tue, 17 Jul 2007 13:51:04 -0400 Received: from wrk225.corp.jabber.com (localhost [127.0.0.1]) by wrk225.corp.jabber.com (Postfix) with ESMTP id D5FA6629DB2; Tue, 17 Jul 2007 11:52:53 -0600 (MDT) Message-ID: <469D01F5.7020704@jabber.org> Date: Tue, 17 Jul 2007 11:52:53 -0600 From: Peter Saint-Andre Organization: XMPP Standards Foundation User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Henry Sinnreich References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: sip@ietf.org, Cullen Jennings , mmusic@ietf.org, jon.peterson@neustar.biz Subject: [Sip] Re: [MMUSIC] ICE deployment data before LC for RFC X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0684566311==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0684566311== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070404000802050809020102" This is a cryptographically signed message in MIME format. --------------ms070404000802050809020102 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Henry Sinnreich wrote: > The work on ICE is truly impressive and so are the numerous I-Ds > associated with ICE. > > However, before sending the I-D for LC to the IESG, it would be > prudent and responsible to the industry (that spends considerable > resources on ICE in good faith) implementing ICE, to either (1) make it > an informational RFC I see no reason for this work not to be standards track. > or (2) publish some deployment data showing such > items as: > > * NAT scenarios that have been tested, > * The % of success, > * Performance, such as call setup delay using SIP. It is my understanding that Google Talk uses something very similar to ICE, which at some point they will migrate to the XMPP profile of ICE defined in XEP-0176 . They are not typically forthcoming with detailed performance data, but the service appears to be fairly robust and on various public discussion lists Google Talk team members have indicated that they successfully establish media exchange about 92+% of the time without a media relay. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms070404000802050809020102 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYUDCC B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0 4STurMCFwLoyx5k1rDHQYTCCCGowggdSoAMCAQICAwFotjANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDcwNzA1MTYxODMyWhcNMDgwNzA0MTYxODMyWjCBwjELMAkGA1UE BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxIjAgBgNVBAoTGVhN UFAgU3RhbmRhcmRzIEZvdW5kYXRpb24xLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2Vy dGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3 DQEJARYSc3RwZXRlckBqYWJiZXIub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAoRCp9cymHb9V1L04LWCmN2wQEbHFWrmgFnAPxRVQpMsB4ifl5iYSDICmBkLINum2inq9 /+0Fz6ScCEONYC/CDOkkmLPItEDNZ0gdUd+kl+5wMPI+567ttt85ResrUAN0B/gcp+prQKxS 7uM6JcSxC0PdwrWK9pWwxPR+LveLgX9/oE9jSSy5BIQnZVgH8nhjlNMcfkTw/hVuGD/8HJFX 1MVySNt7Qy38Kc3CALmuR3ulGUkYeepGUHXj3gdITJ1CKSKCTq6hqzjTZ4m2BDAdIV4LVVlZ pH8AFs7zcl6HuQ2jLAXqBH97iSHjm5bziC9PaNmAbQkLYIPqSK46YdnSmwIDAQABo4IEeDCC BHQwDAYDVR0TBAUwAwIBADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBS08ly4gUAQeznlzuQXQlnPQN0HMTCB3QYDVR0jBIHVMIHSgBQE rNskd1NGRpZfFwFcfUJHvUgZCKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklz cmFlbDEOMAwGA1UEBxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsT EUNBIEF1dGhvcml0eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0g BIIBNzCCATMwggEvBgsrBgEEAYG1NwEBAzCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9pbnRlcm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20g THRkLjADAgEBGoGNTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2Fs IExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZh aWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRd MFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4 MHYwNwYIKwYBBQUHMAGGK2h0dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3Vz ZXIvY2EwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3Mz LnVzZXIuY2EuY3J0MBEGCWCGSAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRD b20gVHJ1c3RlZCBFbWFpbCBDZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFy dGNvbS5vcmcwDQYJKoZIhvcNAQEFBQADggEBAL7ynZiQ7FHEMcQsQetYQwDHKql1d2dBtPtW YjPvU62LyZHbqFKVc2oA6rKaGBqpUKVYUyoBkfJkyAz5/YgrFufw5mnrqysjctDMKTsjdtvu NnL0pIGnvZsQhlL/sTUV/hDOBv00ypsbHXpv5YrVKpCw4Vs9rwSo/5o8f2K8dMHbNB4dv3GX JfMGQUHR/UDTiMqMOxSRAXQ6xGBwNr3zmfDys7qtgoSqy9nBy3er12WRN10jUjdJsFv11Syh 1qyRr+RH0z3Yz6gfd0tq1S9sdzDZ+hFAai3eyjKU6kNLneumEu0w1jeL9EiDRioFsEqCYTuu +c4/cvqC+T/dP89QbGowgghqMIIHUqADAgECAgMBaLYwDQYJKoZIhvcNAQEFBQAwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAzIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnMB4XDTA3MDcwNTE2MTgzMloXDTA4MDcwNDE2MTgzMlowgcIxCzAJBgNVBAYT AlVTMREwDwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQ IFN0YW5kYXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRp ZmljYXRlIE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0B CQEWEnN0cGV0ZXJAamFiYmVyLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKEQqfXMph2/VdS9OC1gpjdsEBGxxVq5oBZwD8UVUKTLAeIn5eYmEgyApgZCyDbptop6vf/t Bc+knAhDjWAvwgzpJJizyLRAzWdIHVHfpJfucDDyPueu7bbfOUXrK1ADdAf4HKfqa0CsUu7j OiXEsQtD3cK1ivaVsMT0fi73i4F/f6BPY0ksuQSEJ2VYB/J4Y5TTHH5E8P4Vbhg//ByRV9TF ckjbe0Mt/CnNwgC5rkd7pRlJGHnqRlB1494HSEydQikigk6uoas402eJtgQwHSFeC1VZWaR/ ABbO83Jeh7kNoywF6gR/e4kh45uW84gvT2jZgG0JC2CD6kiuOmHZ0psCAwEAAaOCBHgwggR0 MAwGA1UdEwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF BQcDBDAdBgNVHQ4EFgQUtPJcuIFAEHs55c7kF0JZz0DdBzEwgd0GA1UdIwSB1TCB0oAUBKzb JHdTRkaWXxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3Jh ZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFD QSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASC ATcwggEzMIIBLwYLKwYBBAGBtTcBAQMwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0 ZC4wAwIBARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBb MCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4Yl aHR0cDovL2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2 MDcGCCsGAQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2Vy L2NhMDsGCCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51 c2VyLmNhLmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29t IFRydXN0ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQC+8p2YkOxRxDHELEHrWEMAxyqpdXdnQbT7VmIz 71Oti8mR26hSlXNqAOqymhgaqVClWFMqAZHyZMgM+f2IKxbn8OZp66srI3LQzCk7I3bb7jZy 9KSBp72bEIZS/7E1Ff4Qzgb9NMqbGx16b+WK1SqQsOFbPa8EqP+aPH9ivHTB2zQeHb9xlyXz BkFB0f1A04jKjDsUkQF0OsRgcDa985nw8rO6rYKEqsvZwct3q9dlkTddI1I3SbBb9dUsodas ka/kR9M92M+oH3dLatUvbHcw2foRQGot3soylOpDS53rphLtMNY3i/RIg0YqBbBKgmE7rvnO P3L6gvk/3T/PUGxqMYIELDCCBCgCAQEwgbcwga8xCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJ c3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAhBgNVBAsTGlNlY3VyZSBDZXJ0aWZp Y2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgRW1haWwg RnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnAgMBaLYwCQYFKw4D AhoFAKCCAkkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcw NzE3MTc1MjUzWjAjBgkqhkiG9w0BCQQxFgQUMm0+4Q6XXzSuWX5bm+e/EjpRFtQwUgYJKoZI hvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgcgGCSsGAQQBgjcQBDGBujCBtzCBrzELMAkGA1UE BhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UE CxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNz IDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNv bS5vcmcCAwFotjCBygYLKoZIhvcNAQkQAgsxgbqggbcwga8xCzAJBgNVBAYTAklMMQ8wDQYD VQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAhBgNVBAsTGlNlY3VyZSBD ZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBDbGFzcyAzIFByaW1hcnkg RW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnAgMBaLYw DQYJKoZIhvcNAQEBBQAEggEAgY07McBcSFHX1BatNinl++vJdmj30P4SGEF3ZQrFB1CUuMFT Hg97V5MXqcbwuPuFr0Ls+OuUIECi5I977iX8abSQxiYaT9Zvw/RL6T00qFBTxTYJbDFR2Tq6 4on/wK5RCJg1VGieCDHG7ra4H+S/iRDHjStyuvm7p/YimUUPsQ7yXiPBSA54Ls+wUbd6Bjs1 /6PRl5apVUXRkMpQdQrDxu2TRi5zsL6JGEs5Mg1GsZuhuk/tCEgG5lS8lHjf8J8516zH0hci hX0rycgMC2zbyqkptSxdOMuQFkPAr4MmTGryigcVyoJhRwwKmnCNgpC9iz9X3aDPc3oaCLB0 bj+nqgAAAAAAAA== --------------ms070404000802050809020102-- --===============0684566311== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0684566311==-- From sip-bounces@ietf.org Tue Jul 17 13:56:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArHG-00017I-C5; Tue, 17 Jul 2007 13:56:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IArHF-0000zs-6X for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 13:56:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArHE-0000y0-SX; Tue, 17 Jul 2007 13:56:00 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IArHD-0000dV-FO; Tue, 17 Jul 2007 13:56:00 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l6HHtqcc015945; Tue, 17 Jul 2007 12:55:52 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 12:55:52 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 19:55:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jul 2007 19:55:47 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180014366B4@DEEXC1U01.de.lucent.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] ICE deployment data before LC for RFC Thread-Index: AcfH+cwnIETVFFZtTmCLWopMWLu+LAAoNGJw References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> From: "DRAGE, Keith \(Keith\)" To: "Henry Sinnreich" , , X-OriginalArrivalTime: 17 Jul 2007 17:55:49.0601 (UTC) FILETIME=[B5A03510:01C7C89B] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.5 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: Cullen Jennings , jon.peterson@neustar.biz Subject: [Sip] RE: [MMUSIC] ICE deployment data before LC for RFC X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org As SIP WG chair and the document shepherd for draft-ietf-sip-ice-option-tag this is what I shall be doing with regard to the ancillary document in this process... I went to RFC 2026 and carefully read the section on proposed standard: 4.1.1 Proposed Standard The entry-level maturity for the standards track is "Proposed Standard". A specific action by the IESG is required to move a specification onto the standards track at the "Proposed Standard" level. A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. The IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet. A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it. However, the IESG may waive this requirement in order to allow a specification to advance to the Proposed Standard state when it is considered to be useful and necessary (and timely) even with known technical omissions. Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. My judgement is that at least the in terms of its draft, the SIP WG has fulfilled the requirements for a request to publish a proposed standard. It appears to me that any further decision about implementation rests with the IESG, who should obviously take into account any submissions made during the IESG last call process. It is therefore my intent to proceed with the publish request for draft-ietf-sip-ice-option-tag. Regards Keith ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Monday, July 16, 2007 11:38 PM To: mmusic@ietf.org; sip@ietf.org Cc: Cullen Jennings; jon.peterson@neustar.biz Subject: [MMUSIC] ICE deployment data before LC for RFC =09 =09 The work on ICE is truly impressive and so are the numerous I-Ds associated with ICE. =20 However, before sending the I-D for LC to the IESG, it would be prudent and responsible to the industry (that spends considerable resources on ICE in good faith) implementing ICE, to either (1) make it an informational RFC or (2) publish some deployment data showing such items as: =20 * NAT scenarios that have been tested,=20 * The % of success,=20 * Performance, such as call setup delay using SIP.=20 =20 I have not seen any such public data on ICE deployment, for example with SIP. A private report has raised my concern about the performance of ICE. =20 In the best IETF tradition, it would also help to have open source code available for ICE, before declaring it a standard. =20 ICE is too important for the IETF (good work Jonathan and other authors!) not to publish (1) deployment results and (2) publish open source code as well. The various nits discussed on the lists are only of secondary importance to the LC compared to the above and would get resolved with such a process anyway. =20 These are my personal two cents. Henry Sinnreich =09 =09 =09 =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 17 14:13:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArXt-00032r-Pl; Tue, 17 Jul 2007 14:13:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IArXs-00032k-Oq for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 14:13:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArXs-00032c-FI for sip@ietf.org; Tue, 17 Jul 2007 14:13:12 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IArXr-0001Mh-2Y for sip@ietf.org; Tue, 17 Jul 2007 14:13:12 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l6HID9lK014750; Tue, 17 Jul 2007 12:13:10 -0600 Message-ID: <469D06B2.1060009@ntt-at.com> Date: Tue, 17 Jul 2007 11:13:06 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] Comment on draft-munakata-sip-privacy-new References: <0D5F89FAC29E2C41B98A6A762007F5D02059E4@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D02059E4@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Mayumi Munakata , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org John; My comments inline.. Elwell, John wrote: > Mayumi, > > "If the "temp-gruu" URI parameter and value exist within the REGISTER > response, the user agent SHOULD use the value of the "temp-gruu" as > an anonymous URI representing the originator. This URI SHOULD be > used for Contact and From, for example, wherever the originator of > the URI is required." > I have not heard of using a temp GRUU in the From header field before. > Normally the From header field contains the AoR, not the contact URI, > and where anonymity is required if contains a value such as > sip:anonymous@example.com or a domain part of "anonymous.invalid". Of > course, a temp GRUU does provide anonymity (given that you are prepared > to disclose the domain), so I suppose it might work. There may be one or > two side effects: > > 1. A UAS that simply displays the From URI would display the temp GRUU > rather than something like "sip:anonymous@example.com". > I agree, this is a mistake on our side and the From URI should not utilize the temp-gruu, and instead should utilize anonymous URI such as "sip:anonymous@example.com". One could try to use the "anonymous.invalid" domain but this will interfere with the SIP Identity which heavily relies on domain of the From header field. We will fix the text here to ensure temp-gruu is not used for From URI. > 2. If the outbound proxy provides an Authentication Service, it would > need to recognise that this is a temporary GRUU and sign the Identity > header field even though the From URI does not match the identity in the > Proxy-Authorization header field. > > If From header is populated using anonymous URI (anonymous@example.com),with domain portion equal to the domain for which the outbound proxy is responsible, this won't be problematic. The identity service would use the information in the proxy-authorization to identity the user and will simply judge whether that user has a right to send out request while withholding its identity. If temp-gruu is used as it is currently written, outbound proxy would need to look up the location-service and see if the AoR associated with the credential is indeed associated with the temp-gruu in the request. The text will be changed to populate the From header field with anonymous URI as mentioned above, so this really is not a concern anymore. As a side note, if there is a concern about revealing its domain name to the peer, one would probably need to utilize a dedicated anonymous service(anonymity provider) which provides URI to be used in From while withholding its original domain name etc. Regards Shida > I would like to hear opinions on this. > > John > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 17 14:19:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArdU-0000kK-Sv; Tue, 17 Jul 2007 14:19:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IArdS-0000jd-S9 for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 14:18:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArdR-0000iy-3i for sip@ietf.org; Tue, 17 Jul 2007 14:18:58 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IArdP-0001wh-UG for sip@ietf.org; Tue, 17 Jul 2007 14:18:56 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6HIItZ6001883 for ; Tue, 17 Jul 2007 13:18:55 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 13:18:55 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 20:18:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jul 2007 20:18:51 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180014366BA@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Publication request for draft-ietf-sip-ice-option-tag Thread-Index: AcfInu0rD+MYqBodTcKUM47ZdeClZQ== From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 17 Jul 2007 18:18:52.0119 (UTC) FILETIME=[EDABB670:01C7C89E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 Subject: [Sip] Publication request for draft-ietf-sip-ice-option-tag X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) I have just requested publication of: http://www.ietf.org/internet-drafts/draft-ietf-sip-ice-option-tag-02.txt The next stage for submitting comments is therefore the IESG last call. The PROTO writeup submitted with the publication request is as follows. Please feel free to respond if you consider any of the information incorrect. Regards Keith ------------------------------------------------------------------------ ----- PROTO writeup for http://www.ietf.org/internet-drafts/draft-ietf-sip-ice-option-tag- 02.txt: "Indicating Support for Interactive Connectivity Establishment (ICE) in the=20 Session Initiation Protocol (SIP)" (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Keith Drage The document has been reviewed and is ready for forwarding to IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The need for a SIP option tag developed out of discussions in the MMUSIC working group=20 on draft-ietf-sip-ice. See discussion in IETF#67, and discussions on the IETF MMUSIC=20 list (Christer Holmber, Michael Slavitch). In conformance with RFC 3427, this portion of=20 the work was passed to the SIP working group. Document history: - draft-ietf-sip-ice-option-tag-00 was submitted 1st March 2007 and expires 1st=20 September 2007. - draft-ietf-sip-ice-option-tag-01 was submitted 5th March 2007 and expires 6th=20 September 2007. - draft-ietf-sip-ice-option-tag-02 was submitted 19th June 2007 and expires 21st=20 December 2007. WGLC was initiated in the SIP WG on draft-ietf-sip-ice-option-tag-01 on 29th March 2007=20 with comments requested by 20th April 2007. Review was made and comments were received from: Peter Blatherwick, Jeroen van Bemmel,=20 Kevin Johns. During the course of the work comments have also been made by: Ernst=20 Horvath. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? The document defines mechanisms that are entirely internal to the Session Initiation=20 Protocol (SIP). The document shepherd considers that no external review from an external=20 specialist is necessary. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. The document defines a new SIP protocol extension for a particular purpose in a form=20 that has been used for many other extensions. The document shepherd has no concerns with=20 the document. There have been no IPR disclosures on this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has been reviewed by appropriate SIP experts. It is not considered that any=20 of the topics have significant architectural or protocol impact. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document has been reviewed against the guidelines in RFC 4485 and it is believed=20 that the document is conformant with those guidelines. For ID-NITS the checks against idnits 2.04.09 report no NITS found except that draft- ietf-mmusic-ice-13 is now at a later version. While this needs correction, it should not=20 cause a problem in allowing IESG last call to proceed. There are no dependent issues in=20 the revisions that impact the technical contents of this draft. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has separate sections for normative and informative references. The=20 normative references have been checked and found to be normative. The informative=20 references have also been checked and found to be all informative. There are no downrefs in the document. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The document defines the following values that require registration: * A SIP option tag for ice. The IANA registry requirements are for a standards track=20 document and this is a standards track document. The IANA considerations section in=20 section 7.1 of the document provides for the appropriate revision to the registry in=20 conformance with the format of that registry. * A media feature tag for ice. The IANA registry requirements are for IETF consensus=20 which can here be represented by the contents of a standards track document. The IANA=20 considerations section in section 7.2 of the document provides for the appropriate=20 revision to the registry in conformance with the format of that registry. Note that=20 while the presentation of the information is slightly different to that of the IANA=20 registry, this is the format that all previous information for this registry has been=20 presented in. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document contains no material written in a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' Technical summary. This specification defines a media feature tag and an option tag for use with the=20 Session Initiation Protocol (SIP). The media feature tag allows a UA to communicate to=20 its registrar that it supports ICE. The option tag allows a User Agent (UA) to require=20 support for ICE in order for a call to proceed. Working group summary. There is consensus in the working group to publish this document. The document came=20 about as a result of discussions in the IETF MMUSIC working group to progress draft- ietf-mmusic-ice. Document Quality There has been no indication of implementation of this specific draft. There are known=20 implementations of earlier versions of draft-ietf-mmusic-ice. Personnel The document shepherd for this document was Keith Drage. The responsible Area Director=20 was Cullen Jennings. 'The IANA Expert(s) for the registries in this document are . ---------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 17 14:50:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAs7u-0004Og-E4; Tue, 17 Jul 2007 14:50:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAs7s-0004Ms-Ty for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 14:50:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAs7s-0004MY-Aa; Tue, 17 Jul 2007 14:50:24 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAs7q-0003b8-V8; Tue, 17 Jul 2007 14:50:24 -0400 Received: from source ([192.150.20.142]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Tue, 17 Jul 2007 11:50:19 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6HIoDWs025784; Tue, 17 Jul 2007 11:50:17 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6HIoB0e007207; Tue, 17 Jul 2007 11:50:12 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 11:50:11 -0700 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, 17 Jul 2007 11:50:07 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: ICE deployment data before LC for RFC Thread-Index: AcfIoaN6k6PDRX4fSfO/54PtQP6CcQ== From: "Henry Sinnreich" To: , X-OriginalArrivalTime: 17 Jul 2007 18:50:11.0013 (UTC) FILETIME=[4D942F50:01C7C8A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Cullen Jennings , behave@ietf.org, jon.peterson@neustar.biz Subject: [Sip] Re: ICE deployment data before LC for RFC X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Following some discussions and soul searching, the best approach for ICE-17 for LC would be to _go ahead and make it an experimental RFC_. This would support the development of interoperable implementations, the collection of deployment data and also hopefully open source code. Though I have full faith in ICE, following the practices that made the IETF successful take precedent here, I believe. This is a change from the attached that I wrote on 7/16/2007. Note: We can only hope the proliferation of SBC in VoIP service provider networks will not make these concerns and ICE for SIP a moot issue, but this is another topic. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >The work on ICE is truly impressive and so are the numerous I-Ds associated with ICE. >However, before sending the I-D for LC to the IESG, it would be prudent and responsible to the industry=20 >(that spends considerable resources on ICE in good faith) implementing ICE, to either (1) make it an informational RFC or=20 >(2) publish some deployment data showing such items as: >* NAT scenarios that have been tested, >* The % of success, >* Performance, such as call setup delay using SIP. >I have not seen any such public data on ICE deployment, for example with SIP.=20 >A private report has raised my concern about the performance of ICE. >In the best IETF tradition, it would also help to have open source code >available for ICE, before declaring it a standard. >ICE is too important for the IETF (good work Jonathan and other authors!) >not to publish=20 >(1) deployment results and (2) publish open source code as well. >The various nits discussed on the lists are only of secondary importance to >the LC=20 >compared to the above and would get resolved with such a process anyway. >These are my personal two cents. Henry Sinnreich _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 17 14:50:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAs7x-0004YH-AU; Tue, 17 Jul 2007 14:50:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAs7u-0004Pg-VX for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 14:50:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAs7u-0004OX-6B; Tue, 17 Jul 2007 14:50:26 -0400 Received: from exprod6og51.obsmtp.com ([64.18.1.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAs7t-0003b3-NL; Tue, 17 Jul 2007 14:50:26 -0400 Received: from source ([192.150.11.134]) by exprod6ob51.postini.com ([64.18.5.12]) with SMTP; Tue, 17 Jul 2007 11:50:18 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6HIn1ot011398; Tue, 17 Jul 2007 11:49:02 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6HIoB0k007207; Tue, 17 Jul 2007 11:50:16 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 11:50:15 -0700 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, 17 Jul 2007 11:48:09 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F6@namail5.corp.adobe.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180014366B4@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] ICE deployment data before LC for RFC Thread-Index: AcfH+cwnIETVFFZtTmCLWopMWLu+LAAoNGJwAAIRH/A= References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> <5D1A7985295922448D5550C94DE29180014366B4@DEEXC1U01.de.lucent.com> From: "Henry Sinnreich" To: "DRAGE, Keith (Keith)" , , X-OriginalArrivalTime: 17 Jul 2007 18:50:15.0060 (UTC) FILETIME=[4FFDB540:01C7C8A3] X-Spam-Score: 0.5 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: Cullen Jennings , behave@ietf.org, jon.peterson@neustar.biz Subject: [Sip] RE: [MMUSIC] ICE deployment data before LC for RFC X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Keith, Thanks for the attention and sorry our mail has crossed. Feel free to proceed as you best think. (I have made my point as well). Henry -----Original Message----- From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 Sent: Tuesday, July 17, 2007 10:56 AM To: Henry Sinnreich; mmusic@ietf.org; sip@ietf.org Cc: Cullen Jennings; jon.peterson@neustar.biz Subject: RE: [MMUSIC] ICE deployment data before LC for RFC As SIP WG chair and the document shepherd for draft-ietf-sip-ice-option-tag this is what I shall be doing with regard to the ancillary document in this process... I went to RFC 2026 and carefully read the section on proposed standard: 4.1.1 Proposed Standard The entry-level maturity for the standards track is "Proposed Standard". A specific action by the IESG is required to move a specification onto the standards track at the "Proposed Standard" level. A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. The IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet. A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it. However, the IESG may waive this requirement in order to allow a specification to advance to the Proposed Standard state when it is considered to be useful and necessary (and timely) even with known technical omissions. Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. My judgement is that at least the in terms of its draft, the SIP WG has fulfilled the requirements for a request to publish a proposed standard. It appears to me that any further decision about implementation rests with the IESG, who should obviously take into account any submissions made during the IESG last call process. It is therefore my intent to proceed with the publish request for draft-ietf-sip-ice-option-tag. Regards Keith ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Monday, July 16, 2007 11:38 PM To: mmusic@ietf.org; sip@ietf.org Cc: Cullen Jennings; jon.peterson@neustar.biz Subject: [MMUSIC] ICE deployment data before LC for RFC =09 =09 The work on ICE is truly impressive and so are the numerous I-Ds associated with ICE. =20 However, before sending the I-D for LC to the IESG, it would be prudent and responsible to the industry (that spends considerable resources on ICE in good faith) implementing ICE, to either (1) make it an informational RFC or (2) publish some deployment data showing such items as: =20 * NAT scenarios that have been tested,=20 * The % of success,=20 * Performance, such as call setup delay using SIP.=20 =20 I have not seen any such public data on ICE deployment, for example with SIP. A private report has raised my concern about the performance of ICE. =20 In the best IETF tradition, it would also help to have open source code available for ICE, before declaring it a standard. =20 ICE is too important for the IETF (good work Jonathan and other authors!) not to publish (1) deployment results and (2) publish open source code as well. The various nits discussed on the lists are only of secondary importance to the LC compared to the above and would get resolved with such a process anyway. =20 These are my personal two cents. Henry Sinnreich =09 =09 =09 =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 17 14:59:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAsGE-0000V8-Q9; Tue, 17 Jul 2007 14:59:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAsGD-0000Un-G1 for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 14:59:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAsGD-0000UY-5d; Tue, 17 Jul 2007 14:59:01 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAsGC-0003v1-NJ; Tue, 17 Jul 2007 14:59:01 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6HIww9H004652; Tue, 17 Jul 2007 13:58:58 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 13:58:58 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 20:58:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jul 2007 20:58:55 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180014366C2@DEEXC1U01.de.lucent.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F6@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] ICE deployment data before LC for RFC Thread-Index: AcfH+cwnIETVFFZtTmCLWopMWLu+LAAoNGJwAAIRH/AAADGJEA== References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> <5D1A7985295922448D5550C94DE29180014366B4@DEEXC1U01.de.lucent.com> <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F6@namail5.corp.adobe.com> From: "DRAGE, Keith \(Keith\)" To: "Henry Sinnreich" , , X-OriginalArrivalTime: 17 Jul 2007 18:58:56.0655 (UTC) FILETIME=[86E2C9F0:01C7C8A4] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.5 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: Cullen Jennings , behave@ietf.org, jon.peterson@neustar.biz Subject: [Sip] RE: [MMUSIC] ICE deployment data before LC for RFC X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A further word on this. Attempting to do any status change is going to create all sorts of downreferencing problems, which while not unresolvable, will certainly delay getting this out. In order to register a new SIP option tag, draft-ietf-sip-ice-option-tag must be a standards track document. RFC 3427 mandates this. Draft-ietf-sip-ice-option-tag normatively references draft-ietf-mmusic-ice. If the former is standards track and the latter is either informational or experimental, I understand that would be a down reference.=20 I was unable to fire up the reference dependency tool to find out what other intended standards track documents normatively referenced draft-ietf-mmusic-ice, but I suspect there are a number. I would therefore suggest you investigate the potential referencing impact further if you wish to proceed. Regards Keith > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 > Sent: Tuesday, July 17, 2007 7:48 PM > To: DRAGE, Keith (Keith); mmusic@ietf.org; sip@ietf.org > Cc: Cullen Jennings; jon.peterson@neustar.biz; behave@ietf.org > Subject: RE: [MMUSIC] ICE deployment data before LC for RFC >=20 > Keith, >=20 > Thanks for the attention and sorry our mail has crossed. >=20 > Feel free to proceed as you best think. (I have made my point=20 > as well). >=20 > Henry >=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Tuesday, July 17, 2007 10:56 AM > To: Henry Sinnreich; mmusic@ietf.org; sip@ietf.org > Cc: Cullen Jennings; jon.peterson@neustar.biz > Subject: RE: [MMUSIC] ICE deployment data before LC for RFC >=20 > As SIP WG chair and the document shepherd for=20 > draft-ietf-sip-ice-option-tag this is what I shall be doing=20 > with regard to the ancillary document in this process... >=20 > I went to RFC 2026 and carefully read the section on proposed=20 > standard: >=20 >=20 > 4.1.1 Proposed Standard >=20 > The entry-level maturity for the standards track is "Proposed > Standard". A specific action by the IESG is required to move a > specification onto the standards track at the "Proposed Standard" > level. >=20 > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood,=20 > has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. >=20 > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. However, such experience is highly desirable, and will > usually represent a strong argument in favor of a Proposed Standard > designation. >=20 > The IESG may require implementation and/or operational experience > prior to granting Proposed Standard status to a specification that > materially affects the core Internet protocols or that specifies > behavior that may have significant operational impact on the > Internet. >=20 > A Proposed Standard should have no known technical omissions with > respect to the requirements placed upon it. However, the IESG may > waive this requirement in order to allow a specification to advance > to the Proposed Standard state when it is considered to be=20 > useful and > necessary (and timely) even with known technical omissions. >=20 > Implementors should treat Proposed Standards as immature > specifications. It is desirable to implement them in order to gain > experience and to validate, test, and clarify the specification. > However, since the content of Proposed Standards may be changed if > problems are found or better solutions are identified, deploying > implementations of such standards into a disruption-sensitive > environment is not recommended. >=20 > My judgement is that at least the in terms of its draft, the=20 > SIP WG has fulfilled the requirements for a request to=20 > publish a proposed standard. > It appears to me that any further decision about=20 > implementation rests with the IESG, who should obviously take=20 > into account any submissions made during the IESG last call process. >=20 > It is therefore my intent to proceed with the publish request=20 > for draft-ietf-sip-ice-option-tag. >=20 > Regards >=20 > Keith >=20 >=20 > ________________________________ >=20 > From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 > Sent: Monday, July 16, 2007 11:38 PM > To: mmusic@ietf.org; sip@ietf.org > Cc: Cullen Jennings; jon.peterson@neustar.biz > Subject: [MMUSIC] ICE deployment data before LC for RFC > =09 > =09 >=20 > The work on ICE is truly impressive and so are the=20 > numerous I-Ds associated with ICE. >=20 > =20 >=20 > However, before sending the I-D for LC to the=20 > IESG, it would be prudent and responsible to the industry=20 > (that spends considerable resources on ICE in good faith)=20 > implementing ICE, to either > (1) make it an informational RFC or (2) publish some=20 > deployment data showing such items as: >=20 > =20 >=20 > * NAT scenarios that have been tested,=20 > * The % of success,=20 > * Performance, such as call setup delay using SIP.=20 >=20 > =20 >=20 > I have not seen any such public data on ICE deployment,=20 > for example with SIP. A private report has raised my concern=20 > about the performance of ICE. >=20 > =20 >=20 > In the best IETF tradition, it would also help to have=20 > open source code available for ICE, before declaring it a standard. >=20 > =20 >=20 > ICE is too important for the IETF (good work Jonathan and other > authors!) not to publish (1) deployment results and (2)=20 > publish open source code as well. >=20 > The various nits discussed on the lists are only of=20 > secondary importance to the LC compared to the above and=20 > would get resolved with such a process anyway. >=20 > =20 >=20 > These are my personal two cents. >=20 > Henry Sinnreich > =09 > =09 > =09 >=20 > =20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 17 15:04:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAsL4-0004HQ-51; Tue, 17 Jul 2007 15:04:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAsL3-0004HK-3J for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 15:04:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAsL2-0004H6-Oa for sip@ietf.org; Tue, 17 Jul 2007 15:04:00 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAsL1-00045O-D6 for sip@ietf.org; Tue, 17 Jul 2007 15:04:00 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6HJ3uQ01274; Tue, 17 Jul 2007 19:03:56 GMT 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, 17 Jul 2007 14:03:23 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF114CA20A@zrc2hxm0.corp.nortel.com> In-reply-to: <0D5F89FAC29E2C41B98A6A762007F5D02059C8@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments on sip-sips Thread-Index: AcfCKEx+ncUlBwX5SrqjW0d4TtdWnAF0OYBAABTOSsAAE5v4AA== References: <0D5F89FAC29E2C41B98A6A762007F5D02054B7@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF114C985A@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D02059C8@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Subject: [Sip] RE: WGLC comments on sip-sips X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks John. See below (I'm removing where we are in agreement).=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Tuesday, July 17, 2007 02:01 > To: Audet, Francois (SC100:3055); sip@ietf.org > Subject: RE: WGLC comments on sip-sips >=20 > Francois, >=20 > More below. I have stripped out the comments that have been=20 > satisfactorily dealt with. >=20 > John=20 >=20 > > > 8. In 4.1.1 "If a UA registers with a SIPS Contact header=20 > field, the=20 > > > registrar > > > returning a service route [RFC3608] MUST return a service route > > > consisting of SIP URIs if the intent of the registrar=20 > is to allow > > > both SIP and SIPS to be used in requests sent by that > > client. If a > > > UA registers with a SIPS Contact header field, the registrar > > > returning a service route MUST return a service route > > consisting of > > > SIPS URIs if the intent of the registrar is to allow > > only SIPS URIs > > > to be used in requests sent by that UA." > > > > > > Presumably the intention of this is to state that RFC 3608 places=20 > > > such a requirement on registrars. The language needs changing to=20 > > > reflect this. > >=20 > However, you didn't respond to the second part of my comment,=20 > concerning the need for a change of language. Thinking about=20 > this further, I now see that we are in fact updating RFC 3608=20 > - correct? If so, then don't we need to state this up front,=20 > and also mention it in the Introduction section where we=20 > mention RFC 3261? OK, I think you are right. It does in fact update 3608. I will fix it. > >=20 > > > 11. In 4.2 "It is RECOMMENDED to use an outbound proxy as per the=20 > > > procedures > > > defined in [I-D.ietf-sip-outbound] for supporting UACs > > that can not > > > provide a certificate for establishing a TLS connection > > (i.e., when > > > server-side authentication is used)." > > > This is a recommendation on a UA, not a proxy, so it does=20 > not belong=20 > > > as a normative statement in 4.2. > >=20 > > I'm not sure I agree on this. Seems like the decision to use or not=20 > > the procedures of sip-outbound in a proxy is a proxy=20 > requirement, not=20 > > a UA requirement. > [JRE] The words "It is RECOMMENDED to use an outbound proxy"=20 > sound to me like a recommendation on a UA, i.e., a=20 > recommendation that the UA be configured to use an outbound=20 > proxy. Perhaps what we are trying to say is "It is=20 > RECOMMENDED that a proxy be able to behave as an outbound=20 > proxy as per the procedures...", in which case it would=20 > indeed belong in this section. Ok, I'll fix as per your suggestion. > >=20 > > > 13. "When a redirect server receives a request with a SIP=20 > > > Request-URI, the > > > redirect server MAY redirect with a 3XX response to=20 > either a SIP=20 > > > or a > > > SIPS Contact header field. If the target UAS had registered > > > previously using a SIPS Contact header field, the=20 > redirect server > > > SHOULD return a SIPS Contact header field if it is in an=20 > > > environment > > > where TLS is usable (as described in the previous paragraph)." > > > This assumes that a redirect server is redirecting=20 > directly to a UA,=20 > > > i.e., to a contact. However, a redirect server can also=20 > redirect to=20 > > > another AoR that resolves to a domain proxy (or another redirect=20 > > > server). In other words, the redirect server may not have any=20 > > > knowledge of a "target UAS". > [JRE] You didn't answer this or make any changes. Do you=20 > consider that no change is necessary? Sorry, I missed that. I guess in that case you can redirect to whatever you want.=20 I'll make some changes. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 17 17:46:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAurv-0005A0-A4; Tue, 17 Jul 2007 17:46:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAuru-00059V-0g for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 17:46:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAurt-00059N-MD for sip@ietf.org; Tue, 17 Jul 2007 17:46:05 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAurs-0000AT-5H for sip@ietf.org; Tue, 17 Jul 2007 17:46:05 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6HLk0E04638; Tue, 17 Jul 2007 21:46:00 GMT 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 Subject: RE: [Sip] New draft modifying RFC 4412 for Responses Date: Tue, 17 Jul 2007 16:45:58 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF114CA5A1@zrc2hxm0.corp.nortel.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New draft modifying RFC 4412 for Responses Thread-Index: Ace/VMIjrZymwelJQoWRZk+A0FBdmwJZkMWg References: <1ECE0EB50388174790F9694F77522CCF10E7A7F6@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "James M. Polk" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > Sent: Thursday, July 05, 2007 15:35 > To: Audet, Francois (SC100:3055); sip@ietf.org > Subject: RE: [Sip] New draft modifying RFC 4412 for Responses >=20 > Francois >=20 > in-line >=20 > At 11:29 AM 6/18/2007, Francois Audet wrote: > >Hi James, > > > >It might be useful to have some wording on the limitations=20 > of using a=20 > >response to carry a Resource-Priority header in a response. >=20 > Do you have any text (or direction) to offer that you would=20 > want to see in this ID? Yes, something along the lines of the paragraph below: > >Specifically, a UAS can not use a response to carry the=20 > >Resource-Priority in cases where the Resource-Priority "absolutely=20 > >has" to be delivered to the UAC. It is therefore only useable for=20 > >cases where a forking proxy may discard the response (i.e., forward=20 > >another instead) without breaking anything. >=20 > I have to admit, I do not understand this use-case (as it is=20 > written), since I'm not sure what you are referring to when you say=20 > "..."absolutely has" to be delivered to the UAC". Right now, RPH=20 > isn't in any response, so when did it become a situation of=20 > "..."absolutely has" to be delivered...". What I mean is that the error response may not be delivered to the UAC because a forking proxy will only deliver one final response. If there are multiple error responses on the individual forks, one being the one with the RPH, and the other being some other response, it is up to the proxy to decide which one to forward back. So the UAC can not rely on receiving the RPH to "re-intiate" the session or provide some alternative treatment. This may or may not be a problem depending on the application (that's why I said "if it absolutely has"). > Remind me what HERFP is again... HERFP is the problem described above. It stands for "Heterogeneous Error Response Forking Problem". > >In other words,you need to think about HERFP before using this draft. > > > >In some scenarios, this is probably the desired behavior. > > > >In other scenarios, it may not acceptable. So instead, for=20 > those scenarios, > >the terminating side would have to send a new request with a=20 > >Resource-Priority > >instead of using a response. What I'm looking for is just a description of the limitation of using a response for carrying the information, in order to alert the implementors. I'm not looking for a solution to the HERFP problem in this draft. > > > > > > > -----Original Message----- > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > Sent: Saturday, June 16, 2007 14:14 > > > To: sip@ietf.org > > > Subject: [Sip] New draft modifying RFC 4412 for Responses > > > > > > SIP WG > > > > > > Here is a new ID I've written because of implementation > > > considerations to allow a SIP Resource-Priority header (RPH) > > > in responses, which RFC 4412 currently disallows, assuming > > > only that stateful devices will use RPH. There have been > > > many requests to have this "only stateful devices" > > > restriction relaxed, in certain scenarios. This ID does > > > this, and proposes how IANA is changed accordingly wrt RPH. > > > This ID does nothing else. > > > > > > Comments are appreciated. > > > > > > >A New Internet-Draft is available from the on-line=20 > Internet-Drafts > > > >directories. > > > > > > > > Title : Allowing SIP Resource=20 > Priority Header in > > > > SIP Responses > > > > Author(s) : J. Polk > > > > Filename : draft-polk-sip-rph-in-responses-00.txt > > > > Pages : 6 > > > > Date : 2007-6-15 > > > > > > > > The Session Initiation Protocol (SIP) Resource=20 > Priority Header > > > > (RPH), in its current form, is ignored in SIP responses. > > > This was a > > > > design choice during RFC 4412's development. This is now > > > considered > > > > a bad design choice in certain scenarios. This=20 > document corrects > > > > RFC 4412's communications model by optionally allowing a > > > SIP server > > > > or user agent client to process the=20 > Resource-Priority Header in a > > > > response. > > > > > > > >A URL for this Internet-Draft is: > > > >http://www.ietf.org/internet-drafts/draft-polk-sip-rph-in-res > > > ponses-00. > > > >txt > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the=20 > application of sip > > > >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 17 22:20:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAz9W-0005Ix-Dl; Tue, 17 Jul 2007 22:20:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IAz9V-0005Im-QP for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 22:20:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAz9V-0005Ie-GP for sip@ietf.org; Tue, 17 Jul 2007 22:20:33 -0400 Received: from mail86.messagelabs.com ([216.82.244.115]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IAz9U-0007Dq-9w for sip@ietf.org; Tue, 17 Jul 2007 22:20:33 -0400 X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-3.tower-86.messagelabs.com!1184725229!53919726!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [20.137.52.151] Received: (qmail 30226 invoked from network); 18 Jul 2007 02:20:29 -0000 Received: from amer-mta07.csc.com (HELO amer-mta07.csc.com) (20.137.52.151) by server-3.tower-86.messagelabs.com with AES256-SHA encrypted SMTP; 18 Jul 2007 02:20:29 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id l6I2Khv9002448 for ; Tue, 17 Jul 2007 22:20:43 -0400 (EDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF114CA5A1@zrc2hxm0.corp.nortel.com> To: "Francois Audet" Subject: RE: [Sip] New draft modifying RFC 4412 for Responses MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Tue, 17 Jul 2007 22:20:26 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1 HF180|March 29, 2007) at 07/17/2007 10:19:11 PM, Serialize complete at 07/17/2007 10:19:11 PM X-Spam-Score: -4.0 (----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1506127008==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1506127008== Content-Type: multipart/alternative; boundary="=_alternative 000CDB298525731C_=" This is a multipart message in MIME format. --=_alternative 000CDB298525731C_= Content-Type: text/plain; charset="US-ASCII" "Francois Audet" wrote on 07/17/2007 05:45:58 PM: > > What I mean is that the error response may not be delivered to the UAC > because a forking proxy will only deliver one final response. If there > are multiple error responses on the individual forks, one being the one > with the RPH, and the other being some other response, it is up to the > proxy to decide which one to forward back. > > So the UAC can not rely on receiving the RPH to "re-intiate" the session > or > provide some alternative treatment. This may or may not be a problem > depending > on the application (that's why I said "if it absolutely has"). > I don't think that will be a problem. For one thing (for the namespaces I am working with) the expectation would be that ALL the responses (except 100 and 403) would have the RPH on the response, so it wouldn't matter which one made it back to the UAC. Secondly, the expectation is that the devices responsible for "re-initiating" WOULD be stateful, and not dependant on the information in the RPH in the response. It is the intervening devices that might not be stateful, and would take advantage of the RPH information in the responses. Janet > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --=_alternative 000CDB298525731C_= Content-Type: text/html; charset="US-ASCII"



        "Francois Audet" <audet@nortel.com> wrote on 07/17/2007 05:45:58 PM:

        >
        > What I mean is that the error response may not be delivered to the UAC
        > because a forking proxy will only deliver one final response. If there
        > are multiple error responses on the individual forks, one being the one
        > with the RPH, and the other being some other response, it is up to the
        > proxy to decide which one to forward back.
        >
        > So the UAC can not rely on receiving the RPH to "re-intiate" the session
        > or
        > provide some alternative treatment. This may or may not be a problem
        > depending
        > on the application (that's why I said "if it absolutely has").
        >

        I don't think that will be a problem.

        For one thing (for the namespaces I am working with) the expectation would be that ALL the responses (except 100 and 403) would have the RPH on the response, so it wouldn't matter which one made it back to the UAC.

        Secondly, the expectation is that the devices responsible for "re-initiating" WOULD be stateful, and not dependant on the information in the RPH in the response.  It is the intervening devices that might not be stateful, and would take advantage of the RPH information in the responses.

        Janet
        > _______________________________________________
        > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
        > This list is for NEW development of the core SIP Protocol
        > Use sip-implementors@cs.columbia.edu for questions on current sip
        > Use sipping@ietf.org for new developments on the application of sip
         --=_alternative 000CDB298525731C_=-- --===============1506127008== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1506127008==-- From sip-bounces@ietf.org Tue Jul 17 23:30:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB0F6-0002kJ-SA; Tue, 17 Jul 2007 23:30:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IB0F5-0002kB-95 for sip-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 23:30:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB0F4-0002k3-VW for sip@ietf.org; Tue, 17 Jul 2007 23:30:22 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IB0F2-0000NG-QN for sip@ietf.org; Tue, 17 Jul 2007 23:30:22 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLC00E8XV19B4@szxga04-in.huawei.com> for sip@ietf.org; Wed, 18 Jul 2007 11:29:33 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLC00776V19OT@szxga04-in.huawei.com> for sip@ietf.org; Wed, 18 Jul 2007 11:29:33 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLC00EYQV15XP@szxml03-in.huawei.com> for sip@ietf.org; Wed, 18 Jul 2007 11:29:33 +0800 (CST) Date: Wed, 18 Jul 2007 11:29:29 +0800 From: Qian Sun Subject: RE: [Sip] Comments on draft-ietf-sip-subnot-etags-00 In-reply-to: <469C9168.4060907@nokia.com> To: 'Aki Niemi' Message-id: <003601c7c8eb$d99e04b0$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Thread-index: AcfIWD9q1JLE/EyTTgS3YX3hknVmsQAjtKYg X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Aki, As I know, OMA PAG has adopted both filtering and this subnot-etags, maybe some companies are developing their products according to OMA specification. Cheers, Qian -----Original Message----- From: Aki Niemi [mailto:aki.niemi@nokia.com] Sent: Tuesday, July 17, 2007 5:53 PM To: ext Qian Sun Cc: 'IETF SIP List' Subject: Re: [Sip] Comments on draft-ietf-sip-subnot-etags-00 Hi Qian, And sorry for a late answer to your comment. I have been on vacation enjoying the beautiful Finnish summer. ;) ext Qian Sun wrote: > Hi, I am not sure whether the following description in this draft is > enough for the usage of Entity-tags with filtering. > > "5.1. Generating Entity-tags The views might correspond to different > groups of users that have varying levels of access rights to the > resource state, or to subscribers that have modified their > subscription using event notification filtering [11]." > > My consideration is: If a subscriber has a subscription with filter > F1, the current corresponding entity-tag is E1. Then the same > subscriber MUST NOT send SUBSCRIBE with a new filter F2 and the > entity-tag E1 in the conditional header field. i.e., if a subscriber > changes filter for an event state, the Suppress-XXX-If-Match should > not be used. The client of subscriber has to record the last filter > for event state and compare filters. If I understand your concern correctly, the problem is with filtering and not with subnot-etags. I think a subscription that installs a filter, or disables/removes it could effectively be an action that itself changes the event state, and causes an if-match condition to fail. But this all depends on the actual implementation of the filtering system. In other words, this seems like an implementation detail of the filtering system. At the moment, I am not aware of any existing filtering implementations, so I'm reluctant to adding any specific text to the draft either. If this becomes a problem, we can always write an update to the filtering specifications. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 02:54:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB3QZ-0002yy-My; Wed, 18 Jul 2007 02:54:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IB3QW-0002yh-Tf for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 02:54:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB3QT-0002yK-LM for sip@ietf.org; Wed, 18 Jul 2007 02:54:21 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IB3QS-0005Zu-5k for sip@ietf.org; Wed, 18 Jul 2007 02:54:21 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6I6s5gY003079; Wed, 18 Jul 2007 09:54:14 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 09:53:14 +0300 Received: from esebe106.NOE.Nokia.com ([172.21.143.51]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 09:53:14 +0300 Received: from [172.21.41.35] ([172.21.41.35]) by esebe106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 09:53:13 +0300 Message-ID: <469DB8DA.6050309@nokia.com> Date: Wed, 18 Jul 2007 09:53:14 +0300 From: Aki Niemi Organization: Nokia User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: ext Qian Sun Subject: Re: [Sip] Comments on draft-ietf-sip-subnot-etags-00 References: <003601c7c8eb$d99e04b0$7c6c460a@china.huawei.com> In-Reply-To: <003601c7c8eb$d99e04b0$7c6c460a@china.huawei.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2007 06:53:13.0916 (UTC) FILETIME=[4FCDD7C0:01C7C908] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Qian, ext Qian Sun wrote: > Hi Aki, > > As I know, OMA PAG has adopted both filtering and this subnot-etags, > maybe some companies are developing their products according to OMA > specification. If that's the case then would this be something for which the OMA PAG specifications could maybe provide some clarification? Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 04:10:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB4cS-0001gB-O6; Wed, 18 Jul 2007 04:10:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IB4cR-0001fO-Dz for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 04:10:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB4cR-0001f5-2L; Wed, 18 Jul 2007 04:10:47 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IB4cP-0000Th-2l; Wed, 18 Jul 2007 04:10:46 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4F5D1215D8; Wed, 18 Jul 2007 10:10:44 +0200 (CEST) X-AuditID: c1b4fb3e-b1036bb0000007e1-61-469dcb042312 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 27FA6204A6; Wed, 18 Jul 2007 10:10:44 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 10:10:43 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 10:10:43 +0200 Message-ID: <469DCB03.9040300@ericsson.com> Date: Wed, 18 Jul 2007 10:10:43 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Henry Sinnreich References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2007 08:10:43.0584 (UTC) FILETIME=[2338E000:01C7C913] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: sip@ietf.org, behave@ietf.org, mmusic@ietf.org Subject: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Henry Sinnreich skrev: > Following some discussions and soul searching, the best approach for > ICE-17 for LC would be to _go ahead and make it an experimental RFC_. > > This would support the development of interoperable implementations, the > collection of deployment data and also hopefully open source code. > > Though I have full faith in ICE, following the practices that made the > IETF successful take precedent here, I believe. > > This is a change from the attached that I wrote on 7/16/2007. > > Note: We can only hope the proliferation of SBC in VoIP service provider > networks will not make these concerns and ICE for SIP a moot issue, but > this is another topic. Henry, I don't quite understand why you are requesting a status change of ICE? To me it appears that ICE is almost finished spec. It has been implemented, used and feedback has been influencing the protocol. It is definitly one of the better examples of current IETF work that actually has running code. Sure, the implementations may not be fully updated yet to the latest draft version. But I think it is safe to say that ICE works in the intended core cases. If there are some corner cases where it fails, that may be. But that is not information we will have until really large scale deployement or someone makes very extensive tests. I think the IETF and the Internet has much more benefit from a standards track solution than any of the risks existing with ICE of today. And to be clear, proposed standard is allowed to be published without a single implementation exists. It might not be good practice, but it is allowed by our process. And as I said before ICE has had enough implementation that I am very confortable in balloting YES for it when it appears on the IESGs table. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 07:30:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB7jn-0004UQ-OW; Wed, 18 Jul 2007 07:30:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IB7jk-0004TA-3G for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 07:30:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB7jj-0004SP-8e for sip@ietf.org; Wed, 18 Jul 2007 07:30:31 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IB7jf-0006l1-9K for sip@ietf.org; Wed, 18 Jul 2007 07:30:31 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EECA521714; Wed, 18 Jul 2007 13:29:20 +0200 (CEST) X-AuditID: c1b4fb3e-b1036bb0000007e1-02-469df9900848 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D013321712; Wed, 18 Jul 2007 13:29:20 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 13:29:20 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 13:29:20 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0E73C23F6; Wed, 18 Jul 2007 14:29:20 +0300 (EEST) Message-ID: <469DF98F.3060506@ericsson.com> Date: Wed, 18 Jul 2007 14:29:19 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2007 11:29:20.0235 (UTC) FILETIME=[E21983B0:01C7C92E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Keith Drage , Dean Willis Subject: [Sip] Draft slides for body (MIME) handling X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Folks, here you have the slides I have put together for the body (MIME) handling presentation on Monday: http://users.piuha.net/gonzalo/temp/ietf69-sip-camarillo-body-handling.ppt These slides relate to this draft: http://www.ietf.org/internet-drafts/draft-camarillo-sip-body-handling-01.txt The slides discuss all the open issues that have been brought up in the list in the last months. Comments are welcome. Thanks, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 10:20:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBAOY-0000Wa-Vh; Wed, 18 Jul 2007 10:20:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBAOV-0000M9-M1 for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 10:20:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBAOT-0000ED-Ta; Wed, 18 Jul 2007 10:20:45 -0400 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBAOS-0002QK-2I; Wed, 18 Jul 2007 10:20:45 -0400 Received: from source ([192.150.20.142]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Wed, 18 Jul 2007 07:20:36 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6IEKWWs012870; Wed, 18 Jul 2007 07:20:32 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6IEKT0g004802; Wed, 18 Jul 2007 07:20:31 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 07:20:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jul 2007 07:20:23 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com> In-Reply-To: <469DCB03.9040300@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJEybT1Lqyu4kbSgaZUq/KUlGECAAK8hkg References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> <469DCB03.9040300@ericsson.com> From: "Henry Sinnreich" To: "Magnus Westerlund" X-OriginalArrivalTime: 18 Jul 2007 14:20:30.0725 (UTC) FILETIME=[CBC9EB50:01C7C946] X-Spam-Score: -4.0 (----) X-Scan-Signature: 0c92ca299e0607fbf0058472806b19df Cc: sip@ietf.org, behave@ietf.org, mmusic@ietf.org Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1324514164==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1324514164== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C946.CB4C2FCF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C946.CB4C2FCF Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Magnus, =20 I sincerely appreciate your interest and this note! =20 > I don't quite understand why you are requesting a status change of ICE =20 However the arguments stated by the WG co-chairs and by you here are procedural in nature, whereas the facts are some cause for serious concern, and I will just mention a few facts: =20 RFC 3489 (STUN) was also presented as a NAT traversal solution back in 2003, but now clearly admits that "STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution." http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-07.txt My guess is, in plain English, RFC 3489 turned out just NOT to be an acceptable solution as it was hoped to be.=20 =20 The excellent I-D shows the ICE call flow with two endpoints behind two NAT (Fig. 22 on page 38) require 66 messages just for the SIP INVITE! http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-07. txt=20 What happens if the two endpoints are in different ISPs that have NAT of their own in addition to the ones in Fig. 22? What happens if one would try ICE along a P2PSIP route with say 5-8 hops? Would there be hundreds of messages? What is the likelihood for failure? =20 By contrast with such approaches based on hope and faith, the BEHAVE WG has produced work based on real measurements and tools to do the measurements, such as =20 "NAT Classification Test Results" =20 "Application Design Guidelines for Traversal through Network Address Translators"=20 The measurements for hole punching are reported in "Peer-to-Peer Communication Across Network Address Translators"=20 http://www.brynosaurus.com/pub/net/p2pnat/ =20 I am also a believer in ICE and have actually urged Jonathan Rosenberg to do this work and he has given his best. Now that we have ICE-17 version, it is in the best interest of the industry and the IETF to make it an experimental RFC, but not yet a standard so that: 1. Independent, compliant implementations will be developed, 2. Testing in events such as SIPit, 3. Reporting the results, such as reported for the "hole punching" above. =20 What happens if indeed hole punching proves to be the far more effective approach? =20 The industry can ill afford a new series of RFC[ICE]-bis and all the years it takes to move from believing to measuring and proving. I am sure IETF procedures were meant in this spirit (though I am not good in producing the right quotes). =20 Thanks again for your attention to this concern about ICE.=20 Also my apology to all the anguish to the numerous contributors to the ICE related I-Ds, but writing test tools and reporting measurements is the right way to go. =20 Henry =20 =20 -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Wednesday, July 18, 2007 1:11 AM To: Henry Sinnreich Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC =20 Henry Sinnreich skrev: > Following some discussions and soul searching, the best approach for > ICE-17 for LC would be to _go ahead and make it an experimental RFC_. >=20 > This would support the development of interoperable implementations, the > collection of deployment data and also hopefully open source code. >=20 > Though I have full faith in ICE, following the practices that made the > IETF successful take precedent here, I believe. >=20 > This is a change from the attached that I wrote on 7/16/2007. >=20 > Note: We can only hope the proliferation of SBC in VoIP service provider > networks will not make these concerns and ICE for SIP a moot issue, but > this is another topic. =20 Henry, =20 I don't quite understand why you are requesting a status change of ICE?=20 To me it appears that ICE is almost finished spec. It has been=20 implemented, used and feedback has been influencing the protocol. It is=20 definitly one of the better examples of current IETF work that actually=20 has running code. Sure, the implementations may not be fully updated yet to the latest draft version. But I think it is safe to say that ICE=20 works in the intended core cases. If there are some corner cases where=20 it fails, that may be. But that is not information we will have until=20 really large scale deployement or someone makes very extensive tests. =20 I think the IETF and the Internet has much more benefit from a standards track solution than any of the risks existing with ICE of today. =20 And to be clear, proposed standard is allowed to be published without a=20 single implementation exists. It might not be good practice, but it is=20 allowed by our process. And as I said before ICE has had enough=20 implementation that I am very confortable in balloting YES for it when=20 it appears on the IESGs table. =20 Cheers =20 Magnus Westerlund =20 IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- ------_=_NextPart_001_01C7C946.CB4C2FCF Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

        Magnus,

         

        I sincerely appreciate your interest and this = note!

         

        > I don't quite understand why you are requesting a status = change of ICE

         

        However the arguments stated by the WG co-chairs and by you here are procedural in nature, whereas = the facts are some cause for serious concern, and I will just mention a few = facts:

         

        RFC 3489 (STUN) was also presented as a NAT traversal solution = back in 2003, but <draft-ietf-behave-rfc3489bis-07> now clearly admits = that "STUN is not a NAT traversal solution by itself. Rather, it is a tool to be = used in the context of a NAT traversal solution. This is an important change = from the previous version of this specification (RFC 3489), which presented STUN = as a complete solution."

        http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-= 07.txt

        My guess is, in plain English, RFC 3489 turned out just NOT to = be an acceptable solution as it was hoped to be.

         

        The excellent I-D <draft-ietf-sipping-nat-scenarios-07> = shows the ICE call flow with two endpoints behind two NAT (Fig. 22 on page 38) = require 66 messages just for the SIP INVITE!

        http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-sc= enarios-07.txt

        What happens if the two endpoints are in different ISPs that = have NAT of their own in addition to the ones in Fig. = 22?

        What happens if one would try ICE along a P2PSIP route with say = 5-8 hops? Would there be hundreds of messages? What is the likelihood for = failure?

         

        By contrast with such approaches based on hope and faith, the = BEHAVE WG has produced work based on real measurements and tools to do the = measurements, such as

         

        "NAT Classification Test = Results"

         

        "Application Design Guidelines for Traversal through = Network Address Translators"

        The measurements for hole punching are reported = in

        "Peer-to-Peer Communication Across Network Address Translators"

        http://www.brynosauru= s.com/pub/net/p2pnat/

         

        I am also a believer in ICE and have actually urged Jonathan Rosenberg to do = this work and he has given his best. Now that we have ICE-17 version, it is in the = best interest of the industry and the IETF to make it an experimental RFC, but not yet = a standard so that:

         1. Independent, compliant implementations will be = developed,

         2. Testing in events such as = SIPit,

         3. Reporting the results, such as reported for the = "hole punching" above.

         

        What happens if indeed hole punching proves to be the far more effective approach?

         

        The industry can ill afford a new series of RFC[ICE]-bis and all = the years it takes to move from believing to measuring and proving. I am = sure IETF procedures were meant in this spirit (though I am not good in producing = the right quotes).

         

        Thanks again for your attention to this concern about ICE. =

        Also my apology to all the anguish to the numerous contributors = to the ICE related I-Ds, but writing test tools and reporting measurements is = the right way to go.

         

        Henry

         

         

        -----Original Message-----
        From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
        Sent: Wednesday, July 18, 2007 1:11 AM
        To: Henry Sinnreich
        Cc: mmusic@ietf.org; sip@ietf.org; = behave@ietf.org
        Subject: Re: [BEHAVE] Re: ICE deployment data before LC for = RFC

         

        Henry = Sinnreich skrev:

        > Following some discussions and soul searching, the best = approach for

        > ICE-17 for LC would be to _go ahead and make it an = experimental RFC_.

        >

        > This would support the development of interoperable implementations, the

        > collection of deployment data and also hopefully open = source code.

        >

        > Though I have full faith in ICE, following the practices = that made the

        > IETF successful take precedent here, I = believe.

        >

        > This is a change from the attached that I wrote on = 7/16/2007.

        >

        > Note: We can only hope the proliferation of SBC in VoIP = service provider

        > networks will not make these concerns and ICE for SIP a = moot issue, but

        > this is another topic.

         

        Henry,

         

        I don't quite understand why you are requesting a status change = of ICE?

        To me it appears that ICE is almost finished spec. It has been =

        implemented, used and feedback has been influencing the = protocol. It is

        definitly one of the better examples of current IETF work that = actually

        has running code. Sure, the implementations may not be fully = updated yet

        to the latest draft version. But I think it is safe to say that = ICE

        works in the intended core cases. If there are some corner cases = where

        it fails, that may be. But that is not information we will have = until

        really large scale deployement or someone makes very extensive = tests.

         

        I think the IETF and the Internet has much more benefit from a standards

        track solution than any of the risks existing with ICE of = today.

         

        And to be clear, proposed standard is allowed to be published = without a

        single implementation exists. It might not be good practice, but = it is

        allowed by our process. And as I said before ICE has had enough =

        implementation that I am very confortable in balloting YES for = it when

        it appears on the IESGs table.

         

        Cheers

         

        Magnus Westerlund

         

        IETF Transport Area Director & TSVWG = Chair

        -----------------------------------------------------------------= -----

        Multimedia Technologies, Ericsson Research = EAB/TVM/M

        -----------------------------------------------------------------= -----

        Ericsson AB      = ;          | Phone +46 8 4048287

        Torshamsgatan 23           | = Fax   +46 8 7575550

        S-164 80 Stockholm, Sweden | mailto: = magnus.westerlund@ericsson.com

        -----------------------------------------------------------------= -----

        ------_=_NextPart_001_01C7C946.CB4C2FCF-- --===============1324514164== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1324514164==-- From sip-bounces@ietf.org Wed Jul 18 10:39:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBAgg-0000v2-0C; Wed, 18 Jul 2007 10:39:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBAgd-0000uo-SO for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 10:39:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBAgd-0000ug-9g for sip@ietf.org; Wed, 18 Jul 2007 10:39:31 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBAgb-0003xj-QR for sip@ietf.org; Wed, 18 Jul 2007 10:39:31 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Jul 2007 10:39:29 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0KAKbCnUZAZnme/2dsb2JhbACIWp4i X-IronPort-AV: i="4.16,550,1175486400"; d="scan'208"; a="126379029:sNHT32167364" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6IEdTeF021222; Wed, 18 Jul 2007 10:39:29 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6IEdKWa020246; Wed, 18 Jul 2007 14:39:25 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 10:39:23 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 10:39:23 -0400 Message-ID: <469E261B.7090804@cisco.com> Date: Wed, 18 Jul 2007 10:39:23 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [Sip] Draft slides for body (MIME) handling References: <469DF98F.3060506@ericsson.com> In-Reply-To: <469DF98F.3060506@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2007 14:39:23.0407 (UTC) FILETIME=[6EEB79F0:01C7C949] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3572; t=1184769569; x=1185633569; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20Draft=20slides=20for=20body=20(MIME)=20handli ng |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=O3pw/s6j8rh9dFMuabxkFSH8KEAal9Py3PnVaqhJi/Q=; b=BczYXXjFOidPGdXogSFhcfYSRZ1qPAVb0so2G/Vy/xmioBEhJgzHSxe1KuTCpWjmYBfuVEYG vuze4PDMkV/3eRzTDSCv+7lw2AdYjI17gEQ0SquG+3jhk+b9sAjc4Fgd; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sip , Keith Drage , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks for sending out in advance. Maybe we can get into the discussion of the slides now, before the meeting. Regarding references to body parts: IMO it is a *bad* idea to make the decision about processing of a body part "on its own" dependent on whether the node doing so has detected a reference to that body part or not. For one thing, that requires a multi-pass parsing mechanism to check for references before deciding what processing to do on a particular part. For another, it requires that the recipient understand every reference. For instance, the sender may have included an extension header that contains a reference to a body part. If the extension isn't understood, then the body part should not be processed. But if the recipient doesn't understand the extension then it won't recognize the reference either, and so will attempt to process the body part as one without references. The only good solution I see to this is to partition the Content-Disposition and/or Content-Type values whose processing is dependent on reference from those whose processing is not dependent on a reference. For instance, we could simply define a new Content-Disposition of "by-reference". Then a normal sequence of processing would be to first process all the body parts according to their type and disposition alone. Any with disposition "by-reference" would be set aside. Then, when processing headers, if a header with a reference is encountered the appropriate processing could be applied to the set aside body part. References within other body parts would be a little more complex, but you get the idea. This would not prevent reference to body parts with other dispositions. It just means that those body parts would also be processed according to their type and disposition, in addition to any processing they might get according to their reference. The "by-reference" disposition is just a defintion that gets no implicit processing. An advantage of this approach is that by-reference body parts don't need to be parsed unless the reference is processed and the action required in processing the reference requires the node to parse the referenced body. (Interaction with handling=required in this case is TBD.) Even a multipart with disposition of by-reference might not need to be parsed. Regarding Content-Disposition in multiparts: While it seems "wrong" to me, I can live with using "render" as the normal disposition for multipart, *if* we can do a careful job of defining what "render" actually means for SIP. Used this way it clearly doesn't always mean to display the content to a user. Thanks, Paul Gonzalo Camarillo wrote: > Folks, > > here you have the slides I have put together for the body (MIME) > handling presentation on Monday: > > http://users.piuha.net/gonzalo/temp/ietf69-sip-camarillo-body-handling.ppt > > These slides relate to this draft: > > http://www.ietf.org/internet-drafts/draft-camarillo-sip-body-handling-01.txt > > > The slides discuss all the open issues that have been brought up in the > list in the last months. > > Comments are welcome. > > Thanks, > > Gonzalo > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 10:53:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBAuP-0000NK-Fh; Wed, 18 Jul 2007 10:53:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBAuM-0000N1-SA for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 10:53:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBAuM-0000Ms-F4; Wed, 18 Jul 2007 10:53:42 -0400 Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBAuK-0003FJ-Jn; Wed, 18 Jul 2007 10:53:42 -0400 Received: from cornfed (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id 3E9A5758069; Wed, 18 Jul 2007 09:53:39 -0500 (CDT) From: "Frank W. Miller" To: "'Henry Sinnreich'" , "'Magnus Westerlund'" Subject: RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 08:53:30 -0600 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com> Thread-Index: AcfJEybT1Lqyu4kbSgaZUq/KUlGECAAK8hkgAAKU9CA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Message-Id: <20070718145339.3E9A5758069@smtpauth00.csee.onr.siteprotect.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3c3f5218b222da1e73e850f1438da613 Cc: sip@ietf.org, behave@ietf.org, mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0328304926==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0328304926== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CF_01C7C919.1DDFF390" This is a multi-part message in MIME format. ------=_NextPart_000_00CF_01C7C919.1DDFF390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings, What I think Henry is advocating is a systematic approach to making sure that the content of the ICE spec is right for its intended purpose, i.e. a complete, general NAT traversal solution. NAT traversal has been in my opinion one of the most difficult aspects of SIP implementation and its very important that its eventual standardized solution be right. I know I spent a lot of time implementing all the "tests" in the first 3489, only to discover that they were not that useful. There are two valid technical concerns that are put forth in this email: 1) Viability of correct operation in practical implementations. ICE can result in very complicated message transfers. 2) Performance. As pointed out in this email and in other places, the additional latency associated with ICE operations can be significant. Henry also points out that there are competing approaches (e.g. Hole Punching) that can perform well in many situations and have better performance. IMHO, another approach by the IETF in general would be to standardize on Hole Punching and leverage the IETF's considerable influence to force NAT vendors to migrate towards implementations that are friendly to Hole Punching. The bottom line is that I agree with Henry in that labeling ICE as an experimental draft is the right thing to do. It will allow those implementing ICE (including myself in all likelihood) to proceed but signals to the users the correct status of the standard's contents. I also want to applaud loudly the underlying tone of Henry's thread here. That is, in solving specific technical problems within the IETF forum, focusing on empirical observation of working implementations should be the MO that we all strive for when developing and proposing what may become protocol standards. Thanks, FM _____ From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Wednesday, July 18, 2007 8:20 AM To: Magnus Westerlund Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Magnus, I sincerely appreciate your interest and this note! > I don't quite understand why you are requesting a status change of ICE However the arguments stated by the WG co-chairs and by you here are procedural in nature, whereas the facts are some cause for serious concern, and I will just mention a few facts: RFC 3489 (STUN) was also presented as a NAT traversal solution back in 2003, but now clearly admits that "STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution." http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-07.txt My guess is, in plain English, RFC 3489 turned out just NOT to be an acceptable solution as it was hoped to be. The excellent I-D shows the ICE call flow with two endpoints behind two NAT (Fig. 22 on page 38) require 66 messages just for the SIP INVITE! http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-07.txt What happens if the two endpoints are in different ISPs that have NAT of their own in addition to the ones in Fig. 22? What happens if one would try ICE along a P2PSIP route with say 5-8 hops? Would there be hundreds of messages? What is the likelihood for failure? By contrast with such approaches based on hope and faith, the BEHAVE WG has produced work based on real measurements and tools to do the measurements, such as "NAT Classification Test Results" "Application Design Guidelines for Traversal through Network Address Translators" The measurements for hole punching are reported in "Peer-to-Peer Communication Across Network Address Translators" http://www.brynosaurus.com/pub/net/p2pnat/ I am also a believer in ICE and have actually urged Jonathan Rosenberg to do this work and he has given his best. Now that we have ICE-17 version, it is in the best interest of the industry and the IETF to make it an experimental RFC, but not yet a standard so that: 1. Independent, compliant implementations will be developed, 2. Testing in events such as SIPit, 3. Reporting the results, such as reported for the "hole punching" above. What happens if indeed hole punching proves to be the far more effective approach? The industry can ill afford a new series of RFC[ICE]-bis and all the years it takes to move from believing to measuring and proving. I am sure IETF procedures were meant in this spirit (though I am not good in producing the right quotes). Thanks again for your attention to this concern about ICE. Also my apology to all the anguish to the numerous contributors to the ICE related I-Ds, but writing test tools and reporting measurements is the right way to go. Henry -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Sent: Wednesday, July 18, 2007 1:11 AM To: Henry Sinnreich Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC Henry Sinnreich skrev: > Following some discussions and soul searching, the best approach for > ICE-17 for LC would be to _go ahead and make it an experimental RFC_. > > This would support the development of interoperable implementations, the > collection of deployment data and also hopefully open source code. > > Though I have full faith in ICE, following the practices that made the > IETF successful take precedent here, I believe. > > This is a change from the attached that I wrote on 7/16/2007. > > Note: We can only hope the proliferation of SBC in VoIP service provider > networks will not make these concerns and ICE for SIP a moot issue, but > this is another topic. Henry, I don't quite understand why you are requesting a status change of ICE? To me it appears that ICE is almost finished spec. It has been implemented, used and feedback has been influencing the protocol. It is definitly one of the better examples of current IETF work that actually has running code. Sure, the implementations may not be fully updated yet to the latest draft version. But I think it is safe to say that ICE works in the intended core cases. If there are some corner cases where it fails, that may be. But that is not information we will have until really large scale deployement or someone makes very extensive tests. I think the IETF and the Internet has much more benefit from a standards track solution than any of the risks existing with ICE of today. And to be clear, proposed standard is allowed to be published without a single implementation exists. It might not be good practice, but it is allowed by our process. And as I said before ICE has had enough implementation that I am very confortable in balloting YES for it when it appears on the IESGs table. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- ------=_NextPart_000_00CF_01C7C919.1DDFF390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

         

        Greetings,<= /p>

         

        What I think Henry is advocating is = a systematic approach to making sure that the content of the ICE spec is = right for its intended purpose, i.e. a complete, general NAT traversal = solution.  NAT traversal has been in my opinion one of the most difficult aspects = of SIP implementation and its very important that its eventual standardized = solution be right.  I know I spent a lot of time implementing all the = “tests” in the first 3489, only to discover that they were not that = useful.  There are two valid technical concerns that are put forth in this = email:

         

        1)     = Viability of correct operation in practical implementations.  ICE can result in very complicated message transfers.

        2)     = Performance.  As pointed out in this email and in other places, the additional latency associated with ICE operations can be = significant.

         

        Henry also points out that there = are competing approaches (e.g. Hole Punching) that can perform well in many situations and have better performance.  IMHO, another approach by = the IETF in general would be to standardize on Hole Punching and leverage = the IETF’s considerable influence to force NAT vendors to migrate towards = implementations that are friendly to Hole Punching.

         

        The bottom line is that I agree = with Henry in that labeling ICE as an experimental draft is the right thing to = do.  It will allow those implementing ICE (including myself in all = likelihood) to proceed but signals to the users the correct status of the standard’s = contents.

         

        I also want to applaud loudly the underlying tone of Henry’s thread here.  That is, in solving specific technical problems within the IETF forum, focusing on empirical = observation of working implementations should be the MO that we all strive for when developing and proposing what may become protocol = standards.

         

        Thanks,

        =

        FM

         

         

        From: Henry = Sinnreich [mailto:hsinnrei@adobe.com]
        Sent: Wednesday, July 18, = 2007 8:20 AM
        To: Magnus Westerlund
        Cc: sip@ietf.org; = behave@ietf.org; mmusic@ietf.org
        Subject: [Sip] RE: = [BEHAVE] Re: ICE deployment data before LC for RFC

         

        Magnus,

         

        I sincerely appreciate your interest and this = note!

         

        > I don't quite understand why you are requesting a status = change of ICE

         

        However the arguments stated by the WG co-chairs and by you here are procedural in nature, whereas = the facts are some cause for serious concern, and I will just mention a few = facts:

         

        RFC 3489 (STUN) was also presented as a NAT traversal solution = back in 2003, but <draft-ietf-behave-rfc3489bis-07> now clearly admits = that "STUN is not a NAT traversal solution by itself. Rather, it is a = tool to be used in the context of a NAT traversal solution. This is an important = change from the previous version of this specification (RFC 3489), which = presented STUN as a complete solution."

        http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-= 07.txt

        My guess is, in plain English, RFC 3489 turned out just NOT to = be an acceptable solution as it was hoped to be.

         

        The excellent I-D <draft-ietf-sipping-nat-scenarios-07> = shows the ICE call flow with two endpoints behind two NAT (Fig. 22 on page 38) = require 66 messages just for the SIP INVITE!

        http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-sc= enarios-07.txt

        What happens if the two endpoints are in different ISPs that = have NAT of their own in addition to the ones in Fig. = 22?

        What happens if one would try ICE along a P2PSIP route with say = 5-8 hops? Would there be hundreds of messages? What is the likelihood for = failure?

         

        By contrast with such approaches based on hope and faith, the = BEHAVE WG has produced work based on real measurements and tools to do the = measurements, such as

         

        "NAT Classification Test = Results"

         

        "Application Design Guidelines for Traversal through = Network Address Translators"

        The measurements for hole punching are reported = in

        "Peer-to-Peer Communication Across Network Address Translators"

        http://www.brynosauru= s.com/pub/net/p2pnat/

         

        I am also a believer in ICE and have actually urged Jonathan Rosenberg to do = this work and he has given his best. Now that we have ICE-17 version, it is in the = best interest of the industry and the IETF to make it an experimental RFC, = but not yet a standard so that:

         1. Independent, compliant implementations will be = developed,

         2. Testing in events such as = SIPit,

         3. Reporting the results, such as reported for the = "hole punching" above.

         

        What happens if indeed hole punching proves to be the far more effective approach?

         

        The industry can ill afford a new series of RFC[ICE]-bis and all = the years it takes to move from believing to measuring and proving. I am = sure IETF procedures were meant in this spirit (though I am not good in producing = the right quotes).

         

        Thanks again for your attention to this concern about ICE. =

        Also my apology to all the anguish to the numerous contributors = to the ICE related I-Ds, but writing test tools and reporting measurements is = the right way to go.

         

        Henry

         

         

        -----Original Message-----
        From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
        Sent: Wednesday, July 18, 2007 1:11 AM
        To: Henry Sinnreich
        Cc: mmusic@ietf.org; sip@ietf.org; = behave@ietf.org
        Subject: Re: [BEHAVE] Re: ICE deployment data before LC for = RFC

         

        Henry = Sinnreich skrev:

        > Following some discussions and soul searching, the best = approach for

        > ICE-17 for LC would be to _go ahead and make it an = experimental RFC_.

        >

        > This would support the development of interoperable implementations, the

        > collection of deployment data and also hopefully open = source code.

        >

        > Though I have full faith in ICE, following the practices = that made the

        > IETF successful take precedent here, I = believe.

        >

        > This is a change from the attached that I wrote on = 7/16/2007.

        >

        > Note: We can only hope the proliferation of SBC in VoIP = service provider

        > networks will not make these concerns and ICE for SIP a = moot issue, but

        > this is another topic.

         

        Henry,

         

        I don't quite understand why you are requesting a status change = of ICE?

        To me it appears that ICE is almost finished spec. It has been =

        implemented, used and feedback has been influencing the = protocol. It is

        definitly one of the better examples of current IETF work that = actually

        has running code. Sure, the implementations may not be fully = updated yet

        to the latest draft version. But I think it is safe to say that = ICE

        works in the intended core cases. If there are some corner cases = where

        it fails, that may be. But that is not information we will have = until

        really large scale deployement or someone makes very extensive = tests.

         

        I think the IETF and the Internet has much more benefit from a standards

        track solution than any of the risks existing with ICE of = today.

         

        And to be clear, proposed standard is allowed to be published = without a

        single implementation exists. It might not be good practice, but = it is

        allowed by our process. And as I said before ICE has had enough =

        implementation that I am very confortable in balloting YES for = it when

        it appears on the IESGs table.

         

        Cheers

         

        Magnus Westerlund

         

        IETF Transport Area Director & TSVWG = Chair

        -----------------------------------------------------------------= -----

        Multimedia Technologies, Ericsson Research = EAB/TVM/M

        -----------------------------------------------------------------= -----

        Ericsson AB      = ;          | Phone +46 8 4048287

        Torshamsgatan 23           | Fax   +46 8 7575550

        S-164 80 Stockholm, Sweden | mailto: = magnus.westerlund@ericsson.com

        -----------------------------------------------------------------= -----

        ------=_NextPart_000_00CF_01C7C919.1DDFF390-- --===============0328304926== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0328304926==-- From sip-bounces@ietf.org Wed Jul 18 11:27:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBBQd-0007EJ-Vq; Wed, 18 Jul 2007 11:27:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBBQd-0007D3-67 for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 11:27:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBBQc-00079j-Mj for sip@ietf.org; Wed, 18 Jul 2007 11:27:02 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBBQc-0004Fv-A7 for sip@ietf.org; Wed, 18 Jul 2007 11:27:02 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6IFQxI27150; Wed, 18 Jul 2007 15:26:59 GMT 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 Subject: RE: [Sip] New draft modifying RFC 4412 for Responses Date: Wed, 18 Jul 2007 10:26:54 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1151A644@zrc2hxm0.corp.nortel.com> In-reply-to: <1ECE0EB50388174790F9694F77522CCF1151A5F7@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New draft modifying RFC 4412 for Responses Thread-Index: AcfI4pDh6QJVsd9OSSecXVV/AC9RsAAa24uwAAA/TjA= References: <1ECE0EB50388174790F9694F77522CCF114CA5A1@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1151A5F7@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Janet P Gunn" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: sip@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > What I mean is that the error response may not be delivered=20 > to the UAC=20 > > because a forking proxy will only deliver one final=20 > response. If there=20 > > are multiple error responses on the individual forks, one being the=20 > > one with the RPH, and the other being some other response,=20 > it is up to=20 > > the proxy to decide which one to forward back. > >=20 > > So the UAC can not rely on receiving the RPH to "re-intiate" the=20 > > session or provide some alternative treatment. This may or=20 > may not be=20 > > a problem depending on the application (that's why I said "if it=20 > > absolutely has"). > >=20 >=20 > I don't think that will be a problem.=20 >=20 > For one thing (for the namespaces I am working with) the=20 > expectation would be that ALL the responses (except 100 and=20 > 403) would have the RPH on the response, so it wouldn't=20 > matter which one made it back to the UAC.=20 I am not talking about multiple provisional responses from the same endpoint. I am talking about multiple responses (provisional and final) from=20 multiple forks. For example, multiple 4XX responses. While it is possible that a single forking proxy may decide to=20 include the RPH in all responses, that proxy has absolutely no=20 control over downstream and upstream proxies who may not include it (they may be proxies in different domains). That's the point I'm trying to make. You can not enforce the=20 presence RPH in responses in a global system. > Secondly, the expectation is that the devices responsible for=20 > "re-initiating" WOULD be stateful, and not dependant on the=20 > information in the RPH in the response. It is the=20 > intervening devices that might not be stateful, and would=20 > take advantage of the RPH information in the responses.=20 That is precisely the type of clarfication that needs to be included in the draft. It points out the constrainsts of the mechanism so=20 implementors use the feature properly. Some text explaining that the UAC needs to be able to deal with the RPH not being present in responses gracefully (and why) is needed. Similar text for proxies also need to be there. What if a proxy=20 forwards a request with RPH and it receives nultiple responses from the downstream proxies, with some including the RPH and others not including it? Does this need to be standardized? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 12:13:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBC96-0003Z9-Dr; Wed, 18 Jul 2007 12:13:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBC91-0003Fj-SH for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 12:12:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBC90-0003D0-FT; Wed, 18 Jul 2007 12:12:55 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBC8y-0006mc-Qd; Wed, 18 Jul 2007 12:12:54 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.101]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1IBC8x-0005M0-FG; Wed, 18 Jul 2007 11:12:51 -0500 In-Reply-To: <469DCB03.9040300@ericsson.com> References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> <469DCB03.9040300@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 11:12:27 -0500 To: Magnus Westerlund X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: sip@ietf.org, Henry Sinnreich , behave@ietf.org, mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 18, 2007, at 3:10 AM, Magnus Westerlund wrote: > Henry Sinnreich skrev: >> Following some discussions and soul searching, the best approach for >> ICE-17 for LC would be to _go ahead and make it an experimental RFC_. >> This would support the development of interoperable >> implementations, the >> collection of deployment data and also hopefully open source code. >> Though I have full faith in ICE, following the practices that made >> the >> IETF successful take precedent here, I believe. >> This is a change from the attached that I wrote on 7/16/2007. >> Note: We can only hope the proliferation of SBC in VoIP service >> provider >> networks will not make these concerns and ICE for SIP a moot >> issue, but >> this is another topic. > > Henry, > > I don't quite understand why you are requesting a status change of > ICE? To me it appears that ICE is almost finished spec. It has been > implemented, used and feedback has been influencing the protocol. > It is definitly one of the better examples of current IETF work > that actually has running code. Sure, the implementations may not > be fully updated yet to the latest draft version. But I think it is > safe to say that ICE works in the intended core cases. If there are > some corner cases where it fails, that may be. But that is not > information we will have until really large scale deployement or > someone makes very extensive tests. Henry has, I believe, been very consistent in urging the IETF to have more "running code" experience on every specification (not just ICE) than our process requires. He has, IIRC, also advocated changing the process to require running code before publishing an RFC. He's even suggested at times that one should have running code before submitting a protocol draft. Another point to consider -- I've known Henry to bark at a tree with no squirrel in it occasionally, but most of the time he's pretty reliable, more so than most technology predictors. If he's worried about ICE, it's probably because he's been talking to people who are trying to implement it and they're telling him it is difficult or that they're having performance or reliability issues. I imagine that there are plenty of internal development teams in various companies that are working on this and not necessarily bringing their results back to the IETF. After all, if everybody sees the emperor as fully clothed, they'd be embarrassed to proclaim otherwise. Of course, I wish all of these developers were tied into the IETF, but then I'm sure I don't want to see every ice-implementor's question on the SIP list. That is why we have a sip-implementors mailing list, right? Personally, I think ICE is the best solution we have. We KNOW of cases where hole-punching doesn't work, and I think ICE will produce usable results in most of those cases. But that's just my personal opinion from reading the specs. I haven't implemented ICE, and I haven't used anybody else's implementation. Sure, it's complex, but that's because the underlying problem is complex -- there are just too many different behaviors out there in "NAT and firewall land". Of course, I could be wrong, too. It's happened before, once or twice ;-). Just how sure are we that we're right about this? Are we designing a "spruce goose" or a practical system? Only experience will tell us. But some good flight reports from the prototypes could go a long way towards reassuring us of the design's utility. So far we've had a couple of people report hearsay evidence -- that somebody else has an ICE implementation and it works. Any of you folks have personal experience you can share? Have there been prototypes exercised at the interop events? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 12:17:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCDK-0006Pd-OM; Wed, 18 Jul 2007 12:17:22 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBCDK-0006PX-3w for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 12:17:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCDJ-0006PP-Mi for sip@ietf.org; Wed, 18 Jul 2007 12:17:21 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBCDH-0006ud-Kj for sip@ietf.org; Wed, 18 Jul 2007 12:17:21 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.101]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1IBCDG-0005ND-PJ for sip@ietf.org; Wed, 18 Jul 2007 11:17:19 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) To: IETF SIP List Message-Id: <4083A622-4D57-4C93-A767-91A860CF9287@softarmor.com> From: Dean Willis Date: Wed, 18 Jul 2007 11:16:54 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.7 (/) X-Scan-Signature: 6d231d878f8d68d85cf12b60d23450ce Subject: [Sip] latest draft, SIP agenda for IETF 69 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0873485770==" Errors-To: sip-bounces@ietf.org --===============0873485770== Content-Type: multipart/alternative; boundary=Apple-Mail-3-309784373 --Apple-Mail-3-309784373 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed For those of you who like agendas in email: SIP Agenda IETF 69 ] Session 1, Monday July 23 0900-1130 Red Lacquer Start Time Topic Discussion Lead Reading List 0900 Agenda Bash and Status Chairs This document 0915 SIPS WGLC Francois Audet draft-ietf-sip-sips-05.txt 0935 Outbound WGLC Rohan Mahy Cullen Jennings draft-ietf-sip-outbound-10.txt 1005 Delivering R-URI and Parameters to UA Jonathan Rosenberg draft-rosenberg-sip-ua-loose-route-01.txt 1040 Resource Priority Header Issues James Polk draft-polk-sip-rph-in-responses-00 draft-polk-sip-rph-new-namespaces-01.txt 1105 MIME Body Handling Gonzalo Camarillo draft-camarillo-sip-body-handling-01.txt 1130 End of Session Session 2, Tuesday July 24 0900-1130 Grand Ballroom Start Time Topic Discussion Lead Reading List 0900 Agenda Bash and Status Chairs This document 0905 Fork Loop Fix and Corrections Robert Sparks draft-ietf-sip-fork-loop-fix-05 draft-sparks-sipping-max-breadth-01 draft-drage-sip-essential-correction-01 0925 SAML Hannes Tschofenig Jeff Hodges draft-ietf-sip-saml-02 0945 eTags For Notification Aki Niemi draft-ietf-sip-subnot-etags-00.txt 1000 UA-Driven Privacy Mayumi Munakata draft-munakata-sip-privacy-new-01.txt 1020 Domain Certs Vijay Gurbani Scott Lawrence draft-gurbani-sip-domain-certs-06.txt 1045 Certificate Authentication Steve Dotson draft-dotson-sip-certificate-auth-03.txt 1100 INFO Considered Harmful Eric Burger draft-burger-sip-info-00 1115 Media identity Dan Wing draft-wing-sip-identity-media-00.txt 1130 End of session --Apple-Mail-3-309784373 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
        For those of you who like = agendas in email:

        SIP Agenda IETF 69

        ]

        Session 1, = Monday July 23 0900-1130 Red Lacquer

        <= TD valign=3D"middle" style=3D"width: 64.0px; margin: 0.0px 0.5px 0.0px = 0.5px; border-style: solid; border-width: 1.0px 1.0px 1.0px 1.0px; = border-color: #808080 #808080 #808080 #808080; padding: 0.0px 2.0px = 0.0px 2.0px">
        0935
        <= TR>
        Start Time
        Topic
        Discussion = Lead
        Reading = List
        0900
        Agenda Bash and Status
        Chairs
        This = document
        0915
        SIPS WGLC
        Francois Audet
        Outbound WGLC
        Rohan Mahy
        Cullen Jennings
        1005
        Delivering R-URI and Parameters to = UA
        Jonathan Rosenberg
        		=
        1040
        Resource Priority Header Issues
        James Polk

        draft-polk-sip-rph-new-namespaces-01.txt

        1105
        MIME Body = Handling
        Gonzalo Camarillo
        		<= /TD>
        1130
        End of Session



        Session 2, Tuesday July 24 0900-1130 Grand = Ballroom

        1115
        =
        Start = Time
        Topic
        Discussion = Lead
        Reading = List
        0900
        Agenda Bash and Status
        Chairs
        This = document
        0905
        Fork Loop Fix and Corrections
        Robert Sparks

        draft-sparks-sipping-max-breadth-01
        draft-drage-sip-essential-correction-01

        0925
        SAML
        Hannes Tschofenig=A0
        Jeff = Hodges
        0945
        eTags For = Notification
        Aki Niemi
        1000
        UA-Driven = Privacy
        Mayumi Munakata
        1020
        Domain Certs
        Vijay Gurbani
        Scott Lawrence
        1045
        Certificate = Authentication
        Steve Dotson
        		<= /TD>
        1100
        INFO Considered = Harmful
        Eric Burger
        Media identity
        Dan Wing
        1130
        End of session



        = --Apple-Mail-3-309784373-- --===============0873485770== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0873485770==-- From sip-bounces@ietf.org Wed Jul 18 12:27:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCMc-0008NN-9U; Wed, 18 Jul 2007 12:26:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBCMX-0008FT-5c for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 12:26:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCMW-0008Ew-2z; Wed, 18 Jul 2007 12:26:52 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBCMU-0005zP-QB; Wed, 18 Jul 2007 12:26:52 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IBCMO-0007sj-2C; Wed, 18 Jul 2007 12:26:45 -0400 In-Reply-To: <239224.19734.qm@web33301.mail.mud.yahoo.com> References: <239224.19734.qm@web33301.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 12:26:55 -0400 To: Pyda Srisuresh X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: fbe0995f04cc21309ef8614a2838e306 Cc: 'Magnus Westerlund' , behave@ietf.org, mmusic@ietf.org, sip@ietf.org, 'Henry Sinnreich' , "Frank W. Miller" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Frank, Henry, Suresh: I agree that ICE is a complex spec. I also agree that it would be =20 very interesting to see more data on which situations result in a direct path between =20 endpoints, as opposed to a path via a TURN server. However, I don't understand the comment that "Hole Punching =20 Techniques" are an alternative. In my view, ICE _is_ a "Hole Punching Technique". Perhaps you are referring to the use of STUN alone??? The problem with using STUN alone is that there are cases where using =20= the reflexive address doesn't work, and there is no way with STUN alone to determine when =20 an endpoint should or should not use a reflexive address. But perhaps you are referring to something else? - Philip On 18-Jul-07, at 11:37 , Pyda Srisuresh wrote: > Thanks to Henry and Frank for so eloquently articulating this. > > As both Henry and Frank mentioned, I fully support standardizing on =20= > HOLE > PUNCHING TECHNIQUE and leveraging the IETF=92s considerable influence =20= > to force > NAT vendors to migrate towards implementations that are friendly to =20= > Hole > Punching and the Application developers to design applications =20 > using the hole > punching techniques. That should be the FIRST order of priority. > > Yet, what is happening in BEHAVE WG is the other way around. Some =20 > people have > put their weight so heavily in favor of ICE that they asked to drop =20= > the work on > hole punching technique as WG item. THIS IS WRONG. I no longer see =20 > "NAT > Traveral application design guidelines" as BEHAVE WG milestone. > > Magnus - Can you explain why the IETF is not allowing HOLE PUNCHING =20= > TECHNIQUES > to move forward as a WG item? > > regards, > suresh > > --- "Frank W. Miller" wrote: > >> >> >> Greetings, >> >> >> >> What I think Henry is advocating is a systematic approach to =20 >> making sure >> that the content of the ICE spec is right for its intended =20 >> purpose, i.e. a >> complete, general NAT traversal solution. NAT traversal has been =20 >> in my >> opinion one of the most difficult aspects of SIP implementation =20 >> and its very >> important that its eventual standardized solution be right. I =20 >> know I spent >> a lot of time implementing all the "tests" in the first 3489, only to >> discover that they were not that useful. There are two valid =20 >> technical >> concerns that are put forth in this email: >> >> >> >> 1) Viability of correct operation in practical =20 >> implementations. ICE can >> result in very complicated message transfers. >> >> 2) Performance. As pointed out in this email and in other =20 >> places, the >> additional latency associated with ICE operations can be significant. >> >> >> >> Henry also points out that there are competing approaches (e.g. Hole >> Punching) that can perform well in many situations and have better >> performance. IMHO, another approach by the IETF in general would =20 >> be to >> standardize on Hole Punching and leverage the IETF's considerable =20 >> influence >> to force NAT vendors to migrate towards implementations that are =20 >> friendly to >> Hole Punching. >> >> >> >> The bottom line is that I agree with Henry in that labeling ICE as an >> experimental draft is the right thing to do. It will allow those >> implementing ICE (including myself in all likelihood) to proceed =20 >> but signals >> to the users the correct status of the standard's contents. >> >> >> >> I also want to applaud loudly the underlying tone of Henry's =20 >> thread here. >> That is, in solving specific technical problems within the IETF =20 >> forum, >> focusing on empirical observation of working implementations =20 >> should be the >> MO that we all strive for when developing and proposing what may =20 >> become >> protocol standards. >> >> >> >> Thanks, >> >> FM >> >> >> >> >> >> _____ >> >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] >> Sent: Wednesday, July 18, 2007 8:20 AM >> To: Magnus Westerlund >> Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org >> Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC >> >> >> >> Magnus, >> >> >> >> I sincerely appreciate your interest and this note! >> >> >> >>> I don't quite understand why you are requesting a status change =20 >>> of ICE >> >> >> >> However the arguments stated by the WG co-chairs and by you here are >> procedural in nature, whereas the facts are some cause for serious =20= >> concern, >> and I will just mention a few facts: >> >> >> >> RFC 3489 (STUN) was also presented as a NAT traversal solution =20 >> back in 2003, >> but now clearly admits that =20 >> "STUN is not a >> NAT traversal solution by itself. Rather, it is a tool to be used =20 >> in the >> context of a NAT traversal solution. This is an important change =20 >> from the >> previous version of this specification (RFC 3489), which presented =20= >> STUN as a >> complete solution." >> >> http://www.ietf.org/internet-drafts/draft-ietf-behave-=20 >> rfc3489bis-07.txt >> >> My guess is, in plain English, RFC 3489 turned out just NOT to be an >> acceptable solution as it was hoped to be. >> >> >> >> The excellent I-D shows the =20 >> ICE call >> flow with two endpoints behind two NAT (Fig. 22 on page 38) =20 >> require 66 >> messages just for the SIP INVITE! >> >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-=20 >> scenarios-07.txt >> >> What happens if the two endpoints are in different ISPs that have =20 >> NAT of >> their own in addition to the ones in Fig. 22? >> >> What happens if one would try ICE along a P2PSIP route with say =20 >> 5-8 hops? >> Would there be hundreds of messages? What is the likelihood for =20 >> failure? >> >> >> >> By contrast with such approaches based on hope and faith, the =20 >> BEHAVE WG has >> produced work based on real measurements and tools to do the =20 >> measurements, >> such as >> >> >> >> "NAT Classification Test Results" >> >> >> >> "Application Design Guidelines for Traversal through Network Address >> Translators" >> >> The measurements for hole punching are reported in >> >> "Peer-to-Peer Communication Across Network Address Translators" >> >> http://www.brynosaurus.com/pub/net/p2pnat/ >> >> >> >> I am also a believer in ICE and have actually urged Jonathan =20 >> Rosenberg to do >> this work and he has given his best. Now that we have ICE-17 =20 >> version, it is >> in the best interest of the industry and the IETF to make it an =20 >> experimental >> RFC, but not yet a standard so that: >> >> 1. Independent, compliant implementations will be developed, >> >> 2. Testing in events such as SIPit, >> >> 3. Reporting the results, such as reported for the "hole =20 >> punching" above. >> >> >> >> What happens if indeed hole punching proves to be the far more =20 >> effective >> approach? >> >> >> >> The industry can ill afford a new series of RFC[ICE]-bis and all =20 >> the years >> it takes to move from believing to measuring and proving. I am =20 >> sure IETF >> procedures were meant in this spirit (though I am not good in =20 >> producing the >> right quotes). >> >> >> >> Thanks again for your attention to this concern about ICE. >> >> Also my apology to all the anguish to the numerous contributors to =20= >> the ICE >> related I-Ds, but writing test tools and reporting measurements is =20= >> the right >> way to go. >> >> >> >> Henry >> >> >> >> >> >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Wednesday, July 18, 2007 1:11 AM >> To: Henry Sinnreich >> Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org >> Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC >> >> >> >> Henry Sinnreich skrev: >> >>> Following some discussions and soul searching, the best approach for >> >>> ICE-17 for LC would be to _go ahead and make it an experimental =20 >>> RFC_. >> >>> >> >>> This would support the development of interoperable =20 >>> implementations, the >> >>> collection of deployment data and also hopefully open source code. >> >>> >> >>> Though I have full faith in ICE, following the practices that =20 >>> made the >> >>> IETF successful take precedent here, I believe. >> >>> >> >>> This is a change from the attached that I wrote on 7/16/2007. >> >>> >> >>> Note: We can only hope the proliferation of SBC in VoIP service =20 >>> provider >> >>> networks will not make these concerns and ICE for SIP a moot =20 >>> issue, but >> >>> this is another topic. >> >> >> >> Henry, >> >> >> >> I don't quite understand why you are requesting a status change of =20= >> ICE? >> >> To me it appears that ICE is almost finished spec. It has been >> >> implemented, used and feedback has been influencing the protocol. =20 >> It is >> >> definitly one of the better examples of current IETF work that =20 >> actually >> >> has running code. Sure, the implementations may not be fully =20 >> updated yet >> >> to the latest draft version. But I think it is safe to say that ICE >> >> works in the intended core cases. If there are some corner cases =20 >> where >> >> it fails, that may be. But that is not information we will have until >> >> really large scale deployement or someone makes very extensive tests. >> >> >> >> I think the IETF and the Internet has much more benefit from a =20 >> standards >> >> track solution than any of the risks existing with ICE of today. >> >> >> >> And to be clear, proposed standard is allowed to be published =20 >> without a >> >> single implementation exists. It might not be good practice, but =20 >> it is >> >> allowed by our process. And as I said before ICE has had enough >> >> implementation that I am very confortable in balloting YES for it =20 >> when >> >> it appears on the IESGs table. >> >> >> >> Cheers >> >> >> >> Magnus Westerlund >> >> >> >> IETF Transport Area Director & TSVWG Chair >> >> ---------------------------------------------------------------------=20= >> - >> >> Multimedia Technologies, Ericsson Research EAB/TVM/M >> >> ---------------------------------------------------------------------=20= >> - >> >> Ericsson AB | Phone +46 8 4048287 >> >> Torshamsgatan 23 | Fax +46 8 7575550 >> >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> >> ---------------------------------------------------------------------=20= >> - >> >>> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave >> > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 13:41:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBDWN-0006Lb-Jj; Wed, 18 Jul 2007 13:41:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBDWM-0006Dz-5L for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 13:41:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBDWJ-0006Ag-VK for sip@ietf.org; Wed, 18 Jul 2007 13:41:05 -0400 Received: from mail145.messagelabs.com ([216.82.245.115]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBDWI-0000vd-CX for sip@ietf.org; Wed, 18 Jul 2007 13:41:03 -0400 X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-11.tower-145.messagelabs.com!1184780460!8392582!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [20.137.52.152] Received: (qmail 11617 invoked from network); 18 Jul 2007 17:41:00 -0000 Received: from amer-mta08.csc.com (HELO amer-mta08.csc.com) (20.137.52.152) by server-11.tower-145.messagelabs.com with AES256-SHA encrypted SMTP; 18 Jul 2007 17:41:00 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta08.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id l6IHf0E1007183 for ; Wed, 18 Jul 2007 13:41:00 -0400 (EDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1151A644@zrc2hxm0.corp.nortel.com> To: "Francois Audet" Subject: RE: [Sip] New draft modifying RFC 4412 for Responses MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Wed, 18 Jul 2007 13:40:57 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1 HF180|March 29, 2007) at 07/18/2007 01:39:42 PM, Serialize complete at 07/18/2007 01:39:42 PM X-Spam-Score: 0.5 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: sip@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0928750057==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0928750057== Content-Type: multipart/alternative; boundary="=_alternative 006121BD8525731C_=" This is a multipart message in MIME format. --=_alternative 006121BD8525731C_= Content-Type: text/plain; charset="US-ASCII" In line. "Francois Audet" wrote on 07/18/2007 11:26:54 AM: > > > What I mean is that the error response may not be delivered > > to the UAC > > > because a forking proxy will only deliver one final > > response. If there > > > are multiple error responses on the individual forks, one being the > > > one with the RPH, and the other being some other response, > > it is up to > > > the proxy to decide which one to forward back. > > > > > > So the UAC can not rely on receiving the RPH to "re-intiate" the > > > session or provide some alternative treatment. This may or > > may not be > > > a problem depending on the application (that's why I said "if it > > > absolutely has"). > > > > > > > I don't think that will be a problem. > > > > For one thing (for the namespaces I am working with) the > > expectation would be that ALL the responses (except 100 and > > 403) would have the RPH on the response, so it wouldn't > > matter which one made it back to the UAC. > > I am not talking about multiple provisional responses from the same > endpoint. > > I am talking about multiple responses (provisional and final) from > multiple forks. For example, multiple 4XX responses. Yes, I understood that. > > While it is possible that a single forking proxy may decide to > include the RPH in all responses, that proxy has absolutely no > control over downstream and upstream proxies who may not include it > (they may be proxies in different domains). > > That's the point I'm trying to make. You can not enforce the > presence RPH in responses in a global system. Agree. For the context I am working in, a "global system" is not of concern. I would not expect universal "RPH in responses" in a global system. > > > Secondly, the expectation is that the devices responsible for > > "re-initiating" WOULD be stateful, and not dependant on the > > information in the RPH in the response. It is the > > intervening devices that might not be stateful, and would > > take advantage of the RPH information in the responses. > > That is precisely the type of clarification that needs to be included > in the draft. It points out the constraints of the mechanism so > implementors use the feature properly. > > Some text explaining that the UAC needs to be able to deal with the RPH > not being present in responses gracefully (and why) is needed. I am not sure why that needs to be in the ID. It is an implementation specific issue. Since RFC 4412, as currently published, forbids RPH in responses, I think it "goes without saying" that "the UAC needs to be able to deal with the RPH not being present in responses". Further, while I know that the systems (and namespaces) _I_ work with intend to use RPH in responses, I also have been told that other systems (using other namespaces) do not intend to put RPH in ANY responses. I do not think there is any need to standardize this aspect, just to adjust the standard so it is PERMITTED. > > Similar text for proxies also need to be there. What if a proxy > forwards a request with RPH and it receives nultiple responses from > the downstream proxies, with some including the RPH and others not > including it? Does this need to be standardized? Again, I do not think there is a need to standardize this aspect. Janet > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --=_alternative 006121BD8525731C_= Content-Type: text/html; charset="US-ASCII"

        In line.

        "Francois Audet" <audet@nortel.com> wrote on 07/18/2007 11:26:54 AM:

        > > > What I mean is that the error response may not be delivered
        > > to the UAC
        > > > because a forking proxy will only deliver one final
        > > response. If there
        > > > are multiple error responses on the individual forks, one being the
        > > > one with the RPH, and the other being some other response,
        > > it is up to
        > > > the proxy to decide which one to forward back.
        > > >
        > > > So the UAC can not rely on receiving the RPH to "re-intiate" the
        > > > session or provide some alternative treatment. This may or
        > > may not be
        > > > a problem depending on the application (that's why I said "if it
        > > > absolutely has").
        > > >
        > >
        > > I don't think that will be a problem.
        > >
        > > For one thing (for the namespaces I am working with) the
        > > expectation would be that ALL the responses (except 100 and
        > > 403) would have the RPH on the response, so it wouldn't
        > > matter which one made it back to the UAC.
        >
        > I am not talking about multiple provisional responses from the same
        > endpoint.
        >
        > I am talking about multiple responses (provisional and final) from
        > multiple forks. For example, multiple 4XX responses.

        Yes, I understood that.
        >
        > While it is possible that a single forking proxy may decide to
        > include the RPH in all responses, that proxy has absolutely no
        > control over downstream and upstream proxies who may not include it
        > (they may be proxies in different domains).
        >
        > That's the point I'm trying to make. You can not enforce the
        > presence RPH in responses in a global system.

        Agree. For the context I am working in, a "global system" is not of concern.  I would not expect universal "RPH in responses" in a global system.

        >
        > > Secondly, the expectation is that the devices responsible for
        > > "re-initiating" WOULD be stateful, and not dependant on the
        > > information in the RPH in the response.  It is the
        > > intervening devices that might not be stateful, and would
        > > take advantage of the RPH information in the responses.
        >
        > That is precisely the type of clarification that needs to be included
        > in the draft. It points out the constraints of the mechanism so
        > implementors use the feature properly.
        >
        > Some text explaining that the UAC needs to be able to deal with the RPH
        > not being present in responses gracefully (and why) is needed.

        I am not sure why that needs to be in the ID.  It is an implementation specific issue.  

        Since  RFC 4412, as currently published, forbids RPH in responses, I think it "goes without saying" that "the UAC needs to be able to deal with the RPH not being present in responses".

        Further, while I know that the systems (and namespaces) _I_ work with intend to use RPH in responses, I also have been told that other systems (using other namespaces) do not intend to put RPH in ANY responses.  I do not think there is any need to standardize this aspect, just to adjust the standard so it is PERMITTED.
        >
        > Similar text for proxies also need to be there. What if a proxy
        > forwards a request with RPH and it receives nultiple responses from
        > the downstream proxies, with some including the RPH and others not
        > including it? Does this need to be standardized?

        Again, I do not think there is a need to standardize this aspect.

        Janet
        >
        >
        > _______________________________________________
        > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
        > This list is for NEW development of the core SIP Protocol
        > Use sip-implementors@cs.columbia.edu for questions on current sip
        > Use sipping@ietf.org for new developments on the application of sip
         --=_alternative 006121BD8525731C_=-- --===============0928750057== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0928750057==-- From sip-bounces@ietf.org Wed Jul 18 14:19:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBE76-000086-UW; Wed, 18 Jul 2007 14:19:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBE75-000079-IC for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 14:19:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBE74-00006Q-QW; Wed, 18 Jul 2007 14:19:02 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBE73-00027p-J0; Wed, 18 Jul 2007 14:19:02 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 18 Jul 2007 11:19:00 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAM70nUarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,551,1175497200"; d="scan'208"; a="184397965:sNHT27953127" 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 l6IIJ0Hn023569; Wed, 18 Jul 2007 11:19:00 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6IIIxSb020950; Wed, 18 Jul 2007 18:19:00 GMT From: "Dan Wing" To: "'Henry Sinnreich'" , "'Magnus Westerlund'" Date: Wed, 18 Jul 2007 11:18:59 -0700 Message-ID: <08c801c7c968$1d1cd8c0$7d646b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com> Thread-Index: AcfJEybT1Lqyu4kbSgaZUq/KUlGECAAK8hkgAAmXLLA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4270; t=1184782740; x=1185646740; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Re=3A=20ICE=20deployment=20data=20before=2 0LC=20for=20RFC |Sender:=20; bh=2FWmfcMe0lUELpsCxRsiCfzJ5DQboIhP+QFWUpycxao=; b=rc1LY+x6P63Ju+iYeB0a+kHKDV/Y+Btd9EZzd2kDBor6bTDjwsRx93b1hhYdCs4eIaI/Hf2+ ebSY7CI6aMrC17UqVJYClcarL0C74Jc613LxV5f5lHEJVzAZKDCRj9hkCeKUIbwxT2ks9lojAl D4JQuevyEdpgVJsBJA5HYl43s=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: sip@ietf.org, behave@ietf.org, mmusic@ietf.org Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > The excellent I-D shows > the ICE call flow with two endpoints behind two NAT (Fig. 22 > on page 38) require 66 messages just for the SIP INVITE! > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-sce > narios-07.txt That figure does not show 66 messages. That figure is clearly showing how the STUN messages are NATted, which leads to an incorrect conclusion around the number of messages. Specifically, for example, it shows this message exchange which might be counted as "four messages"; yet, there are only two messages (the allocate request and the allocate response), which are NATted: L NAT STUN Server | | | |(1) Alloc Req | | |Src=L-PRIV-1 | | |Dest=STUN-PUB-1 | | |--------------->| | | | | | |(2) Alloc Req | | |Src=L-NAT-PUB-1 | | |Des=STUN-PUB-1 | | |--------------->| | | | | |(3) Alloc Resp | | |<---------------| | |Src=STUN-PUB-1 | | |Dest=L-NAT-PUB-1| | |Map=L-NAT-PUB-1 | | |Rel=STUN-PUB-2 | | | | |(4) Alloc Resp | | |<---------------| | |Src=STUN-PUB-1 | | |Dest=L-PRIV-1 | | |Map=L-NAT-PUB-1 | | |Rel=STUN-PUB-2 | | | | | If we added another NAT on that path, the number of messages on the network does not double. The number of messages on the network stays the same -- the messages merely have their IP and UDP headers rewritten by the NATs. That NAT function does not increase the number of messages on the network. Similarly, another message shown in that same figure is also one message; however, it's shown as two messages: L NAT STUN NAT R Server |(9) SIP INVITE | | | | |------------------------------------------------->| | | | | |(10) SIP INVITE | | | | |--------------->| As you know, there aren't two messages -- it's one message that is NATted. If message 9 and 10 were shown as clearly as messages 1-4, messages 9-10 would be shown as four messages (one from L to its NAT, another from NAT to NAT, and the forth (shown) from NAT to R). But this is just one SIP message, which is NATted. It is inaccurate to count it as two separate messages or as four separate messages, because it is only one packet that is NATted. Counting a STUN packet, or a DNS packet, as a separate message each time it traverses a NAT is similarly inaccurate. By my count, figure 22 exchanges 24 STUN/ICE messages and 6 SIP messages. > What happens if the two endpoints are in different ISPs that > have NAT of their own in addition to the ones in Fig. 22? The same 24 STUN/ICE messages would be exchanged, and the same 6 SIP messages would be exchanged. > What happens if one would try ICE along a P2PSIP route with > say 5-8 hops? The SIP signaling messages would traverse those 5-8 additional hops between the P2PSIP nodes participating in the SIP proxy overlay. The STUN/ICE messages are sent peer-to-peer, and would remain the same 24 messages if you're doing the same Figure 22 flow. > Would there be hundreds of messages? No. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 14:59:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBEjh-0002Sj-3K; Wed, 18 Jul 2007 14:58:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBEjf-0002SY-5Y for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 14:58:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBEje-0002SQ-Q6 for sip@ietf.org; Wed, 18 Jul 2007 14:58:54 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBEjd-00039p-Ln for sip@ietf.org; Wed, 18 Jul 2007 14:58:54 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6IIwoI03358; Wed, 18 Jul 2007 18:58:51 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] New draft modifying RFC 4412 for Responses Date: Wed, 18 Jul 2007 13:58:39 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1151AB0D@zrc2hxm0.corp.nortel.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New draft modifying RFC 4412 for Responses Thread-Index: AcfJYuJ3IV+mWiCRRPqdG6nzmQteEgACoq6w References: <1ECE0EB50388174790F9694F77522CCF1151A644@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Janet P Gunn" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Cc: sip@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0847721399==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0847721399== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C96D.A7BD1C8E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C96D.A7BD1C8E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I will be happy if the document is revised to explain that you cannot expect that responses received by a UAC or Proxy will necessarily include RPM, in particular in systems where forking occurs, and that therefore, applications that use this draft must take it into account. ________________________________ From: Janet P Gunn [mailto:jgunn6@csc.com]=20 Sent: Wednesday, July 18, 2007 10:41 To: Audet, Francois (SC100:3055) Cc: sip@ietf.org; James M. Polk Subject: RE: [Sip] New draft modifying RFC 4412 for Responses =09 =09 =09 In line.=20 =09 "Francois Audet" wrote on 07/18/2007 11:26:54 AM: =09 > > > What I mean is that the error response may not be delivered=20 > > to the UAC=20 > > > because a forking proxy will only deliver one final=20 > > response. If there=20 > > > are multiple error responses on the individual forks, one being the=20 > > > one with the RPH, and the other being some other response, > > it is up to=20 > > > the proxy to decide which one to forward back. > > >=20 > > > So the UAC can not rely on receiving the RPH to "re-intiate" the=20 > > > session or provide some alternative treatment. This may or > > may not be=20 > > > a problem depending on the application (that's why I said "if it=20 > > > absolutely has"). > > >=20 > >=20 > > I don't think that will be a problem.=20 > >=20 > > For one thing (for the namespaces I am working with) the=20 > > expectation would be that ALL the responses (except 100 and=20 > > 403) would have the RPH on the response, so it wouldn't=20 > > matter which one made it back to the UAC.=20 >=20 > I am not talking about multiple provisional responses from the same > endpoint. >=20 > I am talking about multiple responses (provisional and final) from=20 > multiple forks. For example, multiple 4XX responses.=20 =09 Yes, I understood that. >=20 > While it is possible that a single forking proxy may decide to > include the RPH in all responses, that proxy has absolutely no > control over downstream and upstream proxies who may not include it > (they may be proxies in different domains). >=20 > That's the point I'm trying to make. You can not enforce the=20 > presence RPH in responses in a global system.=20 =09 Agree. For the context I am working in, a "global system" is not of concern. I would not expect universal "RPH in responses" in a global system.=20 =09 >=20 > > Secondly, the expectation is that the devices responsible for=20 > > "re-initiating" WOULD be stateful, and not dependant on the=20 > > information in the RPH in the response. It is the=20 > > intervening devices that might not be stateful, and would=20 > > take advantage of the RPH information in the responses.=20 >=20 > That is precisely the type of clarification that needs to be included > in the draft. It points out the constraints of the mechanism so=20 > implementors use the feature properly. >=20 > Some text explaining that the UAC needs to be able to deal with the RPH > not being present in responses gracefully (and why) is needed. =09 I am not sure why that needs to be in the ID. It is an implementation specific issue. =20 =09 Since RFC 4412, as currently published, forbids RPH in responses, I think it "goes without saying" that "the UAC needs to be able to deal with the RPH not being present in responses".=20 =09 Further, while I know that the systems (and namespaces) _I_ work with intend to use RPH in responses, I also have been told that other systems (using other namespaces) do not intend to put RPH in ANY responses. I do not think there is any need to standardize this aspect, just to adjust the standard so it is PERMITTED. >=20 > Similar text for proxies also need to be there. What if a proxy=20 > forwards a request with RPH and it receives nultiple responses from > the downstream proxies, with some including the RPH and others not > including it? Does this need to be standardized?=20 =09 Again, I do not think there is a need to standardize this aspect.=20 =09 Janet >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip =09 ------_=_NextPart_001_01C7C96D.A7BD1C8E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
        I will be happy if the document is revised to = explain that=20 you cannot expect that responses received by a UAC or Proxy will=20 necessarily include RPM, in particular in systems where forking occurs, = and that=20 therefore, applications that use this draft must take it into=20 account.

        From: Janet P Gunn = [mailto:jgunn6@csc.com]=20
        Sent: Wednesday, July 18, 2007 10:41
        To: Audet, = Francois=20 (SC100:3055)
        Cc: sip@ietf.org; James M. = Polk
        Subject: RE:=20 [Sip] New draft modifying RFC 4412 for Responses



        In line.         =

        "Francois Audet" <audet@nortel.com> wrote on = 07/18/2007=20 11:26:54 AM:

        > > > What I mean is that the error = response may=20 not be delivered
        > > to the UAC
        > > > because a = forking=20 proxy will only deliver one final
        > > response. If there =
        >=20 > > are multiple error responses on the individual forks, one = being the=20
        > > > one with the RPH, and the other being some other = response,=20
        > > it is up to
        > > > the proxy to decide which = one to=20 forward back.
        > > >
        > > > So the UAC can not = rely on=20 receiving the RPH to "re-intiate" the
        > > > session or = provide=20 some alternative treatment. This may or
        > > may not be =
        > >=20 > a problem depending on the application (that's why I said "if it =
        >=20 > > absolutely has").
        > > >
        > >
        > = > I=20 don't think that will be a problem.
        > >
        > > For = one thing=20 (for the namespaces I am working with) the
        > > expectation = would be=20 that ALL the responses (except 100 and
        > > 403) would have = the RPH=20 on the response, so it wouldn't
        > > matter which one made it = back to=20 the UAC.
        >
        > I am not talking about multiple provisional = responses from the same
        > endpoint.
        >
        > I am = talking about=20 multiple responses (provisional and final) from
        > multiple = forks. For=20 example, multiple 4XX responses.

        Yes, I=20 understood that.
        >
        > While it is possible that a single = forking=20 proxy may decide to
        > include the RPH in all responses, that = proxy has=20 absolutely no
        > control over downstream and upstream proxies = who may=20 not include it
        > (they may be proxies in different = domains).
        >=20
        > That's the point I'm trying to make. You can not enforce the =
        >=20 presence RPH in responses in a global system.         =

        Agree. For the context I am working in, a "global system" = is not of=20 concern.  I would not expect universal "RPH in responses" in a = global=20 system.

        >
        > > = Secondly, the=20 expectation is that the devices responsible for
        > > = "re-initiating"=20 WOULD be stateful, and not dependant on the
        > > information = in the=20 RPH in the response.  It is the
        > > intervening devices = that=20 might not be stateful, and would
        > > take advantage of the = RPH=20 information in the responses.
        >
        > That is precisely the = type of=20 clarification that needs to be included
        > in the draft. It = points out=20 the constraints of the mechanism so
        > implementors use the = feature=20 properly.
        >
        > Some text explaining that the UAC needs to = be able=20 to deal with the RPH
        > not being present in responses gracefully = (and=20 why) is needed.

        I am not sure = why that=20 needs to be in the ID.  It is an implementation specific issue.=20  

        Since  RFC 4412, as = currently=20 published, forbids RPH in responses, I think it "goes without saying" = that=20 "the UAC needs to be able to deal with the RPH not being present in=20 responses".

        Further, while I = know that=20 the systems (and namespaces) _I_ work with intend to use RPH in = responses, I=20 also have been told that other systems (using other namespaces) do not = intend=20 to put RPH in ANY responses.  I do not think there is any need to = standardize this aspect, just to adjust the standard so it is=20 PERMITTED.
        >
        > Similar text for proxies also need to be = there.=20 What if a proxy
        > forwards a request with RPH and it receives = nultiple=20 responses from
        > the downstream proxies, with some including the = RPH and=20 others not
        > including it? Does this need to be=20 standardized?

        Again, I do not = think there=20 is a need to standardize this aspect.

        Janet
        >
        >
        >=20 _______________________________________________
        > Sip mailing = list=20  https://www1.ietf.org/mailman/listinfo/sip
        > This list is = for NEW=20 development of the core SIP Protocol
        > Use=20 sip-implementors@cs.columbia.edu for questions on current sip
        > = Use=20 sipping@ietf.org for new developments on the application of=20 sip
         ------_=_NextPart_001_01C7C96D.A7BD1C8E-- --===============0847721399== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0847721399==-- From sip-bounces@ietf.org Wed Jul 18 15:20:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBF4v-0006la-41; Wed, 18 Jul 2007 15:20:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBF4s-0006hL-LS for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 15:20:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBF4r-0006gx-Vh; Wed, 18 Jul 2007 15:20:50 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBF4r-0003p9-3f; Wed, 18 Jul 2007 15:20:49 -0400 Received: from source ([192.150.11.134]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Wed, 18 Jul 2007 12:20:40 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6IJJJot025959; Wed, 18 Jul 2007 12:19:20 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6IJKI0i013432; Wed, 18 Jul 2007 12:20:34 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 12:20:26 -0700 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, 18 Jul 2007 12:20:22 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AED871@namail5.corp.adobe.com> In-Reply-To: <08c801c7c968$1d1cd8c0$7d646b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJEybT1Lqyu4kbSgaZUq/KUlGECAAK8hkgAAmXLLAAAdQ84A== References: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com> <08c801c7c968$1d1cd8c0$7d646b80@amer.cisco.com> From: "Henry Sinnreich" To: "Dan Wing" , "Magnus Westerlund" X-OriginalArrivalTime: 18 Jul 2007 19:20:26.0798 (UTC) FILETIME=[B248BCE0:01C7C970] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: sip@ietf.org, Philip Matthews , behave@ietf.org, mmusic@ietf.org, p2psip@ietf.org Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dan, What you say makes sense but there is a lingering suspicion that after admitting that RFC 3489 (STUN), RFC 4091, 4092 (ANAT), etc. just don't work is that such paper evaluations are in no way a replacement for proof and measurements. We still need an explanation why the right approach cannot be taken: * Publish open source code at Sourceforge.net or similar, * Publish a test tool as well, * Gather and publish the results, possibly involving SIPit or another, * Perfect the OS code and the protocol until it works OK. This has been done for "Hole Punching for P2P" in=20 http://www.brynosaurus.com/pub/net/p2pnat/=20 What if ICE proves to be no better than its predecessors?=20 So how can one compare something that has tools, measured and published results with something like ICE that we have to take on pure faith? My assumption is that hole punching is much more effective for P2PSIP and I have copied the P2PSIP WG on this. The ratio of messages is probably 5:1 or higher for ICE vs. hole punching and this is critical when routing a P2PSIP message over an overlay in 5-10 hops. Of course I cannot prove it since as yet ICE cannot be measured. Let's do ICE the right way, there is too much at stake here. Henry -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: Wednesday, July 18, 2007 1:19 PM To: Henry Sinnreich; 'Magnus Westerlund' Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org Subject: RE: [BEHAVE] Re: ICE deployment data before LC for RFC > The excellent I-D shows=20 > the ICE call flow with two endpoints behind two NAT (Fig. 22=20 > on page 38) require 66 messages just for the SIP INVITE! >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-sce > narios-07.txt=20 That figure does not show 66 messages. That figure is clearly showing how the STUN messages are NATted, which leads to an incorrect conclusion around the number of=20 messages. Specifically, for example, it shows this message exchange which might be counted as "four messages"; yet, there are only two messages (the allocate request and the allocate response), which are NATted: L NAT STUN =20 Server | | | =20 |(1) Alloc Req | | =20 |Src=3DL-PRIV-1 | | =20 |Dest=3DSTUN-PUB-1 | | =20 |--------------->| | =20 | | | =20 | |(2) Alloc Req | =20 | |Src=3DL-NAT-PUB-1 | =20 | |Des=3DSTUN-PUB-1 | =20 | |--------------->| =20 | | | =20 | |(3) Alloc Resp | =20 | |<---------------| =20 | |Src=3DSTUN-PUB-1 | =20 | |Dest=3DL-NAT-PUB-1| =20 | |Map=3DL-NAT-PUB-1 | =20 | |Rel=3DSTUN-PUB-2 | =20 | | | =20 |(4) Alloc Resp | | =20 |<---------------| | =20 |Src=3DSTUN-PUB-1 | | =20 |Dest=3DL-PRIV-1 | | =20 |Map=3DL-NAT-PUB-1 | | =20 |Rel=3DSTUN-PUB-2 | | =20 | | | =20 If we added another NAT on that path, the number of messages on the network does not double. The number of messages on=20 the network stays the same -- the messages merely have their IP and UDP headers rewritten by the NATs. That NAT function does not increase the number of messages on the network. Similarly, another message shown in that same figure is also one message; however, it's shown as two messages: L NAT STUN NAT R Server |(9) SIP INVITE | | | | |------------------------------------------------->| | | | | |(10) SIP INVITE | | | | |--------------->| As you know, there aren't two messages -- it's one message that is NATted. If message 9 and 10 were shown as clearly as messages 1-4, messages 9-10 would be shown as four messages (one from L to its NAT, another=20 from NAT to NAT, and the forth (shown) from NAT to R). But this is just one SIP message, which is NATted. It is inaccurate to count it as two separate messages or as four separate messages, because it is only one packet that is NATted. Counting a STUN packet, or a DNS packet, as a separate message each time it traverses a=20 NAT is similarly inaccurate. By my count, figure 22 exchanges 24 STUN/ICE messages and 6=20 SIP messages. > What happens if the two endpoints are in different ISPs that=20 > have NAT of their own in addition to the ones in Fig. 22? The same 24 STUN/ICE messages would be exchanged, and the same 6 SIP messages would be exchanged. > What happens if one would try ICE along a P2PSIP route with=20 > say 5-8 hops? The SIP signaling messages would traverse those 5-8 additional=20 hops between the P2PSIP nodes participating in the SIP proxy overlay. The STUN/ICE messages are sent peer-to-peer, and=20 would remain the same 24 messages if you're doing the same=20 Figure 22 flow. =20 > Would there be hundreds of messages? No. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 15:32:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFFe-0000Uc-0N; Wed, 18 Jul 2007 15:31:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBFFQ-0000Ks-KS for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 15:31:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFFO-0000KY-UK; Wed, 18 Jul 2007 15:31:43 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBFFN-0002zx-EC; Wed, 18 Jul 2007 15:31:42 -0400 Received: from source ([192.150.20.142]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Wed, 18 Jul 2007 12:31:34 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6IJVWWs017431; Wed, 18 Jul 2007 12:31:32 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6IJVT0e014943; Wed, 18 Jul 2007 12:31:31 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 12:31:30 -0700 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 Subject: RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 12:31:18 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> In-Reply-To: <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJWHZz70STkhAQTUWLy398tzWtmAAGFg6w References: <239224.19734.qm@web33301.mail.mud.yahoo.com> <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> From: "Henry Sinnreich" To: "Philip Matthews" , "Pyda Srisuresh" X-OriginalArrivalTime: 18 Jul 2007 19:31:30.0491 (UTC) FILETIME=[3DE040B0:01C7C972] X-Spam-Score: -4.0 (----) X-Scan-Signature: 2ce306e4307a2c0b518ae453b13efdd0 Cc: Magnus Westerlund , behave@ietf.org, mmusic@ietf.org, sip@ietf.org, "Frank W. Miller" , p2psip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Phil, > In my view, ICE _is_ a "Hole Punching Technique". Yes, you absolutely right, though the devil is in the details. We cannot go here into a shoot-out between hole punching or other mentioned on the list vs. ICE, but there seems to be a huge difference in effectiveness and performance.=20 Of course I cannot prove it since there are no measurements published for ICE, only faith.=20 Just think of traversing all the NAT while going over 5-10 overlay network hops. Also many ISP are NATed and some are multiple NATed. We are supposed to provide a solution that works across the Internet. A provable (testing tools) and proven solution (measurements). I like ICE and hope to be proven wrong, but the risk is just too big for now. Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Wednesday, July 18, 2007 9:27 AM To: Pyda Srisuresh Cc: Frank W. Miller; Henry Sinnreich; 'Magnus Westerlund'; sip@ietf.org; behave@ietf.org; mmusic@ietf.org Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Frank, Henry, Suresh: I agree that ICE is a complex spec. I also agree that it would be =20 very interesting to see more data on which situations result in a direct path between =20 endpoints, as opposed to a path via a TURN server. However, I don't understand the comment that "Hole Punching =20 Techniques" are an alternative. In my view, ICE _is_ a "Hole Punching Technique". Perhaps you are referring to the use of STUN alone??? The problem with using STUN alone is that there are cases where using =20 the reflexive address doesn't work, and there is no way with STUN alone to determine when =20 an endpoint should or should not use a reflexive address. But perhaps you are referring to something else? - Philip On 18-Jul-07, at 11:37 , Pyda Srisuresh wrote: > Thanks to Henry and Frank for so eloquently articulating this. > > As both Henry and Frank mentioned, I fully support standardizing on =20 > HOLE > PUNCHING TECHNIQUE and leveraging the IETF's considerable influence =20 > to force > NAT vendors to migrate towards implementations that are friendly to =20 > Hole > Punching and the Application developers to design applications =20 > using the hole > punching techniques. That should be the FIRST order of priority. > > Yet, what is happening in BEHAVE WG is the other way around. Some =20 > people have > put their weight so heavily in favor of ICE that they asked to drop =20 > the work on > hole punching technique as WG item. THIS IS WRONG. I no longer see =20 > "NAT > Traveral application design guidelines" as BEHAVE WG milestone. > > Magnus - Can you explain why the IETF is not allowing HOLE PUNCHING =20 > TECHNIQUES > to move forward as a WG item? > > regards, > suresh > > --- "Frank W. Miller" wrote: > >> >> >> Greetings, >> >> >> >> What I think Henry is advocating is a systematic approach to =20 >> making sure >> that the content of the ICE spec is right for its intended =20 >> purpose, i.e. a >> complete, general NAT traversal solution. NAT traversal has been =20 >> in my >> opinion one of the most difficult aspects of SIP implementation =20 >> and its very >> important that its eventual standardized solution be right. I =20 >> know I spent >> a lot of time implementing all the "tests" in the first 3489, only to >> discover that they were not that useful. There are two valid =20 >> technical >> concerns that are put forth in this email: >> >> >> >> 1) Viability of correct operation in practical =20 >> implementations. ICE can >> result in very complicated message transfers. >> >> 2) Performance. As pointed out in this email and in other =20 >> places, the >> additional latency associated with ICE operations can be significant. >> >> >> >> Henry also points out that there are competing approaches (e.g. Hole >> Punching) that can perform well in many situations and have better >> performance. IMHO, another approach by the IETF in general would =20 >> be to >> standardize on Hole Punching and leverage the IETF's considerable =20 >> influence >> to force NAT vendors to migrate towards implementations that are =20 >> friendly to >> Hole Punching. >> >> >> >> The bottom line is that I agree with Henry in that labeling ICE as an >> experimental draft is the right thing to do. It will allow those >> implementing ICE (including myself in all likelihood) to proceed =20 >> but signals >> to the users the correct status of the standard's contents. >> >> >> >> I also want to applaud loudly the underlying tone of Henry's =20 >> thread here. >> That is, in solving specific technical problems within the IETF =20 >> forum, >> focusing on empirical observation of working implementations =20 >> should be the >> MO that we all strive for when developing and proposing what may =20 >> become >> protocol standards. >> >> >> >> Thanks, >> >> FM >> >> >> >> >> >> _____ >> >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] >> Sent: Wednesday, July 18, 2007 8:20 AM >> To: Magnus Westerlund >> Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org >> Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC >> >> >> >> Magnus, >> >> >> >> I sincerely appreciate your interest and this note! >> >> >> >>> I don't quite understand why you are requesting a status change =20 >>> of ICE >> >> >> >> However the arguments stated by the WG co-chairs and by you here are >> procedural in nature, whereas the facts are some cause for serious =20 >> concern, >> and I will just mention a few facts: >> >> >> >> RFC 3489 (STUN) was also presented as a NAT traversal solution =20 >> back in 2003, >> but now clearly admits that =20 >> "STUN is not a >> NAT traversal solution by itself. Rather, it is a tool to be used =20 >> in the >> context of a NAT traversal solution. This is an important change =20 >> from the >> previous version of this specification (RFC 3489), which presented =20 >> STUN as a >> complete solution." >> >> http://www.ietf.org/internet-drafts/draft-ietf-behave-=20 >> rfc3489bis-07.txt >> >> My guess is, in plain English, RFC 3489 turned out just NOT to be an >> acceptable solution as it was hoped to be. >> >> >> >> The excellent I-D shows the =20 >> ICE call >> flow with two endpoints behind two NAT (Fig. 22 on page 38) =20 >> require 66 >> messages just for the SIP INVITE! >> >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-=20 >> scenarios-07.txt >> >> What happens if the two endpoints are in different ISPs that have =20 >> NAT of >> their own in addition to the ones in Fig. 22? >> >> What happens if one would try ICE along a P2PSIP route with say =20 >> 5-8 hops? >> Would there be hundreds of messages? What is the likelihood for =20 >> failure? >> >> >> >> By contrast with such approaches based on hope and faith, the =20 >> BEHAVE WG has >> produced work based on real measurements and tools to do the =20 >> measurements, >> such as >> >> >> >> "NAT Classification Test Results" >> >> >> >> "Application Design Guidelines for Traversal through Network Address >> Translators" >> >> The measurements for hole punching are reported in >> >> "Peer-to-Peer Communication Across Network Address Translators" >> >> http://www.brynosaurus.com/pub/net/p2pnat/ >> >> >> >> I am also a believer in ICE and have actually urged Jonathan =20 >> Rosenberg to do >> this work and he has given his best. Now that we have ICE-17 =20 >> version, it is >> in the best interest of the industry and the IETF to make it an =20 >> experimental >> RFC, but not yet a standard so that: >> >> 1. Independent, compliant implementations will be developed, >> >> 2. Testing in events such as SIPit, >> >> 3. Reporting the results, such as reported for the "hole =20 >> punching" above. >> >> >> >> What happens if indeed hole punching proves to be the far more =20 >> effective >> approach? >> >> >> >> The industry can ill afford a new series of RFC[ICE]-bis and all =20 >> the years >> it takes to move from believing to measuring and proving. I am =20 >> sure IETF >> procedures were meant in this spirit (though I am not good in =20 >> producing the >> right quotes). >> >> >> >> Thanks again for your attention to this concern about ICE. >> >> Also my apology to all the anguish to the numerous contributors to =20 >> the ICE >> related I-Ds, but writing test tools and reporting measurements is =20 >> the right >> way to go. >> >> >> >> Henry >> >> >> >> >> >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Wednesday, July 18, 2007 1:11 AM >> To: Henry Sinnreich >> Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org >> Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC >> >> >> >> Henry Sinnreich skrev: >> >>> Following some discussions and soul searching, the best approach for >> >>> ICE-17 for LC would be to _go ahead and make it an experimental =20 >>> RFC_. >> >>> >> >>> This would support the development of interoperable =20 >>> implementations, the >> >>> collection of deployment data and also hopefully open source code. >> >>> >> >>> Though I have full faith in ICE, following the practices that =20 >>> made the >> >>> IETF successful take precedent here, I believe. >> >>> >> >>> This is a change from the attached that I wrote on 7/16/2007. >> >>> >> >>> Note: We can only hope the proliferation of SBC in VoIP service =20 >>> provider >> >>> networks will not make these concerns and ICE for SIP a moot =20 >>> issue, but >> >>> this is another topic. >> >> >> >> Henry, >> >> >> >> I don't quite understand why you are requesting a status change of =20 >> ICE? >> >> To me it appears that ICE is almost finished spec. It has been >> >> implemented, used and feedback has been influencing the protocol. =20 >> It is >> >> definitly one of the better examples of current IETF work that =20 >> actually >> >> has running code. Sure, the implementations may not be fully =20 >> updated yet >> >> to the latest draft version. But I think it is safe to say that ICE >> >> works in the intended core cases. If there are some corner cases =20 >> where >> >> it fails, that may be. But that is not information we will have until >> >> really large scale deployement or someone makes very extensive tests. >> >> >> >> I think the IETF and the Internet has much more benefit from a =20 >> standards >> >> track solution than any of the risks existing with ICE of today. >> >> >> >> And to be clear, proposed standard is allowed to be published =20 >> without a >> >> single implementation exists. It might not be good practice, but =20 >> it is >> >> allowed by our process. And as I said before ICE has had enough >> >> implementation that I am very confortable in balloting YES for it =20 >> when >> >> it appears on the IESGs table. >> >> >> >> Cheers >> >> >> >> Magnus Westerlund >> >> >> >> IETF Transport Area Director & TSVWG Chair >> >> --------------------------------------------------------------------- >> - >> >> Multimedia Technologies, Ericsson Research EAB/TVM/M >> >> --------------------------------------------------------------------- >> - >> >> Ericsson AB | Phone +46 8 4048287 >> >> Torshamsgatan 23 | Fax +46 8 7575550 >> >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> >> --------------------------------------------------------------------- >> - >> >>> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave >> > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 15:38:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFLw-0004sX-Sy; Wed, 18 Jul 2007 15:38:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBFLr-0004pB-Oc for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 15:38:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFLr-0004p2-Ep; Wed, 18 Jul 2007 15:38:23 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBFLr-0003Ej-3E; Wed, 18 Jul 2007 15:38:23 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6IJcIa02521; Wed, 18 Jul 2007 19:38:18 GMT 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, 18 Jul 2007 14:38:09 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1151ABC7@zrc2hxm0.corp.nortel.com> In-reply-to: <24CCCC428EFEA2469BF046DB3C7A8D22AED871@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJEybT1Lqyu4kbSgaZUq/KUlGECAAK8hkgAAmXLLAAAdQ84AABKemA References: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com> <08c801c7c968$1d1cd8c0$7d646b80@amer.cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D22AED871@namail5.corp.adobe.com> From: "Francois Audet" To: "Henry Sinnreich" , "Dan Wing" , "Magnus Westerlund" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sip@ietf.org, p2psip@ietf.org, behave@ietf.org, Philip Matthews , mmusic@ietf.org Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > * Publish open source code at Sourceforge.net or similar, > * Publish a test tool as well, > * Gather and publish the results, possibly involving SIPit or another, > * Perfect the OS code and the protocol until it works OK. >=20 > This has been done for "Hole Punching for P2P" in=20 > http://www.brynosaurus.com/pub/net/p2pnat/=20 Heuh, no. This is just "exploratory concept" stuff, certainly not an interoperable protocol specification. And if the proponents of this alternative hole punching didn't=20 propose a draft at IETF when we starting working on this back in 2001, it seems to me that it's too late. > My assumption is that hole punching is much more effective=20 > for P2PSIP and I have copied the P2PSIP WG on this. The ratio=20 > of messages is probably 5:1 or higher for ICE vs. hole=20 > punching and this is critical when routing a P2PSIP message=20 > over an overlay in 5-10 hops. Of course I cannot prove it=20 > since as yet ICE cannot be measured. Well, your assumption may be wrong, especially in the absence of a specification for this alternative hole punching technique. The other thing I find funny in here is that the alternative=20 hole punching techique as described on the web site uses a centralize server common to BOTH ends to relay the address, while ICE does not (i.e., each end can use their own STUN server). In other words, the major difference between ICE and the alternative-hole- punching technique seems to be that alternative-hole-punching assumes both ends use the same STUN server, which makes the=20 rest of the exchange simpler (the "magic box" architectural concept is always handy). Ironically, this seems to me to be LESS usable in a global network where you wont't use centralize servers, especially for p2psip. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 15:42:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFQ5-0004lr-0d; Wed, 18 Jul 2007 15:42:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBFQ1-0004k5-SU for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 15:42:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFQ1-0004iY-Dz for sip@ietf.org; Wed, 18 Jul 2007 15:42:41 -0400 Received: from mail130.messagelabs.com ([216.82.250.163]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBFPy-0004Y9-VA for sip@ietf.org; Wed, 18 Jul 2007 15:42:40 -0400 X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-14.tower-130.messagelabs.com!1184787756!5827819!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [20.137.52.152] Received: (qmail 23000 invoked from network); 18 Jul 2007 19:42:37 -0000 Received: from amer-mta08.csc.com (HELO amer-mta08.csc.com) (20.137.52.152) by server-14.tower-130.messagelabs.com with AES256-SHA encrypted SMTP; 18 Jul 2007 19:42:37 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta08.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id l6IJgS85019190 for ; Wed, 18 Jul 2007 15:42:36 -0400 (EDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1151AB0D@zrc2hxm0.corp.nortel.com> To: "Audet, Francois (SC100:3055)" Subject: RE: [Sip] New draft modifying RFC 4412 for Responses MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Wed, 18 Jul 2007 15:42:32 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1 HF180|March 29, 2007) at 07/18/2007 03:41:18 PM, Serialize complete at 07/18/2007 03:41:18 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: sip@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1594822218==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1594822218== Content-Type: multipart/alternative; boundary="=_alternative 006C43368525731C_=" This is a multipart message in MIME format. --=_alternative 006C43368525731C_= Content-Type: text/plain; charset="US-ASCII" Fine with me. Janet "Audet, Francois (SC100:3055)" wrote on 07/18/2007 02:58:39 PM: > I will be happy if the document is revised to explain that you > cannot expect that responses received by a UAC or Proxy will > necessarily include RPM, in particular in systems where forking > occurs, and that therefore, applications that use this draft must > take it into account. > > From: Janet P Gunn [mailto:jgunn6@csc.com] > Sent: Wednesday, July 18, 2007 10:41 > To: Audet, Francois (SC100:3055) > Cc: sip@ietf.org; James M. Polk > Subject: RE: [Sip] New draft modifying RFC 4412 for Responses > > > In line. > > "Francois Audet" wrote on 07/18/2007 11:26:54 AM: > > > > > What I mean is that the error response may not be delivered > > > to the UAC > > > > because a forking proxy will only deliver one final > > > response. If there > > > > are multiple error responses on the individual forks, one being the > > > > one with the RPH, and the other being some other response, > > > it is up to > > > > the proxy to decide which one to forward back. > > > > > > > > So the UAC can not rely on receiving the RPH to "re-intiate" the > > > > session or provide some alternative treatment. This may or > > > may not be > > > > a problem depending on the application (that's why I said "if it > > > > absolutely has"). > > > > > > > > > > I don't think that will be a problem. > > > > > > For one thing (for the namespaces I am working with) the > > > expectation would be that ALL the responses (except 100 and > > > 403) would have the RPH on the response, so it wouldn't > > > matter which one made it back to the UAC. > > > > I am not talking about multiple provisional responses from the same > > endpoint. > > > > I am talking about multiple responses (provisional and final) from > > multiple forks. For example, multiple 4XX responses. > > Yes, I understood that. > > > > While it is possible that a single forking proxy may decide to > > include the RPH in all responses, that proxy has absolutely no > > control over downstream and upstream proxies who may not include it > > (they may be proxies in different domains). > > > > That's the point I'm trying to make. You can not enforce the > > presence RPH in responses in a global system. > > Agree. For the context I am working in, a "global system" is not of > concern. I would not expect universal "RPH in responses" in a global system. > > > > > > Secondly, the expectation is that the devices responsible for > > > "re-initiating" WOULD be stateful, and not dependant on the > > > information in the RPH in the response. It is the > > > intervening devices that might not be stateful, and would > > > take advantage of the RPH information in the responses. > > > > That is precisely the type of clarification that needs to be included > > in the draft. It points out the constraints of the mechanism so > > implementors use the feature properly. > > > > Some text explaining that the UAC needs to be able to deal with the RPH > > not being present in responses gracefully (and why) is needed. > > I am not sure why that needs to be in the ID. It is an > implementation specific issue. > > Since RFC 4412, as currently published, forbids RPH in responses, I > think it "goes without saying" that "the UAC needs to be able to > deal with the RPH not being present in responses". > > Further, while I know that the systems (and namespaces) _I_ work > with intend to use RPH in responses, I also have been told that > other systems (using other namespaces) do not intend to put RPH in > ANY responses. I do not think there is any need to standardize this > aspect, just to adjust the standard so it is PERMITTED. > > > > Similar text for proxies also need to be there. What if a proxy > > forwards a request with RPH and it receives nultiple responses from > > the downstream proxies, with some including the RPH and others not > > including it? Does this need to be standardized? > > Again, I do not think there is a need to standardize this aspect. > > Janet > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip --=_alternative 006C43368525731C_= Content-Type: text/html; charset="US-ASCII"


        Fine with me.

        Janet

        "Audet, Francois (SC100:3055)" <audet@nortel.com> wrote on 07/18/2007 02:58:39 PM:

        > I will be happy if the document is revised to explain that you
        > cannot expect that responses received by a UAC or Proxy will
        > necessarily include RPM, in particular in systems where forking
        > occurs, and that therefore, applications that use this draft must
        > take it into account.
        >
        > From: Janet P Gunn [mailto:jgunn6@csc.com]
        > Sent: Wednesday, July 18, 2007 10:41
        > To: Audet, Francois (SC100:3055)
        > Cc: sip@ietf.org; James M. Polk
        > Subject: RE: [Sip] New draft modifying RFC 4412 for Responses
        >
        >
        > In line.
        >
        > "Francois Audet" <audet@nortel.com> wrote on 07/18/2007 11:26:54 AM:
        >
        > > > > What I mean is that the error response may not be delivered
        > > > to the UAC
        > > > > because a forking proxy will only deliver one final
        > > > response. If there
        > > > > are multiple error responses on the individual forks, one being the
        > > > > one with the RPH, and the other being some other response,
        > > > it is up to
        > > > > the proxy to decide which one to forward back.
        > > > >
        > > > > So the UAC can not rely on receiving the RPH to "re-intiate" the
        > > > > session or provide some alternative treatment. This may or
        > > > may not be
        > > > > a problem depending on the application (that's why I said "if it
        > > > > absolutely has").
        > > > >
        > > >
        > > > I don't think that will be a problem.
        > > >
        > > > For one thing (for the namespaces I am working with) the
        > > > expectation would be that ALL the responses (except 100 and
        > > > 403) would have the RPH on the response, so it wouldn't
        > > > matter which one made it back to the UAC.
        > >
        > > I am not talking about multiple provisional responses from the same
        > > endpoint.
        > >
        > > I am talking about multiple responses (provisional and final) from
        > > multiple forks. For example, multiple 4XX responses.
        >
        > Yes, I understood that.
        > >
        > > While it is possible that a single forking proxy may decide to
        > > include the RPH in all responses, that proxy has absolutely no
        > > control over downstream and upstream proxies who may not include it
        > > (they may be proxies in different domains).
        > >
        > > That's the point I'm trying to make. You can not enforce the
        > > presence RPH in responses in a global system.
        >
        > Agree. For the context I am working in, a "global system" is not of
        > concern.  I would not expect universal "RPH in responses" in a global system.
        >
        > >
        > > > Secondly, the expectation is that the devices responsible for
        > > > "re-initiating" WOULD be stateful, and not dependant on the
        > > > information in the RPH in the response.  It is the
        > > > intervening devices that might not be stateful, and would
        > > > take advantage of the RPH information in the responses.
        > >
        > > That is precisely the type of clarification that needs to be included
        > > in the draft. It points out the constraints of the mechanism so
        > > implementors use the feature properly.
        > >
        > > Some text explaining that the UAC needs to be able to deal with the RPH
        > > not being present in responses gracefully (and why) is needed.
        >
        > I am not sure why that needs to be in the ID.  It is an
        > implementation specific issue.  
        >
        > Since  RFC 4412, as currently published, forbids RPH in responses, I
        > think it "goes without saying" that "the UAC needs to be able to
        > deal with the RPH not being present in responses".
        >
        > Further, while I know that the systems (and namespaces) _I_ work
        > with intend to use RPH in responses, I also have been told that
        > other systems (using other namespaces) do not intend to put RPH in
        > ANY responses.  I do not think there is any need to standardize this
        > aspect, just to adjust the standard so it is PERMITTED.
        > >
        > > Similar text for proxies also need to be there. What if a proxy
        > > forwards a request with RPH and it receives nultiple responses from
        > > the downstream proxies, with some including the RPH and others not
        > > including it? Does this need to be standardized?
        >
        > Again, I do not think there is a need to standardize this aspect.
        >
        > Janet
        > >
        > >
        > > _______________________________________________
        > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
        > > This list is for NEW development of the core SIP Protocol
        > > Use sip-implementors@cs.columbia.edu for questions on current sip
        > > Use sipping@ietf.org for new developments on the application of sip         --=_alternative 006C43368525731C_=-- --===============1594822218== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1594822218==-- From sip-bounces@ietf.org Wed Jul 18 15:43:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFR0-0005ih-CH; Wed, 18 Jul 2007 15:43:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBFQe-0005PG-IE for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 15:43:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFQc-0005Oj-CG; Wed, 18 Jul 2007 15:43:19 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBFQb-0003Mr-Pi; Wed, 18 Jul 2007 15:43:18 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Wed, 18 Jul 2007 12:43:13 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6IJfqot000197; Wed, 18 Jul 2007 12:41:53 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6IJh60c016197; Wed, 18 Jul 2007 12:43:07 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 12:43:06 -0700 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 Subject: RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 12:42:57 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AED891@namail5.corp.adobe.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1151ABC7@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJEybT1Lqyu4kbSgaZUq/KUlGECAAK8hkgAAmXLLAAAdQ84AABKemAAACP2dA= References: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com><08c801c7c968$1d1cd8c0$7d646b80@amer.cisco.com><24CCCC428EFEA2469BF046DB3C7A8D22AED871@namail5.corp.adobe.com> <1ECE0EB50388174790F9694F77522CCF1151ABC7@zrc2hxm0.corp.nortel.com> From: "Henry Sinnreich" To: "Francois Audet" , "Dan Wing" , "Magnus Westerlund" X-OriginalArrivalTime: 18 Jul 2007 19:43:06.0466 (UTC) FILETIME=[DCB59C20:01C7C973] X-Spam-Score: -4.0 (----) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip@ietf.org, mmusic@ietf.org, behave@ietf.org, p2psip@ietf.org, Philip Matthews X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois, > Heuh, no. This is just "exploratory concept" stuff, certainly not an=20 > interoperable protocol specification. I am happy to report we are in total agreement. Henry -----Original Message----- From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Wednesday, July 18, 2007 2:38 PM To: Henry Sinnreich; Dan Wing; Magnus Westerlund Cc: sip@ietf.org; p2psip@ietf.org; behave@ietf.org; Philip Matthews; mmusic@ietf.org Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC =20 > * Publish open source code at Sourceforge.net or similar, > * Publish a test tool as well, > * Gather and publish the results, possibly involving SIPit or another, > * Perfect the OS code and the protocol until it works OK. >=20 > This has been done for "Hole Punching for P2P" in=20 > http://www.brynosaurus.com/pub/net/p2pnat/=20 Heuh, no. This is just "exploratory concept" stuff, certainly not an interoperable protocol specification. And if the proponents of this alternative hole punching didn't=20 propose a draft at IETF when we starting working on this back in 2001, it seems to me that it's too late. > My assumption is that hole punching is much more effective=20 > for P2PSIP and I have copied the P2PSIP WG on this. The ratio=20 > of messages is probably 5:1 or higher for ICE vs. hole=20 > punching and this is critical when routing a P2PSIP message=20 > over an overlay in 5-10 hops. Of course I cannot prove it=20 > since as yet ICE cannot be measured. Well, your assumption may be wrong, especially in the absence of a specification for this alternative hole punching technique. The other thing I find funny in here is that the alternative=20 hole punching techique as described on the web site uses a centralize server common to BOTH ends to relay the address, while ICE does not (i.e., each end can use their own STUN server). In other words, the major difference between ICE and the alternative-hole- punching technique seems to be that alternative-hole-punching assumes both ends use the same STUN server, which makes the=20 rest of the exchange simpler (the "magic box" architectural concept is always handy). Ironically, this seems to me to be LESS usable in a global network where you wont't use centralize servers, especially for p2psip. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 16:26:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBG6L-0007YB-37; Wed, 18 Jul 2007 16:26:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBG6H-0007Xj-Fw for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 16:26:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBG6F-0007XV-TE for sip@ietf.org; Wed, 18 Jul 2007 16:26:21 -0400 Received: from smtp3.versatel.nl ([62.58.50.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBG6E-0004rZ-CF for sip@ietf.org; Wed, 18 Jul 2007 16:26:19 -0400 Received: (qmail 20266 invoked by uid 0); 18 Jul 2007 20:25:56 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 18 Jul 2007 20:25:56 -0000 Message-ID: <001d01c7c979$7e257bc0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "IETF SIP" , "Dean Willis" , "Francois Audet" References: <3D4B049E-23D0-459D-AD58-3D8AF2AB8BE7@softarmor.com> Subject: Re: [Sip] WGLC for draft-ietf-sip-sips-05.txt Date: Wed, 18 Jul 2007 22:23:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A little late, but one consideration: Deprecating the last hop exception means that if the last hop proxy supports this specification, the UAC has no way to request SIPS up to the last hop (which it may want to do; best-effort TLS using sip: will probably not work in the intermediate period until this specification is widely supported). Would it be an idea for the draft to define request disposition tags (RFC3841) "last-hop-exception" and "no-last-hop-exception"? Then the UA could use SIPS, but indicate its preference to allow the last hop exception, and get "almost-end-2-end" security Regards, Jeroen Dean Willis wrote: > I'm pleased to announce that the authors think that the SIPS draft is > ready for working group last call. This draft has had the privilege > of more review prior to WGLC than most of our other efforts, so > perhaps it won't be too controversial. > > Please make a final read through the draft and bring any comments > back to this list. > > I'd like to conclude this WGLC by July 16, 2007, so get your comments > back in by then. And I'll plan to put some discussion time on the > agenda in Chicago. > > Thanks, and have a great weekend. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 16:57:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBGZn-0003pU-DU; Wed, 18 Jul 2007 16:56:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBGZl-0003jr-EE for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 16:56:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBGZl-0003iS-0M for sip@ietf.org; Wed, 18 Jul 2007 16:56:49 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBGZk-0007PX-47 for sip@ietf.org; Wed, 18 Jul 2007 16:56:48 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6IKuiI07031; Wed, 18 Jul 2007 20:56:45 GMT 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 Subject: RE: [Sip] WGLC for draft-ietf-sip-sips-05.txt Date: Wed, 18 Jul 2007 15:56:44 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1151AD21@zrc2hxm0.corp.nortel.com> In-reply-to: <001d01c7c979$7e257bc0$0601a8c0@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC for draft-ietf-sip-sips-05.txt Thread-Index: AcfJeehUvLlnvHfZTe6gh9nU8brdegAA9tIA References: <3D4B049E-23D0-459D-AD58-3D8AF2AB8BE7@softarmor.com> <001d01c7c979$7e257bc0$0601a8c0@BEMBUSTER> From: "Francois Audet" To: "Jeroen van Bemmel" , "IETF SIP" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org We have explored something similar (using an option tag instead) in an earlier version (see=20 https://svn.resiprocate.org/rep/ietf-drafts/audet/draft-ietf-sip-sips-03 .txt),=20 but people felt the additional complexity was not warranted and that allowing for the last-hop exception was not a good goal. It was therefore revoved in the next version. > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 > Sent: Wednesday, July 18, 2007 13:23 > To: IETF SIP; Dean Willis; Audet, Francois (SC100:3055) > Subject: Re: [Sip] WGLC for draft-ietf-sip-sips-05.txt >=20 > A little late, but one consideration: >=20 > Deprecating the last hop exception means that if the last hop=20 > proxy supports this specification, the UAC has no way to=20 > request SIPS up to the last hop (which it may want to do;=20 > best-effort TLS using sip: will probably not work in the=20 > intermediate period until this specification is widely supported). >=20 > Would it be an idea for the draft to define request disposition tags > (RFC3841) "last-hop-exception" and "no-last-hop-exception"?=20 > Then the UA could use SIPS, but indicate its preference to=20 > allow the last hop exception, and get "almost-end-2-end" security >=20 > Regards, > Jeroen >=20 > Dean Willis wrote: > > I'm pleased to announce that the authors think that the=20 > SIPS draft is=20 > > ready for working group last call. This draft has had the=20 > privilege of=20 > > more review prior to WGLC than most of our other efforts,=20 > so perhaps=20 > > it won't be too controversial. > > > > Please make a final read through the draft and bring any=20 > comments back=20 > > to this list. > > > > I'd like to conclude this WGLC by July 16, 2007, so get=20 > your comments=20 > > back in by then. And I'll plan to put some discussion time on the=20 > > agenda in Chicago. > > > > Thanks, and have a great weekend.=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 17:06:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBGif-0000sp-HJ; Wed, 18 Jul 2007 17:06:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBGi7-0000gB-H1 for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 17:05:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBGi7-0000g0-5W; Wed, 18 Jul 2007 17:05:27 -0400 Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBGi6-0007eH-PC; Wed, 18 Jul 2007 17:05:27 -0400 Received: from [192.168.1.120] (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id 99B4C75807D; Wed, 18 Jul 2007 16:05:25 -0500 (CDT) Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC From: "Frank W. Miller" To: Francois Audet In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1151ABC7@zrc2hxm0.corp.nortel.com> References: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com> <08c801c7c968$1d1cd8c0$7d646b80@amer.cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D22AED871@namail5.corp.adobe.com> <1ECE0EB50388174790F9694F77522CCF1151ABC7@zrc2hxm0.corp.nortel.com> Content-Type: text/plain Date: Wed, 18 Jul 2007 15:05:13 -0600 Message-Id: <1184792713.3347.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Magnus Westerlund , behave@ietf.org, p2psip@ietf.org, sip@ietf.org, Henry Sinnreich , Dan Wing , Philip Matthews , mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Wed, 2007-07-18 at 14:38 -0500, Francois Audet wrote: > The other thing I find funny in here is that the alternative > hole punching techique as described on the web site uses a > centralize server common to BOTH ends to relay the address, while > ICE does not (i.e., each end can use their own STUN server). > > In other words, the major difference between ICE and the > alternative-hole- > punching technique seems to be that alternative-hole-punching > assumes both ends use the same STUN server, which makes the > rest of the exchange simpler (the "magic box" architectural > concept is always handy). > > Ironically, this seems to me to be LESS usable in a global network > where you wont't use centralize servers, especially for p2psip. > This may be sufficient, but I don't think its necessary. Each UA punches the hole (and keeps it open, as David described) to whatever STUN server they like, all that's required is that each server have the same view of each client. That is somewhat less restrictive. In the common case of the open Internet, as long as the STUN servers used by each respective UA are in the "open", they don't have to be the same. After that, the "public" or "visible" IP address/port is put in the Contact headers. Regarding the 90% coverage, this is what I'm referring to when I say that it may be preferable to influence the NAT vendors to not do the things that put them in the 10% cases. I sort of thought that was what the NAT guidelines draft was for. In addition, if we are standardizing a protocol based on the 10% cases and imposing potentially huge costs on the 90% to do so, then our approach is incorrect. We should be designing for the 90% case and handling the 10% as exceptional behavior, i.e. a solution where you pay the big cost only in the case where you are actually in the 10%. FM _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 18:39:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIAq-0003WG-5h; Wed, 18 Jul 2007 18:39:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBIAm-0003Rw-MT for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 18:39:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIAm-0003Qb-2M for sip@ietf.org; Wed, 18 Jul 2007 18:39:08 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBIAl-0001rB-Bz for sip@ietf.org; Wed, 18 Jul 2007 18:39:07 -0400 Received: from lappy ([68.26.122.92]) by quinthar.com for ; Wed, 18 Jul 2007 15:38:59 -0700 From: "David Barrett" To: "'Melinda Shore'" , "'Philip Matthews'" , "'Pyda Srisuresh'" Subject: RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 15:38:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfJWHiK1kJjj4/ZRl2bJXpSN42/3wABwWSwAAMGS0QAB7yQkA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Message-Id: Cc: sip@ietf.org, 'Henry Sinnreich' , behave@ietf.org, mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > > ICE makes me want to pound red-hot nails into my eye sockets. That said, > 90% really isn't nearly good enough for residential deployments. Incidentally, 90% is where my stats come out today -- this doesn't include restricted-cone/symmetric and symmetric/symmetric penetration, which has been prototyped but not added to the production system yet. The hope is this will get us much close to the 99% range, but it remains to be seen by how much. Furthermore, I'd wager that for most applications (such as VoIP), even routing 1 in 10 calls through a central relay isn't going to break the bank. (Or for mega-discounts, use the full-cone and non-NAT'd clients (>30%) to act as "free" relays for their peers.) Thus while NAT penetration using what I guess we're calling the "hole punching technique" has been demonstrated to work at 90%+ on a very large scale (hundreds of thousands of clients tested) we should expect that it's possible to get even better still. If ICE can show how it'd do better, that'd be great. But we can't tolerate ICE being any worse than that, and thus before rushing ahead with standardizing an unproven ICE, we should just take the time to prove it. -david _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 18:54:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIPq-0008WN-Fx; Wed, 18 Jul 2007 18:54:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBE25-0007Kq-4z for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 14:13:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBE24-0007JX-Kl for sip@ietf.org; Wed, 18 Jul 2007 14:13:52 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBE23-0001rf-Nx for sip@ietf.org; Wed, 18 Jul 2007 14:13:52 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Wed, 18 Jul 2007 11:13:46 -0700 From: "David Barrett" To: "'Philip Matthews'" , "'Pyda Srisuresh'" Subject: RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 11:13:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfJWHiK1kJjj4/ZRl2bJXpSN42/3wABwWSw In-Reply-To: <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e8a3b85ef670172081194f0b0f68e6f Message-Id: X-Mailman-Approved-At: Wed, 18 Jul 2007 18:54:38 -0400 Cc: sip@ietf.org, 'Henry Sinnreich' , behave@ietf.org, mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree with Henry, Frank, Suresh, and the lurkers on this list who have concern that ICE hasn't demonstrated its claims in the real world, while others have achieved similar ends with great success using much simpler approaches. (Some examples: Skype, Hamachi, Red Swoosh/Akamai, etc.) For example, regarding the "hole punching" approach (by which I assume you mean "opening a hole and trying to keep it open" versus ICE's "open a hole 'on demand' for each connection"), it's been demonstrated to work at large scale with at least 90% direct peer connectivity across the internet, today, with a much simpler message flow and implementation. I find it concerning that ICE has taken a more costly, difficult route without confirming it's truly worth the additional incremental effort (or even a step backwards). I share the concern that ICE standardization has gotten far out ahead of the horse in inventing a new protocol from scratch rather than modeling off of the proven protocols that came before it, which historically has been the IETF strength. Given this choice to go a new route, I think it warrants a higher burden of evidence -- contrasted against known success rates of competing solutions -- before being formally endorsed by the IETF. I'm completely open to ICE being superior to all others. I have no doubt more effort has been put into it, and I'm eager to enjoy the fruits of everyone's labor. But I'd like to see the data that proves it, and I see no reason to charge ahead with standardization until data is firmly in hand. -david > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Wednesday, July 18, 2007 9:27 AM > To: Pyda Srisuresh > Cc: behave@ietf.org; mmusic@ietf.org; sip@ietf.org; 'Henry Sinnreich' > Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC > > Frank, Henry, Suresh: > > I agree that ICE is a complex spec. I also agree that it would be > very interesting to see > more data on which situations result in a direct path between > endpoints, as opposed to > a path via a TURN server. > > However, I don't understand the comment that "Hole Punching > Techniques" are an alternative. > In my view, ICE _is_ a "Hole Punching Technique". > > Perhaps you are referring to the use of STUN alone??? > The problem with using STUN alone is that there are cases where using > the reflexive address > doesn't work, and there is no way with STUN alone to determine when > an endpoint should or > should not use a reflexive address. > > But perhaps you are referring to something else? > - Philip > > > On 18-Jul-07, at 11:37 , Pyda Srisuresh wrote: > > > Thanks to Henry and Frank for so eloquently articulating this. > > > > As both Henry and Frank mentioned, I fully support standardizing on > > HOLE > > PUNCHING TECHNIQUE and leveraging the IETF's considerable influence > > to force > > NAT vendors to migrate towards implementations that are friendly to > > Hole > > Punching and the Application developers to design applications > > using the hole > > punching techniques. That should be the FIRST order of priority. > > > > Yet, what is happening in BEHAVE WG is the other way around. Some > > people have > > put their weight so heavily in favor of ICE that they asked to drop > > the work on > > hole punching technique as WG item. THIS IS WRONG. I no longer see > > "NAT > > Traveral application design guidelines" as BEHAVE WG milestone. > > > > Magnus - Can you explain why the IETF is not allowing HOLE PUNCHING > > TECHNIQUES > > to move forward as a WG item? > > > > regards, > > suresh > > > > --- "Frank W. Miller" wrote: > > > >> > >> > >> Greetings, > >> > >> > >> > >> What I think Henry is advocating is a systematic approach to > >> making sure > >> that the content of the ICE spec is right for its intended > >> purpose, i.e. a > >> complete, general NAT traversal solution. NAT traversal has been > >> in my > >> opinion one of the most difficult aspects of SIP implementation > >> and its very > >> important that its eventual standardized solution be right. I > >> know I spent > >> a lot of time implementing all the "tests" in the first 3489, only to > >> discover that they were not that useful. There are two valid > >> technical > >> concerns that are put forth in this email: > >> > >> > >> > >> 1) Viability of correct operation in practical > >> implementations. ICE can > >> result in very complicated message transfers. > >> > >> 2) Performance. As pointed out in this email and in other > >> places, the > >> additional latency associated with ICE operations can be significant. > >> > >> > >> > >> Henry also points out that there are competing approaches (e.g. Hole > >> Punching) that can perform well in many situations and have better > >> performance. IMHO, another approach by the IETF in general would > >> be to > >> standardize on Hole Punching and leverage the IETF's considerable > >> influence > >> to force NAT vendors to migrate towards implementations that are > >> friendly to > >> Hole Punching. > >> > >> > >> > >> The bottom line is that I agree with Henry in that labeling ICE as an > >> experimental draft is the right thing to do. It will allow those > >> implementing ICE (including myself in all likelihood) to proceed > >> but signals > >> to the users the correct status of the standard's contents. > >> > >> > >> > >> I also want to applaud loudly the underlying tone of Henry's > >> thread here. > >> That is, in solving specific technical problems within the IETF > >> forum, > >> focusing on empirical observation of working implementations > >> should be the > >> MO that we all strive for when developing and proposing what may > >> become > >> protocol standards. > >> > >> > >> > >> Thanks, > >> > >> FM > >> > >> > >> > >> > >> > >> _____ > >> > >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > >> Sent: Wednesday, July 18, 2007 8:20 AM > >> To: Magnus Westerlund > >> Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org > >> Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC > >> > >> > >> > >> Magnus, > >> > >> > >> > >> I sincerely appreciate your interest and this note! > >> > >> > >> > >>> I don't quite understand why you are requesting a status change > >>> of ICE > >> > >> > >> > >> However the arguments stated by the WG co-chairs and by you here are > >> procedural in nature, whereas the facts are some cause for serious > >> concern, > >> and I will just mention a few facts: > >> > >> > >> > >> RFC 3489 (STUN) was also presented as a NAT traversal solution > >> back in 2003, > >> but now clearly admits that > >> "STUN is not a > >> NAT traversal solution by itself. Rather, it is a tool to be used > >> in the > >> context of a NAT traversal solution. This is an important change > >> from the > >> previous version of this specification (RFC 3489), which presented > >> STUN as a > >> complete solution." > >> > >> http://www.ietf.org/internet-drafts/draft-ietf-behave- > >> rfc3489bis-07.txt > >> > >> My guess is, in plain English, RFC 3489 turned out just NOT to be an > >> acceptable solution as it was hoped to be. > >> > >> > >> > >> The excellent I-D shows the > >> ICE call > >> flow with two endpoints behind two NAT (Fig. 22 on page 38) > >> require 66 > >> messages just for the SIP INVITE! > >> > >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat- > >> scenarios-07.txt > >> > >> What happens if the two endpoints are in different ISPs that have > >> NAT of > >> their own in addition to the ones in Fig. 22? > >> > >> What happens if one would try ICE along a P2PSIP route with say > >> 5-8 hops? > >> Would there be hundreds of messages? What is the likelihood for > >> failure? > >> > >> > >> > >> By contrast with such approaches based on hope and faith, the > >> BEHAVE WG has > >> produced work based on real measurements and tools to do the > >> measurements, > >> such as > >> > >> > >> > >> "NAT Classification Test Results" > >> > >> > >> > >> "Application Design Guidelines for Traversal through Network Address > >> Translators" > >> > >> The measurements for hole punching are reported in > >> > >> "Peer-to-Peer Communication Across Network Address Translators" > >> > >> http://www.brynosaurus.com/pub/net/p2pnat/ > >> > >> > >> > >> I am also a believer in ICE and have actually urged Jonathan > >> Rosenberg to do > >> this work and he has given his best. Now that we have ICE-17 > >> version, it is > >> in the best interest of the industry and the IETF to make it an > >> experimental > >> RFC, but not yet a standard so that: > >> > >> 1. Independent, compliant implementations will be developed, > >> > >> 2. Testing in events such as SIPit, > >> > >> 3. Reporting the results, such as reported for the "hole > >> punching" above. > >> > >> > >> > >> What happens if indeed hole punching proves to be the far more > >> effective > >> approach? > >> > >> > >> > >> The industry can ill afford a new series of RFC[ICE]-bis and all > >> the years > >> it takes to move from believing to measuring and proving. I am > >> sure IETF > >> procedures were meant in this spirit (though I am not good in > >> producing the > >> right quotes). > >> > >> > >> > >> Thanks again for your attention to this concern about ICE. > >> > >> Also my apology to all the anguish to the numerous contributors to > >> the ICE > >> related I-Ds, but writing test tools and reporting measurements is > >> the right > >> way to go. > >> > >> > >> > >> Henry > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > >> Sent: Wednesday, July 18, 2007 1:11 AM > >> To: Henry Sinnreich > >> Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org > >> Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC > >> > >> > >> > >> Henry Sinnreich skrev: > >> > >>> Following some discussions and soul searching, the best approach for > >> > >>> ICE-17 for LC would be to _go ahead and make it an experimental > >>> RFC_. > >> > >>> > >> > >>> This would support the development of interoperable > >>> implementations, the > >> > >>> collection of deployment data and also hopefully open source code. > >> > >>> > >> > >>> Though I have full faith in ICE, following the practices that > >>> made the > >> > >>> IETF successful take precedent here, I believe. > >> > >>> > >> > >>> This is a change from the attached that I wrote on 7/16/2007. > >> > >>> > >> > >>> Note: We can only hope the proliferation of SBC in VoIP service > >>> provider > >> > >>> networks will not make these concerns and ICE for SIP a moot > >>> issue, but > >> > >>> this is another topic. > >> > >> > >> > >> Henry, > >> > >> > >> > >> I don't quite understand why you are requesting a status change of > >> ICE? > >> > >> To me it appears that ICE is almost finished spec. It has been > >> > >> implemented, used and feedback has been influencing the protocol. > >> It is > >> > >> definitly one of the better examples of current IETF work that > >> actually > >> > >> has running code. Sure, the implementations may not be fully > >> updated yet > >> > >> to the latest draft version. But I think it is safe to say that ICE > >> > >> works in the intended core cases. If there are some corner cases > >> where > >> > >> it fails, that may be. But that is not information we will have until > >> > >> really large scale deployement or someone makes very extensive tests. > >> > >> > >> > >> I think the IETF and the Internet has much more benefit from a > >> standards > >> > >> track solution than any of the risks existing with ICE of today. > >> > >> > >> > >> And to be clear, proposed standard is allowed to be published > >> without a > >> > >> single implementation exists. It might not be good practice, but > >> it is > >> > >> allowed by our process. And as I said before ICE has had enough > >> > >> implementation that I am very confortable in balloting YES for it > >> when > >> > >> it appears on the IESGs table. > >> > >> > >> > >> Cheers > >> > >> > >> > >> Magnus Westerlund > >> > >> > >> > >> IETF Transport Area Director & TSVWG Chair > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Multimedia Technologies, Ericsson Research EAB/TVM/M > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Ericsson AB | Phone +46 8 4048287 > >> > >> Torshamsgatan 23 | Fax +46 8 7575550 > >> > >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > >> > >> --------------------------------------------------------------------- > >> - > >> > >>> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www1.ietf.org/mailman/listinfo/behave > >> > > > > > > > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 18:54:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIPs-0000EE-Nx; Wed, 18 Jul 2007 18:54:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBEPr-0003Sb-4a for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 14:38:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBEPq-0003SD-N0 for sip@ietf.org; Wed, 18 Jul 2007 14:38:26 -0400 Received: from web33313.mail.mud.yahoo.com ([68.142.206.128]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBEPp-0001My-BY for sip@ietf.org; Wed, 18 Jul 2007 14:38:26 -0400 Received: (qmail 9268 invoked by uid 60001); 18 Jul 2007 18:38:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=3+2cY+yXyBkHGpWc8u4Ua2zsPKSOdRzfNvNuiznkVa3DC6IfYvIoKsXt1wClPSAI+9SyZWVrJOJN00uPyw5NpCe8LAnfssngyupTwL8rtaggH7gFuv2zciNnRWVoYL08Vm+FKBXad7heWxN1F4qRy15wdQrZn693v09YyaMp33c=; X-YMail-OSG: c8eMOgYVM1l2jEeRQ0Q9aMvg9aLtIhJfLV72DzMLBYEGYh5Z4gMv2ZMtWXXY9Dq3TCDRnTflv9.V.dcTa0PXhJPjG.xcZZ4rbBjsPYgXZzMj5h2UBhc- Received: from [209.172.74.45] by web33313.mail.mud.yahoo.com via HTTP; Wed, 18 Jul 2007 11:38:24 PDT Date: Wed, 18 Jul 2007 11:38:24 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC To: Philip Matthews In-Reply-To: <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <857678.8925.qm@web33313.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 213cf0777a99c4ccdd94bb20659dd28c X-Mailman-Approved-At: Wed, 18 Jul 2007 18:54:38 -0400 Cc: 'Magnus Westerlund' , behave@ietf.org, mmusic@ietf.org, sip@ietf.org, 'Henry Sinnreich' , "Frank W. Miller" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --- Philip Matthews wrote: > Frank, Henry, Suresh: > > I agree that ICE is a complex spec. I also agree that it would be > very interesting to see > more data on which situations result in a direct path between > endpoints, as opposed to > a path via a TURN server. > > However, I don't understand the comment that "Hole Punching > Techniques" are an alternative. > In my view, ICE _is_ a "Hole Punching Technique". > > Perhaps you are referring to the use of STUN alone??? > The problem with using STUN alone is that there are cases where using > the reflexive address > doesn't work, and there is no way with STUN alone to determine when > an endpoint should or > should not use a reflexive address. > [suresh] Right, ICE does use the HOLE PUNCHING technique and the BCP guidelines described in draft-ford-behave-app draft, even though ICE draft does NOT acknowledge or reference the above draft or prior work that introduced HOLE PUNCHING TECHNIQUE. ICE is also using HOLE PUNCHING in a limited way within the constraints of STUN and SIP. Hence, the croner case scenarios you site. ICE is NOT HOLE PUNCHING in its native form. In the BEHAVE WG meeting(last IETF), several people talked of ICE as the new application traversal approach blessed by IETF, and proposed dropping the original draft ford-behave-app draft that proposes HOLE PUNCHING TECHNIQUE. As a result, the application milestone is dropped from the WG charter and ford-behave-app is not adapted as work group item. This, to me, is pitting ICE against the basic HOLE PUNCHING TECHNIQUE. This is what I believe to be WRONG. regards, suresh > But perhaps you are referring to something else? > - Philip > > > On 18-Jul-07, at 11:37 , Pyda Srisuresh wrote: > > > Thanks to Henry and Frank for so eloquently articulating this. > > > > As both Henry and Frank mentioned, I fully support standardizing on > > HOLE > > PUNCHING TECHNIQUE and leveraging the IETF’s considerable influence > > to force > > NAT vendors to migrate towards implementations that are friendly to > > Hole > > Punching and the Application developers to design applications > > using the hole > > punching techniques. That should be the FIRST order of priority. > > > > Yet, what is happening in BEHAVE WG is the other way around. Some > > people have > > put their weight so heavily in favor of ICE that they asked to drop > > the work on > > hole punching technique as WG item. THIS IS WRONG. I no longer see > > "NAT > > Traveral application design guidelines" as BEHAVE WG milestone. > > > > Magnus - Can you explain why the IETF is not allowing HOLE PUNCHING > > TECHNIQUES > > to move forward as a WG item? > > > > regards, > > suresh > > > > --- "Frank W. Miller" wrote: > > > >> > >> > >> Greetings, > >> > >> > >> > >> What I think Henry is advocating is a systematic approach to > >> making sure > >> that the content of the ICE spec is right for its intended > >> purpose, i.e. a > >> complete, general NAT traversal solution. NAT traversal has been > >> in my > >> opinion one of the most difficult aspects of SIP implementation > >> and its very > >> important that its eventual standardized solution be right. I > >> know I spent > >> a lot of time implementing all the "tests" in the first 3489, only to > >> discover that they were not that useful. There are two valid > >> technical > >> concerns that are put forth in this email: > >> > >> > >> > >> 1) Viability of correct operation in practical > >> implementations. ICE can > >> result in very complicated message transfers. > >> > >> 2) Performance. As pointed out in this email and in other > >> places, the > >> additional latency associated with ICE operations can be significant. > >> > >> > >> > >> Henry also points out that there are competing approaches (e.g. Hole > >> Punching) that can perform well in many situations and have better > >> performance. IMHO, another approach by the IETF in general would > >> be to > >> standardize on Hole Punching and leverage the IETF's considerable > >> influence > >> to force NAT vendors to migrate towards implementations that are > >> friendly to > >> Hole Punching. > >> > >> > >> > >> The bottom line is that I agree with Henry in that labeling ICE as an > >> experimental draft is the right thing to do. It will allow those > >> implementing ICE (including myself in all likelihood) to proceed > >> but signals > >> to the users the correct status of the standard's contents. > >> > >> > >> > >> I also want to applaud loudly the underlying tone of Henry's > >> thread here. > >> That is, in solving specific technical problems within the IETF > >> forum, > >> focusing on empirical observation of working implementations > >> should be the > >> MO that we all strive for when developing and proposing what may > >> become > >> protocol standards. > >> > >> > >> > >> Thanks, > >> > >> FM > >> > >> > >> > >> > >> > >> _____ > >> > >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > >> Sent: Wednesday, July 18, 2007 8:20 AM > >> To: Magnus Westerlund > >> Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org > >> Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC > >> > >> > >> > >> Magnus, > >> > >> > >> > >> I sincerely appreciate your interest and this note! > >> > >> > >> > >>> I don't quite understand why you are requesting a status change > >>> of ICE > >> > >> > >> > >> However the arguments stated by the WG co-chairs and by you here are > >> procedural in nature, whereas the facts are some cause for serious > >> concern, > >> and I will just mention a few facts: > >> > >> > >> > >> RFC 3489 (STUN) was also presented as a NAT traversal solution > >> back in 2003, > >> but now clearly admits that > >> "STUN is not a > >> NAT traversal solution by itself. Rather, it is a tool to be used > >> in the > >> context of a NAT traversal solution. This is an important change > >> from the > >> previous version of this specification (RFC 3489), which presented > >> STUN as a > >> complete solution." > >> > >> http://www.ietf.org/internet-drafts/draft-ietf-behave- > >> rfc3489bis-07.txt > >> > >> My guess is, in plain English, RFC 3489 turned out just NOT to be an > >> acceptable solution as it was hoped to be. > >> > >> > >> > >> The excellent I-D shows the > >> ICE call > >> flow with two endpoints behind two NAT (Fig. 22 on page 38) > >> require 66 > >> messages just for the SIP INVITE! > >> > >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat- > >> scenarios-07.txt > >> > >> What happens if the two endpoints are in different ISPs that have > >> NAT of > >> their own in addition to the ones in Fig. 22? > >> > >> What happens if one would try ICE along a P2PSIP route with say > >> 5-8 hops? > >> Would there be hundreds of messages? What is the likelihood for > >> failure? > >> > >> > >> > >> By contrast with such approaches based on hope and faith, the > >> BEHAVE WG has > >> produced work based on real measurements and tools to do the > >> measurements, > >> such as > >> > >> > >> > >> "NAT Classification Test Results" > >> > >> > >> > >> "Application Design Guidelines for Traversal through Network Address > >> Translators" > >> > >> The measurements for hole punching are reported in > >> > >> "Peer-to-Peer Communication Across Network Address Translators" > >> > >> http://www.brynosaurus.com/pub/net/p2pnat/ > >> > >> > >> > >> I am also a believer in ICE and have actually urged Jonathan > >> Rosenberg to do > >> this work and he has given his best. Now that we have ICE-17 > >> version, it is > >> in the best interest of the industry and the IETF to make it an > >> experimental > >> RFC, but not yet a standard so that: > >> > >> 1. Independent, compliant implementations will be developed, > >> > >> 2. Testing in events such as SIPit, > >> > >> 3. Reporting the results, such as reported for the "hole > >> punching" above. > >> > >> > >> > >> What happens if indeed hole punching proves to be the far more > >> effective > >> approach? > >> > >> > >> > >> The industry can ill afford a new series of RFC[ICE]-bis and all > >> the years > >> it takes to move from believing to measuring and proving. I am > >> sure IETF > >> procedures were meant in this spirit (though I am not good in > >> producing the > >> right quotes). > >> > >> > >> > >> Thanks again for your attention to this concern about ICE. > >> > >> Also my apology to all the anguish to the numerous contributors to > >> the ICE > >> related I-Ds, but writing test tools and reporting measurements is > >> the right > >> way to go. > >> > >> > >> > >> Henry > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > >> Sent: Wednesday, July 18, 2007 1:11 AM > >> To: Henry Sinnreich > >> Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org > >> Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC > >> > >> > >> > >> Henry Sinnreich skrev: > >> > >>> Following some discussions and soul searching, the best approach for > >> > >>> ICE-17 for LC would be to _go ahead and make it an experimental > >>> RFC_. > >> > >>> > >> > >>> This would support the development of interoperable > >>> implementations, the > >> > >>> collection of deployment data and also hopefully open source code. > >> > >>> > >> > >>> Though I have full faith in ICE, following the practices that > >>> made the > >> > >>> IETF successful take precedent here, I believe. > >> > >>> > >> > >>> This is a change from the attached that I wrote on 7/16/2007. > >> > >>> > >> > >>> Note: We can only hope the proliferation of SBC in VoIP service > >>> provider > >> > >>> networks will not make these concerns and ICE for SIP a moot > >>> issue, but > >> > >>> this is another topic. > >> > >> > >> > >> Henry, > >> > >> > >> > >> I don't quite understand why you are requesting a status change of > >> ICE? > >> > >> To me it appears that ICE is almost finished spec. It has been > >> > >> implemented, used and feedback has been influencing the protocol. > >> It is > >> > >> definitly one of the better examples of current IETF work that > >> actually > >> > >> has running code. Sure, the implementations may not be fully > >> updated yet > >> > >> to the latest draft version. But I think it is safe to say that ICE > >> > >> works in the intended core cases. If there are some corner cases > >> where > >> > >> it fails, that may be. But that is not information we will have until > >> > >> really large scale deployement or someone makes very extensive tests. > >> > >> > >> > >> I think the IETF and the Internet has much more benefit from a > >> standards > >> > >> track solution than any of the risks existing with ICE of today. > >> > >> > >> > >> And to be clear, proposed standard is allowed to be published > >> without a > >> > >> single implementation exists. It might not be good practice, but > >> it is > >> > >> allowed by our process. And as I said before ICE has had enough > >> > >> implementation that I am very confortable in balloting YES for it > >> when > >> > >> it appears on the IESGs table. > >> > >> > >> > >> Cheers > >> > >> > >> > >> Magnus Westerlund > >> > >> > >> > >> IETF Transport Area Director & TSVWG Chair > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Multimedia Technologies, Ericsson Research EAB/TVM/M > >> > >> --------------------------------------------------------------------- > >> - > >> > >> Ericsson AB | Phone +46 8 4048287 > >> > >> Torshamsgatan 23 | Fax +46 8 7575550 > >> > >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > >> > >> --------------------------------------------------------------------- > >> - > >> > >>> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www1.ietf.org/mailman/listinfo/behave > >> > > > > > > > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 18:54:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIPu-0000MK-Fg; Wed, 18 Jul 2007 18:54:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBEVF-0002fz-2l for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 14:44:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBEVE-0002fN-CT; Wed, 18 Jul 2007 14:44:00 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBEVD-0001Wj-TG; Wed, 18 Jul 2007 14:44:00 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 18 Jul 2007 11:43:59 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANb7nUarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,551,1175497200"; d="scan'208"; a="184411557:sNHT26564256" 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 l6IIhx6T004698; Wed, 18 Jul 2007 11:43:59 -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.12.10/8.12.6) with ESMTP id l6IIhYSx015490; Wed, 18 Jul 2007 18:43:56 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 14:43:56 -0400 Received: from 10.86.115.66 ([10.86.115.66]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Wed, 18 Jul 2007 18:43:56 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 18 Jul 2007 14:43:54 -0400 Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC From: Melinda Shore To: David Barrett , "'Philip Matthews'" , Pyda Srisuresh Message-ID: Thread-Topic: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJWHiK1kJjj4/ZRl2bJXpSN42/3wABwWSwAAMGS0Q= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 18 Jul 2007 18:43:56.0472 (UTC) FILETIME=[98BF8380:01C7C96B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1322; t=1184784239; x=1185648239; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20 |Subject:=20Re=3A=20[Sip]=20RE=3A=20[BEHAVE]=20Re=3A=20ICE=20deployment=2 0data=20before=20LC=20for=20RFC |Sender:=20; bh=FGomruZHVVV5PGhYSPpx0WH2XrxXMCEh87GwWWzX504=; b=JVxkldbK6hIqokxk3r5WFxbTWEhtPpWjKvUyf4h4jm7VH4A4/Onj3dIuoP0LWRML+pBapGCy 2rhwWCZg3ldHSFEzFTQtd4PxUJpDkdwmOsLIv+UOyavuh3GjHAHXzN5ChmksG/DDNquHswxYhM vCBMBGvshBwwOXrKks5QFr9bM=; Authentication-Results: sj-dkim-1; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Wed, 18 Jul 2007 18:54:38 -0400 Cc: sip@ietf.org, 'Henry Sinnreich' , behave@ietf.org, mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 7/18/07 2:13 PM, "David Barrett" wrote: > For example, regarding the "hole punching" approach (by which I assume you > mean "opening a hole and trying to keep it open" versus ICE's "open a hole > 'on demand' for each connection"), it's been demonstrated to work at large > scale with at least 90% direct peer connectivity across the internet, today, > with a much simpler message flow and implementation. ICE makes me want to pound red-hot nails into my eye sockets. That said, 90% really isn't nearly good enough for residential deployments. For cheap-o residential equipment, the margins are so thin that a support call or two is sufficient to wipe out the profit on that sale. Part of the reason that ICE is the mess it is is that the group has been iteratively fixing the various failures by adding more tests and probes and messages and whatnot. There are certainly a lot of other ways to achieve reliability but regardless of which one you choose, reliability really does have to be a priority. Ancillary to that is that when you fail you should fail in a way that can be diagnosed with reasonable ease and transparency (auditability is good!), and I think we all know what happens when traditional NAT hole-punching fails - stuff just doesn't work. Melinda _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 18:54:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIPo-0008So-Ao; Wed, 18 Jul 2007 18:54:40 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBBaU-0000op-GD for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 11:37:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBBaU-0000oe-3N for sip@ietf.org; Wed, 18 Jul 2007 11:37:14 -0400 Received: from web33301.mail.mud.yahoo.com ([68.142.206.116]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBBaS-0004a0-NL for sip@ietf.org; Wed, 18 Jul 2007 11:37:14 -0400 Received: (qmail 20356 invoked by uid 60001); 18 Jul 2007 15:37:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=RcWaY5dlPfv7Wn3bij5Yf8r9MyWFv3X7biBuAwQPozF1tnGNjOKR3Akeq04ufr9PpQZFrcNa5fmPB5DfiWJx9m2TC1+Lko5IOEX83LPy0y4quxBwXdK/9uRTUeeIN6goG5I1q1/UQq5sEXeU7u8oqsx3JzwY580a3M0pmCbAUk4=; X-YMail-OSG: YHPVtOsVM1muHnYjzgz5BvnlxjIGUXyjqCvFQHcu Received: from [69.236.76.222] by web33301.mail.mud.yahoo.com via HTTP; Wed, 18 Jul 2007 08:37:12 PDT Date: Wed, 18 Jul 2007 08:37:12 -0700 (PDT) From: Pyda Srisuresh Subject: RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC To: "Frank W. Miller" , 'Henry Sinnreich' , 'Magnus Westerlund' In-Reply-To: <20070718145339.3E9A5758069@smtpauth00.csee.onr.siteprotect.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <239224.19734.qm@web33301.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 X-Mailman-Approved-At: Wed, 18 Jul 2007 18:54:38 -0400 Cc: sip@ietf.org, behave@ietf.org, mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks to Henry and Frank for so eloquently articulating this. As both Henry and Frank mentioned, I fully support standardizing on HOLE PUNCHING TECHNIQUE and leveraging the IETF’s considerable influence to force NAT vendors to migrate towards implementations that are friendly to Hole Punching and the Application developers to design applications using the hole punching techniques. That should be the FIRST order of priority. Yet, what is happening in BEHAVE WG is the other way around. Some people have put their weight so heavily in favor of ICE that they asked to drop the work on hole punching technique as WG item. THIS IS WRONG. I no longer see "NAT Traveral application design guidelines" as BEHAVE WG milestone. Magnus - Can you explain why the IETF is not allowing HOLE PUNCHING TECHNIQUES to move forward as a WG item? regards, suresh --- "Frank W. Miller" wrote: > > > Greetings, > > > > What I think Henry is advocating is a systematic approach to making sure > that the content of the ICE spec is right for its intended purpose, i.e. a > complete, general NAT traversal solution. NAT traversal has been in my > opinion one of the most difficult aspects of SIP implementation and its very > important that its eventual standardized solution be right. I know I spent > a lot of time implementing all the "tests" in the first 3489, only to > discover that they were not that useful. There are two valid technical > concerns that are put forth in this email: > > > > 1) Viability of correct operation in practical implementations. ICE can > result in very complicated message transfers. > > 2) Performance. As pointed out in this email and in other places, the > additional latency associated with ICE operations can be significant. > > > > Henry also points out that there are competing approaches (e.g. Hole > Punching) that can perform well in many situations and have better > performance. IMHO, another approach by the IETF in general would be to > standardize on Hole Punching and leverage the IETF's considerable influence > to force NAT vendors to migrate towards implementations that are friendly to > Hole Punching. > > > > The bottom line is that I agree with Henry in that labeling ICE as an > experimental draft is the right thing to do. It will allow those > implementing ICE (including myself in all likelihood) to proceed but signals > to the users the correct status of the standard's contents. > > > > I also want to applaud loudly the underlying tone of Henry's thread here. > That is, in solving specific technical problems within the IETF forum, > focusing on empirical observation of working implementations should be the > MO that we all strive for when developing and proposing what may become > protocol standards. > > > > Thanks, > > FM > > > > > > _____ > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Wednesday, July 18, 2007 8:20 AM > To: Magnus Westerlund > Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org > Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC > > > > Magnus, > > > > I sincerely appreciate your interest and this note! > > > > > I don't quite understand why you are requesting a status change of ICE > > > > However the arguments stated by the WG co-chairs and by you here are > procedural in nature, whereas the facts are some cause for serious concern, > and I will just mention a few facts: > > > > RFC 3489 (STUN) was also presented as a NAT traversal solution back in 2003, > but now clearly admits that "STUN is not a > NAT traversal solution by itself. Rather, it is a tool to be used in the > context of a NAT traversal solution. This is an important change from the > previous version of this specification (RFC 3489), which presented STUN as a > complete solution." > > http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-07.txt > > My guess is, in plain English, RFC 3489 turned out just NOT to be an > acceptable solution as it was hoped to be. > > > > The excellent I-D shows the ICE call > flow with two endpoints behind two NAT (Fig. 22 on page 38) require 66 > messages just for the SIP INVITE! > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-07.txt > > What happens if the two endpoints are in different ISPs that have NAT of > their own in addition to the ones in Fig. 22? > > What happens if one would try ICE along a P2PSIP route with say 5-8 hops? > Would there be hundreds of messages? What is the likelihood for failure? > > > > By contrast with such approaches based on hope and faith, the BEHAVE WG has > produced work based on real measurements and tools to do the measurements, > such as > > > > "NAT Classification Test Results" > > > > "Application Design Guidelines for Traversal through Network Address > Translators" > > The measurements for hole punching are reported in > > "Peer-to-Peer Communication Across Network Address Translators" > > http://www.brynosaurus.com/pub/net/p2pnat/ > > > > I am also a believer in ICE and have actually urged Jonathan Rosenberg to do > this work and he has given his best. Now that we have ICE-17 version, it is > in the best interest of the industry and the IETF to make it an experimental > RFC, but not yet a standard so that: > > 1. Independent, compliant implementations will be developed, > > 2. Testing in events such as SIPit, > > 3. Reporting the results, such as reported for the "hole punching" above. > > > > What happens if indeed hole punching proves to be the far more effective > approach? > > > > The industry can ill afford a new series of RFC[ICE]-bis and all the years > it takes to move from believing to measuring and proving. I am sure IETF > procedures were meant in this spirit (though I am not good in producing the > right quotes). > > > > Thanks again for your attention to this concern about ICE. > > Also my apology to all the anguish to the numerous contributors to the ICE > related I-Ds, but writing test tools and reporting measurements is the right > way to go. > > > > Henry > > > > > > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Wednesday, July 18, 2007 1:11 AM > To: Henry Sinnreich > Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org > Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC > > > > Henry Sinnreich skrev: > > > Following some discussions and soul searching, the best approach for > > > ICE-17 for LC would be to _go ahead and make it an experimental RFC_. > > > > > > This would support the development of interoperable implementations, the > > > collection of deployment data and also hopefully open source code. > > > > > > Though I have full faith in ICE, following the practices that made the > > > IETF successful take precedent here, I believe. > > > > > > This is a change from the attached that I wrote on 7/16/2007. > > > > > > Note: We can only hope the proliferation of SBC in VoIP service provider > > > networks will not make these concerns and ICE for SIP a moot issue, but > > > this is another topic. > > > > Henry, > > > > I don't quite understand why you are requesting a status change of ICE? > > To me it appears that ICE is almost finished spec. It has been > > implemented, used and feedback has been influencing the protocol. It is > > definitly one of the better examples of current IETF work that actually > > has running code. Sure, the implementations may not be fully updated yet > > to the latest draft version. But I think it is safe to say that ICE > > works in the intended core cases. If there are some corner cases where > > it fails, that may be. But that is not information we will have until > > really large scale deployement or someone makes very extensive tests. > > > > I think the IETF and the Internet has much more benefit from a standards > > track solution than any of the risks existing with ICE of today. > > > > And to be clear, proposed standard is allowed to be published without a > > single implementation exists. It might not be good practice, but it is > > allowed by our process. And as I said before ICE has had enough > > implementation that I am very confortable in balloting YES for it when > > it appears on the IESGs table. > > > > Cheers > > > > Magnus Westerlund > > > > IETF Transport Area Director & TSVWG Chair > > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM/M > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 18:55:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIQr-0001bO-Ha; Wed, 18 Jul 2007 18:55:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBIQp-0001a6-Nq for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 18:55:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIQp-0001YH-6W for sip@ietf.org; Wed, 18 Jul 2007 18:55:43 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBIQo-0002Dn-GK for sip@ietf.org; Wed, 18 Jul 2007 18:55:43 -0400 Received: (qmail 11666 invoked by uid 0); 18 Jul 2007 22:56:55 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 18 Jul 2007 22:56:55 -0000 Message-ID: <009101c7c98e$5d2281b0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Cullen Jennings" , "Rohan Mahy" References: Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-10.txt Date: Thu, 19 Jul 2007 00:52:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Minor comment on section 4.3 (sending requests): it talks about the UAC inserting an 'ob' parameter in its Contact URI, should it do the same for Contact URIs in responses over an outbound flow (for consistency reasons perhaps; allows the other end to detect outbound usage)? Regards, Jeroen Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Session Initiation Protocol Working >> Group of the IETF. >> >> Title : Managing Client Initiated Connections in the Session >> Initiation Protocol (SIP) Author(s) : C. Jennings, R. Mahy >> Filename : draft-ietf-sip-outbound-10.txt >> Pages : 42 >> Date : 2007-7-12 >> >> The Session Initiation Protocol (SIP) allows proxy servers to >> initiate TCP connections and send asynchronous UDP datagrams to >> User Agents in order to deliver requests. However, many practical >> considerations, such as the existence of firewalls and Network >> Address Translators (NATs), prevent servers from connecting to User >> Agents in this way. This specification defines behaviors for User >> Agents, registrars and proxy servers that allow requests to be >> delivered on existing connections established by the User Agent. >> It also defines keep alive behaviors needed to keep NAT bindings >> open and specifies the usage of multiple connections. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-10.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body >> of >> the message. >> You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-ietf-sip-outbound-10.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-sip-outbound-10.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> > > > >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 21:10:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBKXd-00065V-UZ; Wed, 18 Jul 2007 21:10:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBKXc-00064V-P4 for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 21:10:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBKXc-00064M-DA for sip@ietf.org; Wed, 18 Jul 2007 21:10:52 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBKXb-00050k-Nm for sip@ietf.org; Wed, 18 Jul 2007 21:10:52 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 18 Jul 2007 18:10:18 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAD5XnkarR7PE/2dsb2JhbABD X-IronPort-AV: i="4.16,553,1175497200"; d="scan'208"; a="504725241:sNHT4626093046" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6J1AHL1017055 for ; Wed, 18 Jul 2007 18:10:17 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6J1AHA0009589 for ; Thu, 19 Jul 2007 01:10:17 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); Wed, 18 Jul 2007 18:10:17 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 18:10:17 -0700 Message-ID: <469E193A.4020402@cisco.com> Date: Wed, 18 Jul 2007 09:44:26 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 01:10:17.0163 (UTC) FILETIME=[918441B0:01C7C9A1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2966; t=1184807417; x=1185671417; 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:=20comments=20on=20draft-camarillo-sip-body-handling-01 |Sender:=20; bh=noWbBpiVFsyIEt6f/0abVxZdgo56afFD5cF7186QFEs=; b=EfkSZVeh2g8iJ4sHZHeFA8ky1A2cAStg3HwjkkPBQ+11QZ+2q6/v31L7pyOlw+kcc3uYv/Xt RM0SGGBU8U9NLxXXzvqXlzn3OjVRIYpzNBvzUqyz/JsbFafiRMnkNWaX; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -2.1 (--) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Sip] comments on draft-camarillo-sip-body-handling-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The draft makes support of multipart a SHOULD in RFC 3261. If our objective is to use multipart as a vehicle for extending SIP (e.g., by including optional bodies in addition to the mandatory one - a location object plus SDP for example), this is much better served by a MUST. Otherwise, a UAC will have to send a request first with multipart, and if its rejected, retry the request with just the supported parts. Its effectively the same as the behavior we'd see if the only way to extend SIP was with Require, and not Supported. This draft also strikes me as something that is in the essential corrections category, but its debatable. For multipart/alternative - I don't understand the requirement to order them from least to most 'rich'. Is that a general MIME behavior or are we defining it that way? If we want to prioritize, shouldn't we use an explicit q-value or something? Using order seems like it will be brittle (as it has been in SDP where m-lines were never numbered). The use case described for multipart/alternative - new SDP mechanisms - seems kind of bogus. We've decided not to pursue that. Do we have a REAL use case for this? > The reason for not having such a mechanism is that disposition types > are typically supported within a context. Outside that context, a UA > (User Agent) may not support the disposition type. I think the same can be send for content-types. A UA may support a content-type of application/sdp, but only for one disposition ('session') and not another ('render'). So, generally I would say that a UA never really supports a content-type; it supports a set of tuples of {content-type, content-disposition, method}. > UAs process message bodies and body parts in the following way. On > receiving a SIP message, if a body part is not referenced in any way > (e.g., there are no header fields or other body parts with a > Content-ID URL pointing to it), the UA processes the body part as > indicated by its disposition type and the context in which the body > part was received. > > OPEN ISSUE 4: this means that a UA would need to parse all body parts > to find references between them before being able to fully process > them. If we are OK with this, we need to include text here > explaining it. This behavior seems like a bad idea, and I don't understand why it is needed. If the CID URL is part of an optional extension, then you make the body handling optional, and the UA will know to pick up the body part if it supports the extension, otherwise not. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 21:19:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBKfh-00007W-FG; Wed, 18 Jul 2007 21:19:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBKfg-000072-Bh for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 21:19:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBKff-00006j-Fv; Wed, 18 Jul 2007 21:19:11 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBKff-00074j-1F; Wed, 18 Jul 2007 21:19:11 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IBKfe-0001iS-22; Wed, 18 Jul 2007 21:19:10 -0400 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> References: <239224.19734.qm@web33301.mail.mud.yahoo.com> <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 21:19:21 -0400 To: Henry Sinnreich X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Magnus Westerlund , behave@ietf.org, mmusic@ietf.org, sip@ietf.org, Pyda Srisuresh , "Frank W. Miller" , p2psip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > Phil, > >> In my view, ICE _is_ a "Hole Punching Technique". > > Yes, you absolutely right, though the devil is in the details. > > We cannot go here into a shoot-out between hole punching or other > mentioned on the list vs. ICE, but there seems to be a huge difference > in effectiveness and performance. What precise algorithm are you talking about when you say this? As far as I am concerned, ICE is simply a well-documented hole punching algorithm. It differs from others that I have seen written up in the following ways: - ICE has the concept of peer reflexive addresses, which other hole- punching techniques that I have seen do not; - ICE has the concept of controlling/controlled endpoint, which gives the controller additional flexibility in choosing a path; - ICE does NOT have the concept of port prediction, which some other techniques do (e.g., Saikat's TCP work). Philip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 21:48:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBL8C-0004pt-HV; Wed, 18 Jul 2007 21:48:40 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBL8A-0004po-0L for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 21:48:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBL89-0004pg-16 for sip@ietf.org; Wed, 18 Jul 2007 21:48:37 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBL87-0008Ix-EX for sip@ietf.org; Wed, 18 Jul 2007 21:48:36 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLE00IH6KZZ6S@szxga04-in.huawei.com> for sip@ietf.org; Thu, 19 Jul 2007 09:47:59 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLE00K8XKZXZ0@szxga04-in.huawei.com> for sip@ietf.org; Thu, 19 Jul 2007 09:47:59 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLE00DNMKZTE3@szxml04-in.huawei.com> for sip@ietf.org; Thu, 19 Jul 2007 09:47:57 +0800 (CST) Date: Thu, 19 Jul 2007 09:47:53 +0800 From: Qian Sun Subject: RE: [Sip] Comments on draft-ietf-sip-multiple-refer-01.txt In-reply-to: <2057023F-B93F-443C-9762-9B1388C119E9@nostrum.com> To: 'Robert Sparks' , 'Gonzalo Camarillo' Message-id: <003701c7c9a6$d29fa360$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable Thread-index: AcfIgNbk7MUs2+ObRoyPQxrrrgUVDgBH5nYw X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: 'Miguel Garcia' , 'sip' , 'Aki Niemi' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Robert and Gonzalo IMO, "multiple refer" doesn't need AIB part of Referred-By. As Gonzalo = said, the relay (e.g. conference server) understand what is going on, it = must have authenticated the identity of the Referrer. So the Referred-By = header field and 'recipient-list-history'(the same function as Refer-To) = are creditable for final REFER-Target. The triggered SIP message sent by the relay just needs to include = Referred-By header field (maybe plus recipient-list-history), the = Referred-By token is not necessary (like the example "7.2. Insecure = REFER" in rfc3892). The information in Referred-By header field is still = very useful for final REFER-Target to learn the source of the message.=20 It's not worth writing a separate spec for this, just adding few texts = to this draft may be OK. Since this draft has mentioned Refer-Sub, why = not says something about Referred-By? BTW, there are very few commercial IMS implementations on the planet, = but we believe the future of IMS must not bad, maybe same to Referred-By = with AIB. Cheers, Qian -----Original Message----- From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 Sent: Tuesday, July 17, 2007 10:43 PM To: Gonzalo Camarillo Cc: Qian Sun; Miguel Garcia; sip; Aki Niemi; Markus.Isomaki@nokia.com> = Hi, > > [moving this thread from the SIPPING list to this one (SIP) because =20 > this is a SIP document now.] > > You are right. It is not trivial to use Referred-By with multiple =20 > REFER. My suggestion is that, the same way as Referred-By is =20 > specified as an extension of refer, you go ahead specify (if you =20 > are interested) how to use Referred-by with multiple REFER in a =20 > different spec. > > The body that the referrer would add to its REFER (which is what =20 > the refer target would get) could be an XML list with the =20 > recipients (those that can be disclosed) of the multiple REFER =20 > (plus the referrer). Something similar to what recipients get after =20 > a relay processes a list with copyControl attributes (draft-ietf-=20 > sipping-capacity-attribute-04.txt)... in any case, since multiple =20 > REFER is only used within a context of a service, you need to think =20 > whether having a general Referred-By mechanism is needed or if such =20 > functionality can be achieved in a different way within the =20 > services multiple REFER is used in (e.g., conferencing). > > Cheers, > > Gonzalo > > > Qian Sun wrote: >> Hello, Gonzalo >> RFC3892 says: >> The sipfrag inside a Referred-By token MUST contain copies of the >> Refer-To, Referred-By, and Date header fields from the REFER =20 >> request. >> In multiple refer case, the Refer-To header field includes content =20 >> id, not the REFER-Target' URI. The content id is meaningless to =20 >> the REFER-Targets, so the Referred-By token has to include the URI-=20 >> List. >> Cheers, >> Qian >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >> Sent: Monday, July 16, 2007 4:23 PM >> To: Qian Sun >> Cc: Aki.Niemi@nokia.com; Markus.Isomaki@nokia.com; =20 >> miguel.an.garcia@nokia.com; hisham.khartabil@gmail.com; =20 >> sipping@ietf.org >> Subject: Re: Comments on draft-ietf-sip-multiple-refer-01.txt >> Hi, >> thanks for your comments. Answers inline: >> Qian Sun wrote: >> > Some comments on the draft... >> > >> > 1. I think it might be a good idea to talk something on =20 >> "Referred-By" in this draft. Referred-By mechanism is still very =20 >> useful for the multiple refer case. Maybe Refer-To related to a =20 >> URI List with "bcc" or "anonymize" is a trouble. = "Referred-BY=E2=80=9D in =20 >> the message header is to identify the initial REFER-Issuer. This =20 >> information may be encrypted together with "refer-to" URI list, =20 >> including the copy control level such as to/cc/bcc to the end =20 >> user, i.e. REFER-Target, where the information will be decrypted =20 >> by the REFER-Target. In this case the REFER-Recipient won=E2=80=99t = be =20 >> able to get rid of the "bcc" URI from the URI list, and the "bcc" =20 >> URI will be sent to other REFER-Targets along with normal to/cc. =20 >> This will be a problem to destroy the blind cc function. >> > However, the REFER-issuer may opt to not include a Referred-By =20 >> token. For example: >> > REFER sip:conf-123@example.com;gruu;opaque=3Dhha9s8d-999a SIP/ = >> 2.0 >> > Refer-To: >> > Referred-By: Carol >> > Content-Type: application/resource-lists+xml >> > Content-Disposition: recipient-list >> > Content-Length: 362 >> > Content-ID: >> > >> > >> > > > = xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"> >> > >> > >> > >> > >> > >> > >> > >> > When the URI list has no "bcc" or "anonymize" URI, REFER-issuer =20 >> may include the Referred-By token in the REFER body. >> The way Referred-By works is not affected by what this draft says. >> Therefore, I do not see the need to talk about it. >> > >> > 2. Nested refer in multiple refer is very interesting, I =20 >> believe it could be a good idea to enroll a "multiple nested =20 >> refer" example into this draft. Just for an example: >> > REFER sip:list-service@example.com;gruu;opaque=3Dhha9s8d-999a = >> SIP/2.0 >> > Refer-To: >> > Content-ID: >> > >> > >> > > > = xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"> >> > >> > > 3Dsip:conf-123%40shenzhen.example.com" /> >> > > 3Dsip:conf-123%40shenzhen.example.com" /> >> > >> > >> > In this case, the REFER-Recipient acts as a Refer List service, =20 >> has the similar function to the MESSAGE List service, i.e. =20 >> receives a REFER with URI-List and distributes some REFERs to each =20 >> address in the URI-List. >> > Note that, there is only one final REFER-Target in above =20 >> "nested multiple refer" example, not multiple REFER-Targets. In =20 >> some situations, this convergent feature is useful. >> The draft says the following: >> Additionally, REFER-Recipients SHOULD only accept REFER requests >> within the context of an application the server understands =20 >> (e.g., a >> conferencing application). >> this text was added to avoid relays being used as random traffic >> forwarders. Therefore, since a relay needs to understand what is =20 >> going >> on (e.g., a multiple REFER to trigger BYEs towards several conference >> attendees) and currently there is no service that uses nested =20 >> refers, I >> do not think we need to talk about it. >> > >> > 3. I guess it might be a typo in Figure 2 "8. 200K OK", maybe =20 >> you meant "200 OK"? >> yes, thanks for pointing it out. We will fix it. >> Thanks, >> Gonzalo >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 21:57:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBLGg-0005Lr-He; Wed, 18 Jul 2007 21:57:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBLGf-0005LL-50 for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 21:57:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBLGe-0005LB-OZ; Wed, 18 Jul 2007 21:57:24 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBLGe-0008V8-CK; Wed, 18 Jul 2007 21:57:24 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IBLGc-0007uL-2v; Wed, 18 Jul 2007 21:57:23 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <239224.19734.qm@web33301.mail.mud.yahoo.com> <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 21:57:34 -0400 To: Henry Sinnreich , Magnus Westerlund , Behave WG , IETF MMUSIC WG , sip@ietf.org, Pyda Srisuresh , "Frank W. Miller" , P2PSIP Mailing List X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 18-Jul-07, at 21:19 , Philip Matthews wrote: > > On 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > >> Phil, >> >>> In my view, ICE _is_ a "Hole Punching Technique". >> >> Yes, you absolutely right, though the devil is in the details. >> >> We cannot go here into a shoot-out between hole punching or other >> mentioned on the list vs. ICE, but there seems to be a huge >> difference >> in effectiveness and performance. > > What precise algorithm are you talking about when you say this? > As far as I am concerned, ICE is simply a well-documented hole > punching algorithm. > It differs from others that I have seen written up in the following > ways: > - ICE has the concept of peer reflexive addresses, which other hole- > punching techniques that I have seen do not; > - ICE has the concept of controlling/controlled endpoint, which > gives the controller additional flexibility in choosing a path; > - ICE does NOT have the concept of port prediction, which some > other techniques do (e.g., Saikat's TCP work). I should add that ICE also handles: - the case of multi-homed peers, - peers that want to exchange multiple media streams, - media streams which are composed of multiple components (e.g. RTP and RTCP). These are cases that a solution for SIP needs to handle, but I have not seen discussed in other proposals. - Philip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 22:56:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBMC6-0004gg-Dg; Wed, 18 Jul 2007 22:56:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBMC5-0004eq-Ar for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 22:56:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBMC4-0004e6-I9; Wed, 18 Jul 2007 22:56:44 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBMC3-00089s-6g; Wed, 18 Jul 2007 22:56:44 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 18 Jul 2007 19:56:42 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJ9vnkarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,553,1175497200"; d="scan'208"; a="184645472:sNHT33227658" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6J2ugHS028945; Wed, 18 Jul 2007 19:56:42 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id l6J2ufA1012744; Thu, 19 Jul 2007 02:56:41 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> <469DCB03.9040300@ericsson.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <13AC112D-E5EF-438B-97C8-9F3827EA07BF@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 19:55:30 -0700 To: SIP , Behave WG , mmusic@ietf.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8440; t=1184813802; x=1185677802; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20[BEHAVE]=20Re=3A=20ICE=20deployment=2 0data=20before=20LC=20for=20RFC |Sender:=20; bh=x+KWwSoKmqIEePOlsgp20zWpePInK2ZzORIHZTzbieU=; b=QBtjhv25FY3TyBQl1jiHLQF6wwNpKdvOpybfov2JXLOf3YZyd8T8LPY+bM5Gc/2Kwlr8v/YL ppKVaktamhwEHc1R4Q/6zQEm9K4yQwozW1dZ5X5EfgYpHzqfhII1T24j; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org First I apologize for the cross post - this is a mmusic draft, I would appreciate replies on the mmusic list only. Few things I am looking for here .... 1) specific reasons why this work is less appropriate for standards track than other work that IETF puts on the standards track. Keep in mind the first step of standards track is Proposed Standards which requires basically no interoperability, then it could move to Draft Standard where interoperability is shown and finally Full Standard if it turns out to be a good idea. If you are going to post a reply to this point, make sure you have read RFC 2026. 2) I am interested in the specifics of problems that ICE fails to solve that the WG has not previous considered. There are lots of people that have implemented versions of it and think it is a good idea - if people are having some problems with it, I'd love to hear about details of things that are wrong. That it has a lot of messages in some use cases has been known for a long time. It used to have far more messages - engineering was done to consider what was a reasonable amount for call set up times and a new design was done to bring the message to a level most people invovled with the design felt was reasonable. If there are specific other than these that are wrong and not considered in the design, now would be a good time to get them on the table. 3) If people think that Skype for example has a simpler solution that works better than ICE. Feel free to describe exactly what it is. Several people invovled with the ICE design have looked in extreme detail at Skype and others and so far none of them have come back with what we should do different than ICE. 4) ICE can be used in a mode where it only provided the reflexive candidate. People were pretty clear that this was far inferior to the modes where there are other candidates. If someone would like to provide exactly how hole punching works better than this very limited ICE technique, I'd be glad to hear the details. This has certainly been an topic that any could have brought up over the last several years. If someone has specifics, I suggest they get out a full proposal really soon. I am very doubtful that hole punching solution is fundamentally different than the type of hole punching ICE does. 5) Some people have suggested that if all NATs were behave complaint, then we would not need ICE. I strongly disagree. I think the only part of ICE we would not need is the TURN relays which are more or less an optional part. Again, specifics on what can be removed are welcome. ICE is far more complicated that anyone wants - the problem is, no one has come up with a proposal that looks like it comes anywhere close to meeting the requirements and if simpler. The design space has been extensively explored by many people. The raw data to understand what will work on what NATs have been painfully tested and documented in publications such as: http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf http://tools.ietf.org/id/draft-jennings-behave-test-results-04.txt https://www.guha.cc/saikat/stunt-results.php? (Ford used to have a page too but it seems to be gone) I have a very open mind to considering better ways to do ICE - but I need specific suggestions or it is impossible for me to really think about if the suggestions represent a better path or not. I would love to see more open source ICE code (there is lots already) - I feel that this is an area where ICE is likely just table stakes and owning an proprietary ICE stack will not turn out to be a competitive advantage. Having open source implementations where the development cost was shared and everyone could get working products to market faster would be an advantage to companies. Clearly I expect the bulk of ICE implementations to not be open source but I still would be keen on doing what I can to contribute to an open source version as personally I feel that is in the interest of end users, my employer, and the IETF as a SDO. Cullen On Jul 18, 2007, at 9:12 AM, Dean Willis wrote: > > On Jul 18, 2007, at 3:10 AM, Magnus Westerlund wrote: > >> Henry Sinnreich skrev: >>> Following some discussions and soul searching, the best approach for >>> ICE-17 for LC would be to _go ahead and make it an experimental >>> RFC_. >>> This would support the development of interoperable >>> implementations, the >>> collection of deployment data and also hopefully open source code. >>> Though I have full faith in ICE, following the practices that >>> made the >>> IETF successful take precedent here, I believe. >>> This is a change from the attached that I wrote on 7/16/2007. >>> Note: We can only hope the proliferation of SBC in VoIP service >>> provider >>> networks will not make these concerns and ICE for SIP a moot >>> issue, but >>> this is another topic. >> >> Henry, >> >> I don't quite understand why you are requesting a status change of >> ICE? To me it appears that ICE is almost finished spec. It has >> been implemented, used and feedback has been influencing the >> protocol. It is definitly one of the better examples of current >> IETF work that actually has running code. Sure, the >> implementations may not be fully updated yet to the latest draft >> version. But I think it is safe to say that ICE works in the >> intended core cases. If there are some corner cases where it >> fails, that may be. But that is not information we will have until >> really large scale deployement or someone makes very extensive tests. > > Henry has, I believe, been very consistent in urging the IETF to > have more "running code" experience on every specification (not > just ICE) than our process requires. He has, IIRC, also advocated > changing the process to require running code before publishing an > RFC. He's even suggested at times that one should have running code > before submitting a protocol draft. > > Another point to consider -- I've known Henry to bark at a tree > with no squirrel in it occasionally, but most of the time he's > pretty reliable, more so than most technology predictors. If he's > worried about ICE, it's probably because he's been talking to > people who are trying to implement it and they're telling him it is > difficult or that they're having performance or reliability issues. > I imagine that there are plenty of internal development teams in > various companies that are working on this and not necessarily > bringing their results back to the IETF. After all, if everybody > sees the emperor as fully clothed, they'd be embarrassed to > proclaim otherwise. Of course, I wish all of these developers were > tied into the IETF, but then I'm sure I don't want to see every ice- > implementor's question on the SIP list. That is why we have a sip- > implementors mailing list, right? > > Personally, I think ICE is the best solution we have. We KNOW of > cases where hole-punching doesn't work, and I think ICE will > produce usable results in most of those cases. But that's just my > personal opinion from reading the specs. I haven't implemented ICE, > and I haven't used anybody else's implementation. Sure, it's > complex, but that's because the underlying problem is complex -- > there are just too many different behaviors out there in "NAT and > firewall land". Of course, I could be wrong, too. It's happened > before, once or twice ;-). Just how sure are we that we're right > about this? > > Are we designing a "spruce goose" or a practical system? Only > experience will tell us. But some good flight reports from the > prototypes could go a long way towards reassuring us of the > design's utility. > > So far we've had a couple of people report hearsay evidence -- that > somebody else has an ICE implementation and it works. Any of you > folks have personal experience you can share? Have there been > prototypes exercised at the interop events? > > -- > Dean > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 18 22:56:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBMBo-0004Hq-59; Wed, 18 Jul 2007 22:56:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBMBm-0004HJ-Uc for sip-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 22:56:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBMBm-0004HA-Kp; Wed, 18 Jul 2007 22:56:26 -0400 Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBMBm-00089X-6y; Wed, 18 Jul 2007 22:56:26 -0400 Received: from [192.168.1.120] (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id 2E7CD75804E; Wed, 18 Jul 2007 21:56:25 -0500 (CDT) Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC From: "Frank W. Miller" To: Philip Matthews In-Reply-To: References: <239224.19734.qm@web33301.mail.mud.yahoo.com> <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> Content-Type: text/plain Date: Wed, 18 Jul 2007 20:56:09 -0600 Message-Id: <1184813769.3347.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Magnus Westerlund , behave@ietf.org, mmusic@ietf.org, sip@ietf.org, Pyda Srisuresh , Henry Sinnreich , p2psip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Wed, 2007-07-18 at 21:19 -0400, Philip Matthews wrote: > On 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > > > Phil, > > > >> In my view, ICE _is_ a "Hole Punching Technique". > > > > Yes, you absolutely right, though the devil is in the details. > > > > We cannot go here into a shoot-out between hole punching or other > > mentioned on the list vs. ICE, but there seems to be a huge difference > > in effectiveness and performance. > > What precise algorithm are you talking about when you say this? Well, here's the algorithm I use with my UA (the most recent versions I might add): STUN UA Registrar Server | REGISTER | | |-5060------->| | | w/rport | | | | | | 200 OK | | |<5060--------| | | | | | | | | STUN BReq | | |-5060--------------------->| | STUN BReq | | |-5004--------------------->| | STUN BResp | | |<5060----------------------| | STUN BResp | | |<5004----------------------| | | | | . | | | . | | | 10sec | | | . | | | . | | | | | | STUN BReq | | |-5060--------------------->| | STUN BResp | | |<5060----------------------| | STUN BReq | | |-5004--------------------->| | STUN BResp | | |<5004----------------------| | | | | | | I pick up the rport addressing during the REGISTER transaction because of the way my multithreading is done and because its nice to see the same value coming from two different sources out on the Internet. The port numbers on the UA are local port numbers. STUN BReq is a STUN binding request and STUN BResp is a STUN binding response. Port 5004 is for a single RTP session but the same algorithm is usable for any and all UDP ports you need, e.g. additional session ports and RTCP. The difference in order in the first and second sequence is intentional, the implementation doesn't care when the responses show up. This algorithm lets the UA know what its "visible" IP address and port is all the time (assuming that rport and STUN are working) and keeps it the same assuming that the NAT doesn't change it unilaterally (which I have yet to see BTW). When signaling occurs, the "visible" IP address and port are used in the Contact headers for SIP and in the SDP for offers/answers for RTP. Its just about as simple as it gets and I know you're going to say that it doesn't work 100% of the time. I haven't measured how well its done in deployments I've done as yet. I guess I need to do something along those lines. The good news is, I haven't had anyone complain about it so I guess I've been lucky. So let me have it... ;) Thanks, FM _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 00:22:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBNX2-0006UV-I9; Thu, 19 Jul 2007 00:22:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBNX0-0006UO-Fp for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 00:22:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBNX0-0006UG-59 for sip@ietf.org; Thu, 19 Jul 2007 00:22:26 -0400 Received: from alnrmhc16.comcast.net ([206.18.177.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBNWz-0003Ae-N5 for sip@ietf.org; Thu, 19 Jul 2007 00:22:26 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc16) with ESMTP id <20070719042224b16008umege>; Thu, 19 Jul 2007 04:22:24 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6J4K38t014645 for ; Thu, 19 Jul 2007 00:20:03 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6J4Jpad014623; Thu, 19 Jul 2007 00:19:51 -0400 Date: Thu, 19 Jul 2007 00:19:51 -0400 Message-Id: <200707190419.l6J4Jpad014623@dragon.ariadne.com> From: Dale.Worley@comcast.net To: sip@ietf.org In-reply-to: <003601c7c8eb$d99e04b0$7c6c460a@china.huawei.com> (sunqian@huawei.com) Subject: Re: [Sip] Comments on draft-ietf-sip-subnot-etags-00 References: <003601c7c8eb$d99e04b0$7c6c460a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Technical issues: What if both Suppress-Body-If-Match and SuppressN-Notify-If-Match are specified? We probably don't really care, but the document should make it clear if the combination is standardized or not. The entity-tag values for a single resource are the same across subscriptions, but it is not clear whether they are in some sense the same between subscriptions for different resources, or for different resource-IDs that refer to "the same" underlying resource. This may have significance for renewed subscriptions whose initial requests are sent to the same resource AOR but which are ultimately routed to different but "equivalent" resource-IDs. Nits: Section 2.2 o Relatively low rate of actual notifications triggered by actual state changes Better phrased "Relatively low rate of notifications triggered by state changes". Section 3: The entity-tag header is "SIP-ETag", but the "SIP-" portion is redundant. I suppose it's too late to change it to just "ETag". Sections 3 and 4.2: "two types of Xs" is better phrased "two Xs". Section 4.5: 2. If the condition evaluates to true, the notifier sends a 204 (No Notification) response sends no NOTIFY request. Should be "sends a 204 (No Notification) response and sends no NOTIFY request. Section 5.1: The notifier is free to decide the means for generating an entity-tag, except for the special "*" value. Better phrased "free to decide how to generate the entity-tag values, except that no entity-tag may be the special "*" value." Section 5.3: the notifier MUST suppress the resulting NOTIFY request, and generate a 204 (No Notification) "No Notification" response. Should be "a 204 (No Notification) response". Sections 8.3 and 8.4: This document registers two new SIP header field names. These headers are defined by the following information, which has been added to the header fields sub-registry under http://www.iana.org/assignments/sip-parameters. This paragraph is duplicated, and it appears to be addressing both header registrations together, rather than either one alone. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 01:53:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBOxK-00042Z-Um; Thu, 19 Jul 2007 01:53:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBOxI-0003zG-Uv for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 01:53:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBOxI-0003yx-BF for sip@ietf.org; Thu, 19 Jul 2007 01:53:40 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBOxG-00033W-3h for sip@ietf.org; Thu, 19 Jul 2007 01:53:40 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLE002ECWC5K8@szxga04-in.huawei.com> for sip@ietf.org; Thu, 19 Jul 2007 13:52:53 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLE00KS7WC4DI@szxga04-in.huawei.com> for sip@ietf.org; Thu, 19 Jul 2007 13:52:53 +0800 (CST) Received: from t34932 ([10.70.108.127]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLE00LTEWC0E4@szxml03-in.huawei.com> for sip@ietf.org; Thu, 19 Jul 2007 13:52:52 +0800 (CST) Date: Thu, 19 Jul 2007 13:52:48 +0800 From: Linyi Tian Subject: RE: [Sip] Comments and questions todraft-ietf-sip-uri-list-conferencing-01.txt In-reply-to: <469C7596.8090709@ericsson.com> To: 'Gonzalo Camarillo' Message-id: <036a01c7c9c9$097d13f0$7f6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Thread-index: AcfIR6PRdBIG8b/2Q8m2MHw6l+YvAgBgMirw X-Spam-Score: 1.2 (+) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Gonzalo But my question is when and how the rules are provided? For conferencing with pre-defined group the rules are typically specified by group owner (user). How about ad hoc conference? I think currently in PoC ad hoc session, the rules are only local policy for PoC Server, but not provided by initiator, right? If there is a mean for initiator to manipulate rules after session is created, it seems there is a risk after conf is created but rules are not ready. Some attendees may do something bad which is out of control during that period. This is not expected by the initiator. BR, Linyi -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] Sent: Tuesday, July 17, 2007 3:54 PM To: Linyi Tian Cc: sip@ietf.org Subject: Re: [Sip] Comments and questions todraft-ietf-sip-uri-list-conferencing-01.txt Hi Linyi, > (1) On section "5. Conference Server Procedures" > Many conference servers have restriction to maximum number of attendees > for conference. If the users of 'recipient-list' exceeds the limitation, > what status code should be returned? I would return a 403 (Too many recipients). > --------------------------------------- > 7. Security Considerations > This document discusses setup of SIP conferences using a > request-contained URI-list. Both conferencing and URI-lists services > have specific security requirements which will be summarized here. > Conferences generally have authorization rules about who can or cannot > join a conference, what type of media can or cannot be used, etc. This > information is used by the focus to admit or deny participation in a > conference. It is RECOMMENDED that these types of authorization rules > be used to provide security for a SIP conference. > ---------------------------------------- > (2) When and how the authorization rules are specified and applied to > the conference? Before the conference creation seems not possible since > Conf-URI is not assigned. If specified after the conference creation, it > seems there is a risk after conf is created but rules are not ready. > Some attendees may do something bad which is out of control during that > period. They are applied at conference creation. The server receives the request, creates the conference with its rules, and only adds the participants in the list if those rules allow it to do it. This is already implemented in the OMA PoC (Push-to-talk over Cellular) service. Thanks for your comments, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 02:14:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBPHf-00088v-JV; Thu, 19 Jul 2007 02:14:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBPHd-00088p-4m for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 02:14:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBPHc-00088e-Pf for sip@ietf.org; Thu, 19 Jul 2007 02:14:40 -0400 Received: from sip.tutpro.com ([192.98.100.10] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBPHb-0003XW-7I for sip@ietf.org; Thu, 19 Jul 2007 02:14:40 -0400 Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 354FB1EC694 for ; Thu, 19 Jul 2007 09:14:38 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Q3BASMqhS8E for ; Thu, 19 Jul 2007 09:14:36 +0300 (EEST) Received: from taimen (allozyme9.gprs.dnafinland.fi [62.78.104.9]) by tutpro.com (Postfix) with ESMTP for ; Thu, 19 Jul 2007 09:14:36 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 5DBEBAC1C9; Thu, 19 Jul 2007 09:14:29 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18079.325.333518.53741@tutpro.com> Date: Thu, 19 Jul 2007 09:14:29 +0300 To: sip@ietf.org Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org a while back i read ice tutorial slides and my impression was that the protocol was very complex (pity implementers) and provided only a bit better nat traversal capability than what [open]ser/rtpproxy/mediaproxy have been offering to lots of users for years already. because of this (complexity, little added value), i doubt that full ice will be widely implemented or used. i don't have any opinion on if ietf should publish the spec or not though, because there are already so many irrelevant rfcs out there that one more doesn't make any difference. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 02:45:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBPky-0005x8-Gy; Thu, 19 Jul 2007 02:45:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBPkw-0005wv-V8 for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 02:44:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBPks-0005wf-Sh; Thu, 19 Jul 2007 02:44:54 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBPks-0005sT-7J; Thu, 19 Jul 2007 02:44:54 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6J6ihpH030819; Thu, 19 Jul 2007 09:44:52 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 09:44:38 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 09:44:37 +0300 Received: from esdhcp05132.research.nokia.com ([172.21.51.32]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 09:44:33 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: mmusic@ietf.org, "ext Juha Heinanen" Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 09:43:17 +0300 User-Agent: KMail/1.9.6 References: <18079.325.333518.53741@tutpro.com> In-Reply-To: <18079.325.333518.53741@tutpro.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200707190943.17752.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 19 Jul 2007 06:44:33.0499 (UTC) FILETIME=[440642B0:01C7C9D0] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mmusic@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org [As Cullen pointed out, this is better located on MMUSIC. Thanks.] On Thursday 19 July 2007 09:14:29 ext Juha Heinanen wrote: > a while back i read ice tutorial slides and my impression was that the > protocol was very complex (pity implementers) and provided only a bit > better nat traversal capability than what [open]ser/rtpproxy/mediaproxy > have been offering to lots of users for years already. Media proxying is totally broken for a bunch of different reasons: 1/ Like many SIP ALGs - it screws the signaling when it does not understand= =20 something. Last time I tried OpenSER media proxying, TCP/COMEDIA sessions d= id=20 not work at all (even with public unfirewalled IPs on both endpoints). 2/ At least mediaproxy implementation does not scale at all. It might be go= od=20 if one's business consists of selling relay boxes. That's an implementation= =20 issue however. 3/ It is totally fatally insecure by design. It is trivial to DoS, or worse= ,=20 hijack, a media flow by sending fake RTP probe packets to the relay. > because of this (complexity, little added value), i doubt that full ice > will be widely implemented or used. i don't have any opinion on if ietf > should publish the spec or not though, because there are already so many > irrelevant rfcs out there that one more doesn't make any difference. 3/ ICE is secure: no voice hammer, no media hijacking. 2/ ICE scales well as it puts the hard work on the endpoints (and usage of= =20 TURN may be limited to worst cases). 1/ ICE does not screw up the SIP signaling, and you do not need to buy a SI= P=20 server upgrade to support the next SDP extension. In all due fairness, simple hole punching also has advantages 1 and 2 over= =20 media relaying. And it is about as secure as SIP without any traversal=20 mechanism, which is to say, less secure than ICE, but much more secure than= =20 media relaying. Regards, =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 02:46:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBPmk-0006Xy-OU; Thu, 19 Jul 2007 02:46:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBPmi-0006Xt-V5 for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 02:46:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBPmi-0006Xl-LW for sip@ietf.org; Thu, 19 Jul 2007 02:46:48 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBPmg-0004Gs-VB for sip@ietf.org; Thu, 19 Jul 2007 02:46:48 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 844112103C; Thu, 19 Jul 2007 08:46:12 +0200 (CEST) X-AuditID: c1b4fb3e-b0835bb0000007e1-01-469f08b41728 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4393621A25; Thu, 19 Jul 2007 08:46:12 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 08:46:11 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 08:46:11 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6788525D8; Thu, 19 Jul 2007 09:46:11 +0300 (EEST) Message-ID: <469F08B3.7080509@ericsson.com> Date: Thu, 19 Jul 2007 09:46:11 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Qian Sun Subject: Re: [Sip] Comments on draft-ietf-sip-multiple-refer-01.txt References: <003701c7c9a6$d29fa360$7c6c460a@china.huawei.com> In-Reply-To: <003701c7c9a6$d29fa360$7c6c460a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 19 Jul 2007 06:46:11.0463 (UTC) FILETIME=[7E6A6170:01C7C9D0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: 'Miguel Garcia' , 'sip' , 'Aki Niemi' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, as I stated before, at this point, if you think specifying this feature=20 is useful, it should be done in a separate (new) spec. It is too late in=20 the process to add new features to the multiple-refer draft. Cheers, Gonzalo Qian Sun wrote: > Hi, Robert and Gonzalo >=20 > IMO, "multiple refer" doesn't need AIB part of Referred-By. As Gonzalo = said, the relay (e.g. conference server) understand what is going on, it = must have authenticated the identity of the Referrer. So the Referred-By = header field and 'recipient-list-history'(the same function as Refer-To) = are creditable for final REFER-Target. >=20 > The triggered SIP message sent by the relay just needs to include Refer= red-By header field (maybe plus recipient-list-history), the Referred-By = token is not necessary (like the example "7.2. Insecure REFER" in rfc3892= ). The information in Referred-By header field is still very useful for f= inal REFER-Target to learn the source of the message.=20 >=20 > It's not worth writing a separate spec for this, just adding few texts = to this draft may be OK. Since this draft has mentioned Refer-Sub, why no= t says something about Referred-By? >=20 > BTW, there are very few commercial IMS implementations on the planet, b= ut we believe the future of IMS must not bad, maybe same to Referred-By w= ith AIB. >=20 > Cheers, > Qian >=20 > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 > Sent: Tuesday, July 17, 2007 10:43 PM > To: Gonzalo Camarillo > Cc: Qian Sun; Miguel Garcia; sip; Aki Niemi; Markus.Isomaki@nokia.com> = Subject: Re: [Sip] Re: [Sipping] RE: Comments on draft-ietf-sip-multipl= e-refer-01.txt >=20 > As much as I like the Referred-By mechanism, before investing too =20 > much time into extending Referred-by for this case, ask yourself =20 > seriously > if there is a customer for the work. AFAIK, there are no =20 > implementations of the AIB part of Referred-by on the planet (please =20 > speak up if you > have one) and I know of no-one who plans to build it. Unless that =20 > changes, I think we'd all be better off spending our time working on =20 > things > that people will actually use. >=20 > RjS >=20 >=20 > On Jul 17, 2007, at 1:34 AM, Gonzalo Camarillo wrote: >=20 >> Hi, >> >> [moving this thread from the SIPPING list to this one (SIP) because =20 >> this is a SIP document now.] >> >> You are right. It is not trivial to use Referred-By with multiple =20 >> REFER. My suggestion is that, the same way as Referred-By is =20 >> specified as an extension of refer, you go ahead specify (if you =20 >> are interested) how to use Referred-by with multiple REFER in a =20 >> different spec. >> >> The body that the referrer would add to its REFER (which is what =20 >> the refer target would get) could be an XML list with the =20 >> recipients (those that can be disclosed) of the multiple REFER =20 >> (plus the referrer). Something similar to what recipients get after =20 >> a relay processes a list with copyControl attributes (draft-ietf-=20 >> sipping-capacity-attribute-04.txt)... in any case, since multiple =20 >> REFER is only used within a context of a service, you need to think =20 >> whether having a general Referred-By mechanism is needed or if such =20 >> functionality can be achieved in a different way within the =20 >> services multiple REFER is used in (e.g., conferencing). >> >> Cheers, >> >> Gonzalo >> >> >> Qian Sun wrote: >>> Hello, Gonzalo >>> RFC3892 says: >>> The sipfrag inside a Referred-By token MUST contain copies of the >>> Refer-To, Referred-By, and Date header fields from the REFER =20 >>> request. >>> In multiple refer case, the Refer-To header field includes content =20 >>> id, not the REFER-Target' URI. The content id is meaningless to =20 >>> the REFER-Targets, so the Referred-By token has to include the URI-=20 >>> List. >>> Cheers, >>> Qian >>> -----Original Message----- >>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>> Sent: Monday, July 16, 2007 4:23 PM >>> To: Qian Sun >>> Cc: Aki.Niemi@nokia.com; Markus.Isomaki@nokia.com; =20 >>> miguel.an.garcia@nokia.com; hisham.khartabil@gmail.com; =20 >>> sipping@ietf.org >>> Subject: Re: Comments on draft-ietf-sip-multiple-refer-01.txt >>> Hi, >>> thanks for your comments. Answers inline: >>> Qian Sun wrote: >>> > Some comments on the draft... >>> > >>> > 1. I think it might be a good idea to talk something on =20 >>> "Referred-By" in this draft. Referred-By mechanism is still very =20 >>> useful for the multiple refer case. Maybe Refer-To related to a =20 >>> URI List with "bcc" or "anonymize" is a trouble. "Referred-BY=E2=80=9D= in =20 >>> the message header is to identify the initial REFER-Issuer. This =20 >>> information may be encrypted together with "refer-to" URI list, =20 >>> including the copy control level such as to/cc/bcc to the end =20 >>> user, i.e. REFER-Target, where the information will be decrypted =20 >>> by the REFER-Target. In this case the REFER-Recipient won=E2=80=99t b= e =20 >>> able to get rid of the "bcc" URI from the URI list, and the "bcc" =20 >>> URI will be sent to other REFER-Targets along with normal to/cc. =20 >>> This will be a problem to destroy the blind cc function. >>> > However, the REFER-issuer may opt to not include a Referred-By =20 >>> token. For example: >>> > REFER sip:conf-123@example.com;gruu;opaque=3Dhha9s8d-999a SIP/= =20 >>> 2.0 >>> > Refer-To: >>> > Referred-By: Carol >>> > Content-Type: application/resource-lists+xml >>> > Content-Disposition: recipient-list >>> > Content-Length: 362 >>> > Content-ID: >>> > >>> > >>> > >> > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"= > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > When the URI list has no "bcc" or "anonymize" URI, REFER-issuer =20 >>> may include the Referred-By token in the REFER body. >>> The way Referred-By works is not affected by what this draft says. >>> Therefore, I do not see the need to talk about it. >>> > >>> > 2. Nested refer in multiple refer is very interesting, I =20 >>> believe it could be a good idea to enroll a "multiple nested =20 >>> refer" example into this draft. Just for an example: >>> > REFER sip:list-service@example.com;gruu;opaque=3Dhha9s8d-999a = =20 >>> SIP/2.0 >>> > Refer-To: >>> > Content-ID: >>> > >>> > >>> > >> > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"= > >>> > >>> > >> 3Dsip:conf-123%40shenzhen.example.com" /> >>> > >> 3Dsip:conf-123%40shenzhen.example.com" /> >>> > >>> > >>> > In this case, the REFER-Recipient acts as a Refer List service, =20 >>> has the similar function to the MESSAGE List service, i.e. =20 >>> receives a REFER with URI-List and distributes some REFERs to each =20 >>> address in the URI-List. >>> > Note that, there is only one final REFER-Target in above =20 >>> "nested multiple refer" example, not multiple REFER-Targets. In =20 >>> some situations, this convergent feature is useful. >>> The draft says the following: >>> Additionally, REFER-Recipients SHOULD only accept REFER requests >>> within the context of an application the server understands =20 >>> (e.g., a >>> conferencing application). >>> this text was added to avoid relays being used as random traffic >>> forwarders. Therefore, since a relay needs to understand what is =20 >>> going >>> on (e.g., a multiple REFER to trigger BYEs towards several conference >>> attendees) and currently there is no service that uses nested =20 >>> refers, I >>> do not think we need to talk about it. >>> > >>> > 3. I guess it might be a typo in Figure 2 "8. 200K OK", maybe =20 >>> you meant "200 OK"? >>> yes, thanks for pointing it out. We will fix it. >>> Thanks, >>> Gonzalo >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sip@ietf.org for new developments of core SIP >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 02:51:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBPrc-0006wU-70; Thu, 19 Jul 2007 02:51:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBPrZ-0006tr-R5 for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 02:51:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBPrZ-0006tj-G1 for sip@ietf.org; Thu, 19 Jul 2007 02:51:49 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBPrY-00061a-Oj for sip@ietf.org; Thu, 19 Jul 2007 02:51:49 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C47FB20DD4; Thu, 19 Jul 2007 08:51:46 +0200 (CEST) X-AuditID: c1b4fb3c-aee7cbb0000007e1-be-469f0a022c85 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A18AD20A29; Thu, 19 Jul 2007 08:51:46 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 08:51:46 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 08:51:45 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0F2F42903; Thu, 19 Jul 2007 09:51:46 +0300 (EEST) Message-ID: <469F0A01.6040609@ericsson.com> Date: Thu, 19 Jul 2007 09:51:45 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Linyi Tian Subject: Re: [Sip] Comments and questions todraft-ietf-sip-uri-list-conferencing-01.txt References: <036a01c7c9c9$097d13f0$7f6c460a@china.huawei.com> In-Reply-To: <036a01c7c9c9$097d13f0$7f6c460a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 06:51:46.0035 (UTC) FILETIME=[45D60430:01C7C9D1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, the problem of doing many things in one SIP operation (i.e., in a SIP request) is that it is difficult to report errors if something goes wrong. If you want to create an ad-hoc conference with rules that are different from the default ad-hoc conference, you can always use a different way to create the conference (i.e., without using URI lists; using a conference control protocol). URI lists are an optimization for the more typical use cases where session establishment should be very fast. Cheers, Gonzalo Linyi Tian wrote: > Hi, Gonzalo > But my question is when and how the rules are provided? For conferencing with pre-defined group the rules are typically specified by group owner (user). How about ad hoc conference? > I think currently in PoC ad hoc session, the rules are only local policy for PoC Server, but not provided by initiator, right? If there is a mean for initiator to manipulate rules after session is created, it seems there is a risk after conf is created but rules are not ready. Some attendees may do something bad which is out of control during that period. This is not expected by the initiator. > BR, > Linyi > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Tuesday, July 17, 2007 3:54 PM > To: Linyi Tian > Cc: sip@ietf.org > Subject: Re: [Sip] Comments and questions todraft-ietf-sip-uri-list-conferencing-01.txt > > Hi Linyi, > >> (1) On section "5. Conference Server Procedures" >> Many conference servers have restriction to maximum number of attendees >> for conference. If the users of 'recipient-list' exceeds the limitation, >> what status code should be returned? > > I would return a 403 (Too many recipients). > >> --------------------------------------- >> 7. Security Considerations >> This document discusses setup of SIP conferences using a >> request-contained URI-list. Both conferencing and URI-lists services >> have specific security requirements which will be summarized here. >> Conferences generally have authorization rules about who can or cannot >> join a conference, what type of media can or cannot be used, etc. This >> information is used by the focus to admit or deny participation in a >> conference. It is RECOMMENDED that these types of authorization rules >> be used to provide security for a SIP conference. >> ---------------------------------------- >> (2) When and how the authorization rules are specified and applied to >> the conference? Before the conference creation seems not possible since >> Conf-URI is not assigned. If specified after the conference creation, it >> seems there is a risk after conf is created but rules are not ready. >> Some attendees may do something bad which is out of control during that >> period. > > They are applied at conference creation. The server receives the > request, creates the conference with its rules, and only adds the > participants in the list if those rules allow it to do it. This is > already implemented in the OMA PoC (Push-to-talk over Cellular) service. > > Thanks for your comments, > > Gonzalo > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 03:31:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBQTa-00008p-Qk; Thu, 19 Jul 2007 03:31:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBQTZ-0008Tj-4c for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 03:31:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBQTY-0008RV-Qh for sip@ietf.org; Thu, 19 Jul 2007 03:31:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBQSz-00082v-EA for sip@ietf.org; Thu, 19 Jul 2007 03:30:29 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBQSy-00059t-8i for sip@ietf.org; Thu, 19 Jul 2007 03:30:29 -0400 Received: by py-out-1112.google.com with SMTP id f31so1514962pyh for ; Thu, 19 Jul 2007 00:30:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=ZcHltVXOFkX9VZKyLpHsKaeKLzokqU/LRnZ+UAv0NqlDsf/rRXmkkrpDFEdLEaS+ceDEwuaNU3NMiUJITw25YhSy+mwEbYsf8XNxrneFcl13rkJNWwBdWgKZTVjdHAtxlZ6+qYYkmocUAiRV9kXpIGxDIF5tFVzB/XPUKmmJHSg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=rpaQhf/YGTA7B6Bsl/S4RSsJdz6AD58hNp1n2XQgJKWGqLCbWM83DmDT9Kk2eUq3L8irRmMEtuQMg3f46YmyM/0YoXGTwx8hvKF/vXI7rQ9WMOflVeFkEJzbs0LYqVY1CHkFC24IQFeTcLVek/DXStHhkKpnZqsosUBt+6DxRZg= Received: by 10.65.176.3 with SMTP id d3mr4200394qbp.1184830227668; Thu, 19 Jul 2007 00:30:27 -0700 (PDT) Received: by 10.64.253.11 with HTTP; Thu, 19 Jul 2007 00:30:27 -0700 (PDT) Message-ID: <66fe674b0707190030n63781e1ao5d2ff69fede430d9@mail.gmail.com> Date: Thu, 19 Jul 2007 13:00:27 +0530 From: "vishal jogi" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-TMDA-Confirmed: Thu, 19 Jul 2007 03:31:04 -0400 Subject: [Sip] Event - list subscribe X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1302258331==" Errors-To: sip-bounces@ietf.org --===============1302258331== Content-Type: multipart/alternative; boundary="----=_Part_70595_17052737.1184830227432" ------=_Part_70595_17052737.1184830227432 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I have one doubt. i m subscribing to RLS uri, which is refering one Resource-list which doesn't have any mean it's blank server is sending 404 as response for Subscribe, can anyone tell me it's correct behaviour of server, as that is existing Thanks, Vishal... ------=_Part_70595_17052737.1184830227432 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
        Hi,
        I have one doubt.
         
        i m subscribing to RLS uri,
        which is refering one Resource-list which doesn't have any <entry>
        mean it's blank <LIST>
         
        server is sending 404 as response for Subscribe, can anyone tell me it's correct behaviour of server,
        as that <LIST> is existing
         
        Thanks,
        Vishal...
        ------=_Part_70595_17052737.1184830227432-- --===============1302258331== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1302258331==-- From sip-bounces@ietf.org Thu Jul 19 03:41:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBQdG-0004BF-OR; Thu, 19 Jul 2007 03:41:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBQdF-0004AD-8Y for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 03:41:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBQdE-000499-Sk for sip@ietf.org; Thu, 19 Jul 2007 03:41:04 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBQdE-00079p-30 for sip@ietf.org; Thu, 19 Jul 2007 03:41:04 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLF00EVV1BGNE@szxga04-in.huawei.com> for sip@ietf.org; Thu, 19 Jul 2007 15:40:28 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLF007TK1BFCS@szxga04-in.huawei.com> for sip@ietf.org; Thu, 19 Jul 2007 15:40:28 +0800 (CST) Received: from t34932 ([10.70.108.127]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLF00CBT1BCTV@szxml03-in.huawei.com> for sip@ietf.org; Thu, 19 Jul 2007 15:40:27 +0800 (CST) Date: Thu, 19 Jul 2007 15:40:23 +0800 From: Linyi Tian Subject: RE: [Sip] Comments and questions todraft-ietf-sip-uri-list-conferencing-01.txt In-reply-to: <469F0A01.6040609@ericsson.com> To: 'Gonzalo Camarillo' Message-id: <038001c7c9d8$111d24b0$7f6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Thread-index: AcfJ0UeaybRuxeXZSq65Tb/gO9IVrwABoTfw X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Gonzalo > the problem of doing many things in one SIP operation (i.e., in a SIP > request) is that it is difficult to report errors if something goes wrong. [Linyi] I think this problem might exist in URI List Conferencing. For example, too many recipients, URI format is invalid, etc. Do we need to consider these error conditions? > If you want to create an ad-hoc conference with rules that are different > from the default ad-hoc conference, you can always use a different way > to create the conference (i.e., without using URI lists; using a > conference control protocol). URI lists are an optimization for the more > typical use cases where session establishment should be very fast. [Linyi] I agree fast is important. Beyond fast experience users also care about rules of a conference. And in some scenarios default rules obviously can not fulfill their expectation. For example, Initiator wants to provide some simple rules such as maximum attendee number, whether allow inviting new person, etc. I have to admit conf control protocol is too heavy to do that for ad hoc conference. BR, Linyi Linyi Tian wrote: c Hi, Gonzalo > But my question is when and how the rules are provided? For conferencing with pre-defined group the rules are typically specified by group owner (user). How about ad hoc conference? > I think currently in PoC ad hoc session, the rules are only local policy for PoC Server, but not provided by initiator, right? If there is a mean for initiator to manipulate rules after session is created, it seems there is a risk after conf is created but rules are not ready. Some attendees may do something bad which is out of control during that period. This is not expected by the initiator. > BR, > Linyi > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Tuesday, July 17, 2007 3:54 PM > To: Linyi Tian > Cc: sip@ietf.org > Subject: Re: [Sip] Comments and questions todraft-ietf-sip-uri-list-conferencing-01.txt > > Hi Linyi, > >> (1) On section "5. Conference Server Procedures" >> Many conference servers have restriction to maximum number of attendees >> for conference. If the users of 'recipient-list' exceeds the limitation, >> what status code should be returned? > > I would return a 403 (Too many recipients). > >> --------------------------------------- >> 7. Security Considerations >> This document discusses setup of SIP conferences using a >> request-contained URI-list. Both conferencing and URI-lists services >> have specific security requirements which will be summarized here. >> Conferences generally have authorization rules about who can or cannot >> join a conference, what type of media can or cannot be used, etc. This >> information is used by the focus to admit or deny participation in a >> conference. It is RECOMMENDED that these types of authorization rules >> be used to provide security for a SIP conference. >> ---------------------------------------- >> (2) When and how the authorization rules are specified and applied to >> the conference? Before the conference creation seems not possible since >> Conf-URI is not assigned. If specified after the conference creation, it >> seems there is a risk after conf is created but rules are not ready. >> Some attendees may do something bad which is out of control during that >> period. > > They are applied at conference creation. The server receives the > request, creates the conference with its rules, and only adds the > participants in the list if those rules allow it to do it. This is > already implemented in the OMA PoC (Push-to-talk over Cellular) service. > > Thanks for your comments, > > Gonzalo > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 04:12:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBR7c-0000mj-4M; Thu, 19 Jul 2007 04:12:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBR7a-0000mJ-HQ for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 04:12:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBR7a-0000mB-6J for sip@ietf.org; Thu, 19 Jul 2007 04:12:26 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBR7Y-0006Fr-Nj for sip@ietf.org; Thu, 19 Jul 2007 04:12:26 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C2B6120A4F; Thu, 19 Jul 2007 10:12:23 +0200 (CEST) X-AuditID: c1b4fb3c-b067fbb0000007e1-65-469f1ce736d4 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A8B9D2046C; Thu, 19 Jul 2007 10:12:23 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 10:12:23 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 10:12:23 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2A2D424C0; Thu, 19 Jul 2007 11:12:23 +0300 (EEST) Message-ID: <469F1CE7.3090003@ericsson.com> Date: Thu, 19 Jul 2007 11:12:23 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Linyi Tian Subject: Re: [Sip] Comments and questions todraft-ietf-sip-uri-list-conferencing-01.txt References: <038001c7c9d8$111d24b0$7f6c460a@china.huawei.com> In-Reply-To: <038001c7c9d8$111d24b0$7f6c460a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 08:12:23.0145 (UTC) FILETIME=[88FA6D90:01C7C9DC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >> the problem of doing many things in one SIP operation (i.e., in a >> SIP request) is that it is difficult to report errors if something >> goes wrong. > [Linyi] I think this problem might exist in URI List Conferencing. > For example, too many recipients, URI format is invalid, etc. Do we > need to consider these error conditions? Yes, it exists. That's why you want to use that mechanism only in the context of a well-defined service that is scoped well-enough (e.g., ad-hoc sessions in PoC) so that it does not create complex error situations when the mechanism is used. Cheers, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 04:55:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBRml-0002RO-CQ; Thu, 19 Jul 2007 04:54:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBRmj-0002RJ-MK for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 04:54:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBRmj-0002RB-CC for sip@ietf.org; Thu, 19 Jul 2007 04:54:57 -0400 Received: from wx-out-0506.google.com ([66.249.82.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBRmi-0007Cd-OY for sip@ietf.org; Thu, 19 Jul 2007 04:54:57 -0400 Received: by wx-out-0506.google.com with SMTP id h27so411333wxd for ; Thu, 19 Jul 2007 01:54:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EeBlTCFq9DDKM2ZXFSFFkIUG/zl9epJmfXLlle+Ydy30bTvMfkyUpjqaKJNUA4VkhuhtzfYXONdk/4mCPvBZTInKsrTu09m5kBw2DwfuAg3X2rSTKHjX7vPRnBbU866S7Q9GlF38KXbsN0jhAtNZAfTce3E6y++LWyKD0y0uzrU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Euq0woprjHxDjfRp0mb7eABUsQhxUjBHyFHxQhQo/aTqvn7+wztDh9Cm+XDWdXW81NT9tJduvKJyjxaaXU//pagewelQvyyp6B5gs2hrdT5E0IoaPDwkKZfdrMp64tPkjYsU3D5Oegrn/VqPYoAuiBXE5TGF5ym7MhKp9YLQMQw= Received: by 10.78.147.6 with SMTP id u6mr687669hud.1184835295687; Thu, 19 Jul 2007 01:54:55 -0700 (PDT) Received: by 10.78.133.10 with HTTP; Thu, 19 Jul 2007 01:54:53 -0700 (PDT) Message-ID: Date: Thu, 19 Jul 2007 14:24:53 +0530 From: "Vikram Chhibber" To: "vishal jogi" Subject: Re: [Sip] Event - list subscribe In-Reply-To: <66fe674b0707190030n63781e1ao5d2ff69fede430d9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <66fe674b0707190030n63781e1ao5d2ff69fede430d9@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sip@ietf.org, sip-implementors-request@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't think that this is correct behavior of the RLS. If the RLS understands the uri pointing to a resource-list. It should accept this subscription. Even though the list is empty. The user/administrator may provision entries in this list in future by non-SIP mechanism (XCAP). On 7/19/07, vishal jogi wrote: > Hi, > I have one doubt. > > i m subscribing to RLS uri, > which is refering one Resource-list which doesn't have any > mean it's blank > > server is sending 404 as response for Subscribe, can anyone tell me it's > correct behaviour of server, > as that is existing > > Thanks, > Vishal... > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on > current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 06:00:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBSni-0006yX-MA; Thu, 19 Jul 2007 06:00:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBSng-0006xN-VU for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 06:00:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBSng-0006xF-JT for sip@ietf.org; Thu, 19 Jul 2007 06:00:00 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBSnf-0000Rd-Kp for sip@ietf.org; Thu, 19 Jul 2007 06:00:00 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8A5F721973; Thu, 19 Jul 2007 11:59:58 +0200 (CEST) X-AuditID: c1b4fb3e-b1036bb0000007e1-f0-469f361d52ce Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 896DD21322; Thu, 19 Jul 2007 11:59:57 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 11:59:57 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 11:59:56 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D52A924C0; Thu, 19 Jul 2007 12:59:56 +0300 (EEST) Message-ID: <469F361C.1080908@ericsson.com> Date: Thu, 19 Jul 2007 12:59:56 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Kyzivat Subject: References to Body Parts WAS (Re: [Sip] Draft slides for body (MIME) handling) References: <469DF98F.3060506@ericsson.com> <469E261B.7090804@cisco.com> In-Reply-To: <469E261B.7090804@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 09:59:56.0811 (UTC) FILETIME=[8FA9B5B0:01C7C9EB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Paul, > Thanks for sending out in advance. Maybe we can get into the discussion > of the slides now, before the meeting. yes, that was the intention. > Regarding references to body parts: > > IMO it is a *bad* idea to make the decision about processing of a body > part "on its own" dependent on whether the node doing so has detected a > reference to that body part or not. > > For one thing, that requires a multi-pass parsing mechanism to check for > references before deciding what processing to do on a particular part. > For another, it requires that the recipient understand every reference. > For instance, the sender may have included an extension header that > contains a reference to a body part. If the extension isn't understood, > then the body part should not be processed. But if the recipient doesn't > understand the extension then it won't recognize the reference either, > and so will attempt to process the body part as one without references. yes, these two issues are described in the draft. > The only good solution I see to this is to partition the > Content-Disposition and/or Content-Type values whose processing is > dependent on reference from those whose processing is not dependent on a > reference. For instance, we could simply define a new > Content-Disposition of "by-reference". > > Then a normal sequence of processing would be to first process all the > body parts according to their type and disposition alone. Any with > disposition "by-reference" would be set aside. Then, when processing > headers, if a header with a reference is encountered the appropriate > processing could be applied to the set aside body part. References > within other body parts would be a little more complex, but you get the > idea. yes. When looking for references, one would need to process the header fields plus the body parts with a disposition type different than 'by-reference', since, as you point out, those body parts could contain references to 'by-reference' body parts. The only case we would not cover would be two (or more) 'by-reference' body parts referencing each other. But we can just say that this is forbidden (no extension does that at present). > This would not prevent reference to body parts with other dispositions. > It just means that those body parts would also be processed according to > their type and disposition, in addition to any processing they might get > according to their reference. The "by-reference" disposition is just a > defintion that gets no implicit processing. yes, the draft already talks about the possibility of having several references to a body part. In such a case, the body part would need to be processed several times (in different ways). However, the case you are talking about is not currently addresses (i.e., a body part is processed once based on a reference and another time based on its content disposition). None of these situations occur within current extensions, but they could happen in the future. > An advantage of this approach is that by-reference body parts don't need > to be parsed unless the reference is processed and the action required > in processing the reference requires the node to parse the referenced > body. (Interaction with handling=required in this case is TBD.) Even a > multipart with disposition of by-reference might not need to be parsed. The interaction with handling=required would be that if you are not able to find a reference to a 'by-reference' body part with handling=required, you report an error because you have not been able to process the body part. This approach would work and has the advantage to be explicit about how a body part is expected to be processed... I would like to hear more opinions on this. Cheers, Gonzalo > Gonzalo Camarillo wrote: >> Folks, >> >> here you have the slides I have put together for the body (MIME) >> handling presentation on Monday: >> >> http://users.piuha.net/gonzalo/temp/ietf69-sip-camarillo-body-handling.ppt >> >> >> These slides relate to this draft: >> >> http://www.ietf.org/internet-drafts/draft-camarillo-sip-body-handling-01.txt >> >> >> The slides discuss all the open issues that have been brought up in >> the list in the last months. >> >> Comments are welcome. >> >> Thanks, >> >> Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 06:10:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBSy5-00073M-1H; Thu, 19 Jul 2007 06:10:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBSy3-0006xS-70 for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 06:10:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBSy2-0006v8-SU for sip@ietf.org; Thu, 19 Jul 2007 06:10:42 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBSy2-0000jy-7z for sip@ietf.org; Thu, 19 Jul 2007 06:10:42 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AAF6C20FFA; Thu, 19 Jul 2007 12:10:41 +0200 (CEST) X-AuditID: c1b4fb3e-ae831bb0000007e1-98-469f38a1dc60 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 874C32124A; Thu, 19 Jul 2007 12:10:41 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 12:10:41 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 12:10:40 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E738024C0; Thu, 19 Jul 2007 13:10:40 +0300 (EEST) Message-ID: <469F38A0.7090404@ericsson.com> Date: Thu, 19 Jul 2007 13:10:40 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Kyzivat Subject: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides for body (MIME) handling) References: <469DF98F.3060506@ericsson.com> <469E261B.7090804@cisco.com> In-Reply-To: <469E261B.7090804@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 10:10:41.0090 (UTC) FILETIME=[0FAEE220:01C7C9ED] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Paul, > Regarding Content-Disposition in multiparts: > > While it seems "wrong" to me, I can live with using "render" as the > normal disposition for multipart, *if* we can do a careful job of > defining what "render" actually means for SIP. Used this way it clearly > doesn't always mean to display the content to a user. An entity receiving a 'multipart/mixed' body will process its body parts based on their disposition types.If the disposition type of a particular body part is not understood, it will be displayed to the user because the default disposition type is 'render'. Therefore, the 'multipart/mixed' body will never be processed based on its disposition type. This means that it does not make much sense to talk about its disposition type as a whole. However, we need to have one in order to be able to set its handling parameter. That's why we can either keep 'render' explaining that it is actually never used or define a new disposition type. Since existing implementations will not understand our newly defined disposition type, they will treat it as 'render' anyway... but the resulting behavior would be the same. That's why it may make sense to keep using 'render'. On the other hand, semantically, it would make more sense to define a new disposition type. Also, if we decide to define the 'by-reference' disposition type (per a different email thread), it could be used here as well. Cheers, Gonzalo > Gonzalo Camarillo wrote: >> Folks, >> >> here you have the slides I have put together for the body (MIME) >> handling presentation on Monday: >> >> http://users.piuha.net/gonzalo/temp/ietf69-sip-camarillo-body-handling.ppt >> >> >> These slides relate to this draft: >> >> http://www.ietf.org/internet-drafts/draft-camarillo-sip-body-handling-01.txt >> >> >> The slides discuss all the open issues that have been brought up in >> the list in the last months. >> >> Comments are welcome. >> >> Thanks, >> >> Gonzalo >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 06:11:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBSyr-0008LQ-CQ; Thu, 19 Jul 2007 06:11:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBSyq-0008LI-Iz for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 06:11:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBSyq-0008L9-8i for sip@ietf.org; Thu, 19 Jul 2007 06:11:32 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBSyo-0000lG-Uo for sip@ietf.org; Thu, 19 Jul 2007 06:11:32 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6A0B220547; Thu, 19 Jul 2007 12:11:30 +0200 (CEST) X-AuditID: c1b4fb3c-af67dbb0000007e1-6c-469f38d1a8c6 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EC2EC20497; Thu, 19 Jul 2007 12:11:29 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 12:11:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP Identity using Media Path Date: Thu, 19 Jul 2007 12:11:28 +0200 Message-ID: <7374777208BDC7449D5620EF94232567073F7740@esealmw113.eemea.ericsson.se> In-Reply-To: <083e01c7bcfd$6842e230$2014590a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Identity using Media Path Thread-Index: Ace82p2yNu6lfaNzQcq8BXk5gCIEoQAHC+iwAAFo/cADO9lZkA== References: <7374777208BDC7449D5620EF9423256706D44E57@esealmw113.eemea.ericsson.se> <083e01c7bcfd$6842e230$2014590a@amer.cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Dan Wing" , X-OriginalArrivalTime: 19 Jul 2007 10:11:29.0761 (UTC) FILETIME=[2CB17D10:01C7C9ED] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>"in order for the mechanism to work, SBC-type-of-entities must permit=20 >>DTLS, TLS, ICE, or HIP messages to be exchanged in the media path." >>=20 >>A small question for clarification: at what point must this exchange=20 >>(two-way, I assume) work? As soon as the UAS has received the INVITE? >=20 >Yes. A little more on this. As we have discussed before, you may not have two-way connectivity before 200 OK. Now assume that you will have two-way connectivity before you have even sent the SDP answer. I am pretty sure what will not work with most SBCs. Also, even if you don't have any SBCs, but you still have NATs, the calling user often needs to send something in order to open the NAT binding, and allow media plane traffic (including your identity exchange) from the remote end. If you use ICE, or stand-alone STUN, you will have an open NAT binding, but if your terminal opens the network e.g. by sending dummy RTP packets, it will not be able to do so until it has received the SDP answer. So, I also think your solution requires support of ICE/STUN, and in the case of ICE it also requires that the SBCs don't mess up the SDP so that ICE will not be used. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 06:26:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBTD4-0002Il-QY; Thu, 19 Jul 2007 06:26:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBTD2-0002Dk-Uo for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 06:26:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBTD2-0002BM-HX for sip@ietf.org; Thu, 19 Jul 2007 06:26:12 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBTD0-00014W-Uk for sip@ietf.org; Thu, 19 Jul 2007 06:26:12 -0400 Received: from lappy ([67.161.59.204]) by quinthar.com for ; Thu, 19 Jul 2007 03:15:57 -0700 From: "David Barrett" To: "'Cullen Jennings'" , "'SIP'" , "'Behave WG'" , Subject: RE: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 03:15:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <13AC112D-E5EF-438B-97C8-9F3827EA07BF@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfJsHPx6frYreoETXCtB795NMQVMAANmm8Q X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Message-Id: Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Cullen, I think you bring up lot of really great and detailed questions. However, speaking for myself at least, answering those questions doesn't really address my concern. All I want to know is: Does ICE work, and how well? What "works" means is entirely open to debate. I've tossed out "high peer connectivity" and "low connection setup time" as the most important criteria, and I've put hard data behind those numbers as a stake in the ground for comparison, but I'm open to other metrics as well. But regardless of the metrics, I want somebody who uses it and loves it and bases their business upon its success to stand up and explain why it's great. And I want this person to provide real-world data, sampled on a wide scale, proving that ICE "works" -- by any definition. Basically, I want ICE firmly grounded in wide-scale testing and real-world data, and answering the questions below doesn't bring us any closer to that. Whether it's level 10 or level 12 doesn't produce new data. How its algorithms differ from competing ones doesn't show that they're any better or worse. Detailed proposals for change don't shed any light on whether those changes improve or worsen it, because its current state is completely unmeasured. The most powerful thing the IETF can do to standardize the world upon ICE is prove that it works better than any alternative. Because until that's proven, we just need to take it as a matter of faith. -david > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Wednesday, July 18, 2007 7:56 PM > To: SIP; Behave WG; mmusic@ietf.org > Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC > > > First I apologize for the cross post - this is a mmusic draft, I > would appreciate replies on the mmusic list only. > > Few things I am looking for here .... > > 1) specific reasons why this work is less appropriate for standards > track than other work that IETF puts on the standards track. Keep in > mind the first step of standards track is Proposed Standards which > requires basically no interoperability, then it could move to Draft > Standard where interoperability is shown and finally Full Standard if > it turns out to be a good idea. If you are going to post a reply to > this point, make sure you have read RFC 2026. > > 2) I am interested in the specifics of problems that ICE fails to > solve that the WG has not previous considered. There are lots of > people that have implemented versions of it and think it is a good > idea - if people are having some problems with it, I'd love to hear > about details of things that are wrong. That it has a lot of messages > in some use cases has been known for a long time. It used to have far > more messages - engineering was done to consider what was a > reasonable amount for call set up times and a new design was done to > bring the message to a level most people invovled with the design > felt was reasonable. If there are specific other than these that are > wrong and not considered in the design, now would be a good time to > get them on the table. > > 3) If people think that Skype for example has a simpler solution that > works better than ICE. Feel free to describe exactly what it is. > Several people invovled with the ICE design have looked in extreme > detail at Skype and others and so far none of them have come back > with what we should do different than ICE. > > 4) ICE can be used in a mode where it only provided the reflexive > candidate. People were pretty clear that this was far inferior to the > modes where there are other candidates. If someone would like to > provide exactly how hole punching works better than this very limited > ICE technique, I'd be glad to hear the details. This has certainly > been an topic that any could have brought up over the last several > years. If someone has specifics, I suggest they get out a full > proposal really soon. I am very doubtful that hole punching solution > is fundamentally different than the type of hole punching ICE does. > > 5) Some people have suggested that if all NATs were behave complaint, > then we would not need ICE. I strongly disagree. I think the only > part of ICE we would not need is the TURN relays which are more or > less an optional part. Again, specifics on what can be removed are > welcome. > > ICE is far more complicated that anyone wants - the problem is, no > one has come up with a proposal that looks like it comes anywhere > close to meeting the requirements and if simpler. The design space > has been extensively explored by many people. The raw data to > understand what will work on what NATs have been painfully tested and > documented in publications such as: > > http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf > > http://tools.ietf.org/id/draft-jennings-behave-test-results-04.txt > > https://www.guha.cc/saikat/stunt-results.php? > > (Ford used to have a page too but it seems to be gone) > > I have a very open mind to considering better ways to do ICE - but I > need specific suggestions or it is impossible for me to really think > about if the suggestions represent a better path or not. > > I would love to see more open source ICE code (there is lots already) > - I feel that this is an area where ICE is likely just table stakes > and owning an proprietary ICE stack will not turn out to be a > competitive advantage. Having open source implementations where the > development cost was shared and everyone could get working products > to market faster would be an advantage to companies. Clearly I expect > the bulk of ICE implementations to not be open source but I still > would be keen on doing what I can to contribute to an open source > version as personally I feel that is in the interest of end users, my > employer, and the IETF as a SDO. > > Cullen > > > > On Jul 18, 2007, at 9:12 AM, Dean Willis wrote: > > > > > On Jul 18, 2007, at 3:10 AM, Magnus Westerlund wrote: > > > >> Henry Sinnreich skrev: > >>> Following some discussions and soul searching, the best approach for > >>> ICE-17 for LC would be to _go ahead and make it an experimental > >>> RFC_. > >>> This would support the development of interoperable > >>> implementations, the > >>> collection of deployment data and also hopefully open source code. > >>> Though I have full faith in ICE, following the practices that > >>> made the > >>> IETF successful take precedent here, I believe. > >>> This is a change from the attached that I wrote on 7/16/2007. > >>> Note: We can only hope the proliferation of SBC in VoIP service > >>> provider > >>> networks will not make these concerns and ICE for SIP a moot > >>> issue, but > >>> this is another topic. > >> > >> Henry, > >> > >> I don't quite understand why you are requesting a status change of > >> ICE? To me it appears that ICE is almost finished spec. It has > >> been implemented, used and feedback has been influencing the > >> protocol. It is definitly one of the better examples of current > >> IETF work that actually has running code. Sure, the > >> implementations may not be fully updated yet to the latest draft > >> version. But I think it is safe to say that ICE works in the > >> intended core cases. If there are some corner cases where it > >> fails, that may be. But that is not information we will have until > >> really large scale deployement or someone makes very extensive tests. > > > > Henry has, I believe, been very consistent in urging the IETF to > > have more "running code" experience on every specification (not > > just ICE) than our process requires. He has, IIRC, also advocated > > changing the process to require running code before publishing an > > RFC. He's even suggested at times that one should have running code > > before submitting a protocol draft. > > > > Another point to consider -- I've known Henry to bark at a tree > > with no squirrel in it occasionally, but most of the time he's > > pretty reliable, more so than most technology predictors. If he's > > worried about ICE, it's probably because he's been talking to > > people who are trying to implement it and they're telling him it is > > difficult or that they're having performance or reliability issues. > > I imagine that there are plenty of internal development teams in > > various companies that are working on this and not necessarily > > bringing their results back to the IETF. After all, if everybody > > sees the emperor as fully clothed, they'd be embarrassed to > > proclaim otherwise. Of course, I wish all of these developers were > > tied into the IETF, but then I'm sure I don't want to see every ice- > > implementor's question on the SIP list. That is why we have a sip- > > implementors mailing list, right? > > > > Personally, I think ICE is the best solution we have. We KNOW of > > cases where hole-punching doesn't work, and I think ICE will > > produce usable results in most of those cases. But that's just my > > personal opinion from reading the specs. I haven't implemented ICE, > > and I haven't used anybody else's implementation. Sure, it's > > complex, but that's because the underlying problem is complex -- > > there are just too many different behaviors out there in "NAT and > > firewall land". Of course, I could be wrong, too. It's happened > > before, once or twice ;-). Just how sure are we that we're right > > about this? > > > > Are we designing a "spruce goose" or a practical system? Only > > experience will tell us. But some good flight reports from the > > prototypes could go a long way towards reassuring us of the > > design's utility. > > > > So far we've had a couple of people report hearsay evidence -- that > > somebody else has an ICE implementation and it works. Any of you > > folks have personal experience you can share? Have there been > > prototypes exercised at the interop events? > > > > -- > > Dean > > > > > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 06:43:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBTTC-0007uR-6U; Thu, 19 Jul 2007 06:42:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBTTB-0007uL-Ft for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 06:42:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBTTB-0007uD-5d for sip@ietf.org; Thu, 19 Jul 2007 06:42:53 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBTT9-0001W9-NR for sip@ietf.org; Thu, 19 Jul 2007 06:42:53 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6JAgnIk022113 for ; Thu, 19 Jul 2007 13:42:50 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 13:41:47 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 13:41:47 +0300 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6JAfkw4021715 for ; Thu, 19 Jul 2007 13:41:46 +0300 Received: from [172.21.41.35] (esdhcp04135.research.nokia.com [172.21.41.35]) by kusti.research.nokia.com (Postfix) with ESMTP id 3D95D93B81 for ; Thu, 19 Jul 2007 13:41:46 +0300 (EEST) Message-ID: <469F3FE9.2020707@nokia.com> Date: Thu, 19 Jul 2007 13:41:45 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] Comments on draft-ietf-sip-subnot-etags-00 References: <003601c7c8eb$d99e04b0$7c6c460a@china.huawei.com> <200707190419.l6J4Jpad014623@dragon.ariadne.com> In-Reply-To: <200707190419.l6J4Jpad014623@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 10:41:47.0501 (UTC) FILETIME=[682699D0:01C7C9F1] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Dale, Thanks for the review. ext sip-bounces@ietf.org wrote: > Technical issues: > > What if both Suppress-Body-If-Match and SuppressN-Notify-If-Match are > specified? We probably don't really care, but the document should > make it clear if the combination is standardized or not. The combination makes no sense, and should receive a 400 Bad Request. Perhaps the following patch to Section 4.2., 1st paragraph: OLD: > When creating a conditional SUBSCRIBE request, the subscriber MUST > include a conditional header field including an entity-tag to the NEW: > When creating a conditional SUBSCRIBE request, the subscriber MUST > include a single conditional header field including an entity-tag to the ^^^^^^ (I cut out the next technical issue into a separate email with a new subject, as I think it may require a bit more discussion.) > Nits: > > Section 2.2 > > o Relatively low rate of actual notifications triggered by actual > state changes > > Better phrased "Relatively low rate of notifications triggered by > state changes". Fixed. > Section 3: > > The entity-tag header is "SIP-ETag", but the "SIP-" portion is > redundant. I suppose it's too late to change it to just "ETag". Right, we have SIP-ETag defined in RFC 3903 already. > Sections 3 and 4.2: > > "two types of Xs" is better phrased "two Xs". Fixed. > Section 4.5: > > 2. If the condition evaluates to true, the notifier sends a 204 (No > Notification) response sends no NOTIFY request. > > Should be "sends a 204 (No Notification) response and sends no NOTIFY > request. Fixed. > Section 5.1: > > The notifier is free to decide the means for generating an > entity-tag, except for the special "*" value. > > Better phrased "free to decide how to generate the entity-tag values, > except that no entity-tag may be the special "*" value." Much better. Fixed. > Section 5.3: > > the notifier MUST suppress the resulting NOTIFY request, and > generate a 204 (No Notification) "No Notification" response. > > Should be "a 204 (No Notification) response". Fixed. > Sections 8.3 and 8.4: > > This document registers two new SIP header field names. These > headers are defined by the following information, which has been > added to the header fields sub-registry under > http://www.iana.org/assignments/sip-parameters. > > This paragraph is duplicated, and it appears to be addressing both > header registrations together, rather than either one alone. Changed each instance to: This document registers a new SIP header field called Suppress-{Body, Notify}-If-Match. This header field is defined by the following information, which has been added to the header fields sub-registry under http://www.iana.org/assignments/sip-parameters. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 06:44:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBTUv-00013s-Jr; Thu, 19 Jul 2007 06:44:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBTUu-00013Q-Lt for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 06:44:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBTUu-00013H-B2 for sip@ietf.org; Thu, 19 Jul 2007 06:44:40 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBTUt-0003Ik-NJ for sip@ietf.org; Thu, 19 Jul 2007 06:44:40 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6JAi9sb006081 for ; Thu, 19 Jul 2007 13:44:37 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 13:44:31 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 13:44:32 +0300 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.1830); Thu, 19 Jul 2007 13:44:31 +0300 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6JAiUFf003377 for ; Thu, 19 Jul 2007 13:44:30 +0300 Received: from [172.21.41.35] (esdhcp04135.research.nokia.com [172.21.41.35]) by kusti.research.nokia.com (Postfix) with ESMTP id 55A9E93B80 for ; Thu, 19 Jul 2007 13:44:30 +0300 (EEST) Message-ID: <469F408D.2040704@nokia.com> Date: Thu, 19 Jul 2007 13:44:29 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: sip@ietf.org Subject: Model for entity-tags in subnot-etags (was: Re: [Sip] Comments on draft-ietf-sip-subnot-etags-00) References: <003601c7c8eb$d99e04b0$7c6c460a@china.huawei.com> <200707190419.l6J4Jpad014623@dragon.ariadne.com> In-Reply-To: <200707190419.l6J4Jpad014623@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 10:44:31.0788 (UTC) FILETIME=[CA12CEC0:01C7C9F1] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I split out this issue from Dale's email into a separate message. ext sip-bounces@ietf.org wrote: > The entity-tag values for a single resource are the same across > subscriptions, but it is not clear whether they are in some sense the > same between subscriptions for different resources, or for different > resource-IDs that refer to "the same" underlying resource. This may > have significance for renewed subscriptions whose initial requests are > sent to the same resource AOR but which are ultimately routed to > different but "equivalent" resource-IDs. Qian also had similar comments; obviously this seems to be something the draft does not define clearly enough. I suspect Section 5.1. would need additional text explaining the model behind etags in more detail. However, before we try to come up with that text, let's see if we are on common ground on some basic assumptions (as I suspect we might not be there 100%). For the most parts the model should be equivalent to that in HTTP (or at least to my reading of RFC2616). Here are the assumptions under which subnot-etags are currently defined: - There is a single authoritative notifier agent responsible for any single resource. - A resource is identified using a SIP URI. - A subscriber subscribes to a resource using the SIP URI. - With a successful subscription, a subscriber gets access to an entity from the resource. (Entity is HTTP lingo, and basically means a certain "view" of the resource state.) - An entity can be influenced by different external data, e.g., filter rules, authorization rules, etc. - There is a one-to-many relationship between the resource and the entities. - Each entity has an assigned entity-tag. - There is a one-to-many relationship between an entity and its versions (different etag values, of which only one is current). - An entity-tag must be unique across all versions of all entities from a resource. - The rest are implementation details. Comments? Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 07:12:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBTvd-0005MR-3C; Thu, 19 Jul 2007 07:12:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBTvb-0005MC-Cp for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 07:12:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBTva-0005M1-Ch for sip@ietf.org; Thu, 19 Jul 2007 07:12:14 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBTvY-0002AF-TH for sip@ietf.org; Thu, 19 Jul 2007 07:12:14 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3FCCD2039D; Thu, 19 Jul 2007 13:12:12 +0200 (CEST) X-AuditID: c1b4fb3e-b1837bb0000007e1-ab-469f470c890d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0BE3520117; Thu, 19 Jul 2007 13:12:12 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 13:12:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] New draft modifying RFC 4412 for Responses Date: Thu, 19 Jul 2007 13:12:10 +0200 Message-ID: <7374777208BDC7449D5620EF94232567073F78EB@esealmw113.eemea.ericsson.se> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1151AB0D@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New draft modifying RFC 4412 for Responses Thread-Index: AcfJYuJ3IV+mWiCRRPqdG6nzmQteEgACoq6wACH+A/A= References: <1ECE0EB50388174790F9694F77522CCF1151A644@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1151AB0D@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg (JO/LMF)" To: "Francois Audet" , "Janet P Gunn" X-OriginalArrivalTime: 19 Jul 2007 11:12:11.0501 (UTC) FILETIME=[A756E9D0:01C7C9F5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd Cc: sip@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0178106972==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0178106972== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C9F5.A742477E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C9F5.A742477E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 Maybe sending the RPH to the UAC is something that the 199 mechanism = could be used for. =20 Regards, =20 Christer =20 =20 =20 ________________________________ From: Francois Audet [mailto:audet@nortel.com]=20 Sent: 18. hein=E4kuuta 2007 21:59 To: Janet P Gunn Cc: sip@ietf.org; James M. Polk Subject: RE: [Sip] New draft modifying RFC 4412 for Responses =09 =09 I will be happy if the document is revised to explain that you cannot = expect that responses received by a UAC or Proxy will necessarily = include RPM, in particular in systems where forking occurs, and that = therefore, applications that use this draft must take it into account. ________________________________ From: Janet P Gunn [mailto:jgunn6@csc.com]=20 Sent: Wednesday, July 18, 2007 10:41 To: Audet, Francois (SC100:3055) Cc: sip@ietf.org; James M. Polk Subject: RE: [Sip] New draft modifying RFC 4412 for Responses =09 =09 =09 In line.=20 =09 "Francois Audet" wrote on 07/18/2007 11:26:54 AM: =09 > > > What I mean is that the error response may not be delivered=20 > > to the UAC=20 > > > because a forking proxy will only deliver one final=20 > > response. If there=20 > > > are multiple error responses on the individual forks, one being = the=20 > > > one with the RPH, and the other being some other response,=20 > > it is up to=20 > > > the proxy to decide which one to forward back. > > >=20 > > > So the UAC can not rely on receiving the RPH to "re-intiate" the = > > > session or provide some alternative treatment. This may or=20 > > may not be=20 > > > a problem depending on the application (that's why I said "if it = > > > absolutely has"). > > >=20 > >=20 > > I don't think that will be a problem.=20 > >=20 > > For one thing (for the namespaces I am working with) the=20 > > expectation would be that ALL the responses (except 100 and=20 > > 403) would have the RPH on the response, so it wouldn't=20 > > matter which one made it back to the UAC.=20 >=20 > I am not talking about multiple provisional responses from the same > endpoint. >=20 > I am talking about multiple responses (provisional and final) from=20 > multiple forks. For example, multiple 4XX responses.=20 =09 Yes, I understood that. >=20 > While it is possible that a single forking proxy may decide to=20 > include the RPH in all responses, that proxy has absolutely no=20 > control over downstream and upstream proxies who may not include it > (they may be proxies in different domains). >=20 > That's the point I'm trying to make. You can not enforce the=20 > presence RPH in responses in a global system.=20 =09 Agree. For the context I am working in, a "global system" is not of = concern. I would not expect universal "RPH in responses" in a global = system.=20 =09 >=20 > > Secondly, the expectation is that the devices responsible for=20 > > "re-initiating" WOULD be stateful, and not dependant on the=20 > > information in the RPH in the response. It is the=20 > > intervening devices that might not be stateful, and would=20 > > take advantage of the RPH information in the responses.=20 >=20 > That is precisely the type of clarification that needs to be = included > in the draft. It points out the constraints of the mechanism so=20 > implementors use the feature properly. >=20 > Some text explaining that the UAC needs to be able to deal with the = RPH > not being present in responses gracefully (and why) is needed.=20 =09 I am not sure why that needs to be in the ID. It is an implementation = specific issue. =20 =09 Since RFC 4412, as currently published, forbids RPH in responses, I = think it "goes without saying" that "the UAC needs to be able to deal = with the RPH not being present in responses".=20 =09 Further, while I know that the systems (and namespaces) _I_ work with = intend to use RPH in responses, I also have been told that other systems = (using other namespaces) do not intend to put RPH in ANY responses. I = do not think there is any need to standardize this aspect, just to = adjust the standard so it is PERMITTED. >=20 > Similar text for proxies also need to be there. What if a proxy=20 > forwards a request with RPH and it receives nultiple responses from > the downstream proxies, with some including the RPH and others not > including it? Does this need to be standardized?=20 =09 Again, I do not think there is a need to standardize this aspect.=20 =09 Janet >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip =09 ------_=_NextPart_001_01C7C9F5.A742477E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
        Hi,
         
        Maybe sending the RPH to the UAC is = something=20 that the 199 mechanism could be used for.
         
        Regards,
         
        Christer
         
         
         

        From: Francois Audet = [mailto:audet@nortel.com]=20
        Sent: 18. hein=E4kuuta 2007 21:59
        To: Janet P=20 Gunn
        Cc: sip@ietf.org; James M. Polk
        Subject: RE: = [Sip]=20 New draft modifying RFC 4412 for Responses

        I will be happy if the document is revised to = explain=20 that you cannot expect that responses received by a UAC or = Proxy will=20 necessarily include RPM, in particular in systems where forking = occurs, and=20 that therefore, applications that use this draft must take it into=20 account.

        From: Janet P Gunn = [mailto:jgunn6@csc.com]=20
        Sent: Wednesday, July 18, 2007 10:41
        To: Audet, = Francois (SC100:3055)
        Cc: sip@ietf.org; James M.=20 Polk
        Subject: RE: [Sip] New draft modifying RFC 4412 for=20 Responses



        In line.        =20

        "Francois Audet" <audet@nortel.com> = wrote on=20 07/18/2007 11:26:54 AM:

        > > > What I mean is that = the error=20 response may not be delivered
        > > to the UAC
        > > = >=20 because a forking proxy will only deliver one final
        > > = response.=20 If there
        > > > are multiple error responses on the = individual=20 forks, one being the
        > > > one with the RPH, and the = other=20 being some other response,
        > > it is up to
        > > = > the=20 proxy to decide which one to forward back.
        > > > =
        > >=20 > So the UAC can not rely on receiving the RPH to "re-intiate" = the=20
        > > > session or provide some alternative treatment. = This may=20 or
        > > may not be
        > > > a problem depending = on the=20 application (that's why I said "if it
        > > > absolutely=20 has").
        > > >
        > >
        > > I don't think = that will=20 be a problem.
        > >
        > > For one thing (for the = namespaces=20 I am working with) the
        > > expectation would be that ALL = the=20 responses (except 100 and
        > > 403) would have the RPH on = the=20 response, so it wouldn't
        > > matter which one made it back = to the=20 UAC.
        >
        > I am not talking about multiple provisional = responses=20 from the same
        > endpoint.
        >
        > I am talking about = multiple=20 responses (provisional and final) from
        > multiple forks. For = example,=20 multiple 4XX responses.

        Yes, = I=20 understood that.
        >
        > While it is possible that a single = forking=20 proxy may decide to
        > include the RPH in all responses, that = proxy=20 has absolutely no
        > control over downstream and upstream = proxies who=20 may not include it
        > (they may be proxies in different=20 domains).
        >
        > That's the point I'm trying to make. You = can not=20 enforce the
        > presence RPH in responses in a global=20 system.

        Agree. For the = context I am=20 working in, a "global system" is not of concern.  I would not = expect=20 universal "RPH in responses" in a global system. =

        >
        > > Secondly, the expectation is = that the=20 devices responsible for
        > > "re-initiating" WOULD be = stateful, and=20 not dependant on the
        > > information in the RPH in the = response.=20  It is the
        > > intervening devices that might not be=20 stateful, and would
        > > take advantage of the RPH = information in=20 the responses.
        >
        > That is precisely the type of = clarification=20 that needs to be included
        > in the draft. It points out the=20 constraints of the mechanism so
        > implementors use the = feature=20 properly.
        >
        > Some text explaining that the UAC needs = to be=20 able to deal with the RPH
        > not being present in responses = gracefully=20 (and why) is needed.

        I am not = sure why=20 that needs to be in the ID.  It is an implementation specific = issue.=20  

        Since  RFC 4412, = as=20 currently published, forbids RPH in responses, I think it "goes = without=20 saying" that "the UAC needs to be able to deal with the RPH not = being=20 present in responses".

        Further, while I=20 know that the systems (and namespaces) _I_ work with intend to use = RPH in=20 responses, I also have been told that other systems (using other = namespaces)=20 do not intend to put RPH in ANY responses.  I do not think = there is any=20 need to standardize this aspect, just to adjust the standard so it = is=20 PERMITTED.
        >
        > Similar text for proxies also need to be = there.=20 What if a proxy
        > forwards a request with RPH and it receives = nultiple responses from
        > the downstream proxies, with some = including=20 the RPH and others not
        > including it? Does this need to be=20 standardized?

        Again, I do not = think=20 there is a need to standardize this aspect. =

        Janet
        >
        >
        >=20 _______________________________________________
        > Sip mailing = list=20  https://www1.ietf.org/mailman/listinfo/sip
        > This list = is for=20 NEW development of the core SIP Protocol
        > Use=20 sip-implementors@cs.columbia.edu for questions on current = sip
        > Use=20 sipping@ietf.org for new developments on the application of=20 sip
        ------_=_NextPart_001_01C7C9F5.A742477E-- --===============0178106972== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0178106972==-- From sip-bounces@ietf.org Thu Jul 19 07:57:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBUdO-0007Eg-G8; Thu, 19 Jul 2007 07:57:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBUdM-0007EK-Q9 for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 07:57:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBUdM-0007EB-GZ; Thu, 19 Jul 2007 07:57:28 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-04.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBUdL-0003WS-UH; Thu, 19 Jul 2007 07:57:28 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1IBUdP-0007Eb-Em; Thu, 19 Jul 2007 07:57:31 -0400 In-Reply-To: <1184813769.3347.32.camel@localhost.localdomain> References: <239224.19734.qm@web33301.mail.mud.yahoo.com> <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> <1184813769.3347.32.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 07:57:36 -0400 To: "Frank W. Miller" X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Magnus Westerlund , Behave WG , IETF MMUSIC WG , sip@ietf.org, Pyda Srisuresh , Henry Sinnreich , P2PSIP Mailing List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 18-Jul-07, at 22:56 , Frank W. Miller wrote: > > Its just about as simple as it gets and I know you're going to say > that > it doesn't work 100% of the time. I haven't measured how well its > done > in deployments I've done as yet. I guess I need to do something along > those lines. The good news is, I haven't had anyone complain about it > so I guess I've been lucky. So let me have it... ;) This is the original STUN algorithm. One situation where it fails is the following: STUN server | NAT | ------------------ | | UA1 UA2 If the NAT does not support hairpinning, then your algorithm will not work. [http://tools.ietf.org/html/draft-jennings-behave-test-results-04 shows that most NATs today do not support UDP hairpinning, and http://www.guha.cc/saikat/pub/imc05-tcpnat.pdf reports that most do not support TCP hairpinning.] This situation can occur when the two UAs belong to the same company, or both are in the same hotel, or both use the same service provider and the service provider has a NAT in front of its entire network, etc. ICE does to things to solve this problem. First of all, UA1 and UA2 exchange their local addresses and ports as well as their STUN-learned addresses. They then test to see which path works. Second, they also exchange TURN addresses, which serve as a backup in case everything else fails. David Barrett's algorithm, if I understand it correctly, would work in this situation. (As far as I can tell, David's is a simplified version of ICE). - Philip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 08:03:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBUjJ-00045r-OC; Thu, 19 Jul 2007 08:03:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBUjI-00045m-8C for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 08:03:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBUjH-00045e-Uy for sip@ietf.org; Thu, 19 Jul 2007 08:03:35 -0400 Received: from gws03.mail.hcl.in ([203.105.186.19] helo=gws03.hcl.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBUjF-0003g1-Mg for sip@ietf.org; Thu, 19 Jul 2007 08:03:35 -0400 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 78CB237CC10 for ; Thu, 19 Jul 2007 17:27:55 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws03.hcl.in (Postfix) with ESMTP id 4182F37CF2Efor ; Thu, 19 Jul 2007 15:52:56 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.15]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 15:58:29 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jul 2007 15:59:38 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC601DA39FA@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Error code when password expired. Thread-Index: AcfJ6KS1W3tunyF0T1aflsir+idaPAABwymA From: "Anand Kumaravel, TLS-Chennai" To: X-OriginalArrivalTime: 19 Jul 2007 10:28:29.0351 (UTC) FILETIME=[8C6A9370:01C7C9EF] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-15.2578 TC:1F TRN:56 TV:3.6.1039(15306.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Subject: [Sip] Error code when password expired. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1801288476==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1801288476== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C9EF.7ADD5C79" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C9EF.7ADD5C79 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 Hi All, Can any one please explain, what error code should the server respond with, when it gets a REGISTER with expired credentials.=20 Is there any standard explaining this behavior. =20 Thanks, Anand Kumaravel DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have received this email in error please delete it and notify the sender= immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C7C9EF.7ADD5C79 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

         

         

        Hi All,

                 &n= bsp;  Can any one please explain, what error code should the server respond with, when it gets a REGISTER with expired credentials.=

        Is there any standard explaining this= behavior.

         

        Thanks,

        Anan= d Kumaravel

        DISCLAIMER:
        ---------------------------------------------------------------------------= --------------------------------------------

        The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only.
        It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in
        this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates.
        Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
        this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have
        received this email in error please delete it and notify the sender= immediately. Before opening any mail and
        attachments please check them for viruses and defect.

        ---------------------------------------------------------------------------= --------------------------------------------
        ------_=_NextPart_001_01C7C9EF.7ADD5C79-- --===============1801288476== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1801288476==-- From sip-bounces@ietf.org Thu Jul 19 08:24:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBV3Z-0004zA-0v; Thu, 19 Jul 2007 08:24:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBV3X-0004yn-53 for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 08:24:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBV3W-0004yf-Pk for sip@ietf.org; Thu, 19 Jul 2007 08:24:30 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBV3W-0006Uq-6m for sip@ietf.org; Thu, 19 Jul 2007 08:24:30 -0400 X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1184847868!24712522!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 10798 invoked from network); 19 Jul 2007 12:24:29 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-119.messagelabs.com with SMTP; 19 Jul 2007 12:24:29 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l6JCOS7u022187 for ; Thu, 19 Jul 2007 05:24:28 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l6JCOSlL022286 for ; Thu, 19 Jul 2007 07:24:28 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l6JCOQ5g022240 for ; Thu, 19 Jul 2007 07:24:27 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Error code when password expired. Date: Thu, 19 Jul 2007 20:24:25 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B04D52059@ZMY16EXM66.ds.mot.com> In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC601DA39FA@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Error code when password expired. thread-index: AcfJ6KS1W3tunyF0T1aflsir+idaPAABwymAAAP8f0A= References: <66E8AEE9980BB44CA5FCAD39EBA56AC601DA39FA@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> From: "Avasarala Ranjit-A20990" To: "Anand Kumaravel, TLS-Chennai" , X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0385345172==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0385345172== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C9FF.BED9EA1A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C9FF.BED9EA1A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable one option is server can send a 401 Unauthorized with a new set of credentials. Then the user can re register =20 Regards=20 Ranjit=20 =20 ________________________________ From: Anand Kumaravel, TLS-Chennai [mailto:akumaravel@hcl.in]=20 Sent: Thursday, July 19, 2007 4:00 PM To: sip@ietf.org Subject: [Sip] Error code when password expired. =20 =20 Hi All, Can any one please explain, what error code should the server respond with, when it gets a REGISTER with expired credentials.=20 Is there any standard explaining this behavior. =20 Thanks, Anand Kumaravel DISCLAIMER: ------------------------------------------------------------------------ ----------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ------------------------------------------------------------------------ ----------------------------------------------- =09 ------_=_NextPart_001_01C7C9FF.BED9EA1A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
        one option is server can send a 401 = Unauthorized with a new=20 set of credentials. Then the user can re register
         

        Regards
        Ranjit

         

        From: Anand Kumaravel, TLS-Chennai=20 [mailto:akumaravel@hcl.in]
        Sent: Thursday, July 19, 2007 4:00 = PM
        To: sip@ietf.org
        Subject: [Sip] Error code when = password=20 expired.

         

         

        Hi = All,

                   = =20 Can any one please explain, what error code should the server respond = with, when=20 it gets a REGISTER with expired credentials. =

        Is there any standard = explaining=20 this behavior.

         

        Thanks,

        Anand=20 Kumaravel

        DISCLAIMER:
        ------------------------------------------= -------------------------------------------------------------------------= ----

        The=20 contents of this e-mail and any attachment(s) are confidential and = intended for the named recipient(s) only.
        It shall not attach = any=20 liability on the originator or HCL or its affiliates. Any views or = opinions presented in
        this email are solely those of the = author and=20 may not necessarily reflect the opinions of HCL or its = affiliates.
        Any=20 form of reproduction, dissemination, copying, disclosure, = modification,=20 distribution and / or publication of
        this message without the = prior=20 written consent of the author of this e-mail is strictly = prohibited. If=20 you have
        received this email in error please delete it and = notify the=20 sender immediately. Before opening any mail and
        attachments = please=20 check them for viruses and=20 = defect.

        ----------------------------------------------------------= -------------------------------------------------------------
        <= /TD>
        ------_=_NextPart_001_01C7C9FF.BED9EA1A-- --===============0385345172== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0385345172==-- From sip-bounces@ietf.org Thu Jul 19 08:29:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBV8M-0006hV-TY; Thu, 19 Jul 2007 08:29:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBV8L-0006hJ-Fq for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 08:29:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBV8L-0006h8-5s; Thu, 19 Jul 2007 08:29:29 -0400 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBV8J-0004ho-Q0; Thu, 19 Jul 2007 08:29:29 -0400 Received: by mail.iptel.org (Postfix, from userid 103) id C03B11810C53; Thu, 19 Jul 2007 14:29:28 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on mail.iptel.org X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7-deb Received: from [213.192.30.176] (unknown [213.192.30.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.iptel.org (Postfix) with ESMTP id 40EA01810C50; Thu, 19 Jul 2007 14:29:28 +0200 (CEST) Message-ID: <469F5925.20401@iptel.org> Date: Thu, 19 Jul 2007 14:29:25 +0200 From: Jan Janak User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC References: <18079.325.333518.53741@tutpro.com> In-Reply-To: <18079.325.333518.53741@tutpro.com> X-Enigmail-Version: 0.94.2.0 OpenPGP: id=F8190A31 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org, mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha Heinanen wrote: > a while back i read ice tutorial slides and my impression was that the > protocol was very complex (pity implementers) and provided only a bit > better nat traversal capability than what [open]ser/rtpproxy/mediaproxy > have been offering to lots of users for years already. The NAT traversal algorithm implemented in [open]ser, rtpproxy, and mediaproxy had been developed long before the first version of the ICE draft; at that time no other solution existed (except for preliminary STUN and TURN drafts), and we needed something to make it work; in addition to that NAT traversal support in UA was virtually non-existent back then. Having said that, it is true that the algorithm implemented in [open]ser is simpler than ICE, but I believe that these two cannot be directly compared. Even the NAT traversal logic in SER can get pretty complex if none of the end-points is a PSTN gateway in the public internet (especially if you want to handle re-INVITEs and serial forking properly). Jan. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 08:35:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVEE-0004Pd-7h; Thu, 19 Jul 2007 08:35:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBVEC-0004PV-ME for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 08:35:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVEC-0004PN-Cj for sip@ietf.org; Thu, 19 Jul 2007 08:35:32 -0400 Received: from out001.iad.hostedmail.net ([209.225.56.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBVEB-0004ur-14 for sip@ietf.org; Thu, 19 Jul 2007 08:35:32 -0400 Received: from ATL1VEXC020.usdom003.tco.tc ([10.158.7.31]) by out001.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 08:35:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Error code when password expired. Date: Thu, 19 Jul 2007 08:35:31 -0400 Message-ID: In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B04D52059@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Error code when password expired. Thread-Index: AcfJ6KS1W3tunyF0T1aflsir+idaPAABwymAAAP8f0AAAFKIIA== From: "Brett Tate" To: "Anand Kumaravel, TLS-Chennai" , X-OriginalArrivalTime: 19 Jul 2007 12:35:24.0161 (UTC) FILETIME=[47325F10:01C7CA01] X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0777151948==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0777151948== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CA00.E5883AB2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CA00.E5883AB2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The stale parameter can also be indicated within the 401 response; see rfc2617 section 3.3. =20 ________________________________ From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com]=20 Sent: Thursday, July 19, 2007 8:24 AM To: Anand Kumaravel, TLS-Chennai; sip@ietf.org Subject: RE: [Sip] Error code when password expired. =09 =09 one option is server can send a 401 Unauthorized with a new set of credentials. Then the user can re register =20 Regards=20 Ranjit=20 =20 ________________________________ From: Anand Kumaravel, TLS-Chennai [mailto:akumaravel@hcl.in]=20 Sent: Thursday, July 19, 2007 4:00 PM To: sip@ietf.org Subject: [Sip] Error code when password expired. =09 =09 =20 =20 Hi All, Can any one please explain, what error code should the server respond with, when it gets a REGISTER with expired credentials.=20 Is there any standard explaining this behavior. =20 Thanks, Anand Kumaravel DISCLAIMER: ------------------------------------------------------------------------ ----------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ------------------------------------------------------------------------ ----------------------------------------------- =09 ------_=_NextPart_001_01C7CA00.E5883AB2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
        The stale parameter can also be indicated = within the=20 401 response; see rfc2617 section 3.3.
         

        From: Avasarala Ranjit-A20990=20 [mailto:ranjit@motorola.com]
        Sent: Thursday, July 19, 2007 = 8:24=20 AM
        To: Anand Kumaravel, TLS-Chennai; = sip@ietf.org
        Subject:=20 RE: [Sip] Error code when password expired.

        one option is server can send a 401 = Unauthorized with a=20 new set of credentials. Then the user can re = register
         

        Regards
        Ranjit

         

        From: Anand Kumaravel, TLS-Chennai = [mailto:akumaravel@hcl.in]
        Sent: Thursday, July 19, 2007 = 4:00=20 PM
        To: sip@ietf.org
        Subject: [Sip] Error code when = password expired.

         

         

        Hi=20 All,

                   = =20 Can any one please explain, what error code should the server respond = with,=20 when it gets a REGISTER with expired credentials.=20

        Is there any standard = explaining=20 this behavior.

         

        Thanks,

        Anand=20 Kumaravel

        DISCLAIMER:
        ------------------------------------------= -------------------------------------------------------------------------= ----

        The=20 contents of this e-mail and any attachment(s) are confidential = and=20 intended for the named recipient(s) only.
        It shall not attach = any=20 liability on the originator or HCL or its affiliates. Any views = or=20 opinions presented in
        this email are solely those of the = author and=20 may not necessarily reflect the opinions of HCL or its=20 affiliates.
        Any form of reproduction, dissemination, copying, = disclosure, modification, distribution and / or publication of =
        this=20 message without the prior written consent of the author of this = e-mail=20 is strictly prohibited. If you have
        received this email in = error=20 please delete it and notify the sender immediately. Before = opening any=20 mail and
        attachments please check them for viruses and=20 = defect.

        ----------------------------------------------------------= -------------------------------------------------------------
        <= /TD>
        ------_=_NextPart_001_01C7CA00.E5883AB2-- --===============0777151948== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0777151948==-- From sip-bounces@ietf.org Thu Jul 19 09:18:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVtd-0005R3-2T; Thu, 19 Jul 2007 09:18:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBVtc-0005Qy-8S for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 09:18:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVtb-0005Qi-T7 for sip@ietf.org; Thu, 19 Jul 2007 09:18:19 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBVtb-0008MA-38 for sip@ietf.org; Thu, 19 Jul 2007 09:18:19 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 19 Jul 2007 09:18:18 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwPAGYBn0ZAZnmf/2dsb2JhbACIXp4N X-IronPort-AV: i="4.16,557,1175486400"; d="scan'208"; a="65594594:sNHT92292030" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6JDIIue006830; Thu, 19 Jul 2007 09:18:18 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6JDIDWS028723; Thu, 19 Jul 2007 13:18:18 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 09:18:15 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 09:18:15 -0400 Message-ID: <469F6496.8050608@cisco.com> Date: Thu, 19 Jul 2007 09:18:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: References to Body Parts WAS (Re: [Sip] Draft slides for body (MIME) handling) References: <469DF98F.3060506@ericsson.com> <469E261B.7090804@cisco.com> <469F361C.1080908@ericsson.com> In-Reply-To: <469F361C.1080908@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 13:18:15.0091 (UTC) FILETIME=[43972830:01C7CA07] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5760; t=1184851098; x=1185715098; c=relaxed/simple; s=rtpdkim2001; 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=20References=20to=20Body=20Parts=20WAS=20(Re=3A=20[Sip] =20Draft=20slides=20for=20body=0A=20(MIME)=20handling) |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=A4pJW/9qvwzGwez4cHOcc/85xPOjbNDQtVfnDUyG8UY=; b=Ceo6UYxxptQDtAvS29G6cymd1Lj/xYm+yrya5kZ/MwkixlSG9lAPzSj0rDpBIq1v3uK3irhi QLx3G4tq42gs8rzsl0Hjt2Q8LOefBLFrk+gXr9U6IsKgiY9PkCcYlLtL; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Gonzalo Camarillo wrote: > Hi Paul, > >> Thanks for sending out in advance. Maybe we can get into the >> discussion of the slides now, before the meeting. > > yes, that was the intention. > >> Regarding references to body parts: >> >> IMO it is a *bad* idea to make the decision about processing of a body >> part "on its own" dependent on whether the node doing so has detected >> a reference to that body part or not. >> >> For one thing, that requires a multi-pass parsing mechanism to check >> for references before deciding what processing to do on a particular >> part. For another, it requires that the recipient understand every >> reference. For instance, the sender may have included an extension >> header that contains a reference to a body part. If the extension >> isn't understood, then the body part should not be processed. But if >> the recipient doesn't understand the extension then it won't recognize >> the reference either, and so will attempt to process the body part as >> one without references. > > yes, these two issues are described in the draft. > >> The only good solution I see to this is to partition the >> Content-Disposition and/or Content-Type values whose processing is >> dependent on reference from those whose processing is not dependent on >> a reference. For instance, we could simply define a new >> Content-Disposition of "by-reference". >> >> Then a normal sequence of processing would be to first process all the >> body parts according to their type and disposition alone. Any with >> disposition "by-reference" would be set aside. Then, when processing >> headers, if a header with a reference is encountered the appropriate >> processing could be applied to the set aside body part. References >> within other body parts would be a little more complex, but you get >> the idea. > > yes. When looking for references, one would need to process the header > fields plus the body parts with a disposition type different than > 'by-reference', since, as you point out, those body parts could contain > references to 'by-reference' body parts. > > The only case we would not cover would be two (or more) 'by-reference' > body parts referencing each other. But we can just say that this is > forbidden (no extension does that at present). Right. That case makes no sense to construct. >> This would not prevent reference to body parts with other >> dispositions. It just means that those body parts would also be >> processed according to their type and disposition, in addition to any >> processing they might get according to their reference. The >> "by-reference" disposition is just a defintion that gets no implicit >> processing. > > yes, the draft already talks about the possibility of having several > references to a body part. In such a case, the body part would need to > be processed several times (in different ways). However, the case you > are talking about is not currently addresses (i.e., a body part is > processed once based on a reference and another time based on its > content disposition). None of these situations occur within current > extensions, but they could happen in the future. Yes. IMO it is important to get a consistent framework in place that covers whatever kinds of usage might come along. Without that people may invent processing algorithms that cover only the cases they happen to have encountered. >> An advantage of this approach is that by-reference body parts don't >> need to be parsed unless the reference is processed and the action >> required in processing the reference requires the node to parse the >> referenced body. (Interaction with handling=required in this case is >> TBD.) Even a multipart with disposition of by-reference might not need >> to be parsed. > > The interaction with handling=required would be that if you are not able > to find a reference to a 'by-reference' body part with > handling=required, you report an error because you have not been able to > process the body part. Hmm. I guess that makes sense. It means that any time there is an optional header with a reference to a body part then the handling of that body part needs to be optional. But again I guess that makes good sense. Some interesting questions arise when body parts are being processed by middleboxes. (Maybe we aren't supposed to talk about that here.) The whole issue of handling=required gets messy there. The middlebox isn't the intended recipient, so the handling parameter doesn't really apply to it. So presumably it processes whatever headers and body parts it likes. That is another motivation for making the decision about processing be explicit - so it can be selective. > This approach would work and has the advantage to be explicit about how > a body part is expected to be processed... I would like to hear more > opinions on this. Me too. So far this has mostly been a dialog between the two of us. (Dale? - I can usually count on you to have an opinion.) Paul > Cheers, > > Gonzalo > > >> Gonzalo Camarillo wrote: >>> Folks, >>> >>> here you have the slides I have put together for the body (MIME) >>> handling presentation on Monday: >>> >>> http://users.piuha.net/gonzalo/temp/ietf69-sip-camarillo-body-handling.ppt >>> >>> >>> These slides relate to this draft: >>> >>> http://www.ietf.org/internet-drafts/draft-camarillo-sip-body-handling-01.txt >>> >>> >>> The slides discuss all the open issues that have been brought up in >>> the list in the last months. >>> >>> Comments are welcome. >>> >>> Thanks, >>> >>> Gonzalo > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 09:59:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBWXR-00036Y-74; Thu, 19 Jul 2007 09:59:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBWXP-00036T-BP for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 09:59:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBWXP-00036L-00 for sip@ietf.org; Thu, 19 Jul 2007 09:59:27 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBWXO-00011h-7d for sip@ietf.org; Thu, 19 Jul 2007 09:59:26 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 19 Jul 2007 09:59:25 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwPAAMLn0ZAZnmf/2dsb2JhbACIXp4E X-IronPort-AV: i="4.16,557,1175486400"; d="scan'208"; a="65598909:sNHT32100034" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6JDxPTH026507; Thu, 19 Jul 2007 09:59:25 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6JDxBWo013649; Thu, 19 Jul 2007 13:59:25 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 09:59:23 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 09:59:22 -0400 Message-ID: <469F6E3A.3000203@cisco.com> Date: Thu, 19 Jul 2007 09:59:22 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides for body (MIME) handling) References: <469DF98F.3060506@ericsson.com> <469E261B.7090804@cisco.com> <469F38A0.7090404@ericsson.com> In-Reply-To: <469F38A0.7090404@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 13:59:22.0832 (UTC) FILETIME=[027A8D00:01C7CA0D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5331; t=1184853565; x=1185717565; c=relaxed/simple; s=rtpdkim2001; 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=20Content-Disposition=20in=20multiparts=20WAS=20(Re=3A= 20[Sip]=20Draft=20slides=0A=20for=20body=20(MIME)=20handling) |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=9j7WkuX0ctcJGy6tRbUDHBLgKB8wkhF8yM4fYctn1SM=; b=I5OK15XWC9iNA/JL2sVFVq9S56yInktlJMQ33RkYRJ+ee3yFb1NuI+b69HCpCB2tVvLMNblw xZ1Yrkvqr5blz7B63zhn+0DxivSlnbAIHGOVq4kRcA9pSWR1Ui1qJk2M; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Gonzalo Camarillo wrote: > Hi Paul, > >> Regarding Content-Disposition in multiparts: >> >> While it seems "wrong" to me, I can live with using "render" as the >> normal disposition for multipart, *if* we can do a careful job of >> defining what "render" actually means for SIP. Used this way it >> clearly doesn't always mean to display the content to a user. > > An entity receiving a 'multipart/mixed' body will process its body parts > based on their disposition types.If the disposition type of a particular > body part is not understood, it will be displayed to the user because > the default disposition type is 'render'. There is a bigger problem with 'render' than just multipart. We have many uses of body parts that never mention Content-Disposition at all. The related examples don't use it, and so they all get a default of 'render'. This is particularly the case with events. E.g. - the notification for REFER contains type application/sipfrag. Its probably not intended to be "rendered" in any literal sense, though some conclusion about success or failure may be. - usage of filter bodies in presence subscriptions (RFC 4660) doesn't have a specified disposition, so it implicitly uses render. Its hard for me to convince myself that what the presence server does with these can be described as rendering. - In fact, the only place I can think of where 'render' is (implicitly) used in sip and has the appropriate connotation is in MESSAGE. I think we just have to grandfather the use of 'refer' in SIP, and document that the usage in sip does not mean "render", but rather means that the usage must be determined by other context - specifically the type of message or response and the content type. IOW, 'render' in sip can be thought of as a peculiar spelling for 'by-context'. It might be helpful to give guidance for development of future specs about when 'render' should be used vs defining a new disposition. > Therefore, the 'multipart/mixed' body will never be processed based on > its disposition type. Based on my discussion above, I would consider this a case of the multipart being processed according to its context *because* its content-disposition is 'refer'. If it had some other content-disposition then that might mean that it should be processed specially. E.g. if a multipart/mixed had disposition 'by-reference' then that needs to be taken into account, and the processing of the multipart becomes conditional on the reference. Also, there are only certain contexts in which multipart should be processed "normally". Consider a NOTIFY from a REFER, with a Content-Type of message/sipfrag, which happened to include a body as part of the fragment. (This is legal.) That body might contain a multipart/mixed, and that might contain other stuff. But I think the processing of all of that is dependent on processing of the sipfrag. For instance, if something inside that had handling=required, I don't think that means that processing of the NOTIFY fails because the recipient can't handle that. > This means that it does not make much sense to > talk about its disposition type as a whole. Counterexample above. > However, we need to have one > in order to be able to set its handling parameter. That's why we can > either keep 'render' explaining that it is actually never used or define > a new disposition type. I can go either way on that. But because there is existing usage, and because 'render' semantics are already so messed up, I think it makes more sense to stick with 'render' and just clarify its meaning. > Since existing implementations will not understand our newly defined > disposition type, they will treat it as 'render' anyway... but the > resulting behavior would be the same. That's why it may make sense to > keep using 'render'. Yup. > On the other hand, semantically, it would make more sense to define a > new disposition type. > > Also, if we decide to define the 'by-reference' disposition type (per a > different email thread), it could be used here as well. It could be used when there is actually a reference to it. But it would not be an appropriate disposition to use when there is no reference to the multipart. Thanks, Paul > Cheers, > > Gonzalo > > > >> Gonzalo Camarillo wrote: >>> Folks, >>> >>> here you have the slides I have put together for the body (MIME) >>> handling presentation on Monday: >>> >>> http://users.piuha.net/gonzalo/temp/ietf69-sip-camarillo-body-handling.ppt >>> >>> >>> These slides relate to this draft: >>> >>> http://www.ietf.org/internet-drafts/draft-camarillo-sip-body-handling-01.txt >>> >>> >>> The slides discuss all the open issues that have been brought up in >>> the list in the last months. >>> >>> Comments are welcome. >>> >>> Thanks, >>> >>> Gonzalo >>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 09:59:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBWXT-00037r-9B; Thu, 19 Jul 2007 09:59:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBWXS-000378-1U for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 09:59:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBWXR-00036c-Ai; Thu, 19 Jul 2007 09:59:29 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBWXP-0007Qs-Lr; Thu, 19 Jul 2007 09:59:29 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 19 Jul 2007 06:59:26 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAE4Kn0arR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,557,1175497200"; d="scan'208"; a="184927225:sNHT62504640" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6JDxQo6000569; Thu, 19 Jul 2007 06:59:26 -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.12.10/8.12.6) with ESMTP id l6JDxQTb015331; Thu, 19 Jul 2007 13:59:26 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); Thu, 19 Jul 2007 06:59:26 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 06:59:25 -0700 Message-ID: <469F6E43.5050709@cisco.com> Date: Thu, 19 Jul 2007 09:59:31 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: David Barrett Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 13:59:25.0674 (UTC) FILETIME=[042C34A0:01C7CA0D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=20638; t=1184853566; x=1185717566; 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[Sip]=20Re=3A=20[BEHAVE]=20Re=3A=20ICE=20deployment=2 0data=20before=20LC=20for=20RFC |Sender:=20; bh=kegm+GYDfRgP2LF/vwfjfUl7bEXiE1E+NDEidfORIVA=; b=USy6VQ3LvedwHSAHFhE0QW2GAsw+xCh0sVEgMXnqe9pcHEsroQ+1t5d5fAVPg9a92UkPrHr5 31n0RSbagRMrrsOnr/hLBlZg4dmD05MOiu2xLgb2fVfxfsGDtHIZ4wnc29XQ3Gh/gIQXgmY4ND woDpsfpx3YS/NsA3Vv3V1RTL4=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 4ec3642ae9025e273a4a263d640f3300 Cc: 'Cullen Jennings' , 'SIP' , 'Behave WG' , mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There are in fact deployments of ICE, more than one, based on previous versions of the draft. Most folks I talk to are waiting to IETF to finish this thing, so they can go upgrade their code and move to the final version. Delaying it, making it experiental, informational, or any other variation will serve no other purpose than to convince everyone that this work is not done, and so folks should continue to wait. If you want an industry's worth of feedback and data, lets go and finish this thing. That means PS. All of that said, ICE has, probably more than most other specs that have ever come out of RAI, have had the benefit of: a. extensive technical review, comments and feedbacks, including commentary from implementors (including one in my own company, and several others from outside of it) and deployers (Tim Moore from Microsoft) b. design based on years of experience with NATs and NAT traversal c. design based on real collected data on NAT behaviors and on techniques used in other applications d. consideration on incremental deployability and applicability across the entire range of SIP, from p2p to enterprise to large provider to closed application provider and so on e. multiple open source implementations (two have been pointed out already) f. an active design team including security experts that helped in the massive redesign in -10 to simplify things And as such, it would seem to me that, not only is there not a single shred of evidence that suggests this draft deserves anything less than PS, there is evidence only to demonstrate that it has quality far greater than most IETF protocols with that moniker. Other parts of this thread have been folks suggesting alternative techniques that are simpler or work better. Well, I look forward to their drafts. So far, no one has suggested a single thing which was not considered and/or incorporated into ICE in some way over the last four years. ICE was built for reliability - to cover lots of cases and achieve not just 90% effectiveness (not nearly good enough), but as effective as is possible within the limitations of hurting the Internet or violating security policies and other things we won't touch. Without a doubt you can design a custom protocol for any one single deployment scenario with some set of assumptions that works simpler with fewer messages. However, our objective was to design a NAT traversal solution for SIP that applied as broadly as SIP did. ICE has the benefit of resulting in simple flows in simple topologies, but the same logic produces more complex flows in more complex situations, but still works. That was a design decision we made years ago and it remains a sound one. Comments have also been made that, "well, you thought STUN would work and you were wrong". This too is bogus. The limitations of STUN were known at the time of its publication. It was our hope that enough of a market would find it acceptable to be useful. Quoting from RFC 3489: > STUN introduces brittleness into the system in several ways: > > o The discovery process assumes a certain classification of devices > based on their treatment of UDP. There could be other types of > NATs that are deployed that would not fit into one of these molds. > Therefore, future NATs may not be properly detected by STUN. STUN > clients (but not servers) would need to change to accommodate > that. > > o The binding acquisition usage of STUN does not work for all NAT > types. It will work for any application for full cone NATs only. > For restricted cone and port restricted cone NAT, it will work for > some applications depending on the application. Application > specific processing will generally be needed. For symmetric NATs, > the binding acquisition will not yield a usable address. The > tight dependency on the specific type of NAT makes the protocol > brittle. > > o STUN assumes that the server exists on the public Internet. If > the server is located in another private address realm, the user > may or may not be able to use its discovered address to > communicate with other users. There is no way to detect such a > condition. > > o The bindings allocated from the NAT need to be continuously > refreshed. Since the timeouts for these bindings is very > implementation specific, the refresh interval cannot easily be > determined. When the binding is not being actively used to > receive traffic, but to wait for an incoming message, the binding > refresh will needlessly consume network bandwidth. > > o The use of the STUN server as an additional network element > introduces another point of potential security attack. These > attacks are largely prevented by the security measures provided by > STUN, but not entirely. > > > > > > > > Rosenberg, et al. Standards Track [Page 40] > > RFC 3489 STUN March 2003 > > > o The use of the STUN server as an additional network element > introduces another point of failure. If the client cannot locate > a STUN server, or if the server should be unavailable due to > failure, the application cannot function. > > o The use of STUN to discover address bindings will result in an > increase in latency for applications. For example, a Voice over > IP application will see an increase of call setup delays equal to > at least one RTT to the STUN server. > > o The discovery of binding lifetimes is prone to error. It assumes > that the same lifetime will exist for all bindings. This may not > be true if the NAT uses dynamic binding lifetimes to handle > overload, or if the NAT itself reboots during the discovery > process. > > o STUN imposes some restrictions on the network topologies for > proper operation. If client A obtains an address from STUN server > X, and sends it to client B, B may not be able to send to A using > that IP address. The address will not work if any of the > following is true: > > - The STUN server is not in an address realm that is a common > ancestor (topologically) of both clients A and B. For example, > consider client A and B, both of which have residential NAT > devices. Both devices connect them to their cable operators, > but both clients have different providers. Each provider has a > NAT in front of their entire network, connecting it to the > public Internet. If the STUN server used by A is in A's cable > operator's network, an address obtained by it will not be > usable by B. The STUN server must be in the network which is a > common ancestor to both - in this case, the public Internet. > > - The STUN server is in an address realm that is a common > ancestor to both clients, but both clients are behind the same > NAT connecting to that address realm. For example, if the two > clients in the previous example had the same cable operator, > that cable operator had a single NAT connecting their network > to the public Internet, and the STUN server was on the public > Internet, the address obtained by A would not be usable by B. > That is because some NATs will not accept an internal packet > sent to a public IP address which is mapped back to an internal > address. To deal with this, additional protocol mechanisms or > configuration parameters need to be introduced which detect > this case. > > > > > > > Rosenberg, et al. Standards Track [Page 41] > > RFC 3489 STUN March 2003 > > > o Most significantly, STUN introduces potential security threats > which cannot be eliminated. This specification describes > heuristics that can be used to mitigate the problem, but it is > provably unsolvable given what STUN is trying to accomplish. > These security problems are described fully in Section 12. Well, the market didn't find it useful enough. And so we worked to improve. Nearly every one of these limitations has been eliminated by ICE. Go read the IAB considerations section, which discusses this. Binding lifetime discovery is pretty much the only remaining one; fortunately that is a minor one and ICE is just aggressive in that area to compensate. The STUN-control work Dan has been promoting is meant to add ontop of ICE to finally close that issue. So, in case its not abundantly clear, I think there is no merit to the calls for changing ICE to informational or experimental, and that these last minute claims of better solutions or simpler solutions are also without merit. ICE is as deserving, and indeed more so, of a PS moniker than most other documents that achieve that label. -Jonathan R. David Barrett wrote: > Hi Cullen, I think you bring up lot of really great and detailed questions. > > However, speaking for myself at least, answering those questions doesn't > really address my concern. All I want to know is: > > Does ICE work, and how well? > > What "works" means is entirely open to debate. I've tossed out "high peer > connectivity" and "low connection setup time" as the most important > criteria, and I've put hard data behind those numbers as a stake in the > ground for comparison, but I'm open to other metrics as well. > > But regardless of the metrics, I want somebody who uses it and loves it and > bases their business upon its success to stand up and explain why it's > great. And I want this person to provide real-world data, sampled on a wide > scale, proving that ICE "works" -- by any definition. > > Basically, I want ICE firmly grounded in wide-scale testing and real-world > data, and answering the questions below doesn't bring us any closer to that. > Whether it's level 10 or level 12 doesn't produce new data. How its > algorithms differ from competing ones doesn't show that they're any better > or worse. Detailed proposals for change don't shed any light on whether > those changes improve or worsen it, because its current state is completely > unmeasured. > > The most powerful thing the IETF can do to standardize the world upon ICE is > prove that it works better than any alternative. Because until that's > proven, we just need to take it as a matter of faith. > > -david > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Wednesday, July 18, 2007 7:56 PM >> To: SIP; Behave WG; mmusic@ietf.org >> Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC >> >> >> First I apologize for the cross post - this is a mmusic draft, I >> would appreciate replies on the mmusic list only. >> >> Few things I am looking for here .... >> >> 1) specific reasons why this work is less appropriate for standards >> track than other work that IETF puts on the standards track. Keep in >> mind the first step of standards track is Proposed Standards which >> requires basically no interoperability, then it could move to Draft >> Standard where interoperability is shown and finally Full Standard if >> it turns out to be a good idea. If you are going to post a reply to >> this point, make sure you have read RFC 2026. >> >> 2) I am interested in the specifics of problems that ICE fails to >> solve that the WG has not previous considered. There are lots of >> people that have implemented versions of it and think it is a good >> idea - if people are having some problems with it, I'd love to hear >> about details of things that are wrong. That it has a lot of messages >> in some use cases has been known for a long time. It used to have far >> more messages - engineering was done to consider what was a >> reasonable amount for call set up times and a new design was done to >> bring the message to a level most people invovled with the design >> felt was reasonable. If there are specific other than these that are >> wrong and not considered in the design, now would be a good time to >> get them on the table. >> >> 3) If people think that Skype for example has a simpler solution that >> works better than ICE. Feel free to describe exactly what it is. >> Several people invovled with the ICE design have looked in extreme >> detail at Skype and others and so far none of them have come back >> with what we should do different than ICE. >> >> 4) ICE can be used in a mode where it only provided the reflexive >> candidate. People were pretty clear that this was far inferior to the >> modes where there are other candidates. If someone would like to >> provide exactly how hole punching works better than this very limited >> ICE technique, I'd be glad to hear the details. This has certainly >> been an topic that any could have brought up over the last several >> years. If someone has specifics, I suggest they get out a full >> proposal really soon. I am very doubtful that hole punching solution >> is fundamentally different than the type of hole punching ICE does. >> >> 5) Some people have suggested that if all NATs were behave complaint, >> then we would not need ICE. I strongly disagree. I think the only >> part of ICE we would not need is the TURN relays which are more or >> less an optional part. Again, specifics on what can be removed are >> welcome. >> >> ICE is far more complicated that anyone wants - the problem is, no >> one has come up with a proposal that looks like it comes anywhere >> close to meeting the requirements and if simpler. The design space >> has been extensively explored by many people. The raw data to >> understand what will work on what NATs have been painfully tested and >> documented in publications such as: >> >> http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf >> >> http://tools.ietf.org/id/draft-jennings-behave-test-results-04.txt >> >> https://www.guha.cc/saikat/stunt-results.php? >> >> (Ford used to have a page too but it seems to be gone) >> >> I have a very open mind to considering better ways to do ICE - but I >> need specific suggestions or it is impossible for me to really think >> about if the suggestions represent a better path or not. >> >> I would love to see more open source ICE code (there is lots already) >> - I feel that this is an area where ICE is likely just table stakes >> and owning an proprietary ICE stack will not turn out to be a >> competitive advantage. Having open source implementations where the >> development cost was shared and everyone could get working products >> to market faster would be an advantage to companies. Clearly I expect >> the bulk of ICE implementations to not be open source but I still >> would be keen on doing what I can to contribute to an open source >> version as personally I feel that is in the interest of end users, my >> employer, and the IETF as a SDO. >> >> Cullen >> >> >> >> On Jul 18, 2007, at 9:12 AM, Dean Willis wrote: >> >>> On Jul 18, 2007, at 3:10 AM, Magnus Westerlund wrote: >>> >>>> Henry Sinnreich skrev: >>>>> Following some discussions and soul searching, the best approach for >>>>> ICE-17 for LC would be to _go ahead and make it an experimental >>>>> RFC_. >>>>> This would support the development of interoperable >>>>> implementations, the >>>>> collection of deployment data and also hopefully open source code. >>>>> Though I have full faith in ICE, following the practices that >>>>> made the >>>>> IETF successful take precedent here, I believe. >>>>> This is a change from the attached that I wrote on 7/16/2007. >>>>> Note: We can only hope the proliferation of SBC in VoIP service >>>>> provider >>>>> networks will not make these concerns and ICE for SIP a moot >>>>> issue, but >>>>> this is another topic. >>>> Henry, >>>> >>>> I don't quite understand why you are requesting a status change of >>>> ICE? To me it appears that ICE is almost finished spec. It has >>>> been implemented, used and feedback has been influencing the >>>> protocol. It is definitly one of the better examples of current >>>> IETF work that actually has running code. Sure, the >>>> implementations may not be fully updated yet to the latest draft >>>> version. But I think it is safe to say that ICE works in the >>>> intended core cases. If there are some corner cases where it >>>> fails, that may be. But that is not information we will have until >>>> really large scale deployement or someone makes very extensive tests. >>> Henry has, I believe, been very consistent in urging the IETF to >>> have more "running code" experience on every specification (not >>> just ICE) than our process requires. He has, IIRC, also advocated >>> changing the process to require running code before publishing an >>> RFC. He's even suggested at times that one should have running code >>> before submitting a protocol draft. >>> >>> Another point to consider -- I've known Henry to bark at a tree >>> with no squirrel in it occasionally, but most of the time he's >>> pretty reliable, more so than most technology predictors. If he's >>> worried about ICE, it's probably because he's been talking to >>> people who are trying to implement it and they're telling him it is >>> difficult or that they're having performance or reliability issues. >>> I imagine that there are plenty of internal development teams in >>> various companies that are working on this and not necessarily >>> bringing their results back to the IETF. After all, if everybody >>> sees the emperor as fully clothed, they'd be embarrassed to >>> proclaim otherwise. Of course, I wish all of these developers were >>> tied into the IETF, but then I'm sure I don't want to see every ice- >>> implementor's question on the SIP list. That is why we have a sip- >>> implementors mailing list, right? >>> >>> Personally, I think ICE is the best solution we have. We KNOW of >>> cases where hole-punching doesn't work, and I think ICE will >>> produce usable results in most of those cases. But that's just my >>> personal opinion from reading the specs. I haven't implemented ICE, >>> and I haven't used anybody else's implementation. Sure, it's >>> complex, but that's because the underlying problem is complex -- >>> there are just too many different behaviors out there in "NAT and >>> firewall land". Of course, I could be wrong, too. It's happened >>> before, once or twice ;-). Just how sure are we that we're right >>> about this? >>> >>> Are we designing a "spruce goose" or a practical system? Only >>> experience will tell us. But some good flight reports from the >>> prototypes could go a long way towards reassuring us of the >>> design's utility. >>> >>> So far we've had a couple of people report hearsay evidence -- that >>> somebody else has an ICE implementation and it works. Any of you >>> folks have personal experience you can share? Have there been >>> prototypes exercised at the interop events? >>> >>> -- >>> Dean >>> >>> >>> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www1.ietf.org/mailman/listinfo/behave >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 10:12:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBWjZ-0005ka-9X; Thu, 19 Jul 2007 10:12:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBWjX-0005kS-FN for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 10:11:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBWjX-0005kK-5r for sip@ietf.org; Thu, 19 Jul 2007 10:11:59 -0400 Received: from alnrmhc15.comcast.net ([206.18.177.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBWjV-0007ni-UD for sip@ietf.org; Thu, 19 Jul 2007 10:11:59 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc15) with ESMTP id <20070719141157b15003rb8he>; Thu, 19 Jul 2007 14:11:57 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6JEBu8t025836 for ; Thu, 19 Jul 2007 10:11:56 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6JEBuOc025832; Thu, 19 Jul 2007 10:11:56 -0400 Date: Thu, 19 Jul 2007 10:11:56 -0400 Message-Id: <200707191411.l6JEBuOc025832@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <469F408D.2040704@nokia.com> (aki.niemi@nokia.com) Subject: Re: Model for entity-tags in subnot-etags (was: Re: [Sip] Comments on draft-ietf-sip-subnot-etags-00) References: <003601c7c8eb$d99e04b0$7c6c460a@china.huawei.com> <200707190419.l6J4Jpad014623@dragon.ariadne.com> <469F408D.2040704@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Aki Niemi - There is a single authoritative notifier agent responsible for any single resource. - A resource is identified using a SIP URI. - A subscriber subscribes to a resource using the SIP URI. Often a subscriber will send the SUBSCRIBE to a URI which is not the request-URI of the SUBSCRIBE when it reaches the notifier agent. This happens due to normal SIP request routing, but the routing can also change with time. - Each entity has an assigned entity-tag. Each entity has a succession of versions. Each version of each entity has an assigned entity-tag. - There is a one-to-many relationship between an entity and its versions (different etag values, of which only one is current). - An entity-tag must be unique across all versions of all entities from a resource. Does this rule out hash-based entity-tags, which are only probabalistically unique? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 10:22:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBWu9-0004oO-7s; Thu, 19 Jul 2007 10:22:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBWu8-0004o6-0v for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 10:22:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBWu7-0004nf-Ap; Thu, 19 Jul 2007 10:22:55 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBWu5-0001cB-P4; Thu, 19 Jul 2007 10:22:55 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 19 Jul 2007 07:22:53 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALMPn0arR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,557,1175497200"; d="scan'208"; a="167345601:sNHT37532907" 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 l6JEMqNK031706; Thu, 19 Jul 2007 07:22:52 -0700 Received: from [10.32.245.154] (stealth-10-32-245-154.cisco.com [10.32.245.154]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6JEMo6C005087; Thu, 19 Jul 2007 14:22:50 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4BD296F0-6FC7-4BDE-A783-A835F081FBE7@cisco.com> Content-Transfer-Encoding: quoted-printable From: David R Oran Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 10:22:40 -0400 To: "David Barrett" X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12383; t=1184854972; x=1185718972; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20[BEHAVE]=20Re=3A=20ICE=20deployment=2 0data=20before=20LC=20for=20RFC |Sender:=20; bh=kqAskR4tW+DPt7PvKW86K+THsqhA+TM3eU/Pi58egKQ=; b=epeHg/r4RBUPTAeLA1lWvf0v1oPD3eMC7bZLizS+3AIfwH00Haa3Ql5fVLI5FOyTEf71XEyw WileZupc1krOR5mCO8GEMflbOq9B8jQECA+1ly2NLow3mUzDlUJS+6RQ; Authentication-Results: sj-dkim-4; header.From=oran@cisco.com; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: 'Cullen Jennings' , 'SIP' , 'Behave WG' , mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 19, 2007, at 6:15 AM, David Barrett wrote: > Hi Cullen, I think you bring up lot of really great and detailed =20 > questions. > > However, speaking for myself at least, answering those questions =20 > doesn't > really address my concern. All I want to know is: > > Does ICE work, and how well? > > What "works" means is entirely open to debate. It may have been in the past, but the debate I think is closed, =20 because the requirements captured the definition of "works". If you =20 want to re-open the requirements discussion, please be clear about that. > I've tossed out "high peer > connectivity" and "low connection setup time" as the most important > criteria, and I've put hard data behind those numbers as a stake in =20= > the > ground for comparison, but I'm open to other metrics as well. > See the requirements. One not often mentioned but clearly a =20 requirement that ICE works very hard to meet is "use the most direct =20 path available". > But regardless of the metrics, I want somebody who uses it and =20 > loves it and > bases their business upon its success to stand up and explain why it's > great. > And I want this person to provide real-world data, sampled on a wide > scale, proving that ICE "works" -- by any definition. > This is in fact an extremely important exercise, and precisely the =20 activity which according to RFC2026 is what should be happening after =20= approval as proposed standard, and before advancement to draft =20 standard. > Basically, I want ICE firmly grounded in wide-scale testing and =20 > real-world > data, and answering the questions below doesn't bring us any closer =20= > to that. > Whether it's level 10 or level 12 doesn't produce new data. How its > algorithms differ from competing ones doesn't show that they're any =20= > better > or worse. Detailed proposals for change don't shed any light on =20 > whether > those changes improve or worsen it, because its current state is =20 > completely > unmeasured. > Showing how the algorithms work better, or work in more cases that =20 are covered by the requirements does in fact show that it's better, =20 with respect to the requirements. Again, you're arguing indirectly =20 that we should re-open the requirements discussion, which I do not =20 think would be terribly productive, but would support if there is in =20 fact consensus to do so. > The most powerful thing the IETF can do to standardize the world =20 > upon ICE is > prove that it works better than any alternative. Because until that's > proven, we just need to take it as a matter of faith. > I do not think that is desirable. The perfect is the enemy of the =20 good. ICE does not have to be better than anything else. It just has =20 to be "good enough" and see wide adoption. That's my 2=A2 (as an individual, not as an IAB member, in case anybody =20= cares). DaveO > -david > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Wednesday, July 18, 2007 7:56 PM >> To: SIP; Behave WG; mmusic@ietf.org >> Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC =20 >> for RFC >> >> >> First I apologize for the cross post - this is a mmusic draft, I >> would appreciate replies on the mmusic list only. >> >> Few things I am looking for here .... >> >> 1) specific reasons why this work is less appropriate for standards >> track than other work that IETF puts on the standards track. Keep in >> mind the first step of standards track is Proposed Standards which >> requires basically no interoperability, then it could move to Draft >> Standard where interoperability is shown and finally Full Standard if >> it turns out to be a good idea. If you are going to post a reply to >> this point, make sure you have read RFC 2026. >> >> 2) I am interested in the specifics of problems that ICE fails to >> solve that the WG has not previous considered. There are lots of >> people that have implemented versions of it and think it is a good >> idea - if people are having some problems with it, I'd love to hear >> about details of things that are wrong. That it has a lot of messages >> in some use cases has been known for a long time. It used to have far >> more messages - engineering was done to consider what was a >> reasonable amount for call set up times and a new design was done to >> bring the message to a level most people invovled with the design >> felt was reasonable. If there are specific other than these that are >> wrong and not considered in the design, now would be a good time to >> get them on the table. >> >> 3) If people think that Skype for example has a simpler solution that >> works better than ICE. Feel free to describe exactly what it is. >> Several people invovled with the ICE design have looked in extreme >> detail at Skype and others and so far none of them have come back >> with what we should do different than ICE. >> >> 4) ICE can be used in a mode where it only provided the reflexive >> candidate. People were pretty clear that this was far inferior to the >> modes where there are other candidates. If someone would like to >> provide exactly how hole punching works better than this very limited >> ICE technique, I'd be glad to hear the details. This has certainly >> been an topic that any could have brought up over the last several >> years. If someone has specifics, I suggest they get out a full >> proposal really soon. I am very doubtful that hole punching solution >> is fundamentally different than the type of hole punching ICE does. >> >> 5) Some people have suggested that if all NATs were behave complaint, >> then we would not need ICE. I strongly disagree. I think the only >> part of ICE we would not need is the TURN relays which are more or >> less an optional part. Again, specifics on what can be removed are >> welcome. >> >> ICE is far more complicated that anyone wants - the problem is, no >> one has come up with a proposal that looks like it comes anywhere >> close to meeting the requirements and if simpler. The design space >> has been extensively explored by many people. The raw data to >> understand what will work on what NATs have been painfully tested and >> documented in publications such as: >> >> http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf >> >> http://tools.ietf.org/id/draft-jennings-behave-test-results-04.txt >> >> https://www.guha.cc/saikat/stunt-results.php? >> >> (Ford used to have a page too but it seems to be gone) >> >> I have a very open mind to considering better ways to do ICE - but I >> need specific suggestions or it is impossible for me to really think >> about if the suggestions represent a better path or not. >> >> I would love to see more open source ICE code (there is lots already) >> - I feel that this is an area where ICE is likely just table stakes >> and owning an proprietary ICE stack will not turn out to be a >> competitive advantage. Having open source implementations where the >> development cost was shared and everyone could get working products >> to market faster would be an advantage to companies. Clearly I expect >> the bulk of ICE implementations to not be open source but I still >> would be keen on doing what I can to contribute to an open source >> version as personally I feel that is in the interest of end users, my >> employer, and the IETF as a SDO. >> >> Cullen >> >> >> >> On Jul 18, 2007, at 9:12 AM, Dean Willis wrote: >> >>> >>> On Jul 18, 2007, at 3:10 AM, Magnus Westerlund wrote: >>> >>>> Henry Sinnreich skrev: >>>>> Following some discussions and soul searching, the best =20 >>>>> approach for >>>>> ICE-17 for LC would be to _go ahead and make it an experimental >>>>> RFC_. >>>>> This would support the development of interoperable >>>>> implementations, the >>>>> collection of deployment data and also hopefully open source code. >>>>> Though I have full faith in ICE, following the practices that >>>>> made the >>>>> IETF successful take precedent here, I believe. >>>>> This is a change from the attached that I wrote on 7/16/2007. >>>>> Note: We can only hope the proliferation of SBC in VoIP service >>>>> provider >>>>> networks will not make these concerns and ICE for SIP a moot >>>>> issue, but >>>>> this is another topic. >>>> >>>> Henry, >>>> >>>> I don't quite understand why you are requesting a status change of >>>> ICE? To me it appears that ICE is almost finished spec. It has >>>> been implemented, used and feedback has been influencing the >>>> protocol. It is definitly one of the better examples of current >>>> IETF work that actually has running code. Sure, the >>>> implementations may not be fully updated yet to the latest draft >>>> version. But I think it is safe to say that ICE works in the >>>> intended core cases. If there are some corner cases where it >>>> fails, that may be. But that is not information we will have until >>>> really large scale deployement or someone makes very extensive =20 >>>> tests. >>> >>> Henry has, I believe, been very consistent in urging the IETF to >>> have more "running code" experience on every specification (not >>> just ICE) than our process requires. He has, IIRC, also advocated >>> changing the process to require running code before publishing an >>> RFC. He's even suggested at times that one should have running code >>> before submitting a protocol draft. >>> >>> Another point to consider -- I've known Henry to bark at a tree >>> with no squirrel in it occasionally, but most of the time he's >>> pretty reliable, more so than most technology predictors. If he's >>> worried about ICE, it's probably because he's been talking to >>> people who are trying to implement it and they're telling him it is >>> difficult or that they're having performance or reliability issues. >>> I imagine that there are plenty of internal development teams in >>> various companies that are working on this and not necessarily >>> bringing their results back to the IETF. After all, if everybody >>> sees the emperor as fully clothed, they'd be embarrassed to >>> proclaim otherwise. Of course, I wish all of these developers were >>> tied into the IETF, but then I'm sure I don't want to see every ice- >>> implementor's question on the SIP list. That is why we have a sip- >>> implementors mailing list, right? >>> >>> Personally, I think ICE is the best solution we have. We KNOW of >>> cases where hole-punching doesn't work, and I think ICE will >>> produce usable results in most of those cases. But that's just my >>> personal opinion from reading the specs. I haven't implemented ICE, >>> and I haven't used anybody else's implementation. Sure, it's >>> complex, but that's because the underlying problem is complex -- >>> there are just too many different behaviors out there in "NAT and >>> firewall land". Of course, I could be wrong, too. It's happened >>> before, once or twice ;-). Just how sure are we that we're right >>> about this? >>> >>> Are we designing a "spruce goose" or a practical system? Only >>> experience will tell us. But some good flight reports from the >>> prototypes could go a long way towards reassuring us of the >>> design's utility. >>> >>> So far we've had a couple of people report hearsay evidence -- that >>> somebody else has an ICE implementation and it works. Any of you >>> folks have personal experience you can share? Have there been >>> prototypes exercised at the interop events? >>> >>> -- >>> Dean >>> >>> >>> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www1.ietf.org/mailman/listinfo/behave >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 10:54:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBXNo-0003gt-0u; Thu, 19 Jul 2007 10:53:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBXNm-0003g9-Df for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 10:53:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBXNm-0003fs-21; Thu, 19 Jul 2007 10:53:34 -0400 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBXNl-0000So-Gs; Thu, 19 Jul 2007 10:53:34 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 2EA8B1810C50; Thu, 19 Jul 2007 16:53:33 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 19 Jul 2007 16:45:59 +0200 To: Jan Janak ,Juha Heinanen From: Jiri Kuthan Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC In-Reply-To: <469F5925.20401@iptel.org> References: <18079.325.333518.53741@tutpro.com> <469F5925.20401@iptel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20070719145334.2EA8B1810C50@mail.iptel.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sip@ietf.org, mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 14:29 19/07/2007, Jan Janak wrote: >Juha Heinanen wrote: >> a while back i read ice tutorial slides and my impression was that the >> protocol was very complex (pity implementers) and provided only a bit >> better nat traversal capability than what [open]ser/rtpproxy/mediaproxy >> have been offering to lots of users for years already. > > The NAT traversal algorithm implemented in [open]ser, rtpproxy, and > mediaproxy had been developed long before the first version of the ICE > draft; at that time no other solution existed (except for preliminary > STUN and TURN drafts), and we needed something to make it work; in > addition to that NAT traversal support in UA was virtually non-existent > back then. > > Having said that, it is true that the algorithm implemented in > [open]ser is simpler than ICE, but I believe that these two cannot > be directly compared. Even the NAT traversal logic in SER can get > pretty complex if none of the end-points is a PSTN gateway in the > public internet (especially if you want to handle re-INVITEs and > serial forking properly). I don't think it is a question whether ICE is complex or not. The question is if the complexity is worth it. An argumentation line one can choose is the e2e principle which justifies the load of software loaded in the end-devices (think for example of TCP) to gain reliability. If ICE can accomplish the reliability promise, it also helps to migrate away from media relays (which is what SER does using rtpproxy) , which is a good thing. So I think that the right course of action is that folks doubting ICE reliability make their case (by that I mean specific arguments rather than emotional debates about red-colored nails and other hardware). -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 11:05:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBXYN-0005bz-Fy; Thu, 19 Jul 2007 11:04:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBXYL-0005bn-Ck for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 11:04:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBXYJ-0005ax-Ex for sip@ietf.org; Thu, 19 Jul 2007 11:04:27 -0400 Received: from ext-sendmail2.labs.att.com ([205.173.58.20] helo=sendmail2.labs.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBXYI-0000rw-3B for sip@ietf.org; Thu, 19 Jul 2007 11:04:27 -0400 Received: from labs.att.com (internet-austin-webdmz.labs.sbc.com [144.60.9.139]) by sendmail2.labs.att.com (8.14.0/8.13.1) with ESMTP id l6JF4SwH019762 for ; Thu, 19 Jul 2007 10:04:28 -0500 Received: from TSMAIL.ad.tri.sbc.com (tsmail [144.60.55.228]) by labs.att.com (8.14.0/8.13.1) with ESMTP id l6JF4PO2011654 for ; Thu, 19 Jul 2007 10:04:25 -0500 Received: from TSMAIL2.ad.tri.sbc.com ([144.60.55.226]) by TSMAIL.ad.tri.sbc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 10:04:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jul 2007 10:04:24 -0500 Message-ID: <0CED449E95A92A42991EB71B778C17BF059AA475@TSMAIL2.ad.tri.sbc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC3891 (Replaces header) discrepancies Thread-Index: AcfKFhg2vEl7WNxoSQaARCTg5okW6w== From: "Jackson, James" To: X-OriginalArrivalTime: 19 Jul 2007 15:04:24.0748 (UTC) FILETIME=[1833AEC0:01C7CA16] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Subject: [Sip] RFC3891 (Replaces header) discrepancies X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0963273134==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0963273134== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CA16.18218B5C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CA16.18218B5C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It seems that there is discrepancy between a statement in RFC3891 and some vendor implementations. =20 RFC3891, section 4 states: =20 A UAC MUST NOT send an INVITE with a Replaces header field that attempts to replace an early dialog which was not originated by the target of the INVITE with a Replaces header field. =20 The issue appears to be related to the restriction of "originated" in the above statement. It tends to imply that it is invalid if the early dialog was "terminated" by the target rather than "originated" by the target. =20 Consider an attended transfer in which call1 is established between a transferee and a transferor. The transferor creates a new call2 towards transfer target. While this call is still alerting (early dialog), it sends a REFER on call1 with a Replaces header that references call2. In this case, the Replaces header attempts to replace an early dialog which was "terminated" by the target. =20 Thanks ! James ------_=_NextPart_001_01C7CA16.18218B5C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

        It seems that there is discrepancy between a = statement in RFC3891 and some vendor implementations.

         

           = RFC3891, section 4 states:

         

           A UAC = MUST NOT send an INVITE with a Replaces header field that = attempts

           to = replace an early dialog which was not originated by the target of = the

           INVITE with a Replaces header = field.

         

        The issue appears to be related to the restriction of = “originated” in the above statement. It tends to imply that it is invalid if the = early dialog was “terminated” by the target rather than = “originated” by the target.

         

        Consider an attended transfer in which call1 is = established between a transferee and a transferor. The transferor creates a new = call2 towards transfer target. While this call is still alerting (early = dialog), it sends a REFER on call1 with a Replaces header that references call2. In = this case, the Replaces header attempts to replace an early dialog which was = “terminated” by the target.

         

        Thanks !

        James

        ------_=_NextPart_001_01C7CA16.18218B5C-- --===============0963273134== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0963273134==-- From sip-bounces@ietf.org Thu Jul 19 11:20:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBXmq-0001Ir-0V; Thu, 19 Jul 2007 11:19:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBXmo-0001Bz-3z for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 11:19:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBXmn-0001Bp-PI; Thu, 19 Jul 2007 11:19:25 -0400 Received: from smtpauth01.csee.onr.siteprotect.com ([64.26.60.145]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBXmn-0003GY-FR; Thu, 19 Jul 2007 11:19:25 -0400 Received: from cornfed (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth01.csee.onr.siteprotect.com (Postfix) with ESMTP id 14D4D1C8029; Thu, 19 Jul 2007 10:05:08 -0500 (CDT) From: "Frank W. Miller" To: "'Jonathan Rosenberg'" , "'David Barrett'" Subject: RE: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 09:19:07 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <469F6E43.5050709@cisco.com> Thread-index: AcfKDQH7ZSN1xI7SS1Wni46u9zV1DQACXjyw Message-Id: <20070719150508.14D4D1C8029@smtpauth01.csee.onr.siteprotect.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: 'Cullen Jennings' , 'SIP' , 'Behave WG' , mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] a. extensive technical review, comments and feedbacks, including commentary from implementors (including one in my own company, and several others from outside of it) and deployers (Tim Moore from Microsoft) FM: While I applaud the time and effort that the large vendors have obviously invested in this, this is a qualitative statement. Perhaps Cisco and/or Microsoft have empirical data they would be willing to share about robustness and performance? I don't think anyone here, including myself, is saying that ICE should not go forward or be used (its ability to handle hairpinning is of great interest for example), we are asking for evidence that we're not going to have another 3489 experience if we can avoid it. e. multiple open source implementations (two have been pointed out already) FM: I think I missed those, can they be repeated? The only one I'm aware of is pjnath and its first release was a little over two months ago and its based on -15. Thanks, FM _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 11:36:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBY2L-0004WY-6G; Thu, 19 Jul 2007 11:35:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBY2J-0004WC-M3 for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 11:35:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBY2J-0004W0-BF; Thu, 19 Jul 2007 11:35:27 -0400 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBY2I-0003tj-Pv; Thu, 19 Jul 2007 11:35:27 -0400 Received: from source ([192.150.11.134]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Thu, 19 Jul 2007 08:35:14 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6JFXqot020951; Thu, 19 Jul 2007 08:33:53 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6JFZ70c021529; Thu, 19 Jul 2007 08:35:07 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 08:35:07 -0700 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 Subject: RE: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LCfor RFC Date: Thu, 19 Jul 2007 08:30:18 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AEDAED@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LCfor RFC Thread-Index: AcfJothpej38ca2VQqWJmM78llWMcwAdAQ6Q References: <239224.19734.qm@web33301.mail.mud.yahoo.com><3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca><24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> From: "Henry Sinnreich" To: "Philip Matthews" X-OriginalArrivalTime: 19 Jul 2007 15:35:07.0342 (UTC) FILETIME=[627936E0:01C7CA1A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Magnus Westerlund , behave@ietf.org, mmusic@ietf.org, sip@ietf.org, Pyda Srisuresh , "Frank W. Miller" , p2psip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Phil, You are right again, but as mentioned, concept papers (a true torrent over many years lately) and discussion lists cannot replace published measurement tools, measured results and tweaking the approach based on measurements; measuring the improvements, etc.=20 This is the reason why I am not going into debating points about the merits of ICE, but rather the best approach to make it successful and be able to prove it. ICE is not a protocol agreement like SIP, but a technology that faces the great physical complexity on the net, so the protocol discussion approach is no replacement for testing and tweaking. This probably explains why we are in this discussion about ICE in the first place. By the same token I-D process arguments and consensus are no replacement either for proof on the net.=20 Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Wednesday, July 18, 2007 8:19 PM To: Henry Sinnreich Cc: Magnus Westerlund; behave@ietf.org; mmusic@ietf.org; sip@ietf.org; Pyda Srisuresh; Frank W. Miller; p2psip@ietf.org Subject: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LCfor RFC On 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > Phil, > >> In my view, ICE _is_ a "Hole Punching Technique". > > Yes, you absolutely right, though the devil is in the details. > > We cannot go here into a shoot-out between hole punching or other > mentioned on the list vs. ICE, but there seems to be a huge difference > in effectiveness and performance. What precise algorithm are you talking about when you say this? As far as I am concerned, ICE is simply a well-documented hole =20 punching algorithm. It differs from others that I have seen written up in the following =20 ways: - ICE has the concept of peer reflexive addresses, which other hole-=20 punching techniques that I have seen do not; - ICE has the concept of controlling/controlled endpoint, which gives =20 the controller additional flexibility in choosing a path; - ICE does NOT have the concept of port prediction, which some other =20 techniques do (e.g., Saikat's TCP work). Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 11:42:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBY8v-0003Sm-JX; Thu, 19 Jul 2007 11:42:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBY8u-0003SF-08 for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 11:42:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBY8t-0003S6-LY; Thu, 19 Jul 2007 11:42:15 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBY8t-0004Bo-7b; Thu, 19 Jul 2007 11:42:15 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6JFgDq4006106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 10:42:13 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <469F865A.204@nostrum.com> Date: Thu, 19 Jul 2007 10:42:18 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: "Frank W. Miller" Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC References: <20070719150508.14D4D1C8029@smtpauth01.csee.onr.siteprotect.com> In-Reply-To: <20070719150508.14D4D1C8029@smtpauth01.csee.onr.siteprotect.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-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: 'SIP' , mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 7/19/07 10:19 AM, Frank W. Miller wrote: > FM: While I applaud the time and effort that the large vendors have > obviously invested in this, this is a qualitative statement. Perhaps Cisco > and/or Microsoft have empirical data they would be willing to share about > robustness and performance? That's the kind of data you get between "proposed standard" and "draft standard" -- not *prior* to publication. I'm not sure why there's so much noise about setting the bar much, much higher for ICE than we do for other IETF proposals. To be clear: to get this kind of experience (especially as it pertains to interoperability), you need to have a stable (i.e., frozen) specification. Internet Drafts simply don't provide an appropriate basis for the kinds of proof that you and others are demanding. I think we would all benefit from a quick review of RFC 2026: > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. ... > Implementors should treat Proposed Standards as immature > specifications. It is desirable to implement them in order to gain > experience and to validate, test, and clarify the specification. > However, since the content of Proposed Standards may be changed if > problems are found or better solutions are identified, deploying > implementations of such standards into a disruption-sensitive > environment is not recommended. /a _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 13:42:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBa0e-0001EL-VP; Thu, 19 Jul 2007 13:41:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBa0b-0001DI-Q0 for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 13:41:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBa0b-0001D4-7T for sip@ietf.org; Thu, 19 Jul 2007 13:41:49 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBa0a-0007Zw-7n for sip@ietf.org; Thu, 19 Jul 2007 13:41:49 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8EEA62067C; Thu, 19 Jul 2007 19:41:47 +0200 (CEST) X-AuditID: c1b4fb3c-aee7cbb0000007e1-d9-469fa25babd3 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7300A20554; Thu, 19 Jul 2007 19:41:47 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 19:41:47 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 19:41:46 +0200 Received: from [131.160.126.62] (rvi2-126-62.lmf.ericsson.se [131.160.126.62]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C279B24C0; Thu, 19 Jul 2007 20:41:46 +0300 (EEST) Message-ID: <469FA25A.9020806@ericsson.com> Date: Thu, 19 Jul 2007 20:41:46 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides for body (MIME) handling) References: <469DF98F.3060506@ericsson.com> <469E261B.7090804@cisco.com> <469F38A0.7090404@ericsson.com> <469F6E3A.3000203@cisco.com> In-Reply-To: <469F6E3A.3000203@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 17:41:46.0932 (UTC) FILETIME=[142E9F40:01C7CA2C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, yes, I agree there is a bigger issue with 'render'. Even though this bigger issue does not directly relate to multipart, we can also tackle it in the same draft and clarify how 'render' is used and what it means. Cheers, Gonzalo Paul Kyzivat wrote: > > > Gonzalo Camarillo wrote: >> Hi Paul, >> >>> Regarding Content-Disposition in multiparts: >>> >>> While it seems "wrong" to me, I can live with using "render" as the >>> normal disposition for multipart, *if* we can do a careful job of >>> defining what "render" actually means for SIP. Used this way it >>> clearly doesn't always mean to display the content to a user. >> >> An entity receiving a 'multipart/mixed' body will process its body >> parts based on their disposition types.If the disposition type of a >> particular body part is not understood, it will be displayed to the >> user because the default disposition type is 'render'. > > There is a bigger problem with 'render' than just multipart. > > We have many uses of body parts that never mention Content-Disposition > at all. The related examples don't use it, and so they all get a default > of 'render'. This is particularly the case with events. E.g. > > - the notification for REFER contains type application/sipfrag. > Its probably not intended to be "rendered" in any literal sense, > though some conclusion about success or failure may be. > > - usage of filter bodies in presence subscriptions (RFC 4660) > doesn't have a specified disposition, so it implicitly uses render. > Its hard for me to convince myself that what the presence server > does with these can be described as rendering. > > - In fact, the only place I can think of where 'render' is (implicitly) > used in sip and has the appropriate connotation is in MESSAGE. > > I think we just have to grandfather the use of 'refer' in SIP, and > document that the usage in sip does not mean "render", but rather means > that the usage must be determined by other context - specifically the > type of message or response and the content type. IOW, 'render' in sip > can be thought of as a peculiar spelling for 'by-context'. It might be > helpful to give guidance for development of future specs about when > 'render' should be used vs defining a new disposition. > >> Therefore, the 'multipart/mixed' body will never be processed based on >> its disposition type. > > Based on my discussion above, I would consider this a case of the > multipart being processed according to its context *because* its > content-disposition is 'refer'. If it had some other content-disposition > then that might mean that it should be processed specially. E.g. if a > multipart/mixed had disposition 'by-reference' then that needs to be > taken into account, and the processing of the multipart becomes > conditional on the reference. > > Also, there are only certain contexts in which multipart should be > processed "normally". Consider a NOTIFY from a REFER, with a > Content-Type of message/sipfrag, which happened to include a body as > part of the fragment. (This is legal.) That body might contain a > multipart/mixed, and that might contain other stuff. But I think the > processing of all of that is dependent on processing of the sipfrag. For > instance, if something inside that had handling=required, I don't think > that means that processing of the NOTIFY fails because the recipient > can't handle that. > >> This means that it does not make much sense to talk about its >> disposition type as a whole. > > Counterexample above. > >> However, we need to have one in order to be able to set its handling >> parameter. That's why we can either keep 'render' explaining that it >> is actually never used or define a new disposition type. > > I can go either way on that. But because there is existing usage, and > because 'render' semantics are already so messed up, I think it makes > more sense to stick with 'render' and just clarify its meaning. > >> Since existing implementations will not understand our newly defined >> disposition type, they will treat it as 'render' anyway... but the >> resulting behavior would be the same. That's why it may make sense to >> keep using 'render'. > > Yup. > >> On the other hand, semantically, it would make more sense to define a >> new disposition type. >> >> Also, if we decide to define the 'by-reference' disposition type (per >> a different email thread), it could be used here as well. > > It could be used when there is actually a reference to it. But it would > not be an appropriate disposition to use when there is no reference to > the multipart. > > Thanks, > Paul > >> Cheers, >> >> Gonzalo >> >> >> >>> Gonzalo Camarillo wrote: >>>> Folks, >>>> >>>> here you have the slides I have put together for the body (MIME) >>>> handling presentation on Monday: >>>> >>>> http://users.piuha.net/gonzalo/temp/ietf69-sip-camarillo-body-handling.ppt >>>> >>>> >>>> These slides relate to this draft: >>>> >>>> http://www.ietf.org/internet-drafts/draft-camarillo-sip-body-handling-01.txt >>>> >>>> >>>> The slides discuss all the open issues that have been brought up in >>>> the list in the last months. >>>> >>>> Comments are welcome. >>>> >>>> Thanks, >>>> >>>> Gonzalo >>>> >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>>> >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 13:47:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBa66-0005yK-JY; Thu, 19 Jul 2007 13:47:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBa65-0005yD-CO for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 13:47:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBa65-0005y5-2z for sip@ietf.org; Thu, 19 Jul 2007 13:47:29 -0400 Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBa64-0005Kq-Pj for sip@ietf.org; Thu, 19 Jul 2007 13:47:29 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc14) with ESMTP id <20070719174727m1400m1teve>; Thu, 19 Jul 2007 17:47:27 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6JHlQ8t009066 for ; Thu, 19 Jul 2007 13:47:26 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6JHlQqL009062; Thu, 19 Jul 2007 13:47:26 -0400 Date: Thu, 19 Jul 2007 13:47:26 -0400 Message-Id: <200707191747.l6JHlQqL009062@dragon.ariadne.com> To: sip@ietf.org In-reply-to: <0CED449E95A92A42991EB71B778C17BF059AA475@TSMAIL2.ad.tri.sbc.com> (james_jackson@labs.att.com) Subject: Re: [Sip] RFC3891 (Replaces header) discrepancies From: Dale.Worley@comcast.net References: <0CED449E95A92A42991EB71B778C17BF059AA475@TSMAIL2.ad.tri.sbc.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Jackson, James" Consider an attended transfer in which call1 is established between a transferee and a transferor. The transferor creates a new call2 towards transfer target. While this call is still alerting (early dialog), it sends a REFER on call1 with a Replaces header that references call2. In this case, the Replaces header attempts to replace an early dialog which was "terminated" by the target. That is not allowed by RFC 3891. But suppose it was allowed. Further suppose that the transfer target rings for another 90 seconds (sending an additional 180) and then the proxy that manages the transfer target cancels the call, causing the transfer target to send a 487. Who receives the 180 and 487? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 13:51:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaA6-0007QF-Cc; Thu, 19 Jul 2007 13:51:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBaA5-0007Po-0k for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 13:51:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaA4-0007Pf-NO; Thu, 19 Jul 2007 13:51:36 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBaA2-0005Qs-TN; Thu, 19 Jul 2007 13:51:36 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IBaA3-0000Eq-0i; Thu, 19 Jul 2007 13:51:35 -0400 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AEDAED@namail5.corp.adobe.com> References: <239224.19734.qm@web33301.mail.mud.yahoo.com><3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca><24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> <24CCCC428EFEA2469BF046DB3C7A8D22AEDAED@namail5.corp.adobe.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9280291A-AB5A-4AC8-BD63-75AE5339B33D@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LCfor RFC Date: Thu, 19 Jul 2007 13:51:47 -0400 To: Henry Sinnreich X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Magnus Westerlund , behave@ietf.org, mmusic@ietf.org, sip@ietf.org, Pyda Srisuresh , "Frank W. Miller" , p2psip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree that it would be very nice to see more published data on when ICE succeeds (and specifically when it succeeds in finding a direct path). It would also be nice to see more open source implementations. It used to be that the Routing area would hold a draft in the "almost done" state until they had some implementation experience, and then publish as an RFC only once they had that data. Is this what you are looking for? - Philip On 19-Jul-07, at 11:30 , Henry Sinnreich wrote: > Phil, > > You are right again, but as mentioned, concept papers (a true torrent > over many years lately) and discussion lists cannot replace published > measurement tools, measured results and tweaking the approach based on > measurements; measuring the improvements, etc. > > This is the reason why I am not going into debating points about the > merits of ICE, but rather the best approach to make it successful > and be > able to prove it. > > ICE is not a protocol agreement like SIP, but a technology that faces > the great physical complexity on the net, so the protocol discussion > approach is no replacement for testing and tweaking. This probably > explains why we are in this discussion about ICE in the first place. > > By the same token I-D process arguments and consensus are no > replacement > either for proof on the net. > > Henry > > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Wednesday, July 18, 2007 8:19 PM > To: Henry Sinnreich > Cc: Magnus Westerlund; behave@ietf.org; mmusic@ietf.org; sip@ietf.org; > Pyda Srisuresh; Frank W. Miller; p2psip@ietf.org > Subject: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data > before > LCfor RFC > > > On 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > >> Phil, >> >>> In my view, ICE _is_ a "Hole Punching Technique". >> >> Yes, you absolutely right, though the devil is in the details. >> >> We cannot go here into a shoot-out between hole punching or other >> mentioned on the list vs. ICE, but there seems to be a huge >> difference >> in effectiveness and performance. > > What precise algorithm are you talking about when you say this? > As far as I am concerned, ICE is simply a well-documented hole > punching algorithm. > It differs from others that I have seen written up in the following > ways: > - ICE has the concept of peer reflexive addresses, which other hole- > punching techniques that I have seen do not; > - ICE has the concept of controlling/controlled endpoint, which gives > the controller additional flexibility in choosing a path; > - ICE does NOT have the concept of port prediction, which some other > techniques do (e.g., Saikat's TCP work). > > Philip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 13:53:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaBw-0002ke-56; Thu, 19 Jul 2007 13:53:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBaBv-0002kS-0z for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 13:53:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaBu-0002kK-MP for sip@ietf.org; Thu, 19 Jul 2007 13:53:30 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBaBu-00082M-10 for sip@ietf.org; Thu, 19 Jul 2007 13:53:30 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3F71C205E7; Thu, 19 Jul 2007 19:53:25 +0200 (CEST) X-AuditID: c1b4fb3c-b1681bb0000007e1-ca-469fa5150afd Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 216D2203F7; Thu, 19 Jul 2007 19:53:25 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 19:53:24 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 19:53:24 +0200 Received: from [131.160.126.62] (rvi2-126-62.lmf.ericsson.se [131.160.126.62]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1F3FB24C0; Thu, 19 Jul 2007 20:53:24 +0300 (EEST) Message-ID: <469FA512.2050200@ericsson.com> Date: Thu, 19 Jul 2007 20:53:22 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: References to Body Parts WAS (Re: [Sip] Draft slides for body (MIME) handling) References: <469DF98F.3060506@ericsson.com> <469E261B.7090804@cisco.com> <469F361C.1080908@ericsson.com> <469F6496.8050608@cisco.com> In-Reply-To: <469F6496.8050608@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 17:53:24.0433 (UTC) FILETIME=[B3ECD410:01C7CA2D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Paul, > > The interaction with handling=required would be that if you are not able > > to find a reference to a 'by-reference' body part with > > handling=required, you report an error because you have not been able to > > process the body part. > > Hmm. I guess that makes sense. It means that any time there is an > optional header with a reference to a body part then the handling of > that body part needs to be optional. But again I guess that makes good > sense. Not really. I create an extension that consists of a header field (which is optional as any other new header field) that points to a body of disposition type 'by-reference'. If I want to make sure that the UAS understands the extension, I set the body's handling parameter to required. If the UAS does not understand the header field, it will not find any reference to the body. Therefore, it will not be able to process it and will return an error response. Of course, this could also be done with an option-tag in a Require header field. > Some interesting questions arise when body parts are being processed by > middleboxes. (Maybe we aren't supposed to talk about that here.) The > whole issue of handling=required gets messy there. The middlebox isn't > the intended recipient, so the handling parameter doesn't really apply > to it. Well, this is true (or we want to think it is true) in SIP. But this is what RFC 3459 has to say about optional body parts: An OPTIONAL body part is one the sender doesn't care whether the receiving system delivers it or not. A content gateway can silently delete such body parts if the receiving system cannot deliver the part. Maybe we should add some clarifying text in the draft before B2BUA implementers decide to remove all optional body parts they get their hands on :o) > So presumably it processes whatever headers and body parts it > likes. That is another motivation for making the decision about > processing be explicit - so it can be selective. yes, being explicit is always good. Cheers, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 13:54:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaCP-0004GR-Au; Thu, 19 Jul 2007 13:54:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBaCO-0004GM-4W for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 13:54:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaCN-0004DW-ML for sip@ietf.org; Thu, 19 Jul 2007 13:53:59 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBaCM-00083A-V0 for sip@ietf.org; Thu, 19 Jul 2007 13:53:59 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 19 Jul 2007 10:53:58 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABdCn0arR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,557,1175497200"; d="scan'208"; a="9478254:sNHT17333070" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6JHrwBb013478; Thu, 19 Jul 2007 10:53:58 -0700 Received: from dwingwxp ([128.107.115.252]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6JHrvSb006597; Thu, 19 Jul 2007 17:53:57 GMT From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" , Subject: RE: [Sip] SIP Identity using Media Path Date: Thu, 19 Jul 2007 10:53:57 -0700 Message-ID: <0c1a01c7ca2d$c7fb9040$7d646b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <7374777208BDC7449D5620EF94232567073F7740@esealmw113.eemea.ericsson.se> Thread-Index: Ace82p2yNu6lfaNzQcq8BXk5gCIEoQAHC+iwAAFo/cADO9lZkAAH6/iA DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4473; t=1184867638; x=1185731638; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20SIP=20Identity=20using=20Media=20Path |Sender:=20; bh=rMxHoxHbVeeDmswO25CtU27Gbg/dPkoewKbWxPu2Edo=; b=WIwEsRTy+gfvxi2U3RH3IdxOvT8z91GoF25mINp6Hdjj7w65WwuhtKhktOFsnF1geqcYqFEN rWFy75vm5qduNl+OyxqDBc6V7HFfz+OJvSXcF3jULUGo6fnWjjdXfpkA; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, July 19, 2007 3:11 AM > To: Dan Wing; sip@ietf.org > Cc: ietf-rtpsec@imc.org > Subject: RE: [Sip] SIP Identity using Media Path > > > Hi, > > >>"in order for the mechanism to work, SBC-type-of-entities > >>must permit > >>DTLS, TLS, ICE, or HIP messages to be exchanged in the media path." > >> > >>A small question for clarification: at what point must this > >>exchange > >>(two-way, I assume) work? As soon as the UAS has received > >>the INVITE? > > > >Yes. > > A little more on this. > > As we have discussed before, you may not have two-way connectivity > before 200 OK. > > I am pretty sure what will not work with most SBCs. > > Now assume that you will have two-way connectivity before you > have even sent the SDP answer. I think you meant to say "now assume that you will _not_ ..."? In the case of no media path, it would only be possible for the authentication server, and the UA receiving the SIP request, to cryptographically validate the SIP headers and a very minor portion of the SDP (From:, Date:, and the header that we generate that copies the a=fingerprint attributes from the SDP, and the few other headers described in -wing-sip-identity-media). This provides some protection against attackers, and works through SBCs. Specifically, this protects against attackers who were not able to obtain a validly-signed SIP request. However, only validating those SIP headers is inadequate if an attacker has captured or otherwise acquired a validly-signed SIP request, modified the SDP (such that the signature is still valid), and re-injected that SIP request into a SIP proxy that forwards it to you. In order to detect such a replay attack, you need to perform one of the media-path based tests that I describe in wing-sip-identity-media (DTLS-SRTP, HIP, ICE, TLS). > Also, even if you don't have any SBCs, but you still have NATs, the > calling user often needs to send something in order to open the NAT > binding, and allow media plane traffic (including your identity > exchange) from the remote end. If you use ICE, or stand-alone > STUN, you > will have an open NAT binding, but if your terminal opens the network > e.g. by sending dummy RTP packets, it will not be able to do > so until it > has received the SDP answer. * But if you haven't received the SDP answer, where are you sending those dummy RTP packets (what is their destination IP address and UDP port)? * If the NAT perform address-based filtering of incoming packets, it drop incoming UDP packets until the device behind the NAT (the SIP UA, in our case) sends a packet to the IP address sending the incoming packet. The SIP UA would learn that IP address upon receipt of the SDP answer. Further, if the NAT is doing port filtering of incoming packets, the SIP UA needs to know the UDP port the external packet is arriving from, too (which also shows up in the answer). I point out the problem with port filtering NATs because sending dummy UDP packets to the SBC's IP address is not sufficient for those kinds of NATs. Similarly, if the NAT is symmetric (assigns a new UDP port for every new destination port or destination address the SIP UA sends to), sending dummy UDP packets won't be effective for symmetric NATs, either. > So, I also think your solution requires support of ICE/STUN, > and in the case of ICE it also requires that the SBCs > don't mess up the SDP so that ICE will not be used. No, it does not. For protection against simple From: spoofing, it is adequate to simply validate the SIP headers and the signature. For protection against replay attacks, it is necessary for both SIP UAs (*) to implement one of HIP, ICE, DTLS-SRTP, or TLS. (*) The replay attack prevention and implementation of HIP, ICE (with the extension described in -wing-sip-identity-media), DTLS-SRTP, or TLS can be done by the SIP UA itself _or_ by the SBC associated with the UA's signing domain -- such as the Enterprise's SBC if the enterprise is signing the identity (dwing@cisco.com, dwing@boeing.com); or, if the SIP UA's identity is signed by a Service Provider, the SBC operated by the service provider). -d > Regards, > > Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 13:55:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaDa-00057c-CV; Thu, 19 Jul 2007 13:55:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBaDZ-00056v-5m for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 13:55:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaDY-00056n-Qs for sip@ietf.org; Thu, 19 Jul 2007 13:55:12 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBaDY-00085M-7c for sip@ietf.org; Thu, 19 Jul 2007 13:55:12 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Thu, 19 Jul 2007 10:45:01 -0700 From: "David Barrett" To: "'Philip Matthews'" , "'Frank W. Miller'" Subject: RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 10:44:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfJ/AEOlBMUriURROWxMoN7RNp/BQALk3Uw X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Message-Id: Cc: 'Magnus Westerlund' , 'Behave WG' , 'IETF MMUSIC WG' , sip@ietf.org, 'Pyda Srisuresh' , 'Henry Sinnreich' , 'P2PSIP Mailing List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC > > David Barrett's algorithm, if I understand it correctly, would work in > this situation. (As far as I can tell, David's is a simplified version > of ICE). That's correct. The major differences (so far as I know) between what I'm doing and what ICE does include: - Peer's needn't exchange SDP before attempting connection establishment (rather, the rendezvous server just tells both sides the others' LAN/NAT addresses and they try to connect immediately). - Paths are evaluated in parallel rather than sequentially (ie, I attempt to contact you direct via the LAN and indirectly via your NAT at the same time, and then pick the faster of the two) - There's no support for TURN servers as my application doesn't require them (though it would be extremely straightforward to add). - Clients attempt NAT classification as a *purely advisory* function to support debugging and feed into certain non-critical pairwise optimizations. (Said another way, even if the classification is totally wrong, it'll still work.) - Clients use adaptive keepalives to a STUN server to keep their NAT/FW "hole" open. By "adaptive" I mean I use probing to determine highest safe keepalive frequency of the NAT/FW. (Incidentally, there's no requirement that any two clients use the same STUN server, and indeed I intend to move to enable a "distributed STUN service" using the peers themselves.) Basically, I do the minimum necessary for my requirements, which I respect are much easier than SIP's. However, know that despite my system being much easier, it has been *extremely difficult and time consuming* to get working, despite dozens of iterations drawing upon a network of hundreds of thousands of machines on which to test. Thus I would suggest that if my solution took as long as it did, and went through as many variations as it did, the SIP/ICE implementers should be very wary of hardening anything too early before it hits the real world. Because the real world is really, really strange and unpredictable, I can guarantee you that. Phillip's asked me to put together a bit more precise overview of the system I use and I'll try to get to that soon. -david _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 14:02:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaK6-0001E3-9m; Thu, 19 Jul 2007 14:01:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBaK4-0001DY-G7 for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:01:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaK4-0001DK-4z for sip@ietf.org; Thu, 19 Jul 2007 14:01:56 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBaK3-0008PA-J0 for sip@ietf.org; Thu, 19 Jul 2007 14:01:56 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Thu, 19 Jul 2007 11:01:52 -0700 From: "David Barrett" To: "'Pyda Srisuresh'" , "'Melinda Shore'" , "'Philip Matthews'" Subject: RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 11:01:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <725173.15437.qm@web33312.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfKLJfy3vmiOiN8RFO5qEAMFGqczAAAiOtQ X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Message-Id: Cc: sip@ietf.org, 'Henry Sinnreich' , behave@ietf.org, mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Just UDP so far, though I harbor ambitions of adding TCP to the mix so it'll try a bit of everything. > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > Sent: Thursday, July 19, 2007 10:39 AM > To: David Barrett; 'Melinda Shore'; 'Philip Matthews' > Cc: sip@ietf.org; 'Henry Sinnreich'; behave@ietf.org; mmusic@ietf.org > Subject: RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC > > David, > > 90% success in connection rate is very impressive. Are you refering to > UDP, TCP > or both? As you say, fallback such as relay is essential for 100% > connectivity. > One cannot use hole punching without a good fallback scheme. > > regards, > suresh > > --- David Barrett wrote: > > > > -----Original Message----- > > > From: Melinda Shore [mailto:mshore@cisco.com] > > > > > > ICE makes me want to pound red-hot nails into my eye sockets. That > said, > > > 90% really isn't nearly good enough for residential deployments. > > > > Incidentally, 90% is where my stats come out today -- this doesn't > include > > restricted-cone/symmetric and symmetric/symmetric penetration, which has > > been prototyped but not added to the production system yet. The hope is > > this will get us much close to the 99% range, but it remains to be seen > by > > how much. > > > > Furthermore, I'd wager that for most applications (such as VoIP), even > > routing 1 in 10 calls through a central relay isn't going to break the > bank. > > (Or for mega-discounts, use the full-cone and non-NAT'd clients (>30%) > to > > act as "free" relays for their peers.) > > > > Thus while NAT penetration using what I guess we're calling the "hole > > punching technique" has been demonstrated to work at 90%+ on a very > large > > scale (hundreds of thousands of clients tested) we should expect that > it's > > possible to get even better still. If ICE can show how it'd do better, > > that'd be great. But we can't tolerate ICE being any worse than that, > and > > thus before rushing ahead with standardizing an unproven ICE, we should > just > > take the time to prove it. > > > > -david > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 14:02:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaKO-0001ue-W7; Thu, 19 Jul 2007 14:02:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBaKH-0001gg-Rr for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:02:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaKH-0001eO-21 for sip@ietf.org; Thu, 19 Jul 2007 14:02:09 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBaKF-0008Q5-DD for sip@ietf.org; Thu, 19 Jul 2007 14:02:08 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Thu, 19 Jul 2007 11:01:53 -0700 From: "David Barrett" To: "'David R Oran'" Subject: RE: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 11:01:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <4BD296F0-6FC7-4BDE-A783-A835F081FBE7@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfKEH90TIWL7i1uTU+0yFCSG5eilwAHdIkw X-Spam-Score: 0.0 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 Message-Id: Cc: 'Cullen Jennings' , 'SIP' , 'Behave WG' , mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Actually, I'm not trying to reopen the requirements debate. I just want = ICE measured against the requirements that were agreed upon. And I completely agree that perfect is the enemy of the good. The only = ally of the good is reality, and I want to enlist her on our side. -david > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: Thursday, July 19, 2007 7:23 AM > To: David Barrett > Cc: 'Cullen Jennings'; 'SIP'; 'Behave WG'; mmusic@ietf.org > Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for = RFC >=20 >=20 > On Jul 19, 2007, at 6:15 AM, David Barrett wrote: >=20 > > Hi Cullen, I think you bring up lot of really great and detailed > > questions. > > > > However, speaking for myself at least, answering those questions > > doesn't > > really address my concern. All I want to know is: > > > > Does ICE work, and how well? > > > > What "works" means is entirely open to debate. > It may have been in the past, but the debate I think is closed, > because the requirements captured the definition of "works". If you > want to re-open the requirements discussion, please be clear about = that. >=20 > > I've tossed out "high peer > > connectivity" and "low connection setup time" as the most important > > criteria, and I've put hard data behind those numbers as a stake in > > the > > ground for comparison, but I'm open to other metrics as well. > > > See the requirements. One not often mentioned but clearly a > requirement that ICE works very hard to meet is "use the most direct > path available". >=20 > > But regardless of the metrics, I want somebody who uses it and > > loves it and > > bases their business upon its success to stand up and explain why = it's > > great. > > And I want this person to provide real-world data, sampled on a wide > > scale, proving that ICE "works" -- by any definition. > > > This is in fact an extremely important exercise, and precisely the > activity which according to RFC2026 is what should be happening after > approval as proposed standard, and before advancement to draft > standard. >=20 > > Basically, I want ICE firmly grounded in wide-scale testing and > > real-world > > data, and answering the questions below doesn't bring us any closer > > to that. > > Whether it's level 10 or level 12 doesn't produce new data. How its > > algorithms differ from competing ones doesn't show that they're any > > better > > or worse. Detailed proposals for change don't shed any light on > > whether > > those changes improve or worsen it, because its current state is > > completely > > unmeasured. > > > Showing how the algorithms work better, or work in more cases that > are covered by the requirements does in fact show that it's better, > with respect to the requirements. Again, you're arguing indirectly > that we should re-open the requirements discussion, which I do not > think would be terribly productive, but would support if there is in > fact consensus to do so. >=20 > > The most powerful thing the IETF can do to standardize the world > > upon ICE is > > prove that it works better than any alternative. Because until = that's > > proven, we just need to take it as a matter of faith. > > > I do not think that is desirable. The perfect is the enemy of the > good. ICE does not have to be better than anything else. It just has > to be "good enough" and see wide adoption. >=20 > That's my 2=A2 (as an individual, not as an IAB member, in case = anybody > cares). >=20 > DaveO > > -david > > > >> -----Original Message----- > >> From: Cullen Jennings [mailto:fluffy@cisco.com] > >> Sent: Wednesday, July 18, 2007 7:56 PM > >> To: SIP; Behave WG; mmusic@ietf.org > >> Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC > >> for RFC > >> > >> > >> First I apologize for the cross post - this is a mmusic draft, I > >> would appreciate replies on the mmusic list only. > >> > >> Few things I am looking for here .... > >> > >> 1) specific reasons why this work is less appropriate for standards > >> track than other work that IETF puts on the standards track. Keep = in > >> mind the first step of standards track is Proposed Standards which > >> requires basically no interoperability, then it could move to Draft > >> Standard where interoperability is shown and finally Full Standard = if > >> it turns out to be a good idea. If you are going to post a reply = to > >> this point, make sure you have read RFC 2026. > >> > >> 2) I am interested in the specifics of problems that ICE fails to > >> solve that the WG has not previous considered. There are lots of > >> people that have implemented versions of it and think it is a good > >> idea - if people are having some problems with it, I'd love to hear > >> about details of things that are wrong. That it has a lot of = messages > >> in some use cases has been known for a long time. It used to have = far > >> more messages - engineering was done to consider what was a > >> reasonable amount for call set up times and a new design was done = to > >> bring the message to a level most people invovled with the design > >> felt was reasonable. If there are specific other than these that = are > >> wrong and not considered in the design, now would be a good time to > >> get them on the table. > >> > >> 3) If people think that Skype for example has a simpler solution = that > >> works better than ICE. Feel free to describe exactly what it is. > >> Several people invovled with the ICE design have looked in extreme > >> detail at Skype and others and so far none of them have come back > >> with what we should do different than ICE. > >> > >> 4) ICE can be used in a mode where it only provided the reflexive > >> candidate. People were pretty clear that this was far inferior to = the > >> modes where there are other candidates. If someone would like to > >> provide exactly how hole punching works better than this very = limited > >> ICE technique, I'd be glad to hear the details. This has certainly > >> been an topic that any could have brought up over the last several > >> years. If someone has specifics, I suggest they get out a full > >> proposal really soon. I am very doubtful that hole punching = solution > >> is fundamentally different than the type of hole punching ICE does. > >> > >> 5) Some people have suggested that if all NATs were behave = complaint, > >> then we would not need ICE. I strongly disagree. I think the only > >> part of ICE we would not need is the TURN relays which are more or > >> less an optional part. Again, specifics on what can be removed are > >> welcome. > >> > >> ICE is far more complicated that anyone wants - the problem is, no > >> one has come up with a proposal that looks like it comes anywhere > >> close to meeting the requirements and if simpler. The design space > >> has been extensively explored by many people. The raw data to > >> understand what will work on what NATs have been painfully tested = and > >> documented in publications such as: > >> > >> http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf > >> > >> http://tools.ietf.org/id/draft-jennings-behave-test-results-04.txt > >> > >> https://www.guha.cc/saikat/stunt-results.php? > >> > >> (Ford used to have a page too but it seems to be gone) > >> > >> I have a very open mind to considering better ways to do ICE - but = I > >> need specific suggestions or it is impossible for me to really = think > >> about if the suggestions represent a better path or not. > >> > >> I would love to see more open source ICE code (there is lots = already) > >> - I feel that this is an area where ICE is likely just table stakes > >> and owning an proprietary ICE stack will not turn out to be a > >> competitive advantage. Having open source implementations where the > >> development cost was shared and everyone could get working products > >> to market faster would be an advantage to companies. Clearly I = expect > >> the bulk of ICE implementations to not be open source but I still > >> would be keen on doing what I can to contribute to an open source > >> version as personally I feel that is in the interest of end users, = my > >> employer, and the IETF as a SDO. > >> > >> Cullen > >> > >> > >> > >> On Jul 18, 2007, at 9:12 AM, Dean Willis wrote: > >> > >>> > >>> On Jul 18, 2007, at 3:10 AM, Magnus Westerlund wrote: > >>> > >>>> Henry Sinnreich skrev: > >>>>> Following some discussions and soul searching, the best > >>>>> approach for > >>>>> ICE-17 for LC would be to _go ahead and make it an experimental > >>>>> RFC_. > >>>>> This would support the development of interoperable > >>>>> implementations, the > >>>>> collection of deployment data and also hopefully open source = code. > >>>>> Though I have full faith in ICE, following the practices that > >>>>> made the > >>>>> IETF successful take precedent here, I believe. > >>>>> This is a change from the attached that I wrote on 7/16/2007. > >>>>> Note: We can only hope the proliferation of SBC in VoIP service > >>>>> provider > >>>>> networks will not make these concerns and ICE for SIP a moot > >>>>> issue, but > >>>>> this is another topic. > >>>> > >>>> Henry, > >>>> > >>>> I don't quite understand why you are requesting a status change = of > >>>> ICE? To me it appears that ICE is almost finished spec. It has > >>>> been implemented, used and feedback has been influencing the > >>>> protocol. It is definitly one of the better examples of current > >>>> IETF work that actually has running code. Sure, the > >>>> implementations may not be fully updated yet to the latest draft > >>>> version. But I think it is safe to say that ICE works in the > >>>> intended core cases. If there are some corner cases where it > >>>> fails, that may be. But that is not information we will have = until > >>>> really large scale deployement or someone makes very extensive > >>>> tests. > >>> > >>> Henry has, I believe, been very consistent in urging the IETF to > >>> have more "running code" experience on every specification (not > >>> just ICE) than our process requires. He has, IIRC, also advocated > >>> changing the process to require running code before publishing an > >>> RFC. He's even suggested at times that one should have running = code > >>> before submitting a protocol draft. > >>> > >>> Another point to consider -- I've known Henry to bark at a tree > >>> with no squirrel in it occasionally, but most of the time he's > >>> pretty reliable, more so than most technology predictors. If he's > >>> worried about ICE, it's probably because he's been talking to > >>> people who are trying to implement it and they're telling him it = is > >>> difficult or that they're having performance or reliability = issues. > >>> I imagine that there are plenty of internal development teams in > >>> various companies that are working on this and not necessarily > >>> bringing their results back to the IETF. After all, if everybody > >>> sees the emperor as fully clothed, they'd be embarrassed to > >>> proclaim otherwise. Of course, I wish all of these developers were > >>> tied into the IETF, but then I'm sure I don't want to see every = ice- > >>> implementor's question on the SIP list. That is why we have a sip- > >>> implementors mailing list, right? > >>> > >>> Personally, I think ICE is the best solution we have. We KNOW of > >>> cases where hole-punching doesn't work, and I think ICE will > >>> produce usable results in most of those cases. But that's just my > >>> personal opinion from reading the specs. I haven't implemented = ICE, > >>> and I haven't used anybody else's implementation. Sure, it's > >>> complex, but that's because the underlying problem is complex -- > >>> there are just too many different behaviors out there in "NAT and > >>> firewall land". Of course, I could be wrong, too. It's happened > >>> before, once or twice ;-). Just how sure are we that we're right > >>> about this? > >>> > >>> Are we designing a "spruce goose" or a practical system? Only > >>> experience will tell us. But some good flight reports from the > >>> prototypes could go a long way towards reassuring us of the > >>> design's utility. > >>> > >>> So far we've had a couple of people report hearsay evidence -- = that > >>> somebody else has an ICE implementation and it works. Any of you > >>> folks have personal experience you can share? Have there been > >>> prototypes exercised at the interop events? > >>> > >>> -- > >>> Dean > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Behave mailing list > >>> Behave@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/behave > >> > >> > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www1.ietf.org/mailman/listinfo/behave > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 14:06:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaOC-0005js-4r; Thu, 19 Jul 2007 14:06:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBaOB-0005ht-D6 for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:06:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaOB-0005hg-2n for sip@ietf.org; Thu, 19 Jul 2007 14:06:11 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBaOA-0008W0-Ke for sip@ietf.org; Thu, 19 Jul 2007 14:06:10 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Thu, 19 Jul 2007 11:06:03 -0700 From: "David Barrett" To: "'Jiri Kuthan'" , "'Jan Janak'" , "'Juha Heinanen'" Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment databefore LC for RFC Date: Thu, 19 Jul 2007 11:05:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20070719145334.2EA8B1810C50@mail.iptel.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfKFJ51LZhR1yDyQZ+JHkmd4bpt3wAGmvEg X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Message-Id: Cc: sip@ietf.org, mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Jiri Kuthan [mailto:jiri@iptel.org] > Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment databefore > LC for RFC > > So I think that the right course of action is that folks doubting ICE > reliability > make their case (by that I mean specific arguments rather than emotional > debates > about red-colored nails and other hardware). Er, my "specific argument" is "until it's been proven to work, it hasn't been proven to work". It's tautological, but no less true for it. Indeed, if you're *not* doubting ICE, why aren't you? -david _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 14:07:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaPd-0006d7-1f; Thu, 19 Jul 2007 14:07:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBaPb-0006d1-NJ for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:07:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaPb-0006ct-D8 for sip@ietf.org; Thu, 19 Jul 2007 14:07:39 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBaPa-00006a-SQ for sip@ietf.org; Thu, 19 Jul 2007 14:07:39 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Thu, 19 Jul 2007 10:57:30 -0700 From: "David Barrett" To: "'Jonathan Rosenberg'" Subject: RE: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 10:57:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <469F6E43.5050709@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfKDQrsCgBg9rNPRKqODM/+VLHMWwAH6iJg X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Message-Id: Cc: 'Cullen Jennings' , 'SIP' , 'Behave WG' , mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC > > ICE was built for reliability - to cover lots of cases and achieve not > just 90% effectiveness (not nearly good enough), but as effective as is > possible within the limitations of hurting the Internet or violating > security policies and other things we won't touch. Just to clarify, the 90% number (which I'm guessing comes from my published stats) is the success rate of any two peers being able to establish a direct connection without a relay service. If I were to add a relay service (which I don't need for my application, but would be trivial) for the remaining 10% I hope you agree that near 100% of peers would be able to talk. (I say "near" because nothing works at 100% in the real world, no matter how simple it appears on paper.) > a. extensive technical review, comments and feedbacks, including > commentary from implementors (including one in my own company, and > several others from outside of it) and deployers (Tim Moore from > Microsoft) Excellent! Do you or any of your implementor colleagues have any data showing how well the result works? Or if not, do you have an active system that you can instrument to get it? Or a test implementation that can be instrumented in the lab? Or any data at all showing how well ICE works? I understand we have data about the general NAT penetration techniques, years of experience, and active security teams. Does anybody have actual users, using this on a daily basis on a broad scale, proving that the product of all this hard work accomplishes its goals? -david _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 14:08:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaQX-0007Kf-Vj; Thu, 19 Jul 2007 14:08:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBaQV-0007Jk-MQ for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:08:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaQV-0007JO-3c for sip@ietf.org; Thu, 19 Jul 2007 14:08:35 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBaQU-00008q-Lv for sip@ietf.org; Thu, 19 Jul 2007 14:08:35 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Thu, 19 Jul 2007 11:08:31 -0700 From: "David Barrett" To: "'Adam Roach'" , "'Frank W. Miller'" Subject: RE: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 11:08:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <469F8577.4080506@estacado.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfKGuJrnaAzFrntQRqf5CHohBEUPQAFKB0g X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Message-Id: Cc: 'SIP' , 'Behave WG' , mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Adam Roach [mailto:adam@estacado.net] > Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC > > To be clear: to get this kind of experience (especially as it pertains > to interoperability), you need to have a stable (i.e., frozen) > specification. Internet Drafts simply don't provide an appropriate basis > for the kinds of proof that you and others are demanding. It seems premature to freeze the specification before we've proven that what specified actually works. Indeed, the most successful real-world projects I've participated in worked in the exact opposite manner. -da _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 14:08:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaQf-0007eR-Od; Thu, 19 Jul 2007 14:08:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBaQd-0007e7-Nc for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:08:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaQd-0007dg-2D for sip@ietf.org; Thu, 19 Jul 2007 14:08:43 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBaQc-000097-8B for sip@ietf.org; Thu, 19 Jul 2007 14:08:42 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8193C2104C; Thu, 19 Jul 2007 20:08:41 +0200 (CEST) X-AuditID: c1b4fb3e-b2038bb0000007e1-4d-469fa8a90e45 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4C6B820141; Thu, 19 Jul 2007 20:08:41 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 20:08:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SIP Identity using Media Path Date: Thu, 19 Jul 2007 20:08:39 +0200 Message-ID: <7374777208BDC7449D5620EF942325670743BB0B@esealmw113.eemea.ericsson.se> In-Reply-To: <0c1a01c7ca2d$c7fb9040$7d646b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Identity using Media Path Thread-Index: Ace82p2yNu6lfaNzQcq8BXk5gCIEoQAHC+iwAAFo/cADO9lZkAAH6/iAAAiwSbA= References: <7374777208BDC7449D5620EF94232567073F7740@esealmw113.eemea.ericsson.se> <0c1a01c7ca2d$c7fb9040$7d646b80@amer.cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Dan Wing" , X-OriginalArrivalTime: 19 Jul 2007 18:08:40.0889 (UTC) FILETIME=[D62CEA90:01C7CA2F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi, =20 >>>>"in order for the mechanism to work, SBC-type-of-entities must=20 >>>>permit DTLS, TLS, ICE, or HIP messages to be exchanged in the media=20 >>>>path." >>>>=20 >>>>A small question for clarification: at what point must this exchange >>>>(two-way, I assume) work? As soon as the UAS has received the=20 >>>>INVITE? >>>=20 >>>Yes. >>=20 >>A little more on this. >>=20 >>As we have discussed before, you may not have two-way connectivity=20 >>before 200 OK. >> >>I am pretty sure what will not work with most SBCs. >> >>Now assume that you will have two-way connectivity before you have=20 >>even sent the SDP answer. >=20 >=20 >I think you meant to say "now assume that you will _not_ ..."? What I meant to say was: Now you assume that you will have two-way connectivity before you have even sent the SDP answer :) >In the case of no media path, it would only be possible for the >authentication server, and the UA receiving the SIP request, to=20 >cryptographically validate the SIP headers and a very minor=20 >portion of the SDP (From:, Date:, and the header that we=20 >generate that copies the a=3Dfingerprint attributes from the=20 >SDP, and the few other headers described in -wing-sip-identity-media). >=20 >This provides some protection against attackers, and works through >SBCs. Specifically, this protects against attackers who were not >able to obtain a validly-signed SIP request. >=20 >=20 >However, only validating those SIP headers is inadequate if >an attacker has captured or otherwise acquired a validly-signed=20 >SIP request, modified the SDP (such that the signature is=20 >still valid), and re-injected that SIP request into a SIP=20 >proxy that forwards it to you. In order to detect such a=20 >replay attack, you need to perform one of the media-path based=20 >tests that I describe in wing-sip-identity-media (DTLS-SRTP,=20 >HIP, ICE, TLS). >=20 >=20 >>Also, even if you don't have any SBCs, but you still have NATs, the >>calling user often needs to send something in order to open the NAT >>binding, and allow media plane traffic (including your identity >>exchange) from the remote end. If you use ICE, or stand-alone=20 >>STUN, you will have an open NAT binding, but if your terminal opens=20 >>the network e.g. by sending dummy RTP packets, it will not be able to do=20 >>so until it has received the SDP answer. >=20 >* But if you haven't received the SDP answer, where are you sending >those dummy RTP packets (what is their destination IP address and=20 >UDP port)? That is what I am saying: the user needs to get the SDP answer, so that it can open the NAT binding (and allow incoming traffic) >* If the NAT perform address-based filtering of incoming packets,=20 >it drop incoming UDP packets until the device behind the NAT >(the SIP UA, in our case) sends a packet to the IP address sending >the incoming packet. The SIP UA would learn that IP address upon >receipt of the SDP answer. Further, if the NAT is doing port >iltering of incoming packets, the SIP UA needs to know the UDP >port the external packet is arriving from, too (which also shows >up in the answer). I point out the problem with port filtering >NATs because sending dummy UDP packets to the SBC's IP address=20 >is not sufficient for those kinds of NATs. Similarly, if the=20 >NAT is symmetric (assigns a new UDP port for every new=20 >destination port or destination address the SIP UA sends to),=20 >sending dummy UDP packets won't be effective for symmetric >NATs, either. >=20 >>So, I also think your solution requires support of ICE/STUN,=20 >>and in the case of ICE it also requires that the SBCs=20 >>don't mess up the SDP so that ICE will not be used. >=20 >No, it does not. >=20 >For protection against simple From: spoofing, it is adequate to >simply validate the SIP headers and the signature. For protection >against replay attacks, it is necessary for both SIP UAs (*) to >implement one of HIP, ICE, DTLS-SRTP, or TLS. =20 Ok, so let me put it this way: any feature in your solution that, in a NAT requirement, does require end-to-end connectivity before the SDP answer has been sent requires at least STUN (not necessarily ICE) - or some other mechanism which the NAT binding is opened without having the remote SDP. And, if you use ICE, the SBCs must not modify the SDPs in a way so that ICE is disabled. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 14:13:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaUv-00040Y-UK; Thu, 19 Jul 2007 14:13:09 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBaUu-00040M-EC for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:13:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaUu-00040D-3T for sip@ietf.org; Thu, 19 Jul 2007 14:13:08 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBaUt-0000G3-AK for sip@ietf.org; Thu, 19 Jul 2007 14:13:07 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A17FB20547; Thu, 19 Jul 2007 20:13:06 +0200 (CEST) X-AuditID: c1b4fb3c-aee7cbb0000007e1-10-469fa9b25930 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8121D203F7; Thu, 19 Jul 2007 20:13:06 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 20:13:06 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 20:13:05 +0200 Received: from [131.160.126.62] (rvi2-126-62.lmf.ericsson.se [131.160.126.62]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 87D1724C0; Thu, 19 Jul 2007 21:13:05 +0300 (EEST) Message-ID: <469FA9B1.3040601@ericsson.com> Date: Thu, 19 Jul 2007 21:13:05 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] comments on draft-camarillo-sip-body-handling-01 References: <469E193A.4020402@cisco.com> In-Reply-To: <469E193A.4020402@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 18:13:05.0770 (UTC) FILETIME=[740E8CA0:01C7CA30] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jonathan, > The draft makes support of multipart a SHOULD in RFC 3261. If our > objective is to use multipart as a vehicle for extending SIP (e.g., by > including optional bodies in addition to the mandatory one - a location > object plus SDP for example), this is much better served by a MUST. I sent an email with the slides I intend to use to present this draft right before you sent your comments to the list. In those slides I already propose to make it a MUST. So, we are on the same page. > Otherwise, a UAC will have to send a request first with multipart, and > if its rejected, retry the request with just the supported parts. Its > effectively the same as the behavior we'd see if the only way to extend > SIP was with Require, and not Supported. > > This draft also strikes me as something that is in the essential > corrections category, but its debatable. > > For multipart/alternative - I don't understand the requirement to order > them from least to most 'rich'. It is not our requirement. It is just how MIME works. > Is that a general MIME behavior or are > we defining it that way? If we want to prioritize, shouldn't we use an > explicit q-value or something? Using order seems like it will be brittle > (as it has been in SDP where m-lines were never numbered). I do not think we should be changing how MIME works. > The use case described for multipart/alternative - new SDP mechanisms - > seems kind of bogus. We've decided not to pursue that. Do we have a REAL > use case for this? AFAICT, we have decided not to pursue SDPng but we still need a mechanism in order to be able to, at some point, migrate to new session description formats. The current consensus, as I understand it, is that multipart/alternative should not be used to provide alternative SDP descriptions, but that it could be used to provide alternative session descriptions written in different formats. >> The reason for not having such a mechanism is that disposition types >> are typically supported within a context. Outside that context, a UA >> (User Agent) may not support the disposition type. > > I think the same can be send for content-types. A UA may support a > content-type of application/sdp, but only for one disposition > ('session') and not another ('render'). So, generally I would say that a > UA never really supports a content-type; it supports a set of tuples of > {content-type, content-disposition, method}. yes, that is what the draft intends to say. I will clarify it in the text. >> UAs process message bodies and body parts in the following way. On >> receiving a SIP message, if a body part is not referenced in any way >> (e.g., there are no header fields or other body parts with a >> Content-ID URL pointing to it), the UA processes the body part as >> indicated by its disposition type and the context in which the body >> part was received. >> >> OPEN ISSUE 4: this means that a UA would need to parse all body parts >> to find references between them before being able to fully process >> them. If we are OK with this, we need to include text here >> explaining it. > > This behavior seems like a bad idea, and I don't understand why it is > needed. If the CID URL is part of an optional extension, then you make > the body handling optional, and the UA will know to pick up the body > part if it supports the extension, otherwise not. we have a separate email thread where we are discussing this. The current proposal is to avoid having to process the message two times. Thanks for your comments, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 14:14:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaWY-0005sx-3T; Thu, 19 Jul 2007 14:14:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBaWW-0005nW-Rt for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:14:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaWW-0005ju-BY for sip@ietf.org; Thu, 19 Jul 2007 14:14:48 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBaWV-0000Ih-FX for sip@ietf.org; Thu, 19 Jul 2007 14:14:48 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 19 Jul 2007 14:14:47 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwPAE9Gn0ZAZnmf/2dsb2JhbACIXp13 X-IronPort-AV: i="4.16,557,1175486400"; d="scan'208"; a="65630008:sNHT67397268" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6JIEkh5001467; Thu, 19 Jul 2007 14:14:46 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6JIEgEd010747; Thu, 19 Jul 2007 18:14:46 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 14:14:44 -0400 Received: from [161.44.182.188] ([161.44.182.188]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 14:14:44 -0400 Message-ID: <469FAA12.1030800@cisco.com> Date: Thu, 19 Jul 2007 14:14:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides for body (MIME) handling) References: <469DF98F.3060506@ericsson.com> <469E261B.7090804@cisco.com> <469F38A0.7090404@ericsson.com> <469F6E3A.3000203@cisco.com> <469FA25A.9020806@ericsson.com> In-Reply-To: <469FA25A.9020806@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 18:14:44.0765 (UTC) FILETIME=[AF0FFCD0:01C7CA30] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6146; t=1184868886; x=1185732886; c=relaxed/simple; s=rtpdkim2001; 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=20Content-Disposition=20in=20multiparts=20WAS=20(Re=3A= 20[Sip]=20Draft=20slides=0A=20for=20body=20(MIME)=20handling) |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=Asx1iT0pHNBZvWv8iIrgYe+Ul+dZ06AopwB1ff/Ekig=; b=0O5k2x/ii4ZEFXhWddmUbFka3FLVG8BwUcY29AhUyvdtCpSsBGkwvEdKYpaJkX+EPi3hxxgE VrngKg4/q78IyOB7MJEW6qjrhFlyK3p4Lae5HofnMoVqd4FTAvhu/06+; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Gonzalo Camarillo wrote: > Hi, > > yes, I agree there is a bigger issue with 'render'. Even though this > bigger issue does not directly relate to multipart, we can also tackle > it in the same draft and clarify how 'render' is used and what it means. Sounds good. Maybe its just a matter of changing the title of the draft to match the scope. Something like: draft-sipping-content-type-disp-clarification-nn.txt Paul > Cheers, > > Gonzalo > > > Paul Kyzivat wrote: >> >> >> Gonzalo Camarillo wrote: >>> Hi Paul, >>> >>>> Regarding Content-Disposition in multiparts: >>>> >>>> While it seems "wrong" to me, I can live with using "render" as the >>>> normal disposition for multipart, *if* we can do a careful job of >>>> defining what "render" actually means for SIP. Used this way it >>>> clearly doesn't always mean to display the content to a user. >>> >>> An entity receiving a 'multipart/mixed' body will process its body >>> parts based on their disposition types.If the disposition type of a >>> particular body part is not understood, it will be displayed to the >>> user because the default disposition type is 'render'. >> >> There is a bigger problem with 'render' than just multipart. >> >> We have many uses of body parts that never mention Content-Disposition >> at all. The related examples don't use it, and so they all get a >> default of 'render'. This is particularly the case with events. E.g. >> >> - the notification for REFER contains type application/sipfrag. >> Its probably not intended to be "rendered" in any literal sense, >> though some conclusion about success or failure may be. >> >> - usage of filter bodies in presence subscriptions (RFC 4660) >> doesn't have a specified disposition, so it implicitly uses render. >> Its hard for me to convince myself that what the presence server >> does with these can be described as rendering. >> >> - In fact, the only place I can think of where 'render' is (implicitly) >> used in sip and has the appropriate connotation is in MESSAGE. >> >> I think we just have to grandfather the use of 'refer' in SIP, and >> document that the usage in sip does not mean "render", but rather >> means that the usage must be determined by other context - >> specifically the type of message or response and the content type. >> IOW, 'render' in sip can be thought of as a peculiar spelling for >> 'by-context'. It might be helpful to give guidance for development of >> future specs about when 'render' should be used vs defining a new >> disposition. >> >>> Therefore, the 'multipart/mixed' body will never be processed based >>> on its disposition type. >> >> Based on my discussion above, I would consider this a case of the >> multipart being processed according to its context *because* its >> content-disposition is 'refer'. If it had some other >> content-disposition then that might mean that it should be processed >> specially. E.g. if a multipart/mixed had disposition 'by-reference' >> then that needs to be taken into account, and the processing of the >> multipart becomes conditional on the reference. >> >> Also, there are only certain contexts in which multipart should be >> processed "normally". Consider a NOTIFY from a REFER, with a >> Content-Type of message/sipfrag, which happened to include a body as >> part of the fragment. (This is legal.) That body might contain a >> multipart/mixed, and that might contain other stuff. But I think the >> processing of all of that is dependent on processing of the sipfrag. >> For instance, if something inside that had handling=required, I don't >> think that means that processing of the NOTIFY fails because the >> recipient can't handle that. >> >>> This means that it does not make much sense to talk about its >>> disposition type as a whole. >> >> Counterexample above. >> >>> However, we need to have one in order to be able to set its handling >>> parameter. That's why we can either keep 'render' explaining that it >>> is actually never used or define a new disposition type. >> >> I can go either way on that. But because there is existing usage, and >> because 'render' semantics are already so messed up, I think it makes >> more sense to stick with 'render' and just clarify its meaning. >> >>> Since existing implementations will not understand our newly defined >>> disposition type, they will treat it as 'render' anyway... but the >>> resulting behavior would be the same. That's why it may make sense to >>> keep using 'render'. >> >> Yup. >> >>> On the other hand, semantically, it would make more sense to define a >>> new disposition type. >>> >>> Also, if we decide to define the 'by-reference' disposition type (per >>> a different email thread), it could be used here as well. >> >> It could be used when there is actually a reference to it. But it >> would not be an appropriate disposition to use when there is no >> reference to the multipart. >> >> Thanks, >> Paul >> >>> Cheers, >>> >>> Gonzalo >>> >>> >>> >>>> Gonzalo Camarillo wrote: >>>>> Folks, >>>>> >>>>> here you have the slides I have put together for the body (MIME) >>>>> handling presentation on Monday: >>>>> >>>>> http://users.piuha.net/gonzalo/temp/ietf69-sip-camarillo-body-handling.ppt >>>>> >>>>> >>>>> These slides relate to this draft: >>>>> >>>>> http://www.ietf.org/internet-drafts/draft-camarillo-sip-body-handling-01.txt >>>>> >>>>> >>>>> The slides discuss all the open issues that have been brought up in >>>>> the list in the last months. >>>>> >>>>> Comments are welcome. >>>>> >>>>> Thanks, >>>>> >>>>> Gonzalo >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol >>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>> Use sipping@ietf.org for new developments on the application of sip >>>>> >>> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 14:30:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBalF-0002wF-Rr; Thu, 19 Jul 2007 14:30:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBalE-0002w9-NH for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:30:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBalE-0002w0-Di for sip@ietf.org; Thu, 19 Jul 2007 14:30:00 -0400 Received: from ext-sendmail1.labs.att.com ([205.173.58.19] helo=sendmail1.labs.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBalD-0006i5-VF for sip@ietf.org; Thu, 19 Jul 2007 14:30:00 -0400 Received: from labs.att.com (internet-austin-webdmz.labs.sbc.com [144.60.9.139]) by sendmail1.labs.att.com (8.14.0/8.13.1) with ESMTP id l6JITxlE018036; Thu, 19 Jul 2007 13:29:59 -0500 Received: from TSMAIL.ad.tri.sbc.com (tsmail [144.60.55.228]) by labs.att.com (8.14.0/8.13.1) with ESMTP id l6JITsnB000861; Thu, 19 Jul 2007 13:29:54 -0500 Received: from TSMAIL2.ad.tri.sbc.com ([144.60.55.226]) by TSMAIL.ad.tri.sbc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 13:29:53 -0500 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 Subject: RE: [Sip] RFC3891 (Replaces header) discrepancies Date: Thu, 19 Jul 2007 13:29:54 -0500 Message-ID: <0CED449E95A92A42991EB71B778C17BF059AA80E@TSMAIL2.ad.tri.sbc.com> In-Reply-To: <200707191747.l6JHlQqL009062@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RFC3891 (Replaces header) discrepancies Thread-Index: AcfKLOO0Tfu62WoiR1mRZB2t1q+ZDwAA4WFA References: <0CED449E95A92A42991EB71B778C17BF059AA475@TSMAIL2.ad.tri.sbc.com> <200707191747.l6JHlQqL009062@dragon.ariadne.com> From: "Jackson, James" To: , X-OriginalArrivalTime: 19 Jul 2007 18:29:53.0838 (UTC) FILETIME=[CCE984E0:01C7CA32] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The assumption is that the transfer target rejects the initial early dialog on receiving the REFER. The 180 and 487 would be sent in the NOTIFY associated with the REFER. I'm not trying to pick on any vendors here but take a look at what is called "attended transfer with early completion" on this link: http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_ guide09186a0080110c01.html Thanks, James -----Original Message----- From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 Sent: Thursday, July 19, 2007 12:47 PM To: sip@ietf.org Subject: Re: [Sip] RFC3891 (Replaces header) discrepancies From: "Jackson, James" Consider an attended transfer in which call1 is established between a transferee and a transferor. The transferor creates a new call2 towards transfer target. While this call is still alerting (early dialog), it sends a REFER on call1 with a Replaces header that references call2. In this case, the Replaces header attempts to replace an early dialog which was "terminated" by the target. That is not allowed by RFC 3891. But suppose it was allowed. Further suppose that the transfer target rings for another 90 seconds (sending an additional 180) and then the proxy that manages the transfer target cancels the call, causing the transfer target to send a 487. Who receives the 180 and 487? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 14:30:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBalO-000330-5D; Thu, 19 Jul 2007 14:30:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBalM-000314-UZ for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:30:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBalM-00030v-KM for sip@ietf.org; Thu, 19 Jul 2007 14:30:08 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBalM-0006iO-AT for sip@ietf.org; Thu, 19 Jul 2007 14:30:08 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Jul 2007 14:30:08 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwPAA5Kn0ZAZnme/2dsb2JhbACIXp4A X-IronPort-AV: i="4.16,557,1175486400"; d="scan'208"; a="126508784:sNHT26604372" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6JIU7Ra023170; Thu, 19 Jul 2007 14:30:07 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6JITxEp015855; Thu, 19 Jul 2007 18:30:07 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 14:29:50 -0400 Received: from [161.44.182.188] ([161.44.182.188]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 14:29:50 -0400 Message-ID: <469FAD9C.6050806@cisco.com> Date: Thu, 19 Jul 2007 14:29:48 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [Sip] comments on draft-camarillo-sip-body-handling-01 References: <469E193A.4020402@cisco.com> <469FA9B1.3040601@ericsson.com> In-Reply-To: <469FA9B1.3040601@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 18:29:50.0335 (UTC) FILETIME=[CAD300F0:01C7CA32] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=821; t=1184869807; x=1185733807; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20comments=20on=20draft-camarillo-sip-body-hand ling-01 |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=5D4aEWwSRMie+DPSdWgrZAdYRyQY6LdfSY0Xd0AZ+X4=; b=oT6qurIImfSV0Dq6HINOLmETgVOQLbZzE9lfXdjPKr6r3VJAUJfdhYw0EmvBHCI/eoOSmMGf w7mVImIv9BL0IEJN4UZ6LTRnsD5kCwmOronWg0sGcMHHEIqyYkakATqO; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Just one comment in addition to what Gonzalo said: Gonzalo Camarillo wrote: >> The use case described for multipart/alternative - new SDP mechanisms >> - seems kind of bogus. We've decided not to pursue that. Do we have a >> REAL use case for this? > > AFAICT, we have decided not to pursue SDPng but we still need a > mechanism in order to be able to, at some point, migrate to new session > description formats. The current consensus, as I understand it, is that > multipart/alternative should not be used to provide alternative SDP > descriptions, but that it could be used to provide alternative session > descriptions written in different formats. The other classic example, because it is just like email, is MESSAGE with a multipart/alternative containing plain text and html. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 14:30:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBalp-0003Qc-TY; Thu, 19 Jul 2007 14:30:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBaln-0003QH-JP for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:30:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaln-0003Q7-9C; Thu, 19 Jul 2007 14:30:35 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBalm-0000zd-Sn; Thu, 19 Jul 2007 14:30:35 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6JIUSek015558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 13:30:28 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <469FADC9.3000006@nostrum.com> Date: Thu, 19 Jul 2007 13:30:33 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: David Barrett Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC References: In-Reply-To: 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-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: 'SIP' , 'Behave WG' , 'Adam Roach' , "'Frank W. Miller'" , mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 7/19/07 1:08 PM, David Barrett wrote: >> -----Original Message----- >> From: Adam Roach [mailto:adam@estacado.net] >> Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC >> >> To be clear: to get this kind of experience (especially as it pertains >> to interoperability), you need to have a stable (i.e., frozen) >> specification. Internet Drafts simply don't provide an appropriate basis >> for the kinds of proof that you and others are demanding. >> > > It seems premature to freeze the specification before we've proven that what > specified actually works. Indeed, the most successful real-world projects > I've participated in worked in the exact opposite manner. > In that case, you're arguing with the IETF standards process, and have decided to beat on ICE as a proxy whipping boy for reasons that have no technical basis in ICE itself. The current process surrounding RFC publication is detailed in RFC 2026. Section 4.1 details the process you're misunderstanding. It's short. You should read it. If you're up to it, RFC 3774 and RFC 3844 also provide some useful background on the work that has been done in this area recently. Concerns about IETF RFC publication process in general -- and that's what you're arguing about here, not ICE itself -- are best addressed to the IETF-general mailing list and/or the IESG itself (as the conclusion of the problem WG was that issues surrounding the standards process were to be handed back to the IESG). /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 14:31:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBamM-0003xK-Ue; Thu, 19 Jul 2007 14:31:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBamL-0003t0-HI for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:31:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBamL-0003ss-7M for sip@ietf.org; Thu, 19 Jul 2007 14:31:09 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBamK-0006kd-FZ for sip@ietf.org; Thu, 19 Jul 2007 14:31:09 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l6JIV2p16658; Thu, 19 Jul 2007 11:31:02 -0700 In-Reply-To: <009101c7c98e$5d2281b0$0601a8c0@BEMBUSTER> References: <009101c7c98e$5d2281b0$0601a8c0@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4909E092-FDB7-47A8-9EDD-0A340ABB877F@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-10.txt Date: Thu, 19 Jul 2007 11:31:01 -0700 To: "Jeroen van Bemmel" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jeroen, I don't see why 'ob' in the Contact is necessary in a response, but it doesn't hurt anything either. thanks On Jul 18, 2007, at 3:52 PM, Jeroen van Bemmel wrote: > Minor comment on section 4.3 (sending requests): it talks about the > UAC inserting an 'ob' parameter in its Contact URI, should it do > the same for Contact URIs in responses over an outbound flow (for > consistency reasons perhaps; allows the other end to detect > outbound usage)? > > Regards, > Jeroen > > Internet-Drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Session Initiation Protocol Working >>> Group of the IETF. >>> >>> Title : Managing Client Initiated Connections in the Session >>> Initiation Protocol (SIP) Author(s) : C. Jennings, R. Mahy >>> Filename : draft-ietf-sip-outbound-10.txt >>> Pages : 42 >>> Date : 2007-7-12 >>> >>> The Session Initiation Protocol (SIP) allows proxy servers to >>> initiate TCP connections and send asynchronous UDP datagrams to >>> User Agents in order to deliver requests. However, many practical >>> considerations, such as the existence of firewalls and Network >>> Address Translators (NATs), prevent servers from connecting to >>> User >>> Agents in this way. This specification defines behaviors for User >>> Agents, registrars and proxy servers that allow requests to be >>> delivered on existing connections established by the User Agent. >>> It also defines keep alive behaviors needed to keep NAT bindings >>> open and specifies the usage of multiple connections. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-10.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the body >>> of >>> the message. >>> You can also visit >>> https://www1.ietf.org/mailman/listinfo/I-D-announce >>> to change your subscription settings. >>> >>> Internet-Drafts are also available by anonymous FTP. Login with the >>> username "anonymous" and a password of your e-mail address. After >>> logging in, type "cd internet-drafts" and then >>> "get draft-ietf-sip-outbound-10.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE /internet-drafts/draft-ietf-sip-outbound-10.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >> >> >> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 14:37:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBas7-0001M7-3K; Thu, 19 Jul 2007 14:37:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBas5-0001IG-Ju for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:37:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBas4-0001Hw-WA; Thu, 19 Jul 2007 14:37:05 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBas4-0001DR-KS; Thu, 19 Jul 2007 14:37:04 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IBary-0005o8-2q; Thu, 19 Jul 2007 14:36:59 -0400 In-Reply-To: <469F8577.4080506@estacado.net> References: <20070719150508.14D4D1C8029@smtpauth01.csee.onr.siteprotect.com> <469F8577.4080506@estacado.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <906B914C-31A5-43E9-99B5-424899262C7B@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 14:37:17 -0400 To: Adam Roach X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: SIP , Behave WG , "Frank W. Miller" , IETF MMUSIC WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 19-Jul-07, at 11:38 , Adam Roach wrote: > On 7/19/07 10:19 AM, Frank W. Miller wrote: >> FM: While I applaud the time and effort that the large vendors have >> obviously invested in this, this is a qualitative statement. >> Perhaps Cisco >> and/or Microsoft have empirical data they would be willing to >> share about >> robustness and performance? > > That's the kind of data you get between "proposed standard" and > "draft standard" -- not *prior* to publication. I'm not sure why > there's so much noise about setting the bar much, much higher for > ICE than we do for other IETF proposals. Just to play the other side of the fence ... In theory, RFCs advance from "proposed standard" to "draft standard" to "full standard". In practice, this rarely happens. In practice, once an RFC is published, it is either accepted and becomes a de-facto standard, or is ignored. Rarely is it revised and advanced along the standards track. And it is often difficult to discover which status (de-facto standard or ignored) a particular RFC actually has. Look at SIP, for example. It is still at "proposed standard" and will likely stay there for a long time. What Henry, David, and Frank want is some evidence that actually works (and thus will become the de-facto standard) before publishing the document as an RFC. - Philip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 16:09:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBcJS-00079i-LM; Thu, 19 Jul 2007 16:09:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBcJR-00079H-Ji for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 16:09:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBcJR-00078w-9x for sip@ietf.org; Thu, 19 Jul 2007 16:09:25 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBcJQ-0000tg-2E for sip@ietf.org; Thu, 19 Jul 2007 16:09:25 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l6JK8jFx002165 for ; Thu, 19 Jul 2007 15:09:16 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 15:09:16 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 22:09:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Jul 2007 22:09:11 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800147358A@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Slides for IETF#69 Thread-Index: AcfKQKw9PkKc27peQkuinyWd4J+6BA== From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 19 Jul 2007 20:09:12.0872 (UTC) FILETIME=[ACC5F280:01C7CA40] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Sip] Slides for IETF#69 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (as WG chair) To all presenters on Monday and Tuesday. If you are presenting slides in the SIP sessions, we would like these posted to the meeting presentations site well before the meeting session begins. That means you need to get them to the chairs at least 24 hours in advance of session start (and not 25 minutes after). We will be projecting from what is on the meeting presentations site (no exceptions) and therefore if your slides are not there, you will be presenting to a blank screen. Remember that as well as people trying to address your issues in the meeting, we will have people trying to follow the discussion remotely. Access to the slides in advance helps everybody. And remember, we are looking for issues for the meeting to discuss, not tutorials on the document contents - everyone is expected to have read those. Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 17:07:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBdCu-0000qx-Jh; Thu, 19 Jul 2007 17:06:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBdCt-0000qo-I6 for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 17:06:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBdCs-0000qg-Ij for sip@ietf.org; Thu, 19 Jul 2007 17:06:43 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBdCs-0005Ey-7s for sip@ietf.org; Thu, 19 Jul 2007 17:06:42 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6JL6ZAR023725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 16:06:35 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <469FD261.2010607@nostrum.com> Date: Thu, 19 Jul 2007 16:06:41 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] WGLC on draft-ietf-sip-sips References: <5D1A7985295922448D5550C94DE2918001436436@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918001436436@DEEXC1U01.de.lucent.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-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 7/17/07 5:21 AM, DRAGE, Keith (Keith) wrote: > (As WG chair) > > We reached the end of the time when WGLC comments were requested on > Monday. > > If there are any last comments sitting out there that you have been > meaning to submit, can I suggest you get them in an quickly as possible. > Sorry for the late comment here, but I find section 3.3.2 perplexing in the current incarnation of the draft. It made sense before (e.g., in -02, which was the current version in Prague) -- but now that we're changing behavior, it seems completely out of place. By my reading, section 3.3.2 basically says, "If you implement this specification, you are explicitly forbidden from doing the following procedure, which is now explained in enough detail to implement." I would propose removing section 3.3.2. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 17:14:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBdKj-00013r-Gf; Thu, 19 Jul 2007 17:14:49 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBdKh-0000vQ-59 for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 17:14:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBdKg-0000tc-Pm; Thu, 19 Jul 2007 17:14:46 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBdKg-0005RE-9s; Thu, 19 Jul 2007 17:14:46 -0400 Received: from source ([192.150.20.142]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Thu, 19 Jul 2007 14:14:38 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6JLEQWs013301; Thu, 19 Jul 2007 14:14:27 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6JLCUI9025470; Thu, 19 Jul 2007 14:12:30 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 14:14:25 -0700 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, 19 Jul 2007 14:14:21 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AEDCA6@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: ICE deployment data before LC for RFC Thread-Index: AcfKSR+4bsdL7cvpRK+b5k7AGN+GsQ== From: "Henry Sinnreich" To: , , , , X-OriginalArrivalTime: 19 Jul 2007 21:14:25.0847 (UTC) FILETIME=[C9168C70:01C7CA49] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Cullen Jennings , Magnus Westerlund , jon.peterson@neustar.biz, Dean Willis Subject: [Sip] Re: ICE deployment data before LC for RFC X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My apology for the duplicate postings.=20 Having initiated this ample discussion about how to proceed with ICE-17, it seems the following have emerged: ICE-17 is an excellent document (bravo authors and contributors) and can hardly get better at present. The technical points discussed cannot change this fact either way. Ironically, the defense of ICE-17 on procedural grounds makes even less sense, since the culprit is not ICE-17, but the fact that present IETF procedures do not make a clear enough distinction that everyone can understand between I-D categories, such as: * Concept memos; see the torrent in the P2PSIP WG * Protocol standard agreements, such as for SIP * Technology solutions such as ICE-17 or hole punching for NAT traversal * I-Ds to support a business model (excuse me; I will not go there...) Sorry to repeat: Process and consensus in meetings have nothing to do with how good a technology may be. Only measurements and proof will do. How does the IETF support the proof for a technology? (Yes, I have seen all those quotes). Please remember that proving a technology also costs money. This is the reason why I trust more technologies coming out of funded R&D, especially from University research. Vendors of technology may be less likely to share such information. Question: Is a standards organization the best place to develop and promote new technology such as for NAT traversal? (all those p2p companies and Skype did not think so...) Also, be prepared, SBC traversal may come next. In conclusion, there is nothing wrong with the ICE-17 paper IMHO, but rather the IETF processes are either not satisfactory or not well understood by folks like me who avoid reading process documents longer than one web page :-)=20 I have taken therefore the liberty to copy as Adam Roach has suggested. Thanks,=20 Henry Sinnreich _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 17:20:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBdPk-0003oF-6u; Thu, 19 Jul 2007 17:20:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBdPi-0003oA-Ua for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 17:19:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBdPi-0003o2-JH for sip@ietf.org; Thu, 19 Jul 2007 17:19:58 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBdPh-0005ZC-IT for sip@ietf.org; Thu, 19 Jul 2007 17:19:58 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 19 Jul 2007 14:19:57 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKZyn0arR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,558,1175497200"; d="scan'208"; a="386929385:sNHT34269830" 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 l6JLJuY2009528; Thu, 19 Jul 2007 14:19:56 -0700 Received: from dwingwxp (dhcp-128-107-102-137.cisco.com [128.107.102.137]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6JLJq6C028681; Thu, 19 Jul 2007 21:19:52 GMT From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" , Subject: RE: [Sip] SIP Identity using Media Path Date: Thu, 19 Jul 2007 14:19:52 -0700 Message-ID: <00bf01c7ca4a$8e079240$fc736b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7374777208BDC7449D5620EF942325670743BB0B@esealmw113.eemea.ericsson.se> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace82p2yNu6lfaNzQcq8BXk5gCIEoQAHC+iwAAFo/cADO9lZkAAH6/iAAAiwSbAABliREA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7610; t=1184879996; x=1185743996; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20SIP=20Identity=20using=20Media=20Path |Sender:=20; bh=isZmiW4FFJOOWMqbx/O898auW1TVxyycCpTF3/jsnUs=; b=t4HGt+8jn/GP3WJDuCnagqSef6DnE9Tay4wBM+6ML1PSXnabeQAR2ytLOoTFBhEt6o7BrUnY pxa18MZ68ekvOa8kDTYXkAfy9aI40Z860AhH4q63isDNTAEk4JpzQR+V; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: ietf-rtpsec@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > >I think you meant to say "now assume that you will _not_ ..."? > > What I meant to say was: Now you assume that you will have two-way > connectivity before you have even sent the SDP answer :) Thanks for clarifying. This is how we meet our requirement to avoid clipping, and meet the requirement of RFC3264 to have a bi-directional path for sendrecv streams: "Once the offerer has sent the offer, it MUST be prepared to receive media for any recvonly streams described by that offer. It MUST be prepared to send and receive media for any sendrecv streams in the offer, and send media for any sendonly streams in the offer (of course, it cannot actually send until the peer provides an answer with the needed address and port information)." This requirement is captured in section 3.1 and requirement 5 (R5) of draft-wing-media-security-requirements-04.txt. > >In the case of no media path, it would only be possible for the > >authentication server, and the UA receiving the SIP request, to > >cryptographically validate the SIP headers and a very minor > >portion of the SDP (From:, Date:, and the header that we > >generate that copies the a=fingerprint attributes from the > >SDP, and the few other headers described in > -wing-sip-identity-media). > > > >This provides some protection against attackers, and works through > >SBCs. Specifically, this protects against attackers who were not > >able to obtain a validly-signed SIP request. > > > > > >However, only validating those SIP headers is inadequate if > >an attacker has captured or otherwise acquired a validly-signed > >SIP request, modified the SDP (such that the signature is > >still valid), and re-injected that SIP request into a SIP > >proxy that forwards it to you. In order to detect such a > >replay attack, you need to perform one of the media-path based > >tests that I describe in wing-sip-identity-media (DTLS-SRTP, > >HIP, ICE, TLS). > > > > > > >>Also, even if you don't have any SBCs, but you still have NATs, the > >>calling user often needs to send something in order to open the NAT > >>binding, and allow media plane traffic (including your identity > >>exchange) from the remote end. If you use ICE, or stand-alone > >>STUN, you will have an open NAT binding, but if your terminal opens > >>the network e.g. by sending dummy RTP packets, it will not > be able to > do > >>so until it has received the SDP answer. > > > >* But if you haven't received the SDP answer, where are you sending > >those dummy RTP packets (what is their destination IP address and > >UDP port)? > > That is what I am saying: the user needs to get the SDP > answer, so that it can open the NAT binding (and allow > incoming traffic) Yes, in cases with certain kinds of NATs which filter, it is necessary to receive the SDP answer. In cases with certain other kinds of NATs that don't filter (or where there is no NAT), it isn't necessary to receive the SDP answer. However, for reasons unrelated to SIP-Identity-Media, it is important to verify the certificate in the SDP answer matches the certificate exchanged over DTLS (or TLS, if doing comedia). Otherwise, an attacker can send a well-timed DTLS ClientHello or TLS ClientHello which will fool the endpoint into exchanging application-layer data (SRTP or TLS-encrypted application data) with the attacker. Such an exchange with an attacker is undesirable. Thus, to reduce call setup time, it's useful to perform the DTLS/TLS exchange prior to receiving the SDP answer. But it isn't necessary to do so. Certainly you don't want to do anything with the data you receive until you have validated the DTLS/TLS certificate. > >* If the NAT perform address-based filtering of incoming packets, > >it drop incoming UDP packets until the device behind the NAT > >(the SIP UA, in our case) sends a packet to the IP address sending > >the incoming packet. The SIP UA would learn that IP address upon > >receipt of the SDP answer. Further, if the NAT is doing port > >iltering of incoming packets, the SIP UA needs to know the UDP > >port the external packet is arriving from, too (which also shows > >up in the answer). I point out the problem with port filtering > >NATs because sending dummy UDP packets to the SBC's IP address > >is not sufficient for those kinds of NATs. Similarly, if the > >NAT is symmetric (assigns a new UDP port for every new > >destination port or destination address the SIP UA sends to), > >sending dummy UDP packets won't be effective for symmetric > >NATs, either. > > > >>So, I also think your solution requires support of ICE/STUN, > >>and in the case of ICE it also requires that the SBCs > >>don't mess up the SDP so that ICE will not be used. > > > >No, it does not. > > > >For protection against simple From: spoofing, it is adequate to > >simply validate the SIP headers and the signature. For protection > >against replay attacks, it is necessary for both SIP UAs (*) to > >implement one of HIP, ICE, DTLS-SRTP, or TLS. > > Ok, so let me put it this way: any feature in your solution that, in a > NAT requirement, does require end-to-end connectivity before the SDP > answer has been sent requires at least STUN (not necessarily ICE) - or > some other mechanism which the NAT binding is opened without > having the > remote SDP. And, if you use ICE, the SBCs must not modify the > SDPs in a way so that ICE is disabled. draft-wing-sip-identity-media does not require end-to-end media path connectivity before the SDP answer arrives at the offer. draft-wing-sip-identity-media provides identity protection in two "phases", to handle simple attacks and to handle more sophisticated attacks. The first phase is the SIP header signing, which is validated entirely without any regard to the media path. The second phase uses the media path, and protects against replay attacks (where an attacker obtained a signed Invite, for example, and replays it in order to ring your phone again and appear to be the original caller.) To protect against that replay attack, you need to make the caller prove they know something that only they know. In sip-identity-media, I am making the caller prove that he knows the private key associated with the certificate (TLS, DTLS) or public key (HIP, ICE) that is going to be used for the TLS, DTLS, or HIP call setup. If he proves he knows that private key, it is safe and reasonable to display the caller id. If he can't prove that, he is an imposter. If he refuses to prove that (or the media path is blocked), you run the risk that -- after the media path is opened -- you will do the DTLS/HIP/TLS/ICE exchange and at that time you will discover the user is an imposter. That discovery will occur after the phone has been rung and answered. To me, that is a poor time to discover an imposter. It's better than what we have today, though, so I guess it _is_ forward progress and I could live with an implementation that discovered an imposter after the phone is answered. It is certainly better than what we have today. If such imposters become commonplace, users will complain to their network providers about the middle-of-the- night call alerting, phone answering, and attendant "Whoops, sorry, that was an imposter. We will send him a big fat bill. Please resume sleeping" messages displayed on their handsets. -d > Regards, > > Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 18:33:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBeYa-0003Zb-34; Thu, 19 Jul 2007 18:33:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBeYY-0003ZU-7F for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 18:33:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBeYX-0003ZM-T6 for sip@ietf.org; Thu, 19 Jul 2007 18:33:09 -0400 Received: from alnrmhc14.comcast.net ([204.127.225.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBeYX-0004J9-Fo for sip@ietf.org; Thu, 19 Jul 2007 18:33:09 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc14) with ESMTP id <20070719223308b1400iq006e>; Thu, 19 Jul 2007 22:33:08 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6JMX88t029851 for ; Thu, 19 Jul 2007 18:33:08 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6JMX7j8029847; Thu, 19 Jul 2007 18:33:07 -0400 Date: Thu, 19 Jul 2007 18:33:07 -0400 Message-Id: <200707192233.l6JMX7j8029847@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <0CED449E95A92A42991EB71B778C17BF059AA80E@TSMAIL2.ad.tri.sbc.com> (james_jackson@labs.att.com) Subject: Re: [Sip] RFC3891 (Replaces header) discrepancies References: <0CED449E95A92A42991EB71B778C17BF059AA475@TSMAIL2.ad.tri.sbc.com> <200707191747.l6JHlQqL009062@dragon.ariadne.com> <0CED449E95A92A42991EB71B778C17BF059AA80E@TSMAIL2.ad.tri.sbc.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Jackson, James" The assumption is that the transfer target rejects the initial early dialog on receiving the REFER. The 180 and 487 would be sent in the NOTIFY associated with the REFER. I don't see what you're describing here. If the INVITE/Replaces were to complete, you would have the previous early dialog ended (probably with 487). And the INVITE/Replaces would presumably get a 200 quickly. But the phone is still ringing. To what "other end" UA does it send provisional and final responses in regard to its status? I'm not trying to pick on any vendors here but take a look at what is called "attended transfer with early completion" on this link: http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_ guide09186a0080110c01.html >From the looks of Figure 4 on that page, the INVITE/Replaces does *not* complete immediately, but rather its provisional and final responses are the continuation of the previous early dialog at the transer target. I wonder how well that would interoperate. Previously, INVITE/Replaces completes quickly, but there is no reason that it *must*, and transferee phones should be able to cope with long transaction times for INVITE/Replaces. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 18:48:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBen1-0006oe-De; Thu, 19 Jul 2007 18:48:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBen0-0006oX-C2 for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 18:48:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBen0-0006oP-11 for sip@ietf.org; Thu, 19 Jul 2007 18:48:06 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBemz-0007Mx-Ld for sip@ietf.org; Thu, 19 Jul 2007 18:48:05 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6JMlko19374; Thu, 19 Jul 2007 22:47:46 GMT 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 Subject: RE: [Sip] WGLC on draft-ietf-sip-sips Date: Thu, 19 Jul 2007 17:47:45 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF115695C3@zrc2hxm0.corp.nortel.com> In-reply-to: <469FD261.2010607@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC on draft-ietf-sip-sips Thread-Index: AcfKSMWIpI+uwTixTs28LmUhCFqLzwADC3Lg References: <5D1A7985295922448D5550C94DE2918001436436@DEEXC1U01.de.lucent.com> <469FD261.2010607@nostrum.com> From: "Francois Audet" To: "Adam Roach" , "DRAGE, Keith (Keith)" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org You are absolutely correct: this is insane. Like giving matches to kids and telling them not to use it. I don't recall who it was that wanted the procedures to remain in the text. I believe the rationale was "how to deal with legacy SIPS implementations". I really think the text would be much simpler if we removed section 3.3.2 altogether.=20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: Thursday, July 19, 2007 14:07 > To: DRAGE, Keith (Keith) > Cc: sip@ietf.org > Subject: Re: [Sip] WGLC on draft-ietf-sip-sips >=20 > On 7/17/07 5:21 AM, DRAGE, Keith (Keith) wrote: > > (As WG chair) > > > > We reached the end of the time when WGLC comments were requested on=20 > > Monday. > > > > If there are any last comments sitting out there that you have been=20 > > meaning to submit, can I suggest you get them in an quickly=20 > as possible. > > =20 >=20 > Sorry for the late comment here, but I find section 3.3.2=20 > perplexing in the current incarnation of the draft. It made=20 > sense before (e.g., in -02, which was the current version in=20 > Prague) -- but now that we're changing behavior, it seems=20 > completely out of place. >=20 > By my reading, section 3.3.2 basically says, "If you=20 > implement this specification, you are explicitly forbidden=20 > from doing the following procedure, which is now explained in=20 > enough detail to implement." >=20 > I would propose removing section 3.3.2. >=20 > /a >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 19:15:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBfDu-0002oT-4O; Thu, 19 Jul 2007 19:15:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBfDr-0002mM-A5 for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 19:15:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBfDq-0002lx-Tj for sip@ietf.org; Thu, 19 Jul 2007 19:15:50 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBfDq-0005Hu-Ci for sip@ietf.org; Thu, 19 Jul 2007 19:15:50 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6JNFhpr030422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 18:15:43 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <469FF0A4.8040201@nostrum.com> Date: Thu, 19 Jul 2007 18:15:48 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Rohan Mahy References: <46928F5F.3080502@softarmor.com> In-Reply-To: <46928F5F.3080502@softarmor.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-Spam-Score: -1.4 (-) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: sip@ietf.org, Cullen Jennings Subject: [Sip] Outbound: TCP and SigComp X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org With the move to CRLF for keepalive in outbound, the language discussing STUN handling with SigComp in TCP is also gone. This makes sense, since TCP no longer uses STUN. However, there was no equivalent language added for how to handle the CRLF keepalives in conjunction with SigComp. As with the earlier STUN mechanism, you can't just send the CRLF stuff down the TCP connection -- it needs to be wrapped in SigComp. Of course, we could employ the same mechanism originally proposed for STUN (the well-known shim), which would be the 13-byte SigComp shim, plus 2 bytes (CRLF) or 4 bytes (double CRLF). Alternately, we can shave this down a _little_ bit by using bytecodes specifically designed to output just the CRLFs we need; for a double-CRLF, it would look like: at (128) OUTPUT (crlf, 4) JUMP(end) :crlf byte(13,10,13,10) :end END-MESSAGE (0,0,0,0,0,0,0) Which translates to the following 14 bytes: f8 00 b1 22 a0 86 04 16 06 0d 0a 0d 0a 23 (Yes, I realize this is 14 bytes instead of the 17 bytes you get with the shim, so it might not be worth using custom code). For a single CRLF, such code would end up looking like this: at (64) :crlf pad(2) at (128) LOAD (crlf, 3338) OUTPUT (crlf, 2) END-MESSAGE (0,0,0,0,0,0,0) Which translates to the following 11 bytes: f8 00 81 0e 86 ad 0a 22 86 02 23. In practice, we're probably best off just normatively saying that the CRLF characters are sent inside SigComp, and that the mechanism for representing them is a matter to be handled by the SigComp compressor at the sending end. We can point out the shim, and we can include the foregoing purpose-built SigComp messages, but there may be architectural complications to using either of them, so the ultimate requirement is simply to send something that produces "CRLF" as its output when it is sent. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 20:05:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBfzT-0004UY-Aq; Thu, 19 Jul 2007 20:05:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBfzS-0004UT-Qm for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 20:05:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBfzS-0004UL-H3 for sip@ietf.org; Thu, 19 Jul 2007 20:05:02 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBfzR-0006Y8-SM for sip@ietf.org; Thu, 19 Jul 2007 20:05:02 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6K04wdo032864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 19:04:59 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <469FFC30.2090309@nostrum.com> Date: Thu, 19 Jul 2007 19:05:04 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Rohan Mahy References: <46928F5F.3080502@softarmor.com> In-Reply-To: <46928F5F.3080502@softarmor.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-Spam-Score: -1.4 (-) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: sip@ietf.org, Cullen Jennings Subject: [Sip] Outbound: Feature Tag (Ab)Use X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At the risk of further bloodying the corpse of this poor horse, I still think the usage of feature tags in outbound is way, way off in terms of the semantics described in 3261. Reviewing the way this is defined to work in SIP: 3261:8.1.1.9: > If the UAC supports extensions to SIP that can be applied by the > server to the response, the UAC SHOULD include a Supported header > field in the request listing the option tags (Section 19.2) for those > extensions. 3261:8.2.4: > A UAS that wishes to apply some extension when generating the > response MUST NOT do so unless support for that extension is > indicated in the Supported header field in the request. If the > desired extension is not supported, the server SHOULD rely only on > baseline SIP and any other extensions supported by the client. > ... > Any extensions applied to a non-421 response MUST be listed in a > Require header field included in the response. Of course, the server > MUST NOT apply extensions not listed in the Supported header field in > the request. As a result of this, the Require header field in a > response will only ever contain option tags defined in standards- > track RFCs. There are five normative statements in the text I quote above. The mechanism described in the outbound draft actually manages to violate _all_ _five_ of them. The registrar infers *both* support for outbound *and* a request to apply the outbound extension by the presence of the "reg-id" Contact header field parameter. In particular, the client is apparently NOT supposed to send a "Supported: outbound" header field. This appears to contravene the normative statement in 8.1.1.9 cited above. The registrar indicates that outbound procedures are being applied by including a "Supported" header field in the REGISTER response. (In 3261, "Supported" in a _response_ indicates that an extension _can_ _be_ supported in a future request, NOT that it is being applied to the current one -- sections 11 and 13.3.1.4 both talk about Supported usage in responses.) In other words, the registrar (acting as a UAS) is applying an extension when generating a response without that extension being indicated in the "Supported" header field in the request. Again, this directly contravenes two normative statements from section 8.2.4 (cited above). The registrar is further applying an extension to a non-421 response that is not listed in a "Require" header field, in violation of the remaining normative statement in the portion of section 8.2.4 cited above. Why are we doing this so very, very wrong? It's almost as if we've gone out of our way to violate both the spirit AND the law of feature tag handling in as many ways as possible. Most annoyingly, we get exactly the desired behavior if we just do things the way they're described in 3261. To wit: * If a client supports outbound, it includes "Supported: outbound" in all REGISTER requests, regardless of whether the specific request makes use of that extension. * The client adds a "reg-id" header field parameter to any Contacts to which outbound processing is to apply. * The registrar includes "Require: outbound" in any REGISTER requests to which outbound behavior is being applied. * The registrar is free to include "Supported: outbound" in any responses it generates -- and it means exactly what 3261 intends it to mean: that outbound is *supported*, but is not being applied to the response in question. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 20:07:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBg2B-0005bU-S8; Thu, 19 Jul 2007 20:07:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBg2B-0005bJ-47 for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 20:07:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBg2A-0005bB-Qs for sip@ietf.org; Thu, 19 Jul 2007 20:07:50 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBg28-0006ee-GP for sip@ietf.org; Thu, 19 Jul 2007 20:07:50 -0400 Received: (qmail 31847 invoked by uid 0); 20 Jul 2007 00:07:47 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 20 Jul 2007 00:07:47 -0000 Message-ID: <008c01c7ca61$9953e880$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Rohan Mahy" , "Cullen Jennings" References: Date: Fri, 20 Jul 2007 02:04:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org Subject: [Sip] draft-ietf-sip-outbound-10.txt : flow token construction X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, A comment / clarification on outbound-10 section 5.3 Forwarding requests, regarding flow token construction and incoming/outgoing logic: The text says to send a 430 (Flow Failed) "For connection-oriented transports, if the flow no longer exists" (SHOULD) This can be read as saying that if the original TCP connection no longer exists, a 430 should be sent. However, if the UAC somehow lost its connection and recovered, there would be a new TCP connection with (likely) a different ephemeral port at the UAC. For the proposed flow token algorithm, this would cause the described incoming/outgoing logic to fail (since the token no longer matches an incoming flow from the UAC). Moreover, for requests in the other direction ("incoming") the proxy would not be able to locate the new flow, and send a 430 where it could have done better. Two thoughts: 1. To determine if a (non-REGISTER) request is incoming/outgoing, it might be easier to simply say: 1 Via header --> outgoing, else incoming. There are other options, the Edge proxy could check the request URI for a Contact URI it has seen in REGISTER before. It could also be based on Service-Route and/or Path. Perhaps this draft need not explain all details, but it currently only describes logic for mid-dialog requests, and appears to fail in the above described case of TCP connection loss. 2. An alternative implementation could be to maintain a mapping of Contact address ( IP/host+port ) to flow, which is updated each time a REGISTER 200 OK comes by. If the UAC is using the same Contact URIs as in its REGISTER (or a GRUU rewritten by the home proxy), there is no need for a flow token at all: the Edge proxy can use (IP/host+port part of) the request URI as an (hash) index into the flow table (for incoming requests). There are many other designs possible. Main point is that the stateless flow token approach described seems suboptimal in case of TCP connection loss (home proxy may be able to recover if the UAC used 2 or more flows, but if all were lost and the backup edge proxy also implemented this algorithm, ongoing dialogs would be lost) Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 20:18:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBgCD-00088F-2g; Thu, 19 Jul 2007 20:18:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBgCA-000881-Kd for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 20:18:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBgCA-00087s-9g for sip@ietf.org; Thu, 19 Jul 2007 20:18:10 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBgC9-00010f-HR for sip@ietf.org; Thu, 19 Jul 2007 20:18:10 -0400 Received: (qmail 23677 invoked by uid 0); 20 Jul 2007 00:19:18 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 20 Jul 2007 00:19:18 -0000 Message-ID: <009b01c7ca63$08fed540$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Adam Roach" , "Rohan Mahy" References: <46928F5F.3080502@softarmor.com> <469FFC30.2090309@nostrum.com> Subject: Re: [Sip] Outbound: Feature Tag (Ab)Use Date: Fri, 20 Jul 2007 02:15:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: sip@ietf.org, Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Good points, some nits inline Regards, Jeroen Adam Roach wrote: > At the risk of further bloodying the corpse of this poor horse, I > still think the usage of feature tags in outbound is way, way off in > terms of the semantics described in 3261. > > Reviewing the way this is defined to work in SIP: > > 3261:8.1.1.9: >> If the UAC supports extensions to SIP that can be applied by the >> server to the response, the UAC SHOULD include a Supported header >> field in the request listing the option tags (Section 19.2) for >> those extensions. > > 3261:8.2.4: > >> A UAS that wishes to apply some extension when generating the >> response MUST NOT do so unless support for that extension is >> indicated in the Supported header field in the request. If the >> desired extension is not supported, the server SHOULD rely only on >> baseline SIP and any other extensions supported by the client. >> ... >> Any extensions applied to a non-421 response MUST be listed in a >> Require header field included in the response. Of course, the >> server MUST NOT apply extensions not listed in the Supported >> header field in the request. As a result of this, the Require >> header field in a response will only ever contain option tags >> defined in standards- track RFCs. > > There are five normative statements in the text I quote above. The > mechanism described in the outbound draft actually manages to violate > _all_ _five_ of them. > > The registrar infers *both* support for outbound *and* a request to > apply the outbound extension by the presence of the "reg-id" Contact > header field parameter. In particular, the client is apparently NOT > supposed to send a "Supported: outbound" header field. This appears to > contravene the normative statement in 8.1.1.9 cited above. > > The registrar indicates that outbound procedures are being applied by > including a "Supported" header field in the REGISTER response. (In > 3261, "Supported" in a _response_ indicates that an extension _can_ > _be_ supported in a future request, NOT that it is being applied to > the current one -- sections 11 and 13.3.1.4 both talk about Supported > usage in responses.) > > In other words, the registrar (acting as a UAS) is applying an > extension when generating a response without that extension being > indicated in the "Supported" header field in the request. Again, this > directly contravenes two normative statements from section 8.2.4 (cited > above). > > The registrar is further applying an extension to a non-421 response > that is not listed in a "Require" header field, in violation of the > remaining normative statement in the portion of section 8.2.4 cited > above. > Why are we doing this so very, very wrong? It's almost as if we've > gone out of our way to violate both the spirit AND the law of feature > tag handling in as many ways as possible. Most annoyingly, we get > exactly the desired behavior if we just do things the way they're > described in > 3261. To wit: > > * If a client supports outbound, it includes "Supported: outbound" > in all REGISTER requests, regardless of whether the specific > request makes use of that extension. > [jvb] this would probably be a MUST, right? > * The client adds a "reg-id" header field parameter to any Contacts > to which outbound processing is to apply. > > * The registrar includes "Require: outbound" in any REGISTER > requests to which outbound behavior is being applied. [jvb] you mean responses > > * The registrar is free to include "Supported: outbound" in any > responses it generates -- and it means exactly what 3261 intends > it to mean: that outbound is *supported*, but is not being > applied to the response in question. [jvb] is not _necessarily_ being applied, it depends on presence of Require: outbound (only). Guess this is a MAY, right? > > /a > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 20:36:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBgTM-0006AN-6N; Thu, 19 Jul 2007 20:35:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBgTK-0006AH-4A for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 20:35:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBgTJ-0006A9-Pm for sip@ietf.org; Thu, 19 Jul 2007 20:35:53 -0400 Received: from rwcrmhc15.comcast.net ([204.127.192.85]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBgTJ-0001Oh-3X for sip@ietf.org; Thu, 19 Jul 2007 20:35:53 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc15) with ESMTP id <20070720003551m1500a2ul7e>; Fri, 20 Jul 2007 00:35:51 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6K0Zo8t006570 for ; Thu, 19 Jul 2007 20:35:50 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6K0ZoSe006566; Thu, 19 Jul 2007 20:35:50 -0400 Date: Thu, 19 Jul 2007 20:35:50 -0400 Message-Id: <200707200035.l6K0ZoSe006566@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <469FFC30.2090309@nostrum.com> (adam@nostrum.com) Subject: Re: [Sip] Outbound: Feature Tag (Ab)Use References: <46928F5F.3080502@softarmor.com> <469FFC30.2090309@nostrum.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Adam Roach Date: Thu, 19 Jul 2007 19:05:04 -0500 Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: sip@ietf.org, Cullen Jennings At the risk of further bloodying the corpse of this poor horse, I still think the usage of feature tags in outbound is way, way off in terms of the semantics described in 3261. Reviewing the way this is defined to work in SIP: 3261:8.1.1.9: > If the UAC supports extensions to SIP that can be applied by the > server to the response, the UAC SHOULD include a Supported header > field in the request listing the option tags (Section 19.2) for those > extensions. 3261:8.2.4: > A UAS that wishes to apply some extension when generating the > response MUST NOT do so unless support for that extension is > indicated in the Supported header field in the request. If the > desired extension is not supported, the server SHOULD rely only on > baseline SIP and any other extensions supported by the client. > ... > Any extensions applied to a non-421 response MUST be listed in a > Require header field included in the response. Of course, the server > MUST NOT apply extensions not listed in the Supported header field in > the request. As a result of this, the Require header field in a > response will only ever contain option tags defined in standards- > track RFCs. There are five normative statements in the text I quote above. The mechanism described in the outbound draft actually manages to violate _all_ _five_ of them. The registrar infers *both* support for outbound *and* a request to apply the outbound extension by the presence of the "reg-id" Contact header field parameter. In particular, the client is apparently NOT supposed to send a "Supported: outbound" header field. This appears to contravene the normative statement in 8.1.1.9 cited above. The registrar indicates that outbound procedures are being applied by including a "Supported" header field in the REGISTER response. (In 3261, "Supported" in a _response_ indicates that an extension _can_ _be_ supported in a future request, NOT that it is being applied to the current one -- sections 11 and 13.3.1.4 both talk about Supported usage in responses.) In other words, the registrar (acting as a UAS) is applying an extension when generating a response without that extension being indicated in the "Supported" header field in the request. Again, this directly contravenes two normative statements from section 8.2.4 (cited above). The registrar is further applying an extension to a non-421 response that is not listed in a "Require" header field, in violation of the remaining normative statement in the portion of section 8.2.4 cited above. Why are we doing this so very, very wrong? It's almost as if we've gone out of our way to violate both the spirit AND the law of feature tag handling in as many ways as possible. Most annoyingly, we get exactly the desired behavior if we just do things the way they're described in 3261. To wit: * If a client supports outbound, it includes "Supported: outbound" in all REGISTER requests, regardless of whether the specific request makes use of that extension. * The client adds a "reg-id" header field parameter to any Contacts to which outbound processing is to apply. * The registrar includes "Require: outbound" in any REGISTER requests to which outbound behavior is being applied. * The registrar is free to include "Supported: outbound" in any responses it generates -- and it means exactly what 3261 intends it to mean: that outbound is *supported*, but is not being applied to the response in question. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 19 20:40:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBgXh-0001fb-Ev; Thu, 19 Jul 2007 20:40:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBgXa-0001Po-SQ for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 20:40:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBgXa-0001No-91 for sip@ietf.org; Thu, 19 Jul 2007 20:40:18 -0400 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBgXa-0007L6-0Q for sip@ietf.org; Thu, 19 Jul 2007 20:40:18 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc12) with ESMTP id <2007072000401701200mmphke>; Fri, 20 Jul 2007 00:40:17 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6K0eH8t006930 for ; Thu, 19 Jul 2007 20:40:17 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6K0eHAC006926; Thu, 19 Jul 2007 20:40:17 -0400 Date: Thu, 19 Jul 2007 20:40:17 -0400 Message-Id: <200707200040.l6K0eHAC006926@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <469FFC30.2090309@nostrum.com> (adam@nostrum.com) Subject: Re: [Sip] Outbound: Feature Tag (Ab)Use References: <46928F5F.3080502@softarmor.com> <469FFC30.2090309@nostrum.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Adam Roach At the risk of further bloodying the corpse of this poor horse, I still think the usage of feature tags in outbound is way, way off in terms of the semantics described in 3261. You're completely right, of course. Why are we doing this so very, very wrong? It's almost as if we've gone out of our way to violate both the spirit AND the law of feature tag handling in as many ways as possible. And outbound is not the only place this has happened. It took a long time to purge this sort of error from gruu as well. IMHO, I think the reason is that people intuitively want "Supported" to mean "this message is invoking the feature in question" (which is ambiguous as to whether it means that the message contains use of the feature, or that the message requests the far end to apply the feature). People seem to have a hard time grasping that its purpose is to communicate a property of the UA, namely that the UA supports the feature in question. But many people in the world of software don't grasp talking about "properties that things possess", they can only talk about "actions happening right now". Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 01:08:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBkiS-00011m-MV; Fri, 20 Jul 2007 01:07:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBkiQ-00011g-Oo for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 01:07:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBkiQ-00011Y-4N for sip@ietf.org; Fri, 20 Jul 2007 01:07:46 -0400 Received: from py-out-1112.google.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBkiO-0004jm-SS for sip@ietf.org; Fri, 20 Jul 2007 01:07:46 -0400 Received: by py-out-1112.google.com with SMTP id f31so2555019pyh for ; Thu, 19 Jul 2007 22:07:44 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=kUCZvwpC8VxZqvvFIGooJjvCDwhERTG78v9S7Tips18mHMxjRlW6jQJaY71aoe9bBxJK06UxYSTDSfX26sTw8vpixnRnKZ2KZkC3xZjqXGZ8tSGIpI4ILVFqAPUd7cged4YarewmUFbJEI8RztaG+eIWnSJmb/ahqYbRK8s+Chk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=oR1J+s6K4CnUnahqiSxJwmNVviUKIYiiZJpTnsEHc5J2GGIJYNQQQ3ZwVIroOcvOVzo/3uQvWJS9n7jzKhCUmqBhQzM4UE2wrHBdcRdFVQsoH1VFRIAaWC3efMntOOA/NM+7ZcQfmqZYfqv9Eqe2Z7iUDU31TizFkhFZm1H0/gE= Received: by 10.64.243.10 with SMTP id q10mr147250qbh.1184908063597; Thu, 19 Jul 2007 22:07:43 -0700 (PDT) Received: by 10.64.253.11 with HTTP; Thu, 19 Jul 2007 22:07:40 -0700 (PDT) Message-ID: <66fe674b0707192207u583614a5h9dc186d5f7d3a97f@mail.gmail.com> Date: Fri, 20 Jul 2007 10:37:43 +0530 From: "vishal jogi" To: sip@ietf.org, sip-implementors-request@cs.columbia.edu Subject: [Sip] Event - list subscribe In-Reply-To: <66fe674b0707191752x4efe1422q288d2a410dd488a0@mail.gmail.com> MIME-Version: 1.0 References: <66fe674b0707190030n63781e1ao5d2ff69fede430d9@mail.gmail.com> <66fe674b0707191752x4efe1422q288d2a410dd488a0@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0161359256==" Errors-To: sip-bounces@ietf.org --===============0161359256== Content-Type: multipart/alternative; boundary="----=_Part_80532_10035488.1184908063547" ------=_Part_80532_10035488.1184908063547 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Vikram, I have checked draft-ietf-simple-event-list-07, but it doesn't specify anything about this case, is there any draft or RFC which will give exact idea about it?? Thanks, Vishal... On 7/19/07, Vikram Chhibber wrote: > > I don't think that this is correct behavior of the RLS. If the RLS > understands the uri pointing to a resource-list. It should accept this > subscription. Even though the list is empty. The user/administrator > may provision entries in this list in future by non-SIP mechanism > (XCAP). > > On 7/19/07, vishal jogi < vishaljogi@gmail.com> wrote: > > Hi, > > I have one doubt. > > > > i m subscribing to RLS uri, > > which is refering one Resource-list which doesn't have any > > mean it's blank > > > > server is sending 404 as response for Subscribe, can anyone tell me it's > > correct behaviour of server, > > as that is existing > > > > Thanks, > > Vishal... > > _______________________________________________ > > Sip mailing list > > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on > > current sip > > Use sipping@ietf.org for new developments on the application of sip > > > ------=_Part_80532_10035488.1184908063547 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
        Hi Vikram,
         
        I have checked draft-ietf-simple-event-list-07, but it doesn't specify anything about this case,
        is there any draft or RFC which will give exact idea about it??
         
        Thanks,
        Vishal...
         
        On 7/19/07, Vikram Chhibber <vikram.chhibber@gmail.com > wrote:
        I don't think that this is correct behavior of the RLS. If the RLS
        understands the uri pointing to a resource-list. It should accept this
        subscription. Even though the list is empty. The user/administrator
        may provision entries in this list in future by non-SIP mechanism
        (XCAP).

        On 7/19/07, vishal jogi < vishaljogi@gmail.com> wrote:
        > Hi,
        > I have one doubt.
        >
        > i m subscribing to RLS uri,
        > which is refering one Resource-list which doesn't have any <entry>
        > mean it's blank <LIST>
        >
        > server is sending 404 as response for Subscribe, can anyone tell me it's
        > correct behaviour of server,
        > as that <LIST> is existing
        >
        > Thanks,
        > Vishal...
        > _______________________________________________
        > Sip mailing list
        > https://www1.ietf.org/mailman/listinfo/sip
        > This list is for NEW development of the core SIP Protocol
        > Use sip-implementors@cs.columbia.edu for questions on
        > current sip
        > Use sipping@ietf.org for new developments on the application of sip
        >

        ------=_Part_80532_10035488.1184908063547-- --===============0161359256== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0161359256==-- From sip-bounces@ietf.org Fri Jul 20 03:59:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBnOE-0003xl-6D; Fri, 20 Jul 2007 03:59:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBnOC-0003xc-TK for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 03:59:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBnOC-0003xU-Gv for sip@ietf.org; Fri, 20 Jul 2007 03:59:04 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBnOA-0008IG-AL for sip@ietf.org; Fri, 20 Jul 2007 03:59:04 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLG002ZJWT6B5@szxga04-in.huawei.com> for sip@ietf.org; Fri, 20 Jul 2007 15:58:18 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLG006GWWT59W@szxga04-in.huawei.com> for sip@ietf.org; Fri, 20 Jul 2007 15:58:18 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLG001NNWT104@szxml04-in.huawei.com> for sip@ietf.org; Fri, 20 Jul 2007 15:58:17 +0800 (CST) Date: Fri, 20 Jul 2007 15:58:13 +0800 From: Qian Sun Subject: RE: [Sip] comments on draft-camarillo-sip-body-handling-01 In-reply-to: <469FAD9C.6050806@cisco.com> To: 'Paul Kyzivat' , 'Gonzalo Camarillo' Message-id: <007501c7caa3$b8f962e0$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: AcfKMte8iABTRIOyQ5OAKtTf+AKf2gAaSDyQ X-Spam-Score: 1.2 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I suggest Content Indirection Mechanism defined in rfc4483 should also be considered in this draft. It is a little special, an example from rfc4483: 6.1. Single Content Indirection INVITE sip:boromir@example.com SIP/2.0 Accept: message/external-body application/sdp Content-Type: message/external-body; ACCESS-TYPE=URL; URL="http://www.example.net/party/06/2002/announcement"; EXPIRATION="Sat, 20 Jun 2002 12:00:00 GMT"; size=231 Content-Length: 105 Content-Type: application/sdp Content-Disposition: session Content-ID: <4e5562cd1214427d@example.net> In addition, what happens to the INVITE request if the recipient can not get the indirect content? Nits: a letter "l" is missing in the title. Internet-Draft Message Body Hand"l"ing in SIP May 2007 Cheers, Qian -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Friday, July 20, 2007 2:30 AM To: Gonzalo Camarillo Cc: IETF SIP List Subject: Re: [Sip] comments on draft-camarillo-sip-body-handling-01 Just one comment in addition to what Gonzalo said: Gonzalo Camarillo wrote: >> The use case described for multipart/alternative - new SDP mechanisms >> - seems kind of bogus. We've decided not to pursue that. Do we have a >> REAL use case for this? > > AFAICT, we have decided not to pursue SDPng but we still need a > mechanism in order to be able to, at some point, migrate to new session > description formats. The current consensus, as I understand it, is that > multipart/alternative should not be used to provide alternative SDP > descriptions, but that it could be used to provide alternative session > descriptions written in different formats. The other classic example, because it is just like email, is MESSAGE with a multipart/alternative containing plain text and html. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 04:49:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBoAr-0006v2-Pf; Fri, 20 Jul 2007 04:49:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBoAq-0006sE-Ns for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 04:49:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBoAq-0006s6-A9 for sip@ietf.org; Fri, 20 Jul 2007 04:49:20 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBoAp-0004hR-Pq for sip@ietf.org; Fri, 20 Jul 2007 04:49:20 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JLG00E9FZ5RN0@siemenscomms.co.uk> for sip@ietf.org; Fri, 20 Jul 2007 09:49:03 +0100 (BST) Date: Fri, 20 Jul 2007 09:49:18 +0100 From: "Elwell, John" Subject: RE: [Sip] RFC3891 (Replaces header) discrepancies In-reply-to: <200707191747.l6JHlQqL009062@dragon.ariadne.com> To: Dale.Worley@comcast.net, sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0205CBC@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Sip] RFC3891 (Replaces header) discrepancies Thread-Index: AcfKLORJvHPLAEiGQXWgrz2WcHiENgAfSE7g Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0CED449E95A92A42991EB71B778C17BF059AA475@TSMAIL2.ad.tri.sbc.com> <200707191747.l6JHlQqL009062@dragon.ariadne.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In addition to what Dale has said, consider the case where call2 has been forked to several destinations, 2a, 2b, 2c... To populate the Replaces header field and the Refer-To URI, the sender of the REFER request would need to pick one of these arbitrarily, say 2b. So suppose the REFER request were sent and dereferenced, resulting in an INVITE request with Replaces header field arriving at 2b. What if call2 is then answered by 2a (or has already been answered by 2a while this signalling is taking place)? I don't think the intended operation of attended transfer would then be realised. So basically, I don't think the authors of RFC 3891 saw any solutions to problems of this nature, and hence the restriction. John > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: 19 July 2007 18:47 > To: sip@ietf.org > Subject: Re: [Sip] RFC3891 (Replaces header) discrepancies > > > From: "Jackson, James" > > Consider an attended transfer in which call1 is > established between a > transferee and a transferor. The transferor creates a new > call2 towards > transfer target. While this call is still alerting (early > dialog), it > sends a REFER on call1 with a Replaces header that > references call2. In > this case, the Replaces header attempts to replace an > early dialog which > was "terminated" by the target. > > That is not allowed by RFC 3891. But suppose it was allowed. Further > suppose that the transfer target rings for another 90 seconds (sending > an additional 180) and then the proxy that manages the transfer target > cancels the call, causing the transfer target to send a 487. Who > receives the 180 and 487? > > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 04:56:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBoHJ-0003P3-DM; Fri, 20 Jul 2007 04:56:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBoHH-0003Oy-Tk for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 04:55:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBoHH-0003Oq-8S for sip@ietf.org; Fri, 20 Jul 2007 04:55:59 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBoHG-0004oJ-Lv for sip@ietf.org; Fri, 20 Jul 2007 04:55:59 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6K8td8c025637 for ; Fri, 20 Jul 2007 11:55:56 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 11:55:28 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 11:55:27 +0300 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.1830); Fri, 20 Jul 2007 11:55:27 +0300 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6K8tQFv021170 for ; Fri, 20 Jul 2007 11:55:26 +0300 Received: from [172.21.41.35] (esdhcp04135.research.nokia.com [172.21.41.35]) by kusti.research.nokia.com (Postfix) with ESMTP id 700E793B77 for ; Fri, 20 Jul 2007 11:55:26 +0300 (EEST) Message-ID: <46A07879.5090403@nokia.com> Date: Fri, 20 Jul 2007 11:55:21 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: sip@ietf.org References: <003601c7c8eb$d99e04b0$7c6c460a@china.huawei.com> <200707190419.l6J4Jpad014623@dragon.ariadne.com> <469F408D.2040704@nokia.com> <200707191411.l6JEBuOc025832@dragon.ariadne.com> In-Reply-To: <200707191411.l6JEBuOc025832@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2007 08:55:27.0640 (UTC) FILETIME=[B7DED180:01C7CAAB] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Sip] Re: Model for entity-tags in subnot-etags X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Dale, ext sip-bounces@ietf.org wrote: > From: Aki Niemi > > - There is a single authoritative notifier agent responsible for any > single resource. > > - A resource is identified using a SIP URI. > > - A subscriber subscribes to a resource using the SIP URI. > > Often a subscriber will send the SUBSCRIBE to a URI which is not the > request-URI of the SUBSCRIBE when it reaches the notifier agent. This > happens due to normal SIP request routing, but the routing can also > change with time. Correct, but are you saying there might be more than one agent with a different idea on the entity-tags of entities pertaining to a certain resource? In other words, that the resource has multiple agents that may have a different view of the resource state? I believe this is disallowed per RFC3265 already. > - Each entity has an assigned entity-tag. > > Each entity has a succession of versions. Each version of each entity > has an assigned entity-tag. Yes. > - There is a one-to-many relationship between an entity and its versions > (different etag values, of which only one is current). > > - An entity-tag must be unique across all versions of all entities from > a resource. > > Does this rule out hash-based entity-tags, which are only > probabalistically unique? No, I think this MUST statement should probably be followed with an implementation note that talks about what's reasonably unique in this context. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 06:04:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBpLs-0001t6-8D; Fri, 20 Jul 2007 06:04:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBpLq-0001sy-E9 for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 06:04:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBpLp-0001sq-VH for sip@ietf.org; Fri, 20 Jul 2007 06:04:46 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBpLo-0006RW-HX for sip@ietf.org; Fri, 20 Jul 2007 06:04:45 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLH005782MX9W@szxga04-in.huawei.com> for sip@ietf.org; Fri, 20 Jul 2007 18:04:09 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLH005JH2MWUS@szxga04-in.huawei.com> for sip@ietf.org; Fri, 20 Jul 2007 18:04:09 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLH00G3A2MSMH@szxml03-in.huawei.com> for sip@ietf.org; Fri, 20 Jul 2007 18:04:08 +0800 (CST) Date: Fri, 20 Jul 2007 18:04:04 +0800 From: Qian Sun Subject: RE: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides for body (MIME) handling) In-reply-to: <469FAA12.1030800@cisco.com> To: 'Paul Kyzivat' , 'Gonzalo Camarillo' Message-id: <007601c7cab5$4dce3740$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: AcfKMLSR55JFwCImSmeHx5F3gWmlCAAgQCMw X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: 'sip' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, If we define a new Content Disposition type "advertisement" so that the operator or service provider may insert advertisement in the all kinds of message body. And we want the advertisement content 'render' to the users. Could we use multiple content dispositions ("advertisement" and 'render') for a single content part? Or only define a new Content Disposition Parameters "advertisement" instead? This is a real requirement, OMA and GSM is developing the mobile advertisement spec. the current advertisement way in Email or Webpage is very "evil", it is difficult for the user's client to distinguish the real content from advertisement, sometimes this is very disgusting or confusing. A new Content Disposition type "advertisement" or something else could be helpful, the advertisement may be displayed in a place different from the content. Cheers, Qian -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Friday, July 20, 2007 2:15 AM To: Gonzalo Camarillo Cc: sip Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides for body (MIME) handling) Gonzalo Camarillo wrote: > Hi, > > yes, I agree there is a bigger issue with 'render'. Even though this > bigger issue does not directly relate to multipart, we can also tackle > it in the same draft and clarify how 'render' is used and what it means. Sounds good. Maybe its just a matter of changing the title of the draft to match the scope. Something like: draft-sipping-content-type-disp-clarification-nn.txt Paul > Cheers, > > Gonzalo > > > Paul Kyzivat wrote: >> >> >> Gonzalo Camarillo wrote: >>> Hi Paul, >>> >>>> Regarding Content-Disposition in multiparts: >>>> >>>> While it seems "wrong" to me, I can live with using "render" as the >>>> normal disposition for multipart, *if* we can do a careful job of >>>> defining what "render" actually means for SIP. Used this way it >>>> clearly doesn't always mean to display the content to a user. >>> >>> An entity receiving a 'multipart/mixed' body will process its body >>> parts based on their disposition types.If the disposition type of a >>> particular body part is not understood, it will be displayed to the >>> user because the default disposition type is 'render'. >> >> There is a bigger problem with 'render' than just multipart. >> >> We have many uses of body parts that never mention Content-Disposition >> at all. The related examples don't use it, and so they all get a >> default of 'render'. This is particularly the case with events. E.g. >> >> - the notification for REFER contains type application/sipfrag. >> Its probably not intended to be "rendered" in any literal sense, >> though some conclusion about success or failure may be. >> >> - usage of filter bodies in presence subscriptions (RFC 4660) >> doesn't have a specified disposition, so it implicitly uses render. >> Its hard for me to convince myself that what the presence server >> does with these can be described as rendering. >> >> - In fact, the only place I can think of where 'render' is (implicitly) >> used in sip and has the appropriate connotation is in MESSAGE. >> >> I think we just have to grandfather the use of 'refer' in SIP, and >> document that the usage in sip does not mean "render", but rather >> means that the usage must be determined by other context - >> specifically the type of message or response and the content type. >> IOW, 'render' in sip can be thought of as a peculiar spelling for >> 'by-context'. It might be helpful to give guidance for development of >> future specs about when 'render' should be used vs defining a new >> disposition. >> >>> Therefore, the 'multipart/mixed' body will never be processed based >>> on its disposition type. >> >> Based on my discussion above, I would consider this a case of the >> multipart being processed according to its context *because* its >> content-disposition is 'refer'. If it had some other >> content-disposition then that might mean that it should be processed >> specially. E.g. if a multipart/mixed had disposition 'by-reference' >> then that needs to be taken into account, and the processing of the >> multipart becomes conditional on the reference. >> >> Also, there are only certain contexts in which multipart should be >> processed "normally". Consider a NOTIFY from a REFER, with a >> Content-Type of message/sipfrag, which happened to include a body as >> part of the fragment. (This is legal.) That body might contain a >> multipart/mixed, and that might contain other stuff. But I think the >> processing of all of that is dependent on processing of the sipfrag. >> For instance, if something inside that had handling=required, I don't >> think that means that processing of the NOTIFY fails because the >> recipient can't handle that. >> >>> This means that it does not make much sense to talk about its >>> disposition type as a whole. >> >> Counterexample above. >> >>> However, we need to have one in order to be able to set its handling >>> parameter. That's why we can either keep 'render' explaining that it >>> is actually never used or define a new disposition type. >> >> I can go either way on that. But because there is existing usage, and >> because 'render' semantics are already so messed up, I think it makes >> more sense to stick with 'render' and just clarify its meaning. >> >>> Since existing implementations will not understand our newly defined >>> disposition type, they will treat it as 'render' anyway... but the >>> resulting behavior would be the same. That's why it may make sense to >>> keep using 'render'. >> >> Yup. >> >>> On the other hand, semantically, it would make more sense to define a >>> new disposition type. >>> >>> Also, if we decide to define the 'by-reference' disposition type (per >>> a different email thread), it could be used here as well. >> >> It could be used when there is actually a reference to it. But it >> would not be an appropriate disposition to use when there is no >> reference to the multipart. >> >> Thanks, >> Paul >> >>> Cheers, >>> >>> Gonzalo >>> >>> >>> >>>> Gonzalo Camarillo wrote: >>>>> Folks, >>>>> >>>>> here you have the slides I have put together for the body (MIME) >>>>> handling presentation on Monday: >>>>> >>>>> http://users.piuha.net/gonzalo/temp/ietf69-sip-camarillo-body-handling.ppt >>>>> >>>>> >>>>> These slides relate to this draft: >>>>> >>>>> http://www.ietf.org/internet-drafts/draft-camarillo-sip-body-handling-01.txt >>>>> >>>>> >>>>> The slides discuss all the open issues that have been brought up in >>>>> the list in the last months. >>>>> >>>>> Comments are welcome. >>>>> >>>>> Thanks, >>>>> >>>>> Gonzalo >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol >>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>> Use sipping@ietf.org for new developments on the application of sip >>>>> >>> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 06:41:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBpvj-0005gH-LS; Fri, 20 Jul 2007 06:41:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBpvi-0005g9-66 for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 06:41:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBpvh-0005g1-SG for sip@ietf.org; Fri, 20 Jul 2007 06:41:49 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBpvh-0007HS-Iy for sip@ietf.org; Fri, 20 Jul 2007 06:41:49 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.100]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IBpvZ-0008NK-8N; Fri, 20 Jul 2007 05:41:41 -0500 Message-ID: <46A09239.6010908@softarmor.com> Date: Fri, 20 Jul 2007 05:45:13 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Qian Sun Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides for body (MIME) handling) References: <007601c7cab5$4dce3740$7c6c460a@china.huawei.com> In-Reply-To: <007601c7cab5$4dce3740$7c6c460a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: 'sip' , 'Paul Kyzivat' , 'Gonzalo Camarillo' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Qian Sun wrote: > If we define a new Content Disposition type "advertisement" so that > the operator or service provider may insert advertisement in the all > kinds of message body. And we want the advertisement content 'render' > to the users. Could we use multiple content dispositions > ("advertisement" and 'render') for a single content part? Or only > define a new Content Disposition Parameters "advertisement" instead? So is there a need to ever use "advertisement" in conjunction with something besides "render"? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 07:07:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBqIc-0006go-9S; Fri, 20 Jul 2007 07:05:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBqIa-0006eY-Ux for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 07:05:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBqIa-0006eQ-KF for sip@ietf.org; Fri, 20 Jul 2007 07:05:28 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBqIa-0007mh-8i for sip@ietf.org; Fri, 20 Jul 2007 07:05:28 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <200707201105270130078g0je>; Fri, 20 Jul 2007 11:05:27 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6KB5R8t020460 for ; Fri, 20 Jul 2007 07:05:27 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6KB5RSE020456; Fri, 20 Jul 2007 07:05:27 -0400 Date: Fri, 20 Jul 2007 07:05:27 -0400 Message-Id: <200707201105.l6KB5RSE020456@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <46A07879.5090403@nokia.com> (aki.niemi@nokia.com) Subject: Re: [Sip] Re: Model for entity-tags in subnot-etags References: <003601c7c8eb$d99e04b0$7c6c460a@china.huawei.com> <200707190419.l6J4Jpad014623@dragon.ariadne.com> <469F408D.2040704@nokia.com> <200707191411.l6JEBuOc025832@dragon.ariadne.com> <46A07879.5090403@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Aki Niemi ext sip-bounces@ietf.org wrote: > From: Aki Niemi > > - There is a single authoritative notifier agent responsible for any > single resource. > > - A resource is identified using a SIP URI. > > - A subscriber subscribes to a resource using the SIP URI. > > Often a subscriber will send the SUBSCRIBE to a URI which is not the > request-URI of the SUBSCRIBE when it reaches the notifier agent. This > happens due to normal SIP request routing, but the routing can also > change with time. Correct, but are you saying there might be more than one agent with a different idea on the entity-tags of entities pertaining to a certain resource? In other words, that the resource has multiple agents that may have a different view of the resource state? I believe this is disallowed per RFC3265 already. I doubt things could work with multiple agents that have a different view of the resource state. But there might be multiple agents with different addresses, from whom you request the state of the same resource using different SIP URIs. (Which ultimately might all be destinations reached by sending requests to the same AOR.) I don't think it interferes with the subnot mechanism, but my point is that a resource might *not* have a single, specific SIP URI, either as the request-URI when the SUBSCRIBE reaches the agent(s) which can deliver its state, or as the address to which UAs subscribe. All you need to make subnot work is that every UA agrees on which subscriptions are "for the same resource", and that all notifiers for "the same resource" generate the same etags for the same state, and different etags for different state. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 08:07:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBrGJ-0004uG-LS; Fri, 20 Jul 2007 08:07:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBrGH-0004u5-JR for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 08:07:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBrGH-0004tx-9v for sip@ietf.org; Fri, 20 Jul 2007 08:07:09 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBrGF-0005T5-Sm for sip@ietf.org; Fri, 20 Jul 2007 08:07:09 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2007 04:56:55 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwPAENCoEarR7MV/2dsb2JhbACIXptT X-IronPort-AV: i="4.16,562,1175497200"; d="scan'208"; a="167520063:sNHT10480229406" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6KBusKD031896; Fri, 20 Jul 2007 04:56:54 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6KBuj6G007311; Fri, 20 Jul 2007 11:56:54 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); Fri, 20 Jul 2007 07:56:50 -0400 Received: from [10.86.240.216] ([10.86.240.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 07:56:49 -0400 Message-ID: <46A0A2FF.3050806@cisco.com> Date: Fri, 20 Jul 2007 07:56:47 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Qian Sun Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides for body (MIME) handling) References: <007601c7cab5$4dce3740$7c6c460a@china.huawei.com> In-Reply-To: <007601c7cab5$4dce3740$7c6c460a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2007 11:56:49.0550 (UTC) FILETIME=[0DFE82E0:01C7CAC5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7976; t=1184932615; x=1185796615; c=relaxed/simple; s=sjdkim1004; 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=20Content-Disposition=20in=20multiparts=20WAS=20(Re=3A= 20[Sip]=20Draft=20slides=0A=20for=20body=20(MIME)=20handling) |Sender:=20; bh=Os33r4fAj73pvArBmZBnvG1Skh8Q+VxcXquI7eElprE=; b=RMxPjTHMXI7AHi9QMnz8Ks02kyzX0eZGRk0LcQXYi/+iyj57Xrhn97DVunrgItpJ6pH7j8dY u0vcFU4yivEm8MllyfV3+PXABK1EuPtm6S3jad5rE5ovOs7aDhO5l9ZwsDLxVhypAQHg+5cX3I ivaJ/P9gcqFVE1Hh3LWR7AKV0=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: 'sip' , 'Gonzalo Camarillo' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Qian Sun wrote: > Hi, > > If we define a new Content Disposition type "advertisement" so that the operator or service provider may insert advertisement in the all kinds of message body. And we want the advertisement content 'render' to the users. Could we use multiple content dispositions ("advertisement" and 'render') for a single content part? Or only define a new Content Disposition Parameters "advertisement" instead? I'm quite certain that there may be only one content disposition per body part, just as there can be only one content type per body part. > This is a real requirement, OMA and GSM is developing the mobile advertisement spec. the current advertisement way in Email or Webpage is very "evil", it is difficult for the user's client to distinguish the real content from advertisement, sometimes this is very disgusting or confusing. A new Content Disposition type "advertisement" or something else could be helpful, the advertisement may be displayed in a place different from the content. I don't think I want to think or talk about "advertisement". Paul > Cheers, > Qian > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, July 20, 2007 2:15 AM > To: Gonzalo Camarillo > Cc: sip > Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides for body (MIME) handling) > > > > Gonzalo Camarillo wrote: >> Hi, >> >> yes, I agree there is a bigger issue with 'render'. Even though this >> bigger issue does not directly relate to multipart, we can also tackle >> it in the same draft and clarify how 'render' is used and what it means. > > Sounds good. Maybe its just a matter of changing the title of the draft > to match the scope. Something like: > draft-sipping-content-type-disp-clarification-nn.txt > > Paul > >> Cheers, >> >> Gonzalo >> >> >> Paul Kyzivat wrote: >>> >>> Gonzalo Camarillo wrote: >>>> Hi Paul, >>>> >>>>> Regarding Content-Disposition in multiparts: >>>>> >>>>> While it seems "wrong" to me, I can live with using "render" as the >>>>> normal disposition for multipart, *if* we can do a careful job of >>>>> defining what "render" actually means for SIP. Used this way it >>>>> clearly doesn't always mean to display the content to a user. >>>> An entity receiving a 'multipart/mixed' body will process its body >>>> parts based on their disposition types.If the disposition type of a >>>> particular body part is not understood, it will be displayed to the >>>> user because the default disposition type is 'render'. >>> There is a bigger problem with 'render' than just multipart. >>> >>> We have many uses of body parts that never mention Content-Disposition >>> at all. The related examples don't use it, and so they all get a >>> default of 'render'. This is particularly the case with events. E.g. >>> >>> - the notification for REFER contains type application/sipfrag. >>> Its probably not intended to be "rendered" in any literal sense, >>> though some conclusion about success or failure may be. >>> >>> - usage of filter bodies in presence subscriptions (RFC 4660) >>> doesn't have a specified disposition, so it implicitly uses render. >>> Its hard for me to convince myself that what the presence server >>> does with these can be described as rendering. >>> >>> - In fact, the only place I can think of where 'render' is (implicitly) >>> used in sip and has the appropriate connotation is in MESSAGE. >>> >>> I think we just have to grandfather the use of 'refer' in SIP, and >>> document that the usage in sip does not mean "render", but rather >>> means that the usage must be determined by other context - >>> specifically the type of message or response and the content type. >>> IOW, 'render' in sip can be thought of as a peculiar spelling for >>> 'by-context'. It might be helpful to give guidance for development of >>> future specs about when 'render' should be used vs defining a new >>> disposition. >>> >>>> Therefore, the 'multipart/mixed' body will never be processed based >>>> on its disposition type. >>> Based on my discussion above, I would consider this a case of the >>> multipart being processed according to its context *because* its >>> content-disposition is 'refer'. If it had some other >>> content-disposition then that might mean that it should be processed >>> specially. E.g. if a multipart/mixed had disposition 'by-reference' >>> then that needs to be taken into account, and the processing of the >>> multipart becomes conditional on the reference. >>> >>> Also, there are only certain contexts in which multipart should be >>> processed "normally". Consider a NOTIFY from a REFER, with a >>> Content-Type of message/sipfrag, which happened to include a body as >>> part of the fragment. (This is legal.) That body might contain a >>> multipart/mixed, and that might contain other stuff. But I think the >>> processing of all of that is dependent on processing of the sipfrag. >>> For instance, if something inside that had handling=required, I don't >>> think that means that processing of the NOTIFY fails because the >>> recipient can't handle that. >>> >>>> This means that it does not make much sense to talk about its >>>> disposition type as a whole. >>> Counterexample above. >>> >>>> However, we need to have one in order to be able to set its handling >>>> parameter. That's why we can either keep 'render' explaining that it >>>> is actually never used or define a new disposition type. >>> I can go either way on that. But because there is existing usage, and >>> because 'render' semantics are already so messed up, I think it makes >>> more sense to stick with 'render' and just clarify its meaning. >>> >>>> Since existing implementations will not understand our newly defined >>>> disposition type, they will treat it as 'render' anyway... but the >>>> resulting behavior would be the same. That's why it may make sense to >>>> keep using 'render'. >>> Yup. >>> >>>> On the other hand, semantically, it would make more sense to define a >>>> new disposition type. >>>> >>>> Also, if we decide to define the 'by-reference' disposition type (per >>>> a different email thread), it could be used here as well. >>> It could be used when there is actually a reference to it. But it >>> would not be an appropriate disposition to use when there is no >>> reference to the multipart. >>> >>> Thanks, >>> Paul >>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >>>> >>>> >>>>> Gonzalo Camarillo wrote: >>>>>> Folks, >>>>>> >>>>>> here you have the slides I have put together for the body (MIME) >>>>>> handling presentation on Monday: >>>>>> >>>>>> http://users.piuha.net/gonzalo/temp/ietf69-sip-camarillo-body-handling.ppt >>>>>> >>>>>> >>>>>> These slides relate to this draft: >>>>>> >>>>>> http://www.ietf.org/internet-drafts/draft-camarillo-sip-body-handling-01.txt >>>>>> >>>>>> >>>>>> The slides discuss all the open issues that have been brought up in >>>>>> the list in the last months. >>>>>> >>>>>> Comments are welcome. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Gonzalo >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP Protocol >>>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>>> Use sipping@ietf.org for new developments on the application of sip >>>>>> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 09:15:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBsKJ-0006jK-Nr; Fri, 20 Jul 2007 09:15:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBsKI-0006jF-Ek for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 09:15:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBsKI-0006hP-4X for sip@ietf.org; Fri, 20 Jul 2007 09:15:22 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBsKG-0006nV-RB for sip@ietf.org; Fri, 20 Jul 2007 09:15:22 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6KDEgOx007471 for ; Fri, 20 Jul 2007 08:15:15 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 08:15:15 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 15:15:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Jul 2007 15:15:10 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001473844@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP WG status Thread-Index: AcfK0AAM0wnr2G9lRXurgDxoteKRZQ== From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 20 Jul 2007 13:15:12.0434 (UTC) FILETIME=[0121A920:01C7CAD0] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Subject: [Sip] SIP WG status X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is to give an overview of the current work in the SIP WG Regards Keith Documents published since IETF#68 =3D 2 ------------------------------------- draft-ietf-sip-mib-12 as RFC 4780 (Proposed standard) (Thanks to Kevin Lingle, Jean-Francois Mule, Joon Maeng, Dave Walker) draft-ietf-sip-connected-identity-05 (Proposed standard) as RFC 4916 (Thanks to John Elwell) Documents in RFC editor's queue =3D none -------------------------------------- Documents now with IESG =3D 11 ---------------------------- draft-ietf-sip-e2m-sec-06 (Proposed standard) Dean Willis is document shepherd=20 IESG last call completed 14th May 2007. No last call comments. Problems with proposed standard status Current status: Waiting for AD Go ahead draft-ietf-sip-fork-loop-fix-05 (Proposed standard) Keith Drage is document shepherd IESG last call completed 14th May 2007.=20 No last call comments. Security directorate review identified one comment, and one open comment exists on SIP list. Will be discussing at forthcoming meeting Current status: Waiting for AD Go ahead:: Revised ID needed draft-ietf-sip-acr-code-05 (Proposed standard) Dean Willis is document shepherd IESG last call initiated 6th July 2007 to complete 19th July 2007. Currently in state: Approved-announcement to be sent :: Point Raised - writeup needed. draft-ietf-sip-answermode-02 (Proposed standard) Keith Drage is document shepherd IESG last call initiated 10th July 2007 to complete 5th August 2007. Currently in state: In last call. draft-ietf-sip-gruu-14 (Proposed standard) Keith Drage is document shepherd IESG last call initiated 2nd July 2007 to complete 16th July 2007 Currently in state: IESG evaluation. draft-ietf-sip-multiple-refer-01 (Proposed standard) Keith Drage is document shepherd Currently in publication requested - external party, waiting on publication request for draft-ietf-sip-consent-framework draft-ietf-sip-uri-list-message-01 (Proposed standard) Keith Drage is document shepherd Currently in publication requested - external party, waiting on publication request for draft-ietf-sip-consent-framework draft-ietf-sip-uri-list-conferencing-01 (Proposed standard) Keith Drage is document shepherd Currently in publication requested - external party, waiting on publication request for draft-ietf-sip-consent-framework draft-ietf-sip-uri-list-subscribe-01 (Proposed standard) Keith Drage is document shepherd Currently in publication requested - external party, waiting on publication request for draft-ietf-sip-consent-framework draft-ietf-sip-consent-framework-02 (Proposed standard) Keith Drage is document shepherd Publication requested 13th July 2007 Currently in state: Publication requested draft-ietf-sip-ice-option-tag-02 (Proposed standard) Keith Drage is PROTO document shepherd Publication requested 17th July 2007 Currently in state: AD evaluation Documents completed last call awaiting submission to IESG =3D 1 ------------------------------------------------------------- draft-ietf-sip-certs-04 (Proposed standard) Dean Willis is document shepherd Milestone for sending to IESG is June 2007 Token currently with author: waiting on one open issue before new version and submission Documents in WGLC =3D 5 --------------------- draft-ietf-sip-connect-reuse-07 Candidate: Proposed standard Milestone to IESG August 2007 WGLC began 26th October 2005 Has some form of dependency on=20 draft-gurbani-sip-domain-certs-03=20 Alternate proposal: draft-rosenberg-sip-outbound-discovery-mid-dialog-00 Currently WG chairs and authors evaluating what we need in the roadmap here Direction forward? draft-ietf-sip-location-conveyance-08=20 Candidate: Proposed standard Milestone for submission to IESG is July 2007 Review team assembled: Authors, WG chairs, Shida Schubert, Joszef Varga, Henning Schulzrinne, Richard Barnes, Hannes Tschofenig WGLC initiated 4th March 2007 to complete 2nd April 2007. WGLC also issued in GEOPRIV WG See http://www.softarmor.com/sipwg/reviews/location-conveyance/index.html for current status of review. New version (-08) issued but still working WGLC comments Keith Drage is PROTO document shepherd draft-ietf-sip-session-policy-framework-01=20 Candidate: Proposed standard SIPPING WG review initiated 4th August 2006 to complete 25th August 2006 Transferred from SIPPING group because contains elements RFC 3427 says must be done by SIP Related documents in SIPPING: draft-ietf-sipping-policy-package-03=20 draft-ietf-sipping-media-policy-dataset-03 No major WGLC comments - document to be submitted when revised draft available Keith Drage is PROTO document shepherd Milestone for submission to IESG September 2007 draft-ietf-sip-sips-05=20 Candidate: Proposed standard Milestone for WGLC June 2007 WGLC initiated 29th June 2007 to complete 16th July 2007 Dean Willis is PROTO document shepherd Milestone for submission to IESG September 2007 draft-ietf-sip-outbound-10 Candidate: Proposed standard Milestone for WGLC is March 2007 WGLC initiated 9th July 2007 to complete 6th August 2007 Milestone for sending to IESG is June 2007 Review team to supplement WGLC. Review team so far: Authors, WG chairs, Jonathan Rosenberg, Fredrick Thulin, Kevin Johns, Christer Holmberg, AC Mahendran, Alan Hawrylyshen, Byron Campen, Derek McDonald, EKR, Nils Ohlmeier, Francois Audet Dean Willis is PROTO document shepherd WG documents still being developed =3D 8 -------------------------------------- draft-ietf-sip-hop-limit-diagnostics-03 Candidate: Proposed standard Milestone for WGLC is July 2007 Milestone for submission to IESG is November 2007 Scope of charter item is more general than hop limit diagnostics Key issue is size of response when it has to traverse UDP transports. Editor has procedures for reducing size of response body - does this render the mechanism of limited use if this occurs Issue has resulted in generation of: draft-gurbani-sip-large-udp-response-00=20 draft-petithuguenin-sip-fragmentation-responses-02 Should document go forward as is? Draft expired and removed from drafts directory - where next - WG polled draft-ietf-sip-sec-flows-01 Candidate: Informational Milestone for WGLC is July 2007 Milestone for submission to IESG is September 2007 To a certain extent dependent on resolution of ideas in (and therefore waiting on them): draft-ietf-sip-sips-02 =20 draft-gurbani-sip-domain-certs-04=20 Draft expired and removed from drafts directory=20 draft-ietf-sip-saml-02 Candidate: Proposed standard Milestone for WGLC is September 2007 Milestone for submission to IESG is December 2007 draft-ietf-sip-hitchhikers-guide-03 Candidate: Informational Milestone for WGLC December 2007 Milestone for submission to IESG December 2007 See also: draft-sinnreich-sip-tools-01 draft-ietf-sip-xcap-config-00=20 Candidate: proposed standard Milestone for WGLC July 2007 Milestone for submission to IESG December 2007 Document transferred from SIPPING because of potential need for new response code Related documents in SIPPING draft-ietf-sipping-config-framework-11 draft-petrie-sipping-identity-dataset-01=20 draft-petrie-sipping-profile-datasets-04=20 draft-petrie-sipping-sip-dataset-02=20 draft-petrie-sipping-voip-features-dataset-01=20 See also draft-petrie-sip-event-param-err-00.txt Waiting on SIPPING rewrite of draft-ietf-sipping-config-framework OMA liaison - possible interaction with draft-ietf-simple-xcap-diff and draft-urpalainen-sip-xcap-diff-event-01 draft-rosenberg-sip-ua-loose-route-00=20 Agreed as WG item (subject to AD) at IETF#67 Candidate: proposed standard December 2007: Delivering request-URI and parameters to UAS via proxy to WGLC February 2008: Delivering request-URI and parameters to UAS via proxy to IESG (PS) Author to submit sip-00 version draft-ietf-sip-subnot-etags-00 Agreed as WG item (subject to AD) at IETF#67 Candidate: proposed standard September 2007 -- Extension for use of etags in conditional notification to WGLC December 2007 -- Extension for use in etags in conditional notification to IESG (PS) draft-ietf-sip-record-route-fix-00 Essential correction? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 09:23:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBsRm-0004ps-0y; Fri, 20 Jul 2007 09:23:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBsRk-0004pm-2U for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 09:23:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBsRj-0004pe-Nz for sip@ietf.org; Fri, 20 Jul 2007 09:23:03 -0400 Received: from vms040pub.verizon.net ([206.46.252.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBsRj-0002Gw-6E for sip@ietf.org; Fri, 20 Jul 2007 09:23:03 -0400 Received: from [192.168.1.2] ([72.93.110.237]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JLH004ZMBTW12Y8@vms040.mailsrvcs.net> for sip@ietf.org; Fri, 20 Jul 2007 08:22:45 -0500 (CDT) Date: Fri, 20 Jul 2007 09:22:37 -0400 From: David Robbins Subject: Re: [Sip] RFC3891 (Replaces header) discrepancies In-reply-to: <0D5F89FAC29E2C41B98A6A762007F5D0205CBC@GBNTHT12009MSX.gb002.siemens.net> To: "Elwell, John" Message-id: MIME-version: 1.0 (Apple Message framework v752.3) X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7bit References: <0CED449E95A92A42991EB71B778C17BF059AA475@TSMAIL2.ad.tri.sbc.com> <200707191747.l6JHlQqL009062@dragon.ariadne.com> <0D5F89FAC29E2C41B98A6A762007F5D0205CBC@GBNTHT12009MSX.gb002.siemens.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There are some existing SIP server implementations that support REFER/ Replaces in the situation that James describes. It only works, though, if you *know* that there is exactly one dialog involved in the call -- i.e. if you *know* that no forking has occurred. Sending REFER/Replaces to complete a transfer before the transfer target has answered the call is understandably seen as desirable, because it allows the transferor to entirely remove itself from the call at the time of the transfer. But for the reasons John and Dale have noted, it's not as simple as that. The safe, RFC 3892-compliant way to handle this transfer is for the transferor to continue managing the two dialogs (transferee and transfer target) until the transfer target dialog has become confirmed, at which time the REFER is performed. The transferor UA can do this "in the background" -- the device is immediately available to the user for initiating or receiving a new call, even though the UA is waiting for the transfer target to answer. I've had to explain this a number of times to people who don't recognize how forking makes SIP different from traditional switched telephone signaling. They tend to build things without recognizing the possibility of forking. On Jul 20, 2007, at 4:49 AM, Elwell, John wrote: > In addition to what Dale has said, consider the case where call2 has > been forked to several destinations, 2a, 2b, 2c... To populate the > Replaces header field and the Refer-To URI, the sender of the REFER > request would need to pick one of these arbitrarily, say 2b. So > suppose > the REFER request were sent and dereferenced, resulting in an INVITE > request with Replaces header field arriving at 2b. What if call2 is > then > answered by 2a (or has already been answered by 2a while this > signalling > is taking place)? I don't think the intended operation of attended > transfer would then be realised. So basically, I don't think the > authors > of RFC 3891 saw any solutions to problems of this nature, and hence > the > restriction. > > John > >> -----Original Message----- >> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] >> Sent: 19 July 2007 18:47 >> To: sip@ietf.org >> Subject: Re: [Sip] RFC3891 (Replaces header) discrepancies >> >> >> From: "Jackson, James" >> >> Consider an attended transfer in which call1 is >> established between a >> transferee and a transferor. The transferor creates a new >> call2 towards >> transfer target. While this call is still alerting (early >> dialog), it >> sends a REFER on call1 with a Replaces header that >> references call2. In >> this case, the Replaces header attempts to replace an >> early dialog which >> was "terminated" by the target. >> >> That is not allowed by RFC 3891. But suppose it was allowed. >> Further >> suppose that the transfer target rings for another 90 seconds >> (sending >> an additional 180) and then the proxy that manages the transfer >> target >> cancels the call, causing the transfer target to send a 487. Who >> receives the 180 and 487? >> >> Dale >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 10:36:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBtan-00025p-R8; Fri, 20 Jul 2007 10:36:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBtam-00025h-HY for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 10:36:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBtam-00025Z-7z for sip@ietf.org; Fri, 20 Jul 2007 10:36:28 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBtak-0000Ed-R1 for sip@ietf.org; Fri, 20 Jul 2007 10:36:28 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JLH00C5DF8AG3@siemenscomms.co.uk> for sip@ietf.org; Fri, 20 Jul 2007 15:36:10 +0100 (BST) Date: Fri, 20 Jul 2007 15:36:24 +0100 From: "Elwell, John" In-reply-to: <200707191003.l6JA3TVe010387@imf.m.ecl.ntt.co.jp> To: Mayumi Munakata , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0205D5D@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: Comments on privacy-guidelines-00 Thread-Index: AcfJ7Ezc/PKmR+0mSPC81nxPJBVtvwA6F70Q Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <200707191003.l6JA3TVe010387@imf.m.ecl.ntt.co.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Subject: [Sip] Comments on privacy-guidelines-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Mayumi, I have looked through the privacy-guidelines document and have the following comments. 1. I was not aware of TISPAN use of priv-values other than "id". This does indeed give greater justification for this draft, but I would recommend you seek review from a couple of TISPAN experts. 2. Should this in fact be targeted as a BCP? 3. There seems to be no mention of impact on event packages whose notifications might convey information that has been anonymized or removed. I am thinking in particular about Call-Id and the Dialog event package, where an anonymizer would need to intervene. Of course, in this particular case, problems can be avoided by not authorizing subscription - I don't know whether this is a good enough solution. 4. The Join header field is subject to the same issues as Replaces and Target-Dialog. Otherwise it looks to be in good shape. John > -----Original Message----- > From: Mayumi Munakata [mailto:munakata.mayumi@lab.ntt.co.jp] > Sent: 19 July 2007 11:03 > To: Elwell, John > Cc: shida@ntt-at.com; ohba.takumi@lab.ntt.co.jp > Subject: Re: draft-munakata-sip-privacy-new/guideline > > John, > > Thank you for the comments for the privacy drafts. > See inline. > > > [JRE] I guess the question we have to ask is whether there are > > substantical interoperability problems with RFC 3323. As > the only value > > that seems to be used in practice is 'id', rules are fairly > > straightforward. > > TISPAN specs are actually using other priv-values such as > 'user' and 'header'. An interoperability problem could > occur because of different interpretations of priv-values. > > > One concern, however, is with 'history'. I don't know > whether this is > > implemented in practice. RFC 4244 allows a proxy to insert > this value. > > So whilst privacy-new defines a new way for UAs to ensure > privacy and > > should in the longer term lead to a move away from the > Privacy header > > field (depending on what is used for the privacy flag), > what will happen > > to proxy use of Privacy: history? > > The privacy flag to be defined in the privacy-new draft > will be a request for proxies to delete History-Info headers > on the edge of Trust Domain. > However, as you say, 'history' privacy is usually requested > by a proxy for the purpose of topology hiding. > The "privacy" in this new mechanism means the "user-privacy" > so the "network-privacy" (topology hiding) may be out of scope. > > Thanks, > Mayumi > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 10:38:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBtd4-0003lD-RQ; Fri, 20 Jul 2007 10:38:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBtd2-0003iS-KY for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 10:38:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBtd2-0003iK-9F for sip@ietf.org; Fri, 20 Jul 2007 10:38:48 -0400 Received: from ext-sendmail1.labs.att.com ([205.173.58.19] helo=sendmail1.labs.att.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBtd1-0004P1-KL for sip@ietf.org; Fri, 20 Jul 2007 10:38:48 -0400 Received: from labs.att.com (internet-austin-webdmz.labs.sbc.com [144.60.9.139]) by sendmail1.labs.att.com (8.14.1/8.13.1) with ESMTP id l6KEcfQI032527; Fri, 20 Jul 2007 09:38:41 -0500 Received: from TSMAIL.ad.tri.sbc.com (tsmail [144.60.55.228]) by labs.att.com (8.14.1/8.13.1) with ESMTP id l6KEcaQR019722; Fri, 20 Jul 2007 09:38:36 -0500 Received: from TSMAIL2.ad.tri.sbc.com ([144.60.55.226]) by TSMAIL.ad.tri.sbc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 09:38:35 -0500 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 Subject: RE: [Sip] RFC3891 (Replaces header) discrepancies Date: Fri, 20 Jul 2007 09:38:35 -0500 Message-ID: <0CED449E95A92A42991EB71B778C17BF059D6F27@TSMAIL2.ad.tri.sbc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RFC3891 (Replaces header) discrepancies Thread-Index: AcfK0R3puYn0YAgEQiaegzzMvCGK4QACbJYA References: <0CED449E95A92A42991EB71B778C17BF059AA475@TSMAIL2.ad.tri.sbc.com><200707191747.l6JHlQqL009062@dragon.ariadne.com><0D5F89FAC29E2C41B98A6A762007F5D0205CBC@GBNTHT12009MSX.gb002.siemens.net> From: "Jackson, James" To: "David Robbins" , "Elwell, John" X-OriginalArrivalTime: 20 Jul 2007 14:38:35.0941 (UTC) FILETIME=[A7743D50:01C7CADB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks to everyone for the clarification on this ! James -----Original Message----- From: David Robbins [mailto:robbins.dave@verizon.net]=20 Sent: Friday, July 20, 2007 8:23 AM To: Elwell, John Cc: sip@ietf.org Subject: Re: [Sip] RFC3891 (Replaces header) discrepancies There are some existing SIP server implementations that support REFER/=20 Replaces in the situation that James describes. It only works, =20 though, if you *know* that there is exactly one dialog involved in =20 the call -- i.e. if you *know* that no forking has occurred. Sending REFER/Replaces to complete a transfer before the transfer =20 target has answered the call is understandably seen as desirable, =20 because it allows the transferor to entirely remove itself from the =20 call at the time of the transfer. But for the reasons John and Dale =20 have noted, it's not as simple as that. The safe, RFC 3892-compliant =20 way to handle this transfer is for the transferor to continue =20 managing the two dialogs (transferee and transfer target) until the =20 transfer target dialog has become confirmed, at which time the REFER =20 is performed. The transferor UA can do this "in the background" -- =20 the device is immediately available to the user for initiating or =20 receiving a new call, even though the UA is waiting for the transfer =20 target to answer. I've had to explain this a number of times to people who don't =20 recognize how forking makes SIP different from traditional switched =20 telephone signaling. They tend to build things without recognizing =20 the possibility of forking. On Jul 20, 2007, at 4:49 AM, Elwell, John wrote: > In addition to what Dale has said, consider the case where call2 has > been forked to several destinations, 2a, 2b, 2c... To populate the > Replaces header field and the Refer-To URI, the sender of the REFER > request would need to pick one of these arbitrarily, say 2b. So =20 > suppose > the REFER request were sent and dereferenced, resulting in an INVITE > request with Replaces header field arriving at 2b. What if call2 is =20 > then > answered by 2a (or has already been answered by 2a while this =20 > signalling > is taking place)? I don't think the intended operation of attended > transfer would then be realised. So basically, I don't think the =20 > authors > of RFC 3891 saw any solutions to problems of this nature, and hence =20 > the > restriction. > > John > >> -----Original Message----- >> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] >> Sent: 19 July 2007 18:47 >> To: sip@ietf.org >> Subject: Re: [Sip] RFC3891 (Replaces header) discrepancies >> >> >> From: "Jackson, James" >> >> Consider an attended transfer in which call1 is >> established between a >> transferee and a transferor. The transferor creates a new >> call2 towards >> transfer target. While this call is still alerting (early >> dialog), it >> sends a REFER on call1 with a Replaces header that >> references call2. In >> this case, the Replaces header attempts to replace an >> early dialog which >> was "terminated" by the target. >> >> That is not allowed by RFC 3891. But suppose it was allowed. =20 >> Further >> suppose that the transfer target rings for another 90 seconds =20 >> (sending >> an additional 180) and then the proxy that manages the transfer =20 >> target >> cancels the call, causing the transfer target to send a 487. Who >> receives the 180 and 487? >> >> Dale >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 10:57:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBtvZ-0002ap-6d; Fri, 20 Jul 2007 10:57:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBtvX-0002ak-Ot for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 10:57:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBtvX-0002Yd-E6 for sip@ietf.org; Fri, 20 Jul 2007 10:57:55 -0400 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBtvX-0004rb-2s for sip@ietf.org; Fri, 20 Jul 2007 10:57:55 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc12) with ESMTP id <2007072014575401200mjae5e>; Fri, 20 Jul 2007 14:57:54 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6KEvs8t005019 for ; Fri, 20 Jul 2007 10:57:54 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6KEvsbB005015; Fri, 20 Jul 2007 10:57:54 -0400 Date: Fri, 20 Jul 2007 10:57:54 -0400 Message-Id: <200707201457.l6KEvsbB005015@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (robbins.dave@verizon.net) Subject: Re: [Sip] RFC3891 (Replaces header) discrepancies References: <0CED449E95A92A42991EB71B778C17BF059AA475@TSMAIL2.ad.tri.sbc.com> <200707191747.l6JHlQqL009062@dragon.ariadne.com> <0D5F89FAC29E2C41B98A6A762007F5D0205CBC@GBNTHT12009MSX.gb002.siemens.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: David Robbins Thanks for the explanation! The safe, RFC 3892-compliant way to handle this transfer is for the transferor to continue managing the two dialogs (transferee and transfer target) until the transfer target dialog has become confirmed, at which time the REFER is performed. The transferor UA can do this "in the background" -- the device is immediately available to the user for initiating or receiving a new call, even though the UA is waiting for the transfer target to answer. I know the (now obsolete) Xpressa phone from Pingtel does that. I expect many modern phones do so also. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 11:17:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBuEP-0001HU-Uh; Fri, 20 Jul 2007 11:17:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBuEN-0001FA-NG for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 11:17:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBuEN-0001Dg-D9 for sip@ietf.org; Fri, 20 Jul 2007 11:17:23 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBuEM-00018r-2V for sip@ietf.org; Fri, 20 Jul 2007 11:17:23 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6KFHE66087059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Jul 2007 10:17:14 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <5D1A7985295922448D5550C94DE2918001473844@DEEXC1U01.de.lucent.com> References: <5D1A7985295922448D5550C94DE2918001473844@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <4D9A420A-AEC7-4E9A-A8EB-89B2FB661C25@nostrum.com> From: Robert Sparks Subject: Re: [Sip] SIP WG status Date: Fri, 20 Jul 2007 10:17:10 -0500 To: "DRAGE, Keith \(Keith\)" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: -1.4 (-) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0144634677==" Errors-To: sip-bounces@ietf.org --===============0144634677== Content-Type: multipart/alternative; boundary=Apple-Mail-9-479000566 --Apple-Mail-9-479000566 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed At this point in time, I think yes. RjS On Jul 20, 2007, at 8:15 AM, DRAGE, Keith ((Keith)) wrote: > draft-ietf-sip-record-route-fix-00 > Essential correction? --Apple-Mail-9-479000566 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=US-ASCII
        At this point in time, I think yes.

        RjS

        On Jul 20, 2007, at 8:15 AM, DRAGE, Keith ((Keith)) wrote:

        draft-ietf-sip-record-route-fix-00

        Essential correction?


        --Apple-Mail-9-479000566-- --===============0144634677== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0144634677==-- From sip-bounces@ietf.org Fri Jul 20 11:41:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBubc-0004TE-Uv; Fri, 20 Jul 2007 11:41:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBubb-0004MK-Qh for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 11:41:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBubb-0004KH-Gb for sip@ietf.org; Fri, 20 Jul 2007 11:41:23 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBubZ-0001dj-Vd for sip@ietf.org; Fri, 20 Jul 2007 11:41:23 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l6KFexp08961; Fri, 20 Jul 2007 08:41:00 -0700 In-Reply-To: <008c01c7ca61$9953e880$0601a8c0@BEMBUSTER> References: <008c01c7ca61$9953e880$0601a8c0@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <70E59B0F-BD19-4F71-A679-15B7A4DFBCC9@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Fri, 20 Jul 2007 08:40:58 -0700 To: "Jeroen van Bemmel" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org Subject: [Sip] Re: draft-ietf-sip-outbound-10.txt : flow token construction X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 19, 2007, at 5:04 PM, Jeroen van Bemmel wrote: > Hi, > > A comment / clarification on outbound-10 section 5.3 Forwarding > requests, regarding flow token construction and incoming/outgoing > logic: > The text says to send a 430 (Flow Failed) "For connection-oriented > transports, if the flow no longer exists" (SHOULD) > > This can be read as saying that if the original TCP connection no > longer exists, a 430 should be sent. However, if the UAC somehow > lost its connection and recovered, there would be a new TCP > connection with (likely) a different ephemeral port at the UAC. There is a timing issue here. Two things could happen based on timing. 1) If the UA hasn't noticed that its original TCP connection failed, or it noticed but the REGISTER for its new flow has not been received or processed yet, then edge proxy (if any) should send a 430. If there is another active flow, the authoritative proxy can try that flow. The failed flow does not 2) The UA sent a new REGISTER to replace its original (failed) flow and that request has been processed. The original flow would never be attempted. In both cases, the best possible thing that could happen will happen. > For the proposed flow token algorithm, this would cause the > described incoming/outgoing logic to fail (since the token no > longer matches an incoming flow from the UAC). Moreover, for > requests in the other direction ("incoming") the proxy would not be > able to locate the new flow, and send a 430 where it could have > done better. > > Two thoughts: > 1. To determine if a (non-REGISTER) request is incoming/outgoing, > it might be easier to simply say: 1 Via header --> outgoing, else > incoming. In a proxy with a colocated UA (ex: the registration package or a presence server), the proxy can emit "incoming" requests with 1 Via header. > There are other options, the Edge proxy could check the request URI > for a Contact URI it has seen in REGISTER before. It could also be > based on Service-Route and/or Path. This would require the Edge proxy to mirror registration state. We had a requirement that outbound should work without requiring this state mirroring. > Perhaps this draft need not explain all details, but it currently > only describes logic for mid-dialog requests, and appears to fail > in the above described case of TCP connection loss. What you are describing is a mid-dialog flow switchover. This was so controversial that we made this explicitly out of the scope of this document. The document does not prevent an edge proxy from doing this, but it doesn't describe how to do it either. > 2. An alternative implementation could be to maintain a mapping of > Contact address ( IP/host+port ) to flow, which is updated each > time a REGISTER 200 OK comes by. If the UAC is using the same > Contact URIs as in its REGISTER (or a GRUU rewritten by the home > proxy), there is no need for a flow token at all: the Edge proxy > can use (IP/host+port part of) the request URI as an (hash) index > into the flow table (for incoming requests). I'm not understanding where you propose to maintain this mapping. If you want the edge proxy to keep per-flow state, I'm afraid we had a strong consensus not to add mechanism that requires that approach. If the UAC uses a GRUU in the Contact header, the edge proxy may not need to Record-Route. However, that is a topic for either the GRUU spec or another spec on mid-dialog Record-Routing to cover. > There are many other designs possible. Main point is that the > stateless flow token approach described seems suboptimal in case of > TCP connection loss (home proxy may be able to recover if the UAC > used 2 or more flows, but if all were lost and the backup edge > proxy also implemented this algorithm, ongoing dialogs would be lost) Yes. And we decided for this document that losing those calls was acceptable for this document. Other specification work can take up that challenge, otherwise we will never make forward progress. thanks, -rohan > Regards, > Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 11:53:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBunX-0004ps-Ie; Fri, 20 Jul 2007 11:53:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBunU-0004cY-QK for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 11:53:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBunU-0004aG-Co for sip@ietf.org; Fri, 20 Jul 2007 11:53:40 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBunT-00064U-VC for sip@ietf.org; Fri, 20 Jul 2007 11:53:40 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6KFrYaa089021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jul 2007 10:53:34 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <46A0DA86.5070503@nostrum.com> Date: Fri, 20 Jul 2007 10:53:42 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] Outbound: Feature Tag (Ab)Use References: <46928F5F.3080502@softarmor.com> <469FFC30.2090309@nostrum.com> <009b01c7ca63$08fed540$0601a8c0@BEMBUSTER> In-Reply-To: <009b01c7ca63$08fed540$0601a8c0@BEMBUSTER> 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-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org, Rohan Mahy , Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 7/19/07 7:15 PM, Jeroen van Bemmel wrote: > Good points, some nits inline Good nits. Some responses inline. >> >> Why are we doing this so very, very wrong? It's almost as if we've >> gone out of our way to violate both the spirit AND the law of feature >> tag handling in as many ways as possible. Most annoyingly, we get >> exactly the desired behavior if we just do things the way they're >> described in >> 3261. To wit: >> >> * If a client supports outbound, it includes "Supported: outbound" >> in all REGISTER requests, regardless of whether the specific >> request makes use of that extension. >> > > [jvb] this would probably be a MUST, right? Well, we're not strengthening 3261 -- so I believe it's a SHOULD in all requests, and a MUST in REGISTERs that make use of the extension. >> >> * The registrar includes "Require: outbound" in any REGISTER >> requests to which outbound behavior is being applied. > > > [jvb] you mean responses Right. >> * The registrar is free to include "Supported: outbound" in any >> responses it generates -- and it means exactly what 3261 intends >> it to mean: that outbound is *supported*, but is not being >> applied to the response in question. > > > [jvb] is not _necessarily_ being applied, it depends on presence of > Require: outbound (only). Guess this is a MAY, right? I believe you are correct on both counts. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 12:06:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBuzw-0000MH-8G; Fri, 20 Jul 2007 12:06:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBuzu-0000MC-U3 for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 12:06:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBuzu-0000Lz-KM for sip@ietf.org; Fri, 20 Jul 2007 12:06:30 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBuzt-0002DX-7I for sip@ietf.org; Fri, 20 Jul 2007 12:06:30 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l6KG6Op09782; Fri, 20 Jul 2007 09:06:24 -0700 In-Reply-To: <469FFC30.2090309@nostrum.com> References: <46928F5F.3080502@softarmor.com> <469FFC30.2090309@nostrum.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Fri, 20 Jul 2007 09:06:23 -0700 To: Adam Roach X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: sip@ietf.org, Rohan Mahy , Cullen Jennings Subject: [Sip] Re: Outbound: Feature Tag (Ab)Use X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Adam, What can I say but "You're right". Unless there is some fundamental objection, I will make this change pronto to my working copy. I believe this also means I can remove the 'ob' parameter from the UAC's Contact header. thanks, -rohan On Jul 19, 2007, at 5:05 PM, Adam Roach wrote: > At the risk of further bloodying the corpse of this poor horse, I > still think the usage of feature tags in outbound is way, way off > in terms of the semantics described in 3261. > > Reviewing the way this is defined to work in SIP: > > 3261:8.1.1.9: >> If the UAC supports extensions to SIP that can be applied by the >> server to the response, the UAC SHOULD include a Supported header >> field in the request listing the option tags (Section 19.2) for >> those >> extensions. > > 3261:8.2.4: > >> A UAS that wishes to apply some extension when generating the >> response MUST NOT do so unless support for that extension is >> indicated in the Supported header field in the request. If the >> desired extension is not supported, the server SHOULD rely only on >> baseline SIP and any other extensions supported by the client. >> ... >> Any extensions applied to a non-421 response MUST be listed in a >> Require header field included in the response. Of course, the >> server >> MUST NOT apply extensions not listed in the Supported header >> field in >> the request. As a result of this, the Require header field in a >> response will only ever contain option tags defined in standards- >> track RFCs. > > There are five normative statements in the text I quote above. The > mechanism described in the outbound draft actually manages to > violate _all_ _five_ of them. > > The registrar infers *both* support for outbound *and* a request to > apply the outbound extension by the presence of the "reg-id" > Contact header field parameter. In particular, the client is > apparently NOT supposed to send a "Supported: outbound" header > field. This appears to contravene the normative statement in > 8.1.1.9 cited above. > > The registrar indicates that outbound procedures are being applied > by including a "Supported" header field in the REGISTER response. > (In 3261, "Supported" in a _response_ indicates that an extension > _can_ _be_ supported in a future request, NOT that it is being > applied to the current one -- sections 11 and 13.3.1.4 both talk > about Supported usage in responses.) > > In other words, the registrar (acting as a UAS) is applying an > extension when generating a response without that extension being > indicated in the "Supported" header field in the request. Again, > this directly contravenes two normative statements from section > 8.2.4 (cited above). > > The registrar is further applying an extension to a non-421 > response that is not listed in a "Require" header field, in > violation of the remaining normative statement in the portion of > section 8.2.4 cited above. > > Why are we doing this so very, very wrong? It's almost as if we've > gone out of our way to violate both the spirit AND the law of > feature tag handling in as many ways as possible. Most annoyingly, > we get exactly the desired behavior if we just do things the way > they're described in 3261. To wit: > > * If a client supports outbound, it includes "Supported: outbound" > in all REGISTER requests, regardless of whether the specific > request makes use of that extension. > > * The client adds a "reg-id" header field parameter to any Contacts > to which outbound processing is to apply. > > * The registrar includes "Require: outbound" in any REGISTER > requests to which outbound behavior is being applied. > > * The registrar is free to include "Supported: outbound" in any > responses it generates -- and it means exactly what 3261 intends > it to mean: that outbound is *supported*, but is not being > applied > to the response in question. > > /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 12:26:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBvJd-0001AP-H7; Fri, 20 Jul 2007 12:26:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBvJc-0001AK-Oj for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 12:26:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBvJc-0001AC-F7 for sip@ietf.org; Fri, 20 Jul 2007 12:26:52 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBvJb-0002Y8-1e for sip@ietf.org; Fri, 20 Jul 2007 12:26:52 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l6KGQjp10185; Fri, 20 Jul 2007 09:26:45 -0700 In-Reply-To: References: <46928F5F.3080502@softarmor.com> <469FFC30.2090309@nostrum.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8AA4964D-1BA4-4E5E-8189-02A1032AD389@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Fri, 20 Jul 2007 09:26:44 -0700 To: Rohan Mahy X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: sip@ietf.org, Cullen Jennings , Adam Roach Subject: [Sip] Re: Outbound: Feature Tag (Ab)Use X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 20, 2007, at 9:06 AM, Rohan Mahy wrote: > Hi Adam, > > What can I say but "You're right". Unless there is some > fundamental objection, I will make this change pronto to my working > copy. > > I believe this also means I can remove the 'ob' parameter from the > UAC's Contact header. On further thought, I realized that the 'ob' parameter is still needed, since it reflects whether the UAC is sending over a flow for which out bound processing is being applied, as opposed to merely indicating the UAC is capable of requesting outbound. thanks, -rohan > thanks, > -rohan > > > On Jul 19, 2007, at 5:05 PM, Adam Roach wrote: >> At the risk of further bloodying the corpse of this poor horse, I >> still think the usage of feature tags in outbound is way, way off >> in terms of the semantics described in 3261. >> >> Reviewing the way this is defined to work in SIP: >> >> 3261:8.1.1.9: >>> If the UAC supports extensions to SIP that can be applied by the >>> server to the response, the UAC SHOULD include a Supported header >>> field in the request listing the option tags (Section 19.2) >>> for those >>> extensions. >> >> 3261:8.2.4: >> >>> A UAS that wishes to apply some extension when generating the >>> response MUST NOT do so unless support for that extension is >>> indicated in the Supported header field in the request. If the >>> desired extension is not supported, the server SHOULD rely >>> only on >>> baseline SIP and any other extensions supported by the client. >>> ... >>> Any extensions applied to a non-421 response MUST be listed in a >>> Require header field included in the response. Of course, the >>> server >>> MUST NOT apply extensions not listed in the Supported header >>> field in >>> the request. As a result of this, the Require header field in a >>> response will only ever contain option tags defined in standards- >>> track RFCs. >> >> There are five normative statements in the text I quote above. The >> mechanism described in the outbound draft actually manages to >> violate _all_ _five_ of them. >> >> The registrar infers *both* support for outbound *and* a request >> to apply the outbound extension by the presence of the "reg-id" >> Contact header field parameter. In particular, the client is >> apparently NOT supposed to send a "Supported: outbound" header >> field. This appears to contravene the normative statement in >> 8.1.1.9 cited above. >> >> The registrar indicates that outbound procedures are being applied >> by including a "Supported" header field in the REGISTER response. >> (In 3261, "Supported" in a _response_ indicates that an extension >> _can_ _be_ supported in a future request, NOT that it is being >> applied to the current one -- sections 11 and 13.3.1.4 both talk >> about Supported usage in responses.) >> >> In other words, the registrar (acting as a UAS) is applying an >> extension when generating a response without that extension being >> indicated in the "Supported" header field in the request. Again, >> this directly contravenes two normative statements from section >> 8.2.4 (cited above). >> >> The registrar is further applying an extension to a non-421 >> response that is not listed in a "Require" header field, in >> violation of the remaining normative statement in the portion of >> section 8.2.4 cited above. >> >> Why are we doing this so very, very wrong? It's almost as if we've >> gone out of our way to violate both the spirit AND the law of >> feature tag handling in as many ways as possible. Most annoyingly, >> we get exactly the desired behavior if we just do things the way >> they're described in 3261. To wit: >> >> * If a client supports outbound, it includes "Supported: outbound" >> in all REGISTER requests, regardless of whether the specific >> request makes use of that extension. >> >> * The client adds a "reg-id" header field parameter to any >> Contacts >> to which outbound processing is to apply. >> >> * The registrar includes "Require: outbound" in any REGISTER >> requests to which outbound behavior is being applied. >> >> * The registrar is free to include "Supported: outbound" in any >> responses it generates -- and it means exactly what 3261 intends >> it to mean: that outbound is *supported*, but is not being >> applied >> to the response in question. >> >> /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 13:32:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwLT-0002mY-Kl; Fri, 20 Jul 2007 13:32:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBwLS-0002mS-77 for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 13:32:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwLR-0002mK-Tk for sip@ietf.org; Fri, 20 Jul 2007 13:32:49 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBwLR-0003gi-4i for sip@ietf.org; Fri, 20 Jul 2007 13:32:49 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6KHWec18479; Fri, 20 Jul 2007 17:32:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Jul 2007 12:32:35 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF115AF631@zrc2hxm0.corp.nortel.com> In-reply-to: <08333B74-4516-4BF7-94EB-6559A6AF8AFF@ekabal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question about keep-alives in Outbound draft Thread-Index: AcfK6d+ioUgNAdGbQXO913XRWc940gABKJlQ References: <6FC4416DDE56C44DA0AEE67BC7CA437115AA5DDD@zrc2hxm2.corp.nortel.com> <08333B74-4516-4BF7-94EB-6559A6AF8AFF@ekabal.com> From: "Francois Audet" To: "Rohan Mahy" , "Brian Stucker" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: Cullen Jennings , sip@ietf.org Subject: [Sip] RE: Question about keep-alives in Outbound draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Moving to proper mailing list (i.e., sip). Rohan, I also think that the draft could be a little bit clearer about where the CRLF is sent, and where it stops, but I think it's a consequence of how section 3 is structured, and the terms we use. If we made the concept of "Outbound proxy" a bit clearer in the document, and use it throughout, and specifically say that the CRLF is sent to the outbound proxy,=20 it would read much better.=20 Section 3 and above don't even use the term "outbound proxy" and instead uses euphemisms such as "edge proxy", "proxy", "registrar", "host" and "server". Furthermore, it starts with a special case (co-located Registrar and Proxy), and finishes with the the general case (outbound proxy is separate from the Registrar). I would suggest the following editorial changes: - Move section 3.4 to where 3.2 currently is. - Remove the word "Proxy" in the box that says "Registrar/Proxy" (i.e.,=20 it should just say "Registrar". There is no need for having a proxy necessarily co-located in the Registrar, and it's immaterial to this draft. - The box that say "Edge1" and "Edge2" should really be labelled=20 "Outbound Proxy 1" and "Oubound Proxy 2". The text should also use the term "outbound proxy" instead of "edge proxy", and it should just explain that often this configuration is called=20 and "edge proxy". - In section 3.2 (which would now be 3.3), clarify that this is just a=20 special case of the outbound proxy and Registrar being co-located. Also use the term "outbound proxy" in the diagram and the text, as appropriate. - In section 3.3 (which would now be 3.4), clarify that the Host1 and Host2 are really the outbound proxy 1 and 2, in the diagram. - In section 3.5, use the term "outbound proxy" instead of server when talking about the entity receiving the ping and sending the pong. =20 - Section 5 should use the term "Outbound proxy" instead of "Edge proxy". - Section 5.4 is where we should say the "oubound proxy" does not=20 forward the keep alives. - Section 9 should use the terms "Primary outbound proxy" and "Secondary outbound proxy". Cheers > -----Original Message----- > From: Rohan Mahy [mailto:rohan@ekabal.com]=20 > Sent: Friday, July 20, 2007 09:20 > To: Stucker, Brian (RICH1:AR00) > Cc: Rohan Mahy; Cullen Jennings; sipping@ietf.org; Audet,=20 > Francois (SC100:3055) > Subject: Re: Question about keep-alives in Outbound draft >=20 >=20 > On Jul 19, 2007, at 9:50 PM, Brian Stucker wrote: >=20 > > Cullen/Rohan, > > > > I have a question about keep-alive behavior in the -10=20 > version of the=20 > > outbound draft. > > > > How far are keep-alives propagated along the flow created at=20 > > registration? > > > > The text seems a bit hazy on how far it is expected for a=20 > keep- alive=20 > > to be propagated along the flow. Section 8 has text in the last=20 > > paragraph on page 25 that seems to imply that STUN=20 > keep-alives go no=20 > > further than the edge proxy immediately adjacent to the=20 > client device.=20 > > Section > > 4.4.3 > > seems to also limit generation of STUN keep-alives to the=20 > User-Agent=20 > > only. >=20 > one-hop. one-hop only Mister Kamarov. >=20 > > Likewise, section 4.4.1 and 5.4 seem to limit the TCP CRLF=20 > response to=20 > > the first edge-proxy as well. >=20 > yes. >=20 > I don't think either of these statements is hazy. Can you=20 > propose a rewording? >=20 > > Inclusion of the keep-stun or keep-crlf parameters for a Path URI=20 > > inserted by an edge proxy or registrar outside of the one in the=20 > > outbound-proxy-set seems moot as earlier edge-proxies that don't=20 > > support these mechanisms would ostensibly drop the keep-alives. >=20 > if these parameters find their way into a URI handled by=20 > another proxy (instead of the UAC), they will be ignored (and=20 > no keepalives will be generated by the proxy). >=20 > > Further, you only show a NAT/FW between the first=20 > edge-proxy and the=20 > > User-Agent in the figure for section 3.4. >=20 > yes. that was part of our design assumptions. we had a hum=20 > on that about a year ago. We assume that there is a full SIP=20 > connectivity among any of the proxies and that anything=20 > necessary to make that work is taken care of. >=20 > > However, the spec never really > > says very clearly what should occur at the edge-proxy:=20 > should it check=20 > > for freshness of the next-hop towards the registrar or not,=20 > based upon=20 > > what it observed in the Path header coming back in the registration=20 > > response? >=20 > It says very clearly what to actually do and I hope it=20 > doesn't even hint that you should even begin to think about=20 > such a heinous thing as sending keepalives to the registrar=20 > from the EP. >=20 > > Is there a reason that edge-proxies are not expected to regenerate/=20 > > relay the appropriate keep-alive message to the next entry=20 > on the Path=20 > > vector? > > Not doing so means that some other mechanism must be=20 > employed to keep=20 > > bindings/pinholes open between the various edge-proxies and the=20 > > registrar proxy. >=20 > If that problem exists in your environment, it is completely=20 > out of the scope of outbound. The spec is about routing=20 > traffic over outbound-initiated flows from the UA. >=20 > > For instance, in IMS you can have a P-CSCF in the visited network=20 > > talking to an IBCF in the visited network that is connected=20 > to an IBCF=20 > > in the home network that finally terminates at the S-CSCF=20 > in the home=20 > > network of the user that is registering. A NAT/FW is likely=20 > to exist=20 > > between the UA and the visited P-CSCF as well as between=20 > the IBCF in=20 > > the visited network and the IBCF in the home network. >=20 > How do SIP messages make it today from a P-CSCF to an S-SCSF? >=20 > > Another possible example (I believe) would be in the case of p2psip=20 > > where you may have multiple hops between the client and the node=20 > > acting as a registrar for the DHT algorithm. Wouldn't you=20 > want to keep=20 > > the entire path to the node storing your contact information in the=20 > > DHT alive or is there some other property of the DHT algorithm that=20 > > ensures that this is always the case even though outbound=20 > only keeps=20 > > the last hop fresh? >=20 > p2psip has some unique requirements. I don't think outbound=20 > prevents p2psip from addressing their requirements, but they=20 > are certainly not the concerns that outbound intended to address. >=20 > thanks, > -rohan >=20 >=20 > > Regards, > > Brian >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 13:57:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwj2-0005S9-A3; Fri, 20 Jul 2007 13:57:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBwj1-0005S2-4W for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 13:57:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwj0-0005Ru-PU for sip@ietf.org; Fri, 20 Jul 2007 13:57:10 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBwiz-0008PH-If for sip@ietf.org; Fri, 20 Jul 2007 13:57:10 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l6KHurp12515; Fri, 20 Jul 2007 10:56:53 -0700 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF115AF631@zrc2hxm0.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437115AA5DDD@zrc2hxm2.corp.nortel.com> <08333B74-4516-4BF7-94EB-6559A6AF8AFF@ekabal.com> <1ECE0EB50388174790F9694F77522CCF115AF631@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4DF02533-B636-40AB-8957-2D791CC4C468@ekabal.com> Content-Transfer-Encoding: quoted-printable From: Rohan Mahy Date: Fri, 20 Jul 2007 10:56:51 -0700 To: "Francois Audet" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org, Brian Stucker Subject: [Sip] Re: Question about keep-alives in Outbound draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Fran=E7ois, We started off using the term outbound proxy in previous versions of =20 the draft and many people complained that the term did not have a =20 meaningful or useful definition. It was one of those "its what I =20 mean" definitions. I think the definitions of edge proxy, =20 authoritative proxy, registrar, and UAC are pretty tight. There =20 certainly might be some places where we say "host" or "client" or =20 "proxy" where we should be saying something more well defined, but if =20= so, I would like to change them to the correct terms, not to outbound =20= proxy". AFAIK, going back to outbound proxy will be a big step backwards for =20 the document. Also, the registrar and proxy together is the simplest =20= case to explain and I think it is still the most common topology. thanks, -rohan On Jul 20, 2007, at 10:32 AM, Francois Audet wrote: > Moving to proper mailing list (i.e., sip). > > Rohan, I also think that the draft could be a little bit clearer > about where the CRLF is sent, and where it stops, but I think it's a > consequence of how section 3 is structured, and the terms we use. > > If we made the concept of "Outbound proxy" a bit clearer in the > document, and > use it throughout, and specifically say that the CRLF is sent to the > outbound proxy, > it would read much better. > > Section 3 and above don't even use the term "outbound proxy" and =20 > instead > uses > euphemisms such as "edge proxy", "proxy", "registrar", "host" and > "server". > > Furthermore, it starts with a special case (co-located Registrar and > Proxy), > and finishes with the the general case (outbound proxy is separate > from the Registrar). > > I would suggest the following editorial changes: > > - Move section 3.4 to where 3.2 currently is. > > - Remove the word "Proxy" in the box that says "Registrar/Proxy" > (i.e., > it should just say "Registrar". There is no need for having a =20 > proxy > necessarily co-located in the Registrar, and it's immaterial to =20= > this > draft. > > - The box that say "Edge1" and "Edge2" should really be labelled > "Outbound Proxy 1" and "Oubound Proxy 2". The text should also > use the term "outbound proxy" instead of "edge proxy", and it > should just explain that often this configuration is called > and "edge proxy". > > - In section 3.2 (which would now be 3.3), clarify that this is just a > special case of the outbound proxy and Registrar being co-located. > Also use the term "outbound proxy" in the diagram and the text, as > appropriate. > > - In section 3.3 (which would now be 3.4), clarify that the Host1 and > Host2 are really the outbound proxy 1 and 2, in the diagram. > > - In section 3.5, use the term "outbound proxy" instead of server > when talking about the entity receiving the ping and sending the =20 > pong. > > - Section 5 should use the term "Outbound proxy" instead of "Edge > proxy". > > - Section 5.4 is where we should say the "oubound proxy" does not > forward the keep alives. > > - Section 9 should use the terms "Primary outbound proxy" and =20 > "Secondary > > outbound proxy". > > Cheers > >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan@ekabal.com] >> Sent: Friday, July 20, 2007 09:20 >> To: Stucker, Brian (RICH1:AR00) >> Cc: Rohan Mahy; Cullen Jennings; sipping@ietf.org; Audet, >> Francois (SC100:3055) >> Subject: Re: Question about keep-alives in Outbound draft >> >> >> On Jul 19, 2007, at 9:50 PM, Brian Stucker wrote: >> >>> Cullen/Rohan, >>> >>> I have a question about keep-alive behavior in the -10 >> version of the >>> outbound draft. >>> >>> How far are keep-alives propagated along the flow created at >>> registration? >>> >>> The text seems a bit hazy on how far it is expected for a >> keep- alive >>> to be propagated along the flow. Section 8 has text in the last >>> paragraph on page 25 that seems to imply that STUN >> keep-alives go no >>> further than the edge proxy immediately adjacent to the >> client device. >>> Section >>> 4.4.3 >>> seems to also limit generation of STUN keep-alives to the >> User-Agent >>> only. >> >> one-hop. one-hop only Mister Kamarov. >> >>> Likewise, section 4.4.1 and 5.4 seem to limit the TCP CRLF >> response to >>> the first edge-proxy as well. >> >> yes. >> >> I don't think either of these statements is hazy. Can you >> propose a rewording? >> >>> Inclusion of the keep-stun or keep-crlf parameters for a Path URI >>> inserted by an edge proxy or registrar outside of the one in the >>> outbound-proxy-set seems moot as earlier edge-proxies that don't >>> support these mechanisms would ostensibly drop the keep-alives. >> >> if these parameters find their way into a URI handled by >> another proxy (instead of the UAC), they will be ignored (and >> no keepalives will be generated by the proxy). >> >>> Further, you only show a NAT/FW between the first >> edge-proxy and the >>> User-Agent in the figure for section 3.4. >> >> yes. that was part of our design assumptions. we had a hum >> on that about a year ago. We assume that there is a full SIP >> connectivity among any of the proxies and that anything >> necessary to make that work is taken care of. >> >>> However, the spec never really >>> says very clearly what should occur at the edge-proxy: >> should it check >>> for freshness of the next-hop towards the registrar or not, >> based upon >>> what it observed in the Path header coming back in the registration >>> response? >> >> It says very clearly what to actually do and I hope it >> doesn't even hint that you should even begin to think about >> such a heinous thing as sending keepalives to the registrar >> from the EP. >> >>> Is there a reason that edge-proxies are not expected to regenerate/ >>> relay the appropriate keep-alive message to the next entry >> on the Path >>> vector? >>> Not doing so means that some other mechanism must be >> employed to keep >>> bindings/pinholes open between the various edge-proxies and the >>> registrar proxy. >> >> If that problem exists in your environment, it is completely >> out of the scope of outbound. The spec is about routing >> traffic over outbound-initiated flows from the UA. >> >>> For instance, in IMS you can have a P-CSCF in the visited network >>> talking to an IBCF in the visited network that is connected >> to an IBCF >>> in the home network that finally terminates at the S-CSCF >> in the home >>> network of the user that is registering. A NAT/FW is likely >> to exist >>> between the UA and the visited P-CSCF as well as between >> the IBCF in >>> the visited network and the IBCF in the home network. >> >> How do SIP messages make it today from a P-CSCF to an S-SCSF? >> >>> Another possible example (I believe) would be in the case of p2psip >>> where you may have multiple hops between the client and the node >>> acting as a registrar for the DHT algorithm. Wouldn't you >> want to keep >>> the entire path to the node storing your contact information in the >>> DHT alive or is there some other property of the DHT algorithm that >>> ensures that this is always the case even though outbound >> only keeps >>> the last hop fresh? >> >> p2psip has some unique requirements. I don't think outbound >> prevents p2psip from addressing their requirements, but they >> are certainly not the concerns that outbound intended to address. >> >> thanks, >> -rohan >> >> >>> Regards, >>> Brian >> >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 14:09:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwv4-0007b9-HD; Fri, 20 Jul 2007 14:09:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBqtZ-0002kv-9e for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 07:43:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBqtV-0002kJ-Io; Fri, 20 Jul 2007 07:43:37 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBqtU-0004vw-2E; Fri, 20 Jul 2007 07:43:37 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:49215) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1IBqtQ-0003El-Cr; Fri, 20 Jul 2007 12:43:32 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <40048F36-6069-40A3-BF6E-42D458638709@csperkins.org> Content-Transfer-Encoding: quoted-printable From: Colin Perkins Date: Fri, 20 Jul 2007 12:43:30 +0100 To: MMUSIC WG X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-Mailman-Approved-At: Fri, 20 Jul 2007 14:09:35 -0400 Cc: Cullen Jennings , Jean-Francois Mule , Joerg Ott Subject: [Sip] Progressing ICE X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org [This note is sent to MMUSIC, with bcc to BEHAVE, SIP, and P2PSIP =20 since the discussion has included those groups. Replies to MMUSIC =20 only please, as ICE is an MMUSIC working group draft] The MMUSIC chairs have reviewed the mailing list discussion =20 pertaining to ICE over the last few days. While we agree that further =20= implementation experience and publication of deployment results would =20= be valuable, as it is for any new protocol, we do not believe this =20 sufficient cause to revisit the consensus to request publication of =20 draft-ietf-mmusic-ice-17.txt as a Proposed Standard. The characteristics of Proposed Standard specifications are described =20= in RFC 2026 section 4.1.1 as follows: > The entry-level maturity for the standards track is "Proposed > Standard". A specific action by the IESG is required to move a > specification onto the standards track at the "Proposed Standard" > level. > > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has =20 > received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. However, such experience is highly desirable, and will > usually represent a strong argument in favor of a Proposed Standard > designation. > > The IESG may require implementation and/or operational experience > prior to granting Proposed Standard status to a specification that > materially affects the core Internet protocols or that specifies > behavior that may have significant operational impact on the > Internet. > > A Proposed Standard should have no known technical omissions with > respect to the requirements placed upon it. However, the IESG may > waive this requirement in order to allow a specification to advance > to the Proposed Standard state when it is considered to be =20 > useful and > necessary (and timely) even with known technical omissions. > > Implementors should treat Proposed Standards as immature > specifications. It is desirable to implement them in order to gain > experience and to validate, test, and clarify the specification. > However, since the content of Proposed Standards may be changed if > problems are found or better solutions are identified, deploying > implementations of such standards into a disruption-sensitive > environment is not recommended. Our judgement is that ICE meets these requirements, and that there is =20= general working group consensus to request publication. Accordingly, =20 our intention is to proceed as we previously announced, and request =20 that ICE be published as a Proposed Standard RFC. Colin Perkins, J=F6rg Ott, and Jean-Fran=E7ois Mul=E9 MMUSIC chairs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 14:09:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwv3-0007a2-2G; Fri, 20 Jul 2007 14:09:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBZxb-0005jQ-2r for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 13:38:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBZxa-0005in-Nm for sip@ietf.org; Thu, 19 Jul 2007 13:38:42 -0400 Received: from web33312.mail.mud.yahoo.com ([68.142.206.127]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBZxa-0007Bk-9l for sip@ietf.org; Thu, 19 Jul 2007 13:38:42 -0400 Received: (qmail 15794 invoked by uid 60001); 19 Jul 2007 17:38:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Q31OE9U5PaiNU50WPFXt08hk3aV7dVuJ7VwqOMSu3XEk1jW6xY93fkTEI3ojNazseXegCYe1YX8g4rFTn+MvJmk8QcbhOHMGj2qTdZVAS3uaQaazoAymuMNNDVWcmlivAmxvLTZPYa1fCieK2QwPXhQCc8yz27+yR/Jt6ponE64=; X-YMail-OSG: OoavG3AVM1l7DqQe672pWQ.yI1Y3WF0m1U8jwrcavRQ5lPFpOy6NB0UbhBB8IIEXizzQsg-- Received: from [209.172.74.45] by web33312.mail.mud.yahoo.com via HTTP; Thu, 19 Jul 2007 10:38:41 PDT Date: Thu, 19 Jul 2007 10:38:41 -0700 (PDT) From: Pyda Srisuresh Subject: RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC To: David Barrett , 'Melinda Shore' , 'Philip Matthews' MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <725173.15437.qm@web33312.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-Mailman-Approved-At: Fri, 20 Jul 2007 14:09:35 -0400 Cc: sip@ietf.org, 'Henry Sinnreich' , behave@ietf.org, mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org David, 90% success in connection rate is very impressive. Are you refering to UDP, TCP or both? As you say, fallback such as relay is essential for 100% connectivity. One cannot use hole punching without a good fallback scheme. regards, suresh --- David Barrett wrote: > > -----Original Message----- > > From: Melinda Shore [mailto:mshore@cisco.com] > > > > ICE makes me want to pound red-hot nails into my eye sockets. That said, > > 90% really isn't nearly good enough for residential deployments. > > Incidentally, 90% is where my stats come out today -- this doesn't include > restricted-cone/symmetric and symmetric/symmetric penetration, which has > been prototyped but not added to the production system yet. The hope is > this will get us much close to the 99% range, but it remains to be seen by > how much. > > Furthermore, I'd wager that for most applications (such as VoIP), even > routing 1 in 10 calls through a central relay isn't going to break the bank. > (Or for mega-discounts, use the full-cone and non-NAT'd clients (>30%) to > act as "free" relays for their peers.) > > Thus while NAT penetration using what I guess we're calling the "hole > punching technique" has been demonstrated to work at 90%+ on a very large > scale (hundreds of thousands of clients tested) we should expect that it's > possible to get even better still. If ICE can show how it'd do better, > that'd be great. But we can't tolerate ICE being any worse than that, and > thus before rushing ahead with standardizing an unproven ICE, we should just > take the time to prove it. > > -david > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 14:09:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwv4-0007b9-HD; Fri, 20 Jul 2007 14:09:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBqtZ-0002kv-9e for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 07:43:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBqtV-0002kJ-Io; Fri, 20 Jul 2007 07:43:37 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBqtU-0004vw-2E; Fri, 20 Jul 2007 07:43:37 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:49215) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1IBqtQ-0003El-Cr; Fri, 20 Jul 2007 12:43:32 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <40048F36-6069-40A3-BF6E-42D458638709@csperkins.org> Content-Transfer-Encoding: quoted-printable From: Colin Perkins Date: Fri, 20 Jul 2007 12:43:30 +0100 To: MMUSIC WG X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-Mailman-Approved-At: Fri, 20 Jul 2007 14:09:35 -0400 Cc: Cullen Jennings , Jean-Francois Mule , Joerg Ott Subject: [Sip] Progressing ICE X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org [This note is sent to MMUSIC, with bcc to BEHAVE, SIP, and P2PSIP =20 since the discussion has included those groups. Replies to MMUSIC =20 only please, as ICE is an MMUSIC working group draft] The MMUSIC chairs have reviewed the mailing list discussion =20 pertaining to ICE over the last few days. While we agree that further =20= implementation experience and publication of deployment results would =20= be valuable, as it is for any new protocol, we do not believe this =20 sufficient cause to revisit the consensus to request publication of =20 draft-ietf-mmusic-ice-17.txt as a Proposed Standard. The characteristics of Proposed Standard specifications are described =20= in RFC 2026 section 4.1.1 as follows: > The entry-level maturity for the standards track is "Proposed > Standard". A specific action by the IESG is required to move a > specification onto the standards track at the "Proposed Standard" > level. > > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has =20 > received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. However, such experience is highly desirable, and will > usually represent a strong argument in favor of a Proposed Standard > designation. > > The IESG may require implementation and/or operational experience > prior to granting Proposed Standard status to a specification that > materially affects the core Internet protocols or that specifies > behavior that may have significant operational impact on the > Internet. > > A Proposed Standard should have no known technical omissions with > respect to the requirements placed upon it. However, the IESG may > waive this requirement in order to allow a specification to advance > to the Proposed Standard state when it is considered to be =20 > useful and > necessary (and timely) even with known technical omissions. > > Implementors should treat Proposed Standards as immature > specifications. It is desirable to implement them in order to gain > experience and to validate, test, and clarify the specification. > However, since the content of Proposed Standards may be changed if > problems are found or better solutions are identified, deploying > implementations of such standards into a disruption-sensitive > environment is not recommended. Our judgement is that ICE meets these requirements, and that there is =20= general working group consensus to request publication. Accordingly, =20 our intention is to proceed as we previously announced, and request =20 that ICE be published as a Proposed Standard RFC. Colin Perkins, J=F6rg Ott, and Jean-Fran=E7ois Mul=E9 MMUSIC chairs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 14:09:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwv3-0007a2-2G; Fri, 20 Jul 2007 14:09:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBZxb-0005jQ-2r for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 13:38:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBZxa-0005in-Nm for sip@ietf.org; Thu, 19 Jul 2007 13:38:42 -0400 Received: from web33312.mail.mud.yahoo.com ([68.142.206.127]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBZxa-0007Bk-9l for sip@ietf.org; Thu, 19 Jul 2007 13:38:42 -0400 Received: (qmail 15794 invoked by uid 60001); 19 Jul 2007 17:38:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Q31OE9U5PaiNU50WPFXt08hk3aV7dVuJ7VwqOMSu3XEk1jW6xY93fkTEI3ojNazseXegCYe1YX8g4rFTn+MvJmk8QcbhOHMGj2qTdZVAS3uaQaazoAymuMNNDVWcmlivAmxvLTZPYa1fCieK2QwPXhQCc8yz27+yR/Jt6ponE64=; X-YMail-OSG: OoavG3AVM1l7DqQe672pWQ.yI1Y3WF0m1U8jwrcavRQ5lPFpOy6NB0UbhBB8IIEXizzQsg-- Received: from [209.172.74.45] by web33312.mail.mud.yahoo.com via HTTP; Thu, 19 Jul 2007 10:38:41 PDT Date: Thu, 19 Jul 2007 10:38:41 -0700 (PDT) From: Pyda Srisuresh Subject: RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC To: David Barrett , 'Melinda Shore' , 'Philip Matthews' MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <725173.15437.qm@web33312.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-Mailman-Approved-At: Fri, 20 Jul 2007 14:09:35 -0400 Cc: sip@ietf.org, 'Henry Sinnreich' , behave@ietf.org, mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org David, 90% success in connection rate is very impressive. Are you refering to UDP, TCP or both? As you say, fallback such as relay is essential for 100% connectivity. One cannot use hole punching without a good fallback scheme. regards, suresh --- David Barrett wrote: > > -----Original Message----- > > From: Melinda Shore [mailto:mshore@cisco.com] > > > > ICE makes me want to pound red-hot nails into my eye sockets. That said, > > 90% really isn't nearly good enough for residential deployments. > > Incidentally, 90% is where my stats come out today -- this doesn't include > restricted-cone/symmetric and symmetric/symmetric penetration, which has > been prototyped but not added to the production system yet. The hope is > this will get us much close to the 99% range, but it remains to be seen by > how much. > > Furthermore, I'd wager that for most applications (such as VoIP), even > routing 1 in 10 calls through a central relay isn't going to break the bank. > (Or for mega-discounts, use the full-cone and non-NAT'd clients (>30%) to > act as "free" relays for their peers.) > > Thus while NAT penetration using what I guess we're calling the "hole > punching technique" has been demonstrated to work at 90%+ on a very large > scale (hundreds of thousands of clients tested) we should expect that it's > possible to get even better still. If ICE can show how it'd do better, > that'd be great. But we can't tolerate ICE being any worse than that, and > thus before rushing ahead with standardizing an unproven ICE, we should just > take the time to prove it. > > -david > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 14:09:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwv5-0007dg-Bx; Fri, 20 Jul 2007 14:09:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBtmZ-00025B-TZ for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 10:48:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBtmZ-00024y-Hy for sip@ietf.org; Fri, 20 Jul 2007 10:48:39 -0400 Received: from web33306.mail.mud.yahoo.com ([68.142.206.121]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBtmZ-0004c9-4A for sip@ietf.org; Fri, 20 Jul 2007 10:48:39 -0400 Received: (qmail 42524 invoked by uid 60001); 20 Jul 2007 14:48:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=bgOG0vEyxaJUH0jcE3EPAYoUALnk99g5hyCvgkoZR9UDDiSB4ppOhkAXvZuRxvqsetUKD7VaPx7+8VJjpOS6ctqXlE28pht271hlG7yQfowt360CE3eYB0RNJAxw5tPKt5GzzkbQWSH4WNr5c2jzOEFlx9/TLH41xOjF2XjpZME=; X-YMail-OSG: p_naqYoVM1k8h9.pNsw5qeWaWi.N2xoQnYRPbntHxDHAUnSmCZRDU.sd4z7zU7.G_fRTsU6BaQ-- Received: from [69.236.76.222] by web33306.mail.mud.yahoo.com via HTTP; Fri, 20 Jul 2007 07:48:38 PDT Date: Fri, 20 Jul 2007 07:48:38 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC To: Philip Matthews , Henry Sinnreich In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <615870.42407.qm@web33306.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-Mailman-Approved-At: Fri, 20 Jul 2007 14:09:35 -0400 Cc: Magnus Westerlund , behave@ietf.org, mmusic@ietf.org, sip@ietf.org, Pyda Srisuresh , "Frank W. Miller" , p2psip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --- Philip Matthews wrote: > > On 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > > > Phil, > > > >> In my view, ICE _is_ a "Hole Punching Technique". > > > > Yes, you absolutely right, though the devil is in the details. > > > > We cannot go here into a shoot-out between hole punching or other > > mentioned on the list vs. ICE, but there seems to be a huge difference > > in effectiveness and performance. > > What precise algorithm are you talking about when you say this? > As far as I am concerned, ICE is simply a well-documented hole > punching algorithm. > It differs from others that I have seen written up in the following > ways: > - ICE has the concept of peer reflexive addresses, which other hole- > punching techniques that I have seen do not; [suresh] I dont know what you are talking about. AFAIK, Peer reflexive address is same as the public endpoint assigned to a node behind NAT. How can that be not part of HOLE-PUNCHING technique? > - ICE has the concept of controlling/controlled endpoint, which gives > the controller additional flexibility in choosing a path; [suresh] HOLE-PUNCHING technique is based on communication along a control path with external rendezvous server(s), which act as the key controller. The peering endpoints either make requests to punch holes or receiving requests to help in hole-punching by a peer. > - ICE does NOT have the concept of port prediction, which some other > techniques do (e.g., Saikat's TCP work). [suresh] Hole punchign technique is not complete by itself to setup connections. It needs a fallback scheme. Port prediction and relays can be effective fallback to hole punching. regards, suresh > > Philip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 14:09:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwv3-0007ab-PL; Fri, 20 Jul 2007 14:09:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBVDI-00043B-LO for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 08:34:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVDI-000432-Bz for sip@ietf.org; Thu, 19 Jul 2007 08:34:36 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBVDG-0004sX-3H for sip@ietf.org; Thu, 19 Jul 2007 08:34:36 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1078908uge for ; Thu, 19 Jul 2007 05:34:33 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=UNakZPUx27Cy/SqWupo45VOLE+HMOBJtAZO03MD6PdNVcLzBQoMMQ++7jk/snrfSHN+GJE16Sinpn+MZZCqfxF1woIH9K5Q57X8bwoDn8WXx5xmBhqhw6sb1lcgIy7l5mllyrPkp/Zv2bs+PAyRwnDeedNuYvz8fG25TNQcn8YI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=FrBc6ERmVluMErLQglaWd5/7sNRarH0TaN2Zgci8z4yfPRw18fH913NcxpJSImLwSjGj5Ce9VKe35YcinNhTw0l6jIa4JhjmQqJRJ5Loda0FLno2LmXUQAWVvhfz5oMw4EoZDTWKCrGOThRn+sBbWUoV3Z6T4p/ySTGXOvOf6u8= Received: by 10.86.68.16 with SMTP id q16mr1892016fga.1184848473186; Thu, 19 Jul 2007 05:34:33 -0700 (PDT) Received: from ?192.168.1.1? ( [89.109.141.244]) by mx.google.com with ESMTPS id j12sm4386186fkf.2007.07.19.05.34.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Jul 2007 05:34:32 -0700 (PDT) Message-ID: <469F5A56.9010908@gmail.com> Date: Thu, 19 Jul 2007 22:34:30 +1000 From: Evgeniy Khramtsov User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> <469DCB03.9040300@ericsson.com> <13AC112D-E5EF-438B-97C8-9F3827EA07BF@cisco.com> In-Reply-To: <13AC112D-E5EF-438B-97C8-9F3827EA07BF@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-Mailman-Approved-At: Fri, 20 Jul 2007 14:09:35 -0400 Cc: SIP , Behave WG , mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings wrote: > I would love to see more open source ICE code (there is lots already) Could you point me to the _lots_ of open source ICE code? Is there any open source implementation which supports TURN? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 14:09:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwv3-0007ab-PL; Fri, 20 Jul 2007 14:09:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBVDI-00043B-LO for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 08:34:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVDI-000432-Bz for sip@ietf.org; Thu, 19 Jul 2007 08:34:36 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBVDG-0004sX-3H for sip@ietf.org; Thu, 19 Jul 2007 08:34:36 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1078908uge for ; Thu, 19 Jul 2007 05:34:33 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=UNakZPUx27Cy/SqWupo45VOLE+HMOBJtAZO03MD6PdNVcLzBQoMMQ++7jk/snrfSHN+GJE16Sinpn+MZZCqfxF1woIH9K5Q57X8bwoDn8WXx5xmBhqhw6sb1lcgIy7l5mllyrPkp/Zv2bs+PAyRwnDeedNuYvz8fG25TNQcn8YI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=FrBc6ERmVluMErLQglaWd5/7sNRarH0TaN2Zgci8z4yfPRw18fH913NcxpJSImLwSjGj5Ce9VKe35YcinNhTw0l6jIa4JhjmQqJRJ5Loda0FLno2LmXUQAWVvhfz5oMw4EoZDTWKCrGOThRn+sBbWUoV3Z6T4p/ySTGXOvOf6u8= Received: by 10.86.68.16 with SMTP id q16mr1892016fga.1184848473186; Thu, 19 Jul 2007 05:34:33 -0700 (PDT) Received: from ?192.168.1.1? ( [89.109.141.244]) by mx.google.com with ESMTPS id j12sm4386186fkf.2007.07.19.05.34.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Jul 2007 05:34:32 -0700 (PDT) Message-ID: <469F5A56.9010908@gmail.com> Date: Thu, 19 Jul 2007 22:34:30 +1000 From: Evgeniy Khramtsov User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> <469DCB03.9040300@ericsson.com> <13AC112D-E5EF-438B-97C8-9F3827EA07BF@cisco.com> In-Reply-To: <13AC112D-E5EF-438B-97C8-9F3827EA07BF@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-Mailman-Approved-At: Fri, 20 Jul 2007 14:09:35 -0400 Cc: SIP , Behave WG , mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings wrote: > I would love to see more open source ICE code (there is lots already) Could you point me to the _lots_ of open source ICE code? Is there any open source implementation which supports TURN? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 14:09:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwv2-0007ZU-9k; Fri, 20 Jul 2007 14:09:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBY5K-0006yq-Gu for sip-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 11:38:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBY5K-0006ye-6x; Thu, 19 Jul 2007 11:38:34 -0400 Received: from estacado-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:266::2] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBY5J-0001sh-IN; Thu, 19 Jul 2007 11:38:34 -0400 Received: from orthrus.local ([172.17.1.56]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l6JFcQ6C064180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 10:38:26 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <469F8577.4080506@estacado.net> Date: Thu, 19 Jul 2007 10:38:31 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: "Frank W. Miller" Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC References: <20070719150508.14D4D1C8029@smtpauth01.csee.onr.siteprotect.com> In-Reply-To: <20070719150508.14D4D1C8029@smtpauth01.csee.onr.siteprotect.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-Mailman-Approved-At: Fri, 20 Jul 2007 14:09:35 -0400 Cc: 'SIP' , 'Behave WG' , mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 7/19/07 10:19 AM, Frank W. Miller wrote: > FM: While I applaud the time and effort that the large vendors have > obviously invested in this, this is a qualitative statement. Perhaps Cisco > and/or Microsoft have empirical data they would be willing to share about > robustness and performance? That's the kind of data you get between "proposed standard" and "draft standard" -- not *prior* to publication. I'm not sure why there's so much noise about setting the bar much, much higher for ICE than we do for other IETF proposals. To be clear: to get this kind of experience (especially as it pertains to interoperability), you need to have a stable (i.e., frozen) specification. Internet Drafts simply don't provide an appropriate basis for the kinds of proof that you and others are demanding. I think we would all benefit from a quick review of RFC 2026: > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. ... > Implementors should treat Proposed Standards as immature > specifications. It is desirable to implement them in order to gain > experience and to validate, test, and clarify the specification. > However, since the content of Proposed Standards may be changed if > problems are found or better solutions are identified, deploying > implementations of such standards into a disruption-sensitive > environment is not recommended. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 14:22:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBx7e-0001Qw-La; Fri, 20 Jul 2007 14:22:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBx7c-0001GC-Dx for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 14:22:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBx7c-0001D8-0W for sip@ietf.org; Fri, 20 Jul 2007 14:22:36 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBx7b-0000RN-0p for sip@ietf.org; Fri, 20 Jul 2007 14:22:35 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l6KIKol10578; Fri, 20 Jul 2007 18:20:51 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Jul 2007 13:22:26 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF115AF710@zrc2hxm0.corp.nortel.com> In-reply-to: <4DF02533-B636-40AB-8957-2D791CC4C468@ekabal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question about keep-alives in Outbound draft Thread-Index: AcfK92ILVSyX44nMQNa7C7Q/SwdvMQAAKG2A References: <6FC4416DDE56C44DA0AEE67BC7CA437115AA5DDD@zrc2hxm2.corp.nortel.com> <08333B74-4516-4BF7-94EB-6559A6AF8AFF@ekabal.com> <1ECE0EB50388174790F9694F77522CCF115AF631@zrc2hxm0.corp.nortel.com> <4DF02533-B636-40AB-8957-2D791CC4C468@ekabal.com> From: "Francois Audet" To: "Rohan Mahy" X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Cc: Cullen Jennings , sip@ietf.org, Brian Stucker Subject: [Sip] RE: Question about keep-alives in Outbound draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The "Registrar" and "Authoritative proxy" definitions are prety tight, = sure. That's OK with me. The problem is that you have no consistent term in the document for "the = place where the UAC sends both requests and keep alives". In some places it's called "host", in others "server", in others "edge = proxy", in others "registrar", depending on topology. In other places, it's just = avoided altogether, e.g.., the request is "sent" as oppose to the = request is "sent to edge proxy". If we don't want to use the term "outbound proxy" that is used = consistently in RFC 3261 (presumably because it's both an "outbound" and an "inbound" = proxy at the same=20 time, and because it means "the outbound proxy that conforms to the this = draft"), then let's=20 use "Edge proxy" consistently. And we should state that "An Edge proxy = is an Outbound Proxy (as per RFC 3261) that conforms to the requirements of this = specification" (if the statement is true). That would mean that in your co-located scenario, it would be a = "Registrar/Edge Proxy" instead of "Registrar/Proxy", and in your multiple connection scenario, = it would be "Edge Proxy 1" and "Edge Proxy 2". Would that work? > -----Original Message----- > From: Rohan Mahy [mailto:rohan@ekabal.com]=20 > Sent: Friday, July 20, 2007 10:57 > To: Audet, Francois (SC100:3055) > Cc: Rohan Mahy; Stucker, Brian (RICH1:AR00); Cullen Jennings;=20 > sip@ietf.org > Subject: Re: Question about keep-alives in Outbound draft >=20 > Fran=E7ois, >=20 > We started off using the term outbound proxy in previous=20 > versions of the draft and many people complained that the=20 > term did not have a meaningful or useful definition. It was=20 > one of those "its what I mean" definitions. I think the=20 > definitions of edge proxy, authoritative proxy, registrar,=20 > and UAC are pretty tight. There certainly might be some=20 > places where we say "host" or "client" or "proxy" where we=20 > should be saying something more well defined, but if so, I=20 > would like to change them to the correct terms, not to=20 > outbound proxy". >=20 > AFAIK, going back to outbound proxy will be a big step=20 > backwards for the document. Also, the registrar and proxy=20 > together is the simplest case to explain and I think it is=20 > still the most common topology. >=20 > thanks, > -rohan >=20 >=20 > On Jul 20, 2007, at 10:32 AM, Francois Audet wrote: > > Moving to proper mailing list (i.e., sip). > > > > Rohan, I also think that the draft could be a little bit=20 > clearer about=20 > > where the CRLF is sent, and where it stops, but I think it's a=20 > > consequence of how section 3 is structured, and the terms we use. > > > > If we made the concept of "Outbound proxy" a bit clearer in the=20 > > document, and use it throughout, and specifically say that=20 > the CRLF is=20 > > sent to the outbound proxy, it would read much better. > > > > Section 3 and above don't even use the term "outbound proxy" and=20 > > instead uses euphemisms such as "edge proxy", "proxy", "registrar",=20 > > "host" and "server". > > > > Furthermore, it starts with a special case (co-located=20 > Registrar and=20 > > Proxy), and finishes with the the general case (outbound proxy is=20 > > separate from the Registrar). > > > > I would suggest the following editorial changes: > > > > - Move section 3.4 to where 3.2 currently is. > > > > - Remove the word "Proxy" in the box that says "Registrar/Proxy" > > (i.e., > > it should just say "Registrar". There is no need for having a=20 > > proxy > > necessarily co-located in the Registrar, and it's immaterial to=20 > > this > > draft. > > > > - The box that say "Edge1" and "Edge2" should really be labelled > > "Outbound Proxy 1" and "Oubound Proxy 2". The text should also > > use the term "outbound proxy" instead of "edge proxy", and it > > should just explain that often this configuration is called > > and "edge proxy". > > > > - In section 3.2 (which would now be 3.3), clarify that=20 > this is just a > > special case of the outbound proxy and Registrar being co-located. > > Also use the term "outbound proxy" in the diagram and the text, as > > appropriate. > > > > - In section 3.3 (which would now be 3.4), clarify that the=20 > Host1 and > > Host2 are really the outbound proxy 1 and 2, in the diagram. > > > > - In section 3.5, use the term "outbound proxy" instead of server > > when talking about the entity receiving the ping and sending the=20 > > pong. > > > > - Section 5 should use the term "Outbound proxy" instead of "Edge=20 > > proxy". > > > > - Section 5.4 is where we should say the "oubound proxy" does not > > forward the keep alives. > > > > - Section 9 should use the terms "Primary outbound proxy" and=20 > > "Secondary > > > > outbound proxy". > > > > Cheers > > > >> -----Original Message----- > >> From: Rohan Mahy [mailto:rohan@ekabal.com] > >> Sent: Friday, July 20, 2007 09:20 > >> To: Stucker, Brian (RICH1:AR00) > >> Cc: Rohan Mahy; Cullen Jennings; sipping@ietf.org; Audet, Francois=20 > >> (SC100:3055) > >> Subject: Re: Question about keep-alives in Outbound draft > >> > >> > >> On Jul 19, 2007, at 9:50 PM, Brian Stucker wrote: > >> > >>> Cullen/Rohan, > >>> > >>> I have a question about keep-alive behavior in the -10 > >> version of the > >>> outbound draft. > >>> > >>> How far are keep-alives propagated along the flow created at=20 > >>> registration? > >>> > >>> The text seems a bit hazy on how far it is expected for a > >> keep- alive > >>> to be propagated along the flow. Section 8 has text in the last=20 > >>> paragraph on page 25 that seems to imply that STUN > >> keep-alives go no > >>> further than the edge proxy immediately adjacent to the > >> client device. > >>> Section > >>> 4.4.3 > >>> seems to also limit generation of STUN keep-alives to the > >> User-Agent > >>> only. > >> > >> one-hop. one-hop only Mister Kamarov. > >> > >>> Likewise, section 4.4.1 and 5.4 seem to limit the TCP CRLF > >> response to > >>> the first edge-proxy as well. > >> > >> yes. > >> > >> I don't think either of these statements is hazy. Can you=20 > propose a=20 > >> rewording? > >> > >>> Inclusion of the keep-stun or keep-crlf parameters for a Path URI=20 > >>> inserted by an edge proxy or registrar outside of the one in the=20 > >>> outbound-proxy-set seems moot as earlier edge-proxies that don't=20 > >>> support these mechanisms would ostensibly drop the keep-alives. > >> > >> if these parameters find their way into a URI handled by another=20 > >> proxy (instead of the UAC), they will be ignored (and no=20 > keepalives=20 > >> will be generated by the proxy). > >> > >>> Further, you only show a NAT/FW between the first > >> edge-proxy and the > >>> User-Agent in the figure for section 3.4. > >> > >> yes. that was part of our design assumptions. we had a=20 > hum on that=20 > >> about a year ago. We assume that there is a full SIP connectivity=20 > >> among any of the proxies and that anything necessary to make that=20 > >> work is taken care of. > >> > >>> However, the spec never really > >>> says very clearly what should occur at the edge-proxy: > >> should it check > >>> for freshness of the next-hop towards the registrar or not, > >> based upon > >>> what it observed in the Path header coming back in the=20 > registration=20 > >>> response? > >> > >> It says very clearly what to actually do and I hope it=20 > doesn't even=20 > >> hint that you should even begin to think about such a=20 > heinous thing=20 > >> as sending keepalives to the registrar from the EP. > >> > >>> Is there a reason that edge-proxies are not expected to=20 > regenerate/=20 > >>> relay the appropriate keep-alive message to the next entry > >> on the Path > >>> vector? > >>> Not doing so means that some other mechanism must be > >> employed to keep > >>> bindings/pinholes open between the various edge-proxies and the=20 > >>> registrar proxy. > >> > >> If that problem exists in your environment, it is=20 > completely out of=20 > >> the scope of outbound. The spec is about routing traffic over=20 > >> outbound-initiated flows from the UA. > >> > >>> For instance, in IMS you can have a P-CSCF in the visited network=20 > >>> talking to an IBCF in the visited network that is connected > >> to an IBCF > >>> in the home network that finally terminates at the S-CSCF > >> in the home > >>> network of the user that is registering. A NAT/FW is likely > >> to exist > >>> between the UA and the visited P-CSCF as well as between > >> the IBCF in > >>> the visited network and the IBCF in the home network. > >> > >> How do SIP messages make it today from a P-CSCF to an S-SCSF? > >> > >>> Another possible example (I believe) would be in the case=20 > of p2psip=20 > >>> where you may have multiple hops between the client and the node=20 > >>> acting as a registrar for the DHT algorithm. Wouldn't you > >> want to keep > >>> the entire path to the node storing your contact=20 > information in the=20 > >>> DHT alive or is there some other property of the DHT=20 > algorithm that=20 > >>> ensures that this is always the case even though outbound > >> only keeps > >>> the last hop fresh? > >> > >> p2psip has some unique requirements. I don't think=20 > outbound prevents=20 > >> p2psip from addressing their requirements, but they are=20 > certainly not=20 > >> the concerns that outbound intended to address. > >> > >> thanks, > >> -rohan > >> > >> > >>> Regards, > >>> Brian > >> > >> >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 14:48:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxWt-0005fM-IO; Fri, 20 Jul 2007 14:48:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBxWs-0005fF-4c for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 14:48:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxWr-0005f7-RQ for sip@ietf.org; Fri, 20 Jul 2007 14:48:41 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBxWq-0005Ka-9p for sip@ietf.org; Fri, 20 Jul 2007 14:48:41 -0400 Received: (qmail 16258 invoked by uid 0); 20 Jul 2007 18:49:53 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 20 Jul 2007 18:49:53 -0000 Message-ID: <00b801c7cafe$2e5ae040$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Rohan Mahy" References: <46928F5F.3080502@softarmor.com> <469FFC30.2090309@nostrum.com> <8AA4964D-1BA4-4E5E-8189-02A1032AD389@ekabal.com> Subject: Re: [Sip] Re: Outbound: Feature Tag (Ab)Use Date: Fri, 20 Jul 2007 20:45:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org, Cullen Jennings , Adam Roach X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan, The flag is needed, but you could make it a header parameter rather than a URI parameter (both for Contact and for Path). There is no need for it to appear in the request URI of mid-dialog requests. The EP can use its own convention to encode the flag, due to things like GRUU it cannot rely on the 'ob' parameter being in the request URI anyway. Regards, Jeroen Rohan Mahy wrote: > On Jul 20, 2007, at 9:06 AM, Rohan Mahy wrote: > >> Hi Adam, >> >> What can I say but "You're right". Unless there is some >> fundamental objection, I will make this change pronto to my working >> copy. >> >> I believe this also means I can remove the 'ob' parameter from the >> UAC's Contact header. > > On further thought, I realized that the 'ob' parameter is still > needed, since it reflects whether the UAC is sending over a flow for > which out bound processing is being applied, as opposed to merely > indicating the UAC is capable of requesting outbound. > > thanks, > -rohan > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 14:53:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxbl-0000oG-IT; Fri, 20 Jul 2007 14:53:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IBxbj-0000oA-DH for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 14:53:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxbj-0000o2-1w for sip@ietf.org; Fri, 20 Jul 2007 14:53:43 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBxbh-0007h0-No for sip@ietf.org; Fri, 20 Jul 2007 14:53:42 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l6KIrTp14275; Fri, 20 Jul 2007 11:53:29 -0700 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF115AF710@zrc2hxm0.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437115AA5DDD@zrc2hxm2.corp.nortel.com> <08333B74-4516-4BF7-94EB-6559A6AF8AFF@ekabal.com> <1ECE0EB50388174790F9694F77522CCF115AF631@zrc2hxm0.corp.nortel.com> <4DF02533-B636-40AB-8957-2D791CC4C468@ekabal.com> <1ECE0EB50388174790F9694F77522CCF115AF710@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4CED1F3D-5226-48CD-B5D8-3CF130D8C158@ekabal.com> Content-Transfer-Encoding: quoted-printable From: Rohan Mahy Date: Fri, 20 Jul 2007 11:53:28 -0700 To: "Francois Audet" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org, Brian Stucker Subject: [Sip] Re: Question about keep-alives in Outbound draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Francois, I think calling the composed registrar and proxy an Edge Proxy will =20 be confusing for a lot of people, but if you have a few places in =20 mind and want to send example text for one or two of these I think =20 its worth considering the change. thanks, -rohan On Jul 20, 2007, at 11:22 AM, Francois Audet wrote: > The "Registrar" and "Authoritative proxy" definitions are prety =20 > tight, sure. That's > OK with me. > > The problem is that you have no consistent term in the document for =20= > "the place where > the UAC sends both requests and keep alives". > > In some places it's called "host", in others "server", in others =20 > "edge proxy", > in others "registrar", depending on topology. In other places, it's =20= > just > avoided altogether, e.g.., the request is "sent" as oppose to the =20 > request is > "sent to edge proxy". > > If we don't want to use the term "outbound proxy" that is used =20 > consistently in > RFC 3261 (presumably because it's both an "outbound" and an =20 > "inbound" proxy at the same > time, and because it means "the outbound proxy that conforms to the =20= > this draft"), then let's > use "Edge proxy" consistently. And we should state that "An Edge =20 > proxy is an Outbound > Proxy (as per RFC 3261) that conforms to the requirements of this =20 > specification" (if the > statement is true). > > That would mean that in your co-located scenario, it would be a =20 > "Registrar/Edge Proxy" > instead of "Registrar/Proxy", and in your multiple connection =20 > scenario, it would be > "Edge Proxy 1" and "Edge Proxy 2". > > Would that work? > >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan@ekabal.com] >> Sent: Friday, July 20, 2007 10:57 >> To: Audet, Francois (SC100:3055) >> Cc: Rohan Mahy; Stucker, Brian (RICH1:AR00); Cullen Jennings; >> sip@ietf.org >> Subject: Re: Question about keep-alives in Outbound draft >> >> Fran=E7ois, >> >> We started off using the term outbound proxy in previous >> versions of the draft and many people complained that the >> term did not have a meaningful or useful definition. It was >> one of those "its what I mean" definitions. I think the >> definitions of edge proxy, authoritative proxy, registrar, >> and UAC are pretty tight. There certainly might be some >> places where we say "host" or "client" or "proxy" where we >> should be saying something more well defined, but if so, I >> would like to change them to the correct terms, not to >> outbound proxy". >> >> AFAIK, going back to outbound proxy will be a big step >> backwards for the document. Also, the registrar and proxy >> together is the simplest case to explain and I think it is >> still the most common topology. >> >> thanks, >> -rohan >> >> >> On Jul 20, 2007, at 10:32 AM, Francois Audet wrote: >>> Moving to proper mailing list (i.e., sip). >>> >>> Rohan, I also think that the draft could be a little bit >> clearer about >>> where the CRLF is sent, and where it stops, but I think it's a >>> consequence of how section 3 is structured, and the terms we use. >>> >>> If we made the concept of "Outbound proxy" a bit clearer in the >>> document, and use it throughout, and specifically say that >> the CRLF is >>> sent to the outbound proxy, it would read much better. >>> >>> Section 3 and above don't even use the term "outbound proxy" and >>> instead uses euphemisms such as "edge proxy", "proxy", "registrar", >>> "host" and "server". >>> >>> Furthermore, it starts with a special case (co-located >> Registrar and >>> Proxy), and finishes with the the general case (outbound proxy is >>> separate from the Registrar). >>> >>> I would suggest the following editorial changes: >>> >>> - Move section 3.4 to where 3.2 currently is. >>> >>> - Remove the word "Proxy" in the box that says "Registrar/Proxy" >>> (i.e., >>> it should just say "Registrar". There is no need for having a >>> proxy >>> necessarily co-located in the Registrar, and it's immaterial to >>> this >>> draft. >>> >>> - The box that say "Edge1" and "Edge2" should really be labelled >>> "Outbound Proxy 1" and "Oubound Proxy 2". The text should also >>> use the term "outbound proxy" instead of "edge proxy", and it >>> should just explain that often this configuration is called >>> and "edge proxy". >>> >>> - In section 3.2 (which would now be 3.3), clarify that >> this is just a >>> special case of the outbound proxy and Registrar being co-located. >>> Also use the term "outbound proxy" in the diagram and the text, as >>> appropriate. >>> >>> - In section 3.3 (which would now be 3.4), clarify that the >> Host1 and >>> Host2 are really the outbound proxy 1 and 2, in the diagram. >>> >>> - In section 3.5, use the term "outbound proxy" instead of server >>> when talking about the entity receiving the ping and sending the >>> pong. >>> >>> - Section 5 should use the term "Outbound proxy" instead of "Edge >>> proxy". >>> >>> - Section 5.4 is where we should say the "oubound proxy" does not >>> forward the keep alives. >>> >>> - Section 9 should use the terms "Primary outbound proxy" and >>> "Secondary >>> >>> outbound proxy". >>> >>> Cheers >>> >>>> -----Original Message----- >>>> From: Rohan Mahy [mailto:rohan@ekabal.com] >>>> Sent: Friday, July 20, 2007 09:20 >>>> To: Stucker, Brian (RICH1:AR00) >>>> Cc: Rohan Mahy; Cullen Jennings; sipping@ietf.org; Audet, Francois >>>> (SC100:3055) >>>> Subject: Re: Question about keep-alives in Outbound draft >>>> >>>> >>>> On Jul 19, 2007, at 9:50 PM, Brian Stucker wrote: >>>> >>>>> Cullen/Rohan, >>>>> >>>>> I have a question about keep-alive behavior in the -10 >>>> version of the >>>>> outbound draft. >>>>> >>>>> How far are keep-alives propagated along the flow created at >>>>> registration? >>>>> >>>>> The text seems a bit hazy on how far it is expected for a >>>> keep- alive >>>>> to be propagated along the flow. Section 8 has text in the last >>>>> paragraph on page 25 that seems to imply that STUN >>>> keep-alives go no >>>>> further than the edge proxy immediately adjacent to the >>>> client device. >>>>> Section >>>>> 4.4.3 >>>>> seems to also limit generation of STUN keep-alives to the >>>> User-Agent >>>>> only. >>>> >>>> one-hop. one-hop only Mister Kamarov. >>>> >>>>> Likewise, section 4.4.1 and 5.4 seem to limit the TCP CRLF >>>> response to >>>>> the first edge-proxy as well. >>>> >>>> yes. >>>> >>>> I don't think either of these statements is hazy. Can you >> propose a >>>> rewording? >>>> >>>>> Inclusion of the keep-stun or keep-crlf parameters for a Path URI >>>>> inserted by an edge proxy or registrar outside of the one in the >>>>> outbound-proxy-set seems moot as earlier edge-proxies that don't >>>>> support these mechanisms would ostensibly drop the keep-alives. >>>> >>>> if these parameters find their way into a URI handled by another >>>> proxy (instead of the UAC), they will be ignored (and no >> keepalives >>>> will be generated by the proxy). >>>> >>>>> Further, you only show a NAT/FW between the first >>>> edge-proxy and the >>>>> User-Agent in the figure for section 3.4. >>>> >>>> yes. that was part of our design assumptions. we had a >> hum on that >>>> about a year ago. We assume that there is a full SIP connectivity >>>> among any of the proxies and that anything necessary to make that >>>> work is taken care of. >>>> >>>>> However, the spec never really >>>>> says very clearly what should occur at the edge-proxy: >>>> should it check >>>>> for freshness of the next-hop towards the registrar or not, >>>> based upon >>>>> what it observed in the Path header coming back in the >> registration >>>>> response? >>>> >>>> It says very clearly what to actually do and I hope it >> doesn't even >>>> hint that you should even begin to think about such a >> heinous thing >>>> as sending keepalives to the registrar from the EP. >>>> >>>>> Is there a reason that edge-proxies are not expected to >> regenerate/ >>>>> relay the appropriate keep-alive message to the next entry >>>> on the Path >>>>> vector? >>>>> Not doing so means that some other mechanism must be >>>> employed to keep >>>>> bindings/pinholes open between the various edge-proxies and the >>>>> registrar proxy. >>>> >>>> If that problem exists in your environment, it is >> completely out of >>>> the scope of outbound. The spec is about routing traffic over >>>> outbound-initiated flows from the UA. >>>> >>>>> For instance, in IMS you can have a P-CSCF in the visited network >>>>> talking to an IBCF in the visited network that is connected >>>> to an IBCF >>>>> in the home network that finally terminates at the S-CSCF >>>> in the home >>>>> network of the user that is registering. A NAT/FW is likely >>>> to exist >>>>> between the UA and the visited P-CSCF as well as between >>>> the IBCF in >>>>> the visited network and the IBCF in the home network. >>>> >>>> How do SIP messages make it today from a P-CSCF to an S-SCSF? >>>> >>>>> Another possible example (I believe) would be in the case >> of p2psip >>>>> where you may have multiple hops between the client and the node >>>>> acting as a registrar for the DHT algorithm. Wouldn't you >>>> want to keep >>>>> the entire path to the node storing your contact >> information in the >>>>> DHT alive or is there some other property of the DHT >> algorithm that >>>>> ensures that this is always the case even though outbound >>>> only keeps >>>>> the last hop fresh? >>>> >>>> p2psip has some unique requirements. I don't think >> outbound prevents >>>> p2psip from addressing their requirements, but they are >> certainly not >>>> the concerns that outbound intended to address. >>>> >>>> thanks, >>>> -rohan >>>> >>>> >>>>> Regards, >>>>> Brian >>>> >>>> >> >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 17:46:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC0IR-0006PS-Ai; Fri, 20 Jul 2007 17:45:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IC0IP-0006OG-NY for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 17:45:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC0IP-0006O2-C0 for sip@ietf.org; Fri, 20 Jul 2007 17:45:57 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IC0IP-0002q7-2R for sip@ietf.org; Fri, 20 Jul 2007 17:45:57 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6KLjsDC009635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jul 2007 16:45:54 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <46A12D1A.10509@nostrum.com> Date: Fri, 20 Jul 2007 16:46:02 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: SIP WG , Gonzalo Camarillo 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-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Sip] draft-camarillo-sip-body-handling-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > This specification recommends support for 'multipart/mixed' and > 'multipart/alternative'. At present, there are no SIP extensions > that use different 'multipart' subtypes such as parallel [RFC2046], > digest [RFC2046], or related [RFC2387]. Actually, RFC 4662 uses multipart/related. It does, however, use option tags -- so we're in good shape there. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 17:53:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC0PY-0005Oo-Tj; Fri, 20 Jul 2007 17:53:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IC0PX-0005Oi-Gb for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 17:53:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC0PX-0005OZ-6V for sip@ietf.org; Fri, 20 Jul 2007 17:53:19 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IC0PW-0002yx-Nh for sip@ietf.org; Fri, 20 Jul 2007 17:53:19 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6KLrHth014460 for ; Fri, 20 Jul 2007 14:53:17 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6KLqh5H003882 for ; Fri, 20 Jul 2007 14:52:44 -0700 Received: from 172.24.29.66 ([172.24.29.66]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 Jul 2007 21:53:14 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 20 Jul 2007 16:13:55 -0400 From: Eric Burger To: IETF SIP Message-ID: Thread-Topic: INFO and Content Negotiation Thread-Index: AcfLCn9Zvg80MTb9EdyGRgAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] INFO and Content Negotiation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org 12 second proof point of why content type doesn't work. So here comes an INVITE. I am an INFO-friendly UAS. I negotiate by using Accept. This INVITE has the line: Accept: application/kpml-response+xml Wow! This is great! I know the UAC *wants* DTMF. Why? Because it accepts a DTMF content type. Excellent - I can now send them DTMF. The user enters a digit, and I send an INFO with type application/kpml-response+xml. UAC says, "What the heck was that?" Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 17:53:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC0Pe-0005Vn-V3; Fri, 20 Jul 2007 17:53:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IC0Pc-0005Sz-Gy for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 17:53:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC0Pa-0005Qa-Lm for sip@ietf.org; Fri, 20 Jul 2007 17:53:24 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IC0PZ-0000c8-OM for sip@ietf.org; Fri, 20 Jul 2007 17:53:22 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6KLrJdI014532; Fri, 20 Jul 2007 14:53:19 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6KLqh5L003882; Fri, 20 Jul 2007 14:52:47 -0700 Received: from 172.24.29.66 ([172.24.29.66]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 Jul 2007 21:53:17 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 20 Jul 2007 16:46:11 -0400 From: Eric Burger To: "Jesske, R" Message-ID: Thread-Topic: AW: [Sipping] comments on draft-burger-sip-info-00 Thread-Index: AcfIkd0E2RdwcfmQTdmyoddqeaZ0uQAcuMuwAAoux7AAeGF/QQ== In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4117709@S4DE8PSAAQB.mitte.t-com.de> Mime-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: IETF SIP Subject: [Sip] Re: AW: [Sipping] comments on draft-burger-sip-info-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org [Moved to SIP by chair request] MUMBLEBRATZ for UA-to-UA communication will always work if you own the endpoints. Might as well use INFO for MUMBLEBRATZ. If one wants interoperable communication or if you want to deploy equipment from more than one vendor, or at least not having to specify exact behavior (i.e., creating your own proprietary protocol), INFO doesn't work, as already documented. For that matter, we can save a ton of messages if we drop all the pesky negotiation in SIP. Why bother if we just "know" what the endpoints will accept. We just need to start sending RTP and things will just work :-) On 7/18/07 10:10 AM, "Jesske, R" wrote: > Dear all, > I'm concerned about the discussion here and the aim of the draft to restr= ict > the use of INFO only to SIP-T and Q-SIG. >=20 > If you now change restrict the RFC2976 you will tear down each implementa= tion > already done based on RFC2976. Like for DTMF that is broadly used within = the > world. So you are against backward compatibility? >=20 > The draft is claiming that INFO has to be routed over each proxy where th= e > INVITE is routed to. I do not know what's the problem with that. A proxy > forwards and the question is how much load will this cause. UA's can sent > re-INVITES or REGISTER, RE-REGISTER a couple of times and nobody claims t= hat. > INFO is used for UA to UA communication so is this not proper enough that= at > least the UA's will know what to do with the MIME? > INFO is ideal to sent information that has to correlate with the Dialog u= sing > other mechanisms like an 2nd stream like http or a MESSAGE or a other con= trol > protocol can not fulfil this. Even it could be get lost when you want to > traverse several SIP domains or if you interwork with the PSTN/ISDN. >=20 > The Example of DTMF for INFO can only be done at mid dialog. >=20 > Using KPML --> We have minimum 4 more Messages. No additional Load? >=20 >=20 >=20 > Best Regards >=20 > Roland >=20 >=20 >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: Christer Holmberg (JO/LMF) >> [mailto:christer.holmberg@ericsson.com] >> Gesendet: Mittwoch, 18. Juli 2007 12:18 >> An: Dean Willis >> Cc: IETF Sipping List >> Betreff: RE: [Sipping] comments on draft-burger-sip-info-00 >>=20 >>=20 >>=20 >> Hi,=20 >>=20 >>>>>> - I disagree with the statement in chapter 1 regarding >> the "context=20 >>>>>> for interpreting". The context is associated with the >> content type. >>>>>>=20 >>>>>=20 >>>>> Content type is, as I have repeatedly argued, completely >> insufficient >>=20 >>>>> for interpretation of context in the general case. What, >> for example, >>=20 >>>>> does it mean when an INFO shows up with a wav file >> attached? Play it? >>>>> Record it? Parse it using speech recognition and pass it >> to a command >>=20 >>>>> processor? >>>>=20 >>>> The dialog (you can't send INFOs out-of-dialog, as far as I >> know) will >>=20 >>>> be associated with an application, and if the application >> doesn't know >>=20 >>>> what to do with it, it can promt the user: "You have now received a >>>> file. What do you want to do with it? Save it? Play it? Display it? >>>> Delete it?". >>>=20 >>> And how does the receiver know what the sender intended? >>>=20 >>> Assume you're taking to my "phone" application. You send digits. >>> Should those be rendered to me, or fed into the user >>> interface of a phone-based game we happen to be playing? >>=20 >> How do you solve it with 2833? >>=20 >> How do you solve it with KPML? >>=20 >> You could even have the same problem with normal voice, e.g. >> if the game >> is controlled using voice recognition. Shall the received voice be fed >> to the speaker, or fed to the game application? >>=20 >> In some cases it may not matter if the data is fed to multiple >> applications. But, if you do need to dispatch data so specific >> applications you either need some kind of application >> reference, or you >> handle the dispatching locally in your device (the game >> application can >> tell it wants DTMFs, and/or the device chooses - either >> automatically or >> manually - which application will get the data etc). Or you use >> different SIP sessions. >>=20 >> In other cases you will not have the problem. For example, >> videoControl >> messages would normally be fed to a video control application, and >> nowhere else. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >>=20 >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP Notice: This email message, together with any attachments, may contain inf= ormation of BEA Systems, Inc., its subsidiaries and affiliated entiti= es, that may be confidential, proprietary, copyrighted and/or legally p= rivileged, and is intended solely for the use of the individual or entity n= amed in this message. If you are not the intended recipient, and have recei= ved this message in error, please immediately return this by email and then= delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 17:53:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC0Pi-0005ku-Hh; Fri, 20 Jul 2007 17:53:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IC0Pg-0005c8-BE for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 17:53:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC0Pf-0005ZH-Gc for sip@ietf.org; Fri, 20 Jul 2007 17:53:27 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IC0Pe-0002z9-NP for sip@ietf.org; Fri, 20 Jul 2007 17:53:27 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6KLrIJT014487; Fri, 20 Jul 2007 14:53:18 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6KLqh5J003882; Fri, 20 Jul 2007 14:52:46 -0700 Received: from 172.24.29.66 ([172.24.29.66]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 Jul 2007 21:53:15 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 20 Jul 2007 16:23:25 -0400 From: Eric Burger To: "Christer Holmberg (JO/LMF)" , Jonathan Rosenberg Message-ID: Thread-Topic: [Sipping] comments on draft-burger-sip-info-00 Thread-Index: AcfFiygVlVgtoSOdQ6WDO+HOA/f1cgCEANyQANwp5B4= In-Reply-To: <7374777208BDC7449D5620EF942325670730A6E0@esealmw113.eemea.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: IETF SIP Subject: [Sip] Re: [Sipping] comments on draft-burger-sip-info-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org [moved to SIP list at the request of the Chair] In line. On 7/16/07 7:43 AM, "Christer Holmberg (JO/LMF)" wrote: > > Hi, > > I have a number off issues with the draft, and I think it's extremely > un-objective. > > - I disagree with the statement in chapter 1 regarding the "context for > interpreting". The context is associated with the content type. > > - I disagree with the statement in chapter 1 regarding not negotiation > method. You can indicate what content types you support. > > - I disagree with the stamement in chapter 1 saying that something would > work only in limited or controlled networks. I am not really sure what a > controlled network means in this context, though. Of course some people > may have implemented something which only works between certain nodes, > or in certain networks, but that's a separate issue (and not even > specific to INFO). See the trivial example where this breaks down that I just posted. See also RFC 3458 for a few examples of how media type alone is not sufficient for determining why one is receiving the content. > - I don't understand the statement in chapter 1 saying "Likewise, a > routing proxy, such as the 3GPP IMS S-CSCF, will not expect to receive > media server control messages.". A routing proxy most likely wouldn't > care about media server control messages, so I don't understand the > "will not expect" thing. By expect, I meant from a traffic load perspective. Clearly the S-CSCF will be ignorant of most messages. > - I don't understand the statement in chapter 2, saying "a DTMF digit > type could be for user stimulus, post-dial digit collection, simple > transport of a > digit (no signaling context), or a mistake.". How is that specfic to > INFO? I can press a DTMF button "by mistake" no matter what mechanism I > use to transport it... The mistake here is the INFO, not the digit press. See the trivial example. That is an example of a mistake. > Now, these are issues Eric and I have agree to discuss off-line in > Chicago. > > I also have comments (some of which I've already given before) on > Jonathan's statements: > >> 1. confusion resulting from DTMF being sent in rfc2833 and INFO > > I believe you have the same problem with KPML, and the solution is to > use only one mechanism to send the DTMF. And we agree :-) >> 2. no way to signal whether the far end wants to receive DTMF via INFO; > > The far end indicates what content types it supports for this session. > >> it may be getting it via rfc2833 and that is fine for most cases > > Fine. Then you don't indicate support for the content types used with > the INFO solution See trivial example of why this CANNOT work. >> 3. proxies seeing INFO message load when they don't care about it > > That is a potential issues, yes, but you MAY end up with exactly the > same proxy path using KPML. It depends on the network architecture and > routing mechanisms. Yes, but at least KPML has a *few* throttling mechanisms, including digit maps, the potential for intermediaries collapsing events, and the generic RFC 3265 throttling mechanisms. INFO has *NO* throttling mechanisms. > And, with KPML you will end up with multiple dialogs. Whether that is a > problem or not is for each one to decide, but I think it's fair to > document that, and possible issues related to it. Why we have multiple dialogs was beaten to death by RFC 3265. What part of unsolicited subscriptions is still OK? >> 4. no way to pass digit maps so that you end up sending every digit in > its own INFO or guess at the maps, so its inefficient > > That is a limitation, yes, but it may not be required by everyone. And, > it could be solved using a content type parameter. > >> 5. security issues in case the DTMF is containing calling card info or > credit cards - rfc2833 along with SRTP is much more secured > > The security issue is not specific to DTMF, and using that argument we > should send everything sensitive on the media plane. Also, in some > environments the security may be provided other ways. > >> and so on. > > I don't have anything against documenting and discussing different > issues. But we shall be fair, and look at issues with ALL alternatives. > > The document doesn't say anything about WHY people are using INFO in the > first place. It only says that "people think it's an IETF way of doing > things", without considering that fact that there could be issues with > other mechanisms why people are not using them. Please enumerate why people use INFO, other than the RFC 4722, "It was the only thing available" argument. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 17:53:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC0Pp-00060n-8W; Fri, 20 Jul 2007 17:53:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IC0Pi-0005l7-G0 for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 17:53:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC0Pf-0005ZF-GV; Fri, 20 Jul 2007 17:53:27 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IC0Pe-0002zA-QL; Fri, 20 Jul 2007 17:53:27 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6KLrPMO014911; Fri, 20 Jul 2007 14:53:25 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6KLqh5T003882; Fri, 20 Jul 2007 14:52:53 -0700 Received: from 172.24.29.66 ([172.24.29.66]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 Jul 2007 21:53:16 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 20 Jul 2007 16:41:16 -0400 From: Eric Burger To: IETF SIP Message-ID: Thread-Topic: Example of NOTIFY instead of INFO Thread-Index: AcfLDlF1j+IXaTcBEdyGRgAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: "'sipping@ietf.org'" Subject: [Sip] Example of NOTIFY instead of INFO X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org [Please keep discussion of INFO to the SIP list. Copied to the SIPPING list because this message touches upon SPITSTOP. Please keep discussion of SPITSTOP to the SIPPING list.] Let us take the case of Malicious Indicator. This is where a subscriber receives a call, realizes it is a malicious call (threatening, SPIT, etc.). They then press the SPIT button (or press *xx), which tells their service provider to mark the UAC as a bad actor. One framework proposed for this is the SPITSTOP Reference Scenario, draft-niccolini-sipping-spitstop-00.txt. One might be tempted to think that INFO would be a great option for this service. It follows the return path of the INVITE, and so the INFO will hit the caller's inbound proxy, which it can learn the caller is (statistically) a bad actor. That way the inbound proxy can do stuff like notify law enforcement, add a vote to "this is a SPIT source," or other useful action. However, consider a few issues. First, since INFO lives exclusively within an established dialog, there is no way to assert this message after the call completes. Second, this mechanism *relies* on an active service provider topology. If there is no proxy in the chain that will eat the INFO, the caller will see the "this is a bad guy" message, which may have consequences in the real world. Third, there is no a'priori way for the UAS to know whether or not it can issue the INFO. The caller CERTAINLY will not advertise, "please tell me if I am bad, particularly I know in advance that I *am* a bad actor." What is the correct way of doing this? Here is where we have theory and practice. Theory says the proxy needs to SUBSCRIBE for the SPIT event at the UAS. At this point, life is good, interoperable, and works across networks. This enables events after the dialog is torn down, as presumably the SPIT event will refer not to, "this dialog," which does not exist, but to "that dialog identifier," which exists (and is theoretically unique) forever. [PLEASE TURN YOUR FLAME THROWERS OFF AT THIS POINT] Practice is that service providers might be able to add value by providing proprietary phones or IAD's to their subscribers that just "know" they have an implicit subscription for this service. Yes, there is a whole host of problems with this, but if you are in a controlled, limited, no desire for inter-network connectivity, this mechanism will work. Moreover, by creating, in this case, a SPIT event package, it will even allow the *possibility* of interoperable interworking if the endpoints implement the full SUBSCRIBE protocol. This approach shuts down the, "Oh, but with INFO I can save 3 messages, even though this all happens after the call connects so it adds no user-visible delay" argument. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 18:21:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC0pa-0003Cs-Ls; Fri, 20 Jul 2007 18:20:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IC0pY-0003C6-Ff for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 18:20:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC0pY-0003Bj-4D for sip@ietf.org; Fri, 20 Jul 2007 18:20:12 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IC0pX-00016o-LJ for sip@ietf.org; Fri, 20 Jul 2007 18:20:12 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Jul 2007 18:20:11 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswMALLRoEZAZnmf/2dsb2JhbACIX5w/ X-IronPort-AV: i="4.16,564,1175486400"; d="scan'208"; a="65753996:sNHT25597608" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6KMKBGT019162 for ; Fri, 20 Jul 2007 18:20:11 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6KMKBWI004321 for ; Fri, 20 Jul 2007 22:20:11 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 18:20:11 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 18:20:10 -0400 Message-ID: <46A13517.8000406@cisco.com> Date: Fri, 20 Jul 2007 18:20:07 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: SIP IETF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2007 22:20:10.0454 (UTC) FILETIME=[22AB8F60:01C7CB1C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=509; t=1184970011; x=1185834011; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Comment=20on=20draft-ietf-sip-fork-loop-fix-05 |Sender:=20 |To:=20SIP=20IETF=20; bh=R644FdwpfaX/7zOgFLUv78i9wMTYzOoqknF0rDgl7qs=; b=EFZOo/0lFOXhNJv1KXSF3A6dQ/0yUGfgVgtPozclg8S5Zpa17mHN6zcwL0NlgJB9uo84XFF0 AuVYS5Os96juAhcaFyt1a7B3IoIzBsJTzt+TZKSl1mCTWwM9Vn4xABZ4; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Sip] Comment on draft-ietf-sip-fork-loop-fix-05 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Just catching up :-( One thing occurred to me - this document goes out of its way to say that a proxy need not do the loop check unless it forks. In general that makes sense, but in one case it does not: Some proxies hide/suppress/obfuscate via headers, and then reverse the process on responses. A proxy that does so breaks loop checking by any of the proxies whose vias it hid. So I think a proxy that does this MUST perform a loop check itself even if it does not fork. Thanks, Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 20 19:09:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC1ah-0001Oc-M8; Fri, 20 Jul 2007 19:08:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IC1af-0001OX-OC for sip-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 19:08:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC1af-0001OO-E1 for sip@ietf.org; Fri, 20 Jul 2007 19:08:53 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IC1ae-0004HQ-VW for sip@ietf.org; Fri, 20 Jul 2007 19:08:53 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6KN8mp03683; Fri, 20 Jul 2007 23:08:48 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Jul 2007 18:08:46 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF115AFB45@zrc2hxm0.corp.nortel.com> In-reply-to: <4DF02533-B636-40AB-8957-2D791CC4C468@ekabal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification on draft-ietf-sip-outbound Thread-Index: AcfK92ILVSyX44nMQNa7C7Q/SwdvMQAKrEag References: <6FC4416DDE56C44DA0AEE67BC7CA437115AA5DDD@zrc2hxm2.corp.nortel.com> <08333B74-4516-4BF7-94EB-6559A6AF8AFF@ekabal.com> <1ECE0EB50388174790F9694F77522CCF115AF631@zrc2hxm0.corp.nortel.com> <4DF02533-B636-40AB-8957-2D791CC4C468@ekabal.com> From: "Francois Audet" To: "Rohan Mahy" , "Cullen Jennings" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: sip@ietf.org Subject: [Sip] Clarification on draft-ietf-sip-outbound X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 The last sentence of section 8 says "The SIP keepalive STUN usage requires no backwards compatibility.". It's not clear "with what". I'm assuming that you mean it works with rfc3489bis but not RFC 3489? Please clarify (in the document and on the mailing list). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 21 09:54:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICFPn-0003Tn-It; Sat, 21 Jul 2007 09:54:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICFPm-0003Rg-7s for sip-confirm+ok@megatron.ietf.org; Sat, 21 Jul 2007 09:54:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICFPl-0003RY-Ua for sip@ietf.org; Sat, 21 Jul 2007 09:54:33 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICFPl-0000cN-7u for sip@ietf.org; Sat, 21 Jul 2007 09:54:33 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l6LDsWRF023999 for ; Sat, 21 Jul 2007 08:54:32 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 08:54:32 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 15:54:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 21 Jul 2007 15:54:27 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800147393E@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Author drafts for consideration at IETF#69 Thread-Index: AcfLnqeSeDYV87eaRiGqWPuXVnebhQ== From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 21 Jul 2007 13:54:29.0330 (UTC) FILETIME=[A85D3320:01C7CB9E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Subject: [Sip] Author drafts for consideration at IETF#69 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG co-chair) You will not from the agenda that we have a number of author drafts to be discussed. In general we will be looking as part of this discussion to identify if there is work to be performed within the WG on this subject. The drafts are: http://www.ietf.org/internet-drafts/draft-polk-sip-rph-in-responses-00.t xt Updates a SIP standards track document. Note that IEPREP are now out of the requirements loop on this subject. http://www.ietf.org/internet-drafts/draft-polk-sip-rph-new-namespaces-01 .txt Prime function is the registration of new namespaces in the IANA registry. The requirements for adding to this registry are: "A new namespace MUST be defined in a Standards Track RFC, following the 'Standards Action' policy in [RFC2434]". The proposal is to take this action using a SIP WG item. http://www.ietf.org/internet-drafts/draft-camarillo-sip-body-handling-01 .txt An attempt to plug the underspecification of message body handling that should have been in RFC 3261. http://www.ietf.org/internet-drafts/draft-munakata-sip-privacy-new-01.tx t A replacement privacy mechanism for RFC 3323. http://www.ietf.org/internet-drafts/draft-gurbani-sip-domain-certs-06.tx t Security document therefore requirements work is done in SIP. http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate-auth-03 .txt Security document therefore requirements work is done in SIP. http://www.ietf.org/internet-drafts/draft-burger-sip-info-00 An attempt to provider a sounder basis for INFO usage, and therefore an reference point for questions that keep coming back to the SIP list. http://www.ietf.org/internet-drafts/draft-wing-sip-identity-media-00.txt Security document therefore requirements work is done in SIP. Independently of what appears in the slides we will be looking for the answers to two questions for each of these drafts: Is there support for a body of work in this area? ------------------------------------------------- To answer this question it is suggested that you primarily study the abstract for the draft, and if necessary seek clarification on the list or at the microphone in the meeting. Instead of this abstract, you may wish to suggest some alternative scope for adoption. At this point we don't necessarily need to decide whether the work is standards track, BCP or informational although that will form a part of the discussions the ADs and the chairs have in setting milestones. Note that answering YES to this also expresses an intention within the WG to provide resources to work on and review this draft (therefore do not answer "YES" if you just consider it mostly harmless. There are three answers to this question: YES NO NEEDS FURTHER WORK BEFORE WE DECIDE A yes result means that the chairs will discuss with the ADs whether it is appropriate to set new milestones for this work and what they should be, taking into account the discussion made. We will also proceed to the second question. Does the document currently provided constitute a baseline draft for the identified work? ------------------------------------------------------------------------ ----------------- What the WG is looking for here is whether the document, or its next revision, could (subject to the agreement of the milestones with the AD) become a draft-ietf-sip-xxxx document. This doesn't mean it has to be perfect, merely that this is a better starting point to the work than some other draft that may exist or that someone intends to produce. Again there are three answers to this question: YES NO NEEDS FURTHER WORK BEFORE WE DECIDE It is entirely appropriate to hold discussions on the list to formulate your opinions to answer the above questions. Expressions of support are also appropriate. Note that we may not proceed to the questions on all these drafts if it becomes apparent from list discussion or discussion at the mic that the answer will not be "YES". Requests for clarification on any of the above are welcome. Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 21 10:09:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICFdt-0006b8-TH; Sat, 21 Jul 2007 10:09:09 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICFds-0006b1-5X for sip-confirm+ok@megatron.ietf.org; Sat, 21 Jul 2007 10:09:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICFdr-0006at-Rh for sip@ietf.org; Sat, 21 Jul 2007 10:09:07 -0400 Received: from rwcrmhc15.comcast.net ([216.148.227.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICFdr-0000st-J6 for sip@ietf.org; Sat, 21 Jul 2007 10:09:07 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc15) with ESMTP id <20070721140906m1500a2qs1e>; Sat, 21 Jul 2007 14:09:06 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6LE958t009619 for ; Sat, 21 Jul 2007 10:09:05 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6LE95fj009615; Sat, 21 Jul 2007 10:09:05 -0400 Date: Sat, 21 Jul 2007 10:09:05 -0400 Message-Id: <200707211409.l6LE95fj009615@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <46A13517.8000406@cisco.com> (pkyzivat@cisco.com) Subject: Re: [Sip] Comment on draft-ietf-sip-fork-loop-fix-05 References: <46A13517.8000406@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Paul Kyzivat Some proxies hide/suppress/obfuscate via headers, and then reverse the process on responses. A proxy that does so breaks loop checking by any of the proxies whose vias it hid. So I think a proxy that does this MUST perform a loop check itself even if it does not fork. Hmmm, if you have a loop consisting of two obfuscating non-forking proxies and one non-obfuscating forking proxy, could any of the three proxies detect the loop? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 21 10:48:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICGFZ-0000kS-Fm; Sat, 21 Jul 2007 10:48:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICGFY-0000kK-5b for sip-confirm+ok@megatron.ietf.org; Sat, 21 Jul 2007 10:48:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICGFX-0000kC-SL; Sat, 21 Jul 2007 10:48:03 -0400 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICGFX-0001XZ-DT; Sat, 21 Jul 2007 10:48:03 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 41B4F1810C56; Sat, 21 Jul 2007 16:48:03 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 21 Jul 2007 16:47:52 +0200 To: "David Barrett" ,"'Jan Janak'" , "'Juha Heinanen'" From: Jiri Kuthan Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment databefore LC for RFC In-Reply-To: <20070719180614.85AB218115BC@mail.iptel.org> References: <20070719145334.2EA8B1810C50@mail.iptel.org> <20070719180614.85AB218115BC@mail.iptel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20070721144803.41B4F1810C56@mail.iptel.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip@ietf.org, mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 20:05 19/07/2007, David Barrett wrote: >> -----Original Message----- >> From: Jiri Kuthan [mailto:jiri@iptel.org] >> Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment databefore >> LC for RFC >> >> So I think that the right course of action is that folks doubting ICE >> reliability >> make their case (by that I mean specific arguments rather than emotional >> debates >> about red-colored nails and other hardware). > >Er, my "specific argument" is "until it's been proven to work, it hasn't >been proven to work". It's tautological, but no less true for it. > >Indeed, if you're *not* doubting ICE, why aren't you? Hi David, I'm not entirely sure what is the step you are suggesting? I think ICE is architecturally right answer to the right problem. Notwithstanding that, there are certainly some things I prefer differently (e.g., the infamous debate about proactive hole punching) or may turn out to be bugs. I think though that the key problem at this point is of institutional nature. In the IETF language, "hasn't been proven to work" is adequate to "lacking running code" and this appears to be a phenomen which is indeed occuring in the IETF and is not unique to ICE. The question is how to get this fixed? Some other standardization bodies enjoying the amount of contributions and complexity as the IETF is enjoying now (S in SIP does not really stand for Simple), proceed with 'after-fact filters', in that they produce the initial specs faster and later produce 'profiles' which separate what has proved and what less. Plus -bis versions are produced for whatever appears worth puttting effort in it (i.e., for which there is running code and field evidence of improvement need).This could be an approach which may be more feasible in today's IETF's dimension than trying to get back to historical roots. -jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 21 11:00:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICGRI-0007e4-4d; Sat, 21 Jul 2007 11:00:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICGRH-0007dm-9S for sip-confirm+ok@megatron.ietf.org; Sat, 21 Jul 2007 11:00:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICGRG-0007cW-UW for sip@ietf.org; Sat, 21 Jul 2007 11:00:10 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICGRG-0004vH-4f for sip@ietf.org; Sat, 21 Jul 2007 11:00:10 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l6LF08uJ001684; Sat, 21 Jul 2007 10:00:08 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 10:00:08 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 17:00:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 21 Jul 2007 17:00:04 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001473941@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Documents nearly ready for WGLC Thread-Index: AcfLp9HfkGdeiOq8TyunyGpdcN7chw== From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 21 Jul 2007 15:00:06.0231 (UTC) FILETIME=[D2F09E70:01C7CBA7] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Dean Willis Subject: [Sip] Documents nearly ready for WGLC X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As SIP WG co-chair) We have a few documents we are looking to get into WGLC in the near future. In parallel with the WGLC, we would like some dedicated reviewers who will undertake to do a full review of the document. The purpose of this mail is therefore to invite expressions of interest in performing a review of either of the following documents: http://www.ietf.org/internet-drafts/draft-ietf-sip-subnot-etags-00.txt http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers-guide-03. txt (Note that for this latter document we will also be looking for some cross WG review) Further out, but one we know we will need a number of reviewers for specific sections: http://tools.ietf.org/id/draft-ietf-sip-sec-flows-01.txt Please respond to the WG chairs. Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 21 13:11:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICITp-00074D-LK; Sat, 21 Jul 2007 13:10:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICITn-00073z-Lm for sip-confirm+ok@megatron.ietf.org; Sat, 21 Jul 2007 13:10:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICITn-00073n-Bu; Sat, 21 Jul 2007 13:10:55 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICITm-0003h7-Pa; Sat, 21 Jul 2007 13:10:55 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Sat, 21 Jul 2007 10:10:47 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6LH9Uot007824; Sat, 21 Jul 2007 10:09:30 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6LH8nI9011858; Sat, 21 Jul 2007 10:08:49 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 10:10:46 -0700 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 Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC Date: Sat, 21 Jul 2007 10:10:10 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com> In-Reply-To: <20070721144803.41B4F1810C56@mail.iptel.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC Thread-Index: AcfLpi72E4uz+FnVTwmkMQscEMfhaAAErYbw References: <20070719145334.2EA8B1810C50@mail.iptel.org><20070719180614.85AB218115BC@mail.iptel.org> <20070721144803.41B4F1810C56@mail.iptel.org> From: "Henry Sinnreich" To: "Jiri Kuthan" , "David Barrett" , "Jan Janak" , "Juha Heinanen" X-OriginalArrivalTime: 21 Jul 2007 17:10:46.0676 (UTC) FILETIME=[14359540:01C7CBBA] X-Spam-Score: -4.0 (----) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: sip@ietf.org, mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I fully agree with Jiri that this is an IETF problem and not an ICE problem. ICE-17 is a great document, no doubt about it. What happens however of someone finds an innovative approach that may work better? Will it be rejected because it will not be RFC standards compliant? What could an innovator tell customers about a solution that works better but is not IETF ICE RFC standards compliant? Henry -----Original Message----- From: Jiri Kuthan [mailto:jiri@iptel.org]=20 Sent: Saturday, July 21, 2007 9:48 AM To: David Barrett; 'Jan Janak'; 'Juha Heinanen' Cc: sip@ietf.org; mmusic@ietf.org Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC At 20:05 19/07/2007, David Barrett wrote: >> -----Original Message----- >> From: Jiri Kuthan [mailto:jiri@iptel.org] >> Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment databefore >> LC for RFC >>=20 >> So I think that the right course of action is that folks doubting ICE >> reliability >> make their case (by that I mean specific arguments rather than emotional >> debates >> about red-colored nails and other hardware). > >Er, my "specific argument" is "until it's been proven to work, it hasn't >been proven to work". It's tautological, but no less true for it. > >Indeed, if you're *not* doubting ICE, why aren't you? Hi David, I'm not entirely sure what is the step you are suggesting? I think ICE is architecturally right answer to the right problem. Notwithstanding that, there are certainly some things I prefer differently (e.g., the infamous debate about proactive hole punching) or may turn out to be bugs. I think though that the key problem at this point is of institutional nature. In the IETF language, "hasn't been proven to work" is adequate to "lacking running code" and this appears to be a phenomen which is indeed occuring in the IETF and is not unique to ICE. The question is how to get this fixed? Some other standardization bodies enjoying the amount of contributions and complexity as the IETF is enjoying now (S in SIP does not really stand for Simple), proceed with 'after-fact filters', in that they produce the initial specs faster and later produce 'profiles' which separate what has proved and what less. Plus -bis versions are produced for whatever appears worth puttting effort in it (i.e., for which there is running code and field evidence of improvement need).This could be=20 an approach which may be more feasible in today's IETF's dimension than trying to get back to historical roots. -jiri=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 21 14:20:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICJZD-00070b-T8; Sat, 21 Jul 2007 14:20:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICJZC-00070Q-Ew for sip-confirm+ok@megatron.ietf.org; Sat, 21 Jul 2007 14:20:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICJZB-00070I-TD for sip@ietf.org; Sat, 21 Jul 2007 14:20:34 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICJZB-0008Qq-Ir for sip@ietf.org; Sat, 21 Jul 2007 14:20:33 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Jul 2007 14:20:33 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoUALbqoUZAZnme/2dsb2JhbACIX50V X-IronPort-AV: i="4.16,567,1175486400"; d="scan'208"; a="126667700:sNHT25509470" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6LIKXMk005613; Sat, 21 Jul 2007 14:20:33 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6LIKWWI021935; Sat, 21 Jul 2007 18:20:32 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); Sat, 21 Jul 2007 14:20:32 -0400 Received: from [10.86.240.164] ([10.86.240.164]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 14:20:32 -0400 Message-ID: <46A24E6F.1060402@cisco.com> Date: Sat, 21 Jul 2007 14:20:31 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] Comment on draft-ietf-sip-fork-loop-fix-05 References: <46A13517.8000406@cisco.com> <200707211409.l6LE95fj009615@dragon.ariadne.com> In-Reply-To: <200707211409.l6LE95fj009615@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2007 18:20:32.0630 (UTC) FILETIME=[D33B7960:01C7CBC3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=904; t=1185042033; x=1185906033; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20Comment=20on=20draft-ietf-sip-fork-loop-fix-0 5 |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=PeU2dS8C54hzoev+bVwP9IYmhS5QTaYU2bF1v5nlzrE=; b=Qvon84E0XJrBssxaYLGxl6uCRAEbQ4AKx52I56DfY7FBikXXYP87rrOkXpMjIvGgU5G/4z5e 0Nm1HODBvEm5q/uQ3w07BTjGNJyJ0be6hkLDcDfPFBqFySc+asHdFqrl; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dale.Worley@comcast.net wrote: > From: Paul Kyzivat > > Some proxies hide/suppress/obfuscate via headers, and then reverse the > process on responses. A proxy that does so breaks loop checking by any > of the proxies whose vias it hid. So I think a proxy that does this MUST > perform a loop check itself even if it does not fork. > > Hmmm, if you have a loop consisting of two obfuscating non-forking > proxies and one non-obfuscating forking proxy, could any of the three > proxies detect the loop? Yes, if the obfuscating proxy performs the loop checking based on its own Via. But if you have *two* obfuscating proxies in the loop then I think it becomes impossible to detect the loop. In a way, this is similar the a loop that includes both a sip leg and a PSTN leg. I don't have a good solution for either of these. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 21 14:51:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICK39-0004dk-8a; Sat, 21 Jul 2007 14:51:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICK37-0004bl-PG for sip-confirm+ok@megatron.ietf.org; Sat, 21 Jul 2007 14:51:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICK37-0004bb-FZ for sip@ietf.org; Sat, 21 Jul 2007 14:51:29 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICK36-0005cp-EC for sip@ietf.org; Sat, 21 Jul 2007 14:51:29 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D9B5920582; Sat, 21 Jul 2007 20:51:27 +0200 (CEST) X-AuditID: c1b4fb3e-ae831bb0000007e1-16-46a255affe85 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A99F620550; Sat, 21 Jul 2007 20:51:27 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 20:51:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 21 Jul 2007 20:51:24 +0200 Message-ID: <7374777208BDC7449D5620EF942325670743C924@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] Example of NOTIFY instead of INFO Thread-Index: AcfLDlF1j+IXaTcBEdyGRgAWy4mm/wAd8g2A References: From: "Christer Holmberg (JO/LMF)" To: "Eric Burger" , "IETF SIP" X-OriginalArrivalTime: 21 Jul 2007 18:51:27.0478 (UTC) FILETIME=[24CED160:01C7CBC8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Subject: [Sip] RE: [Sipping] Example of NOTIFY instead of INFO X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >[Please keep discussion of INFO to the SIP list. Copied to=20 >the SIPPING list because this message touches upon SPITSTOP. =20 >Please keep discussion of SPITSTOP to the SIPPING list.] >=20 >=20 >Let us take the case of Malicious Indicator. This is where a=20 >subscriber receives a call, realizes it is a malicious call=20 >(threatening, SPIT, etc.). >They then press the SPIT button (or press *xx), which tells=20 >their service provider to mark the UAC as a bad actor. One=20 >framework proposed for this is the SPITSTOP Reference=20 >Scenario, draft-niccolini-sipping-spitstop-00.txt. >=20 >One might be tempted to think that INFO would be a great=20 >option for this service. It follows the return path of the=20 >INVITE, and so the INFO will hit the caller's inbound proxy,=20 >which it can learn the caller is (statistically) a bad actor.=20 >That way the inbound proxy can do stuff like notify law=20 >enforcement, add a vote to "this is a SPIT source," or other=20 >useful action. >=20 >However, consider a few issues. First, since INFO lives=20 >exclusively within an established dialog, there is no way to=20 >assert this message after the call completes. Second, this=20 >mechanism *relies* on an active service provider topology. =20 >If there is no proxy in the chain that will eat the INFO, the=20 >caller will see the "this is a bad guy" message, which may=20 >have consequences in the real world. Third, there is no=20 >a'priori way for the UAS to know whether or not it can issue=20 >the INFO. The caller CERTAINLY will not advertise, "please=20 >tell me if I am bad, particularly I know in advance that I=20 >*am* a bad actor." This is an example of a special case, where you don't want to INFO to go "all the way back", ie you want it to be terminated somewhere along the dialog path, and I don't think that is a valid justification why you couldn't use INFO in cases where you don't have that issue. I don't even think this behavior would be allowed according to the proxy rules, so the proxy would more or less be a B2BUA in this case. So, if the outbound proxy supports this mechanism, and DOES want to use INFO, it can insert application/mal-ind in the Accept header before forwarding it towards the UAS (since it is acting as a B2BUA, it is allowed to do so). =20 >What is the correct way of doing this? Here is where we have theory and practice. >=20 >Theory says the proxy needs to SUBSCRIBE for the SPIT event=20 >at the UAS. At this point, life is good, interoperable, and=20 >works across networks. This enables events after the dialog=20 >is torn down, as presumably the SPIT event will refer not to,=20 >"this dialog," which does not exist, but to "that dialog=20 >identifier," which exists (and is theoretically unique) forever. > >[PLEASE TURN YOUR FLAME THROWERS OFF AT THIS POINT] Practice=20 >is that service providers might be able to add value by=20 >providing proprietary phones or IAD's to their subscribers=20 >that just "know" they have an implicit subscription for this=20 >service. Yes, there is a whole host of problems with this,=20 >but if you are in a controlled, limited, no desire for=20 >inter-network connectivity, this mechanism will work. =20 >Moreover, by creating, in this case, a SPIT event package, it=20 >will even allow the *possibility* of interoperable interworking if the endpoints=20 >implement the full SUBSCRIBE protocol. >=20 >This approach shuts down the, "Oh, but with INFO I can save 3 messages, even though this all happens after the call=20 >connects so it adds no user-visible delay" argument. I am a little confused. I thought YOU have been saying that we shall define mechanisms which are NOT based on behavior in controlled and limited networks... Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 21 14:51:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICK3G-0004qG-Bc; Sat, 21 Jul 2007 14:51:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICK3E-0004pG-Sd for sip-confirm+ok@megatron.ietf.org; Sat, 21 Jul 2007 14:51:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICK3E-0004ov-IB for sip@ietf.org; Sat, 21 Jul 2007 14:51:36 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICK3D-0005dF-42 for sip@ietf.org; Sat, 21 Jul 2007 14:51:36 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 799EA208C5; Sat, 21 Jul 2007 20:51:34 +0200 (CEST) X-AuditID: c1b4fb3c-b1681bb0000007e1-21-46a255b6665a Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 70AB320400; Sat, 21 Jul 2007 20:51:34 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 20:51:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO and Content Negotiation Date: Sat, 21 Jul 2007 20:51:31 +0200 Message-ID: <7374777208BDC7449D5620EF942325670743C925@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO and Content Negotiation Thread-Index: AcfLCn9Zvg80MTb9EdyGRgAWy4mm/wAepRIg References: From: "Christer Holmberg (JO/LMF)" To: "Eric Burger" , "IETF SIP" X-OriginalArrivalTime: 21 Jul 2007 18:51:33.0885 (UTC) FILETIME=[28A072D0:01C7CBC8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I don't really understand your issue here... Did you send the text using = INFO, or something? ;) Regards, Christer=20 > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: 20. hein=E4kuuta 2007 23:14 > To: IETF SIP > Subject: [Sip] INFO and Content Negotiation >=20 > 12 second proof point of why content type doesn't work. >=20 > So here comes an INVITE. I am an INFO-friendly UAS. I=20 > negotiate by using Accept. >=20 > This INVITE has the line: > Accept: application/kpml-response+xml >=20 >=20 > Wow! This is great! I know the UAC *wants* DTMF. Why? =20 > Because it accepts a DTMF content type. Excellent - I can=20 > now send them DTMF. >=20 > The user enters a digit, and I send an INFO with type=20 > application/kpml-response+xml. >=20 > UAC says, "What the heck was that?" >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 21 14:51:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICK3P-0005KF-8N; Sat, 21 Jul 2007 14:51:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICK3M-0005Jp-JJ for sip-confirm+ok@megatron.ietf.org; Sat, 21 Jul 2007 14:51:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICK3M-0005Ja-5u for sip@ietf.org; Sat, 21 Jul 2007 14:51:44 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICK3L-0000w6-1l for sip@ietf.org; Sat, 21 Jul 2007 14:51:44 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 75F2220582; Sat, 21 Jul 2007 20:51:42 +0200 (CEST) X-AuditID: c1b4fb3e-b0034bb0000007e1-18-46a255be5d6c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3EB9C20550; Sat, 21 Jul 2007 20:51:42 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 20:51:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: AW: [Sipping] comments on draft-burger-sip-info-00 Date: Sat, 21 Jul 2007 20:51:39 +0200 Message-ID: <7374777208BDC7449D5620EF942325670743C926@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: AW: [Sipping] comments on draft-burger-sip-info-00 Thread-Index: AcfIkd0E2RdwcfmQTdmyoddqeaZ0uQAcuMuwAAoux7AAeGF/QQAdRisg References: <9886E5FCA6D76549A3011068483A4BD4117709@S4DE8PSAAQB.mitte.t-com.de> From: "Christer Holmberg (JO/LMF)" To: "Eric Burger" , "Jesske, R" X-OriginalArrivalTime: 21 Jul 2007 18:51:42.0025 (UTC) FILETIME=[2D7A8390:01C7CBC8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: IETF SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, =20 >[Moved to SIP by chair request] >=20 >MUMBLEBRATZ for UA-to-UA communication will always work if=20 >you own the endpoints. Might as well use INFO for MUMBLEBRATZ. >=20 >If one wants interoperable communication or if you want to=20 >deploy equipment from more than one vendor, or at least not=20 >having to specify exact behavior (i.e., creating your own=20 >proprietary protocol), INFO doesn't work, as already documented. If you are going to use INFO to carry videoControl messages, of course = those messages, and the meaning of those, must be defined and documented = - in order to make them non-proprietary. It's the same with ISUP. You use INFO to carry SPECIFIED ISUP messages, = and endpoints supporting ISUP know the procedures how to deal with the = messages, because it is defined in standard documentation. =20 >For that matter, we can save a ton of messages if we drop all=20 >the pesky negotiation in SIP. Why bother if we just "know"=20 >what the endpoints will accept. We just need to start=20 >sending RTP and things will just work :-) Please show me message you save by not using INFO. The negotiation can = in most cases be "encapsulated" in SIP messages you are going to send = anyway. But, if you use an event based mechanism, you actually WILL get more SIP = messages, because you need to send the NOTIFY request(s). Regards, Christer >=20 >=20 > On 7/18/07 10:10 AM, "Jesske, R" wrote: >=20 > > Dear all, > > I'm concerned about the discussion here and the aim of the draft to=20 > > restrict the use of INFO only to SIP-T and Q-SIG. > >=20 > > If you now change restrict the RFC2976 you will tear down each=20 > > implementation already done based on RFC2976. Like for DTMF that is=20 > > broadly used within the world. So you are against backward=20 > compatibility? > >=20 > > The draft is claiming that INFO has to be routed over each=20 > proxy where=20 > > the INVITE is routed to. I do not know what's the problem=20 > with that. A=20 > > proxy forwards and the question is how much load will this=20 > cause. UA's=20 > > can sent re-INVITES or REGISTER, RE-REGISTER a couple of=20 > times and nobody claims that. > > INFO is used for UA to UA communication so is this not=20 > proper enough=20 > > that at least the UA's will know what to do with the MIME? > > INFO is ideal to sent information that has to correlate with the=20 > > Dialog using other mechanisms like an 2nd stream like http or a=20 > > MESSAGE or a other control protocol can not fulfil this.=20 > Even it could=20 > > be get lost when you want to traverse several SIP domains=20 > or if you interwork with the PSTN/ISDN. > >=20 > > The Example of DTMF for INFO can only be done at mid dialog. > >=20 > > Using KPML --> We have minimum 4 more Messages. No additional Load? > >=20 > >=20 > >=20 > > Best Regards > >=20 > > Roland > >=20 > >=20 > >=20 > >> -----Urspr=FCngliche Nachricht----- > >> Von: Christer Holmberg (JO/LMF) > >> [mailto:christer.holmberg@ericsson.com] > >> Gesendet: Mittwoch, 18. Juli 2007 12:18 > >> An: Dean Willis > >> Cc: IETF Sipping List > >> Betreff: RE: [Sipping] comments on draft-burger-sip-info-00 > >>=20 > >>=20 > >>=20 > >> Hi, > >>=20 > >>>>>> - I disagree with the statement in chapter 1 regarding > >> the "context > >>>>>> for interpreting". The context is associated with the > >> content type. > >>>>>>=20 > >>>>>=20 > >>>>> Content type is, as I have repeatedly argued, completely > >> insufficient > >>=20 > >>>>> for interpretation of context in the general case. What, > >> for example, > >>=20 > >>>>> does it mean when an INFO shows up with a wav file > >> attached? Play it? > >>>>> Record it? Parse it using speech recognition and pass it > >> to a command > >>=20 > >>>>> processor? > >>>>=20 > >>>> The dialog (you can't send INFOs out-of-dialog, as far as I > >> know) will > >>=20 > >>>> be associated with an application, and if the application > >> doesn't know > >>=20 > >>>> what to do with it, it can promt the user: "You have now=20 > received a=20 > >>>> file. What do you want to do with it? Save it? Play it?=20 > Display it? > >>>> Delete it?". > >>>=20 > >>> And how does the receiver know what the sender intended? > >>>=20 > >>> Assume you're taking to my "phone" application. You send digits. > >>> Should those be rendered to me, or fed into the user=20 > interface of a=20 > >>> phone-based game we happen to be playing? > >>=20 > >> How do you solve it with 2833? > >>=20 > >> How do you solve it with KPML? > >>=20 > >> You could even have the same problem with normal voice, e.g. > >> if the game > >> is controlled using voice recognition. Shall the received voice be=20 > >> fed to the speaker, or fed to the game application? > >>=20 > >> In some cases it may not matter if the data is fed to multiple=20 > >> applications. But, if you do need to dispatch data so specific=20 > >> applications you either need some kind of application=20 > reference, or=20 > >> you handle the dispatching locally in your device (the game=20 > >> application can tell it wants DTMFs, and/or the device chooses -=20 > >> either automatically or manually - which application will get the=20 > >> data etc). Or you use different SIP sessions. > >>=20 > >> In other cases you will not have the problem. For example,=20 > >> videoControl messages would normally be fed to a video control=20 > >> application, and nowhere else. > >>=20 > >> Regards, > >>=20 > >> Christer > >>=20 > >>=20 > >>=20 > >> _______________________________________________ > >> Sipping mailing list =20 > https://www1.ietf.org/mailman/listinfo/sipping > >> This list is for NEW development of the application of SIP Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sip@ietf.org for new developments of core SIP > >>=20 > >=20 > >=20 > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sip@ietf.org for new developments of core SIP >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 21 16:00:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICL7Q-00006E-EZ; Sat, 21 Jul 2007 16:00:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICL7P-000065-3S for sip-confirm+ok@megatron.ietf.org; Sat, 21 Jul 2007 15:59:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICL7O-00005x-Pb for sip@ietf.org; Sat, 21 Jul 2007 15:59:58 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICL7O-0002Un-Fh for sip@ietf.org; Sat, 21 Jul 2007 15:59:58 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 21 Jul 2007 12:59:58 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoUAGICokarR7PD/2dsb2JhbACIX5xo X-IronPort-AV: i="4.16,567,1175497200"; d="scan'208"; a="186236406:sNHT25167501" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6LJxvdL017465 for ; Sat, 21 Jul 2007 12:59:57 -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.12.10/8.12.6) with ESMTP id l6LJxvSb008434 for ; Sat, 21 Jul 2007 19:59:57 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); Sat, 21 Jul 2007 15:59:56 -0400 Received: from [10.86.240.164] ([10.86.240.164]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 15:59:56 -0400 Message-ID: <46A265BB.8030907@cisco.com> Date: Sat, 21 Jul 2007 15:59:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: SIP IETF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2007 19:59:56.0426 (UTC) FILETIME=[B5EE86A0:01C7CBD1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=251; t=1185047997; x=1185911997; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Comment=20on=20draft-sparks-sipping-max-breadth-01 |Sender:=20; bh=HQr21Cj06dxPdpOK1t+w4/IuG1Ok+2TaeHoU1M62oSM=; b=dRXf2PFfV1bXFCfX+w7avi33me6QS9WchjkGfO12/bBjwZJcJP4V8r27IZPPWrZIg5KQLgD/ qvS/YG1M3L8tPB4pWucYjbCwgHDEr7FzK1ix4DmC44VbAH1MKQ9X8z3q; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Sip] Comment on draft-sparks-sipping-max-breadth-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Looks good to me. I will make my pro-forma suggestion that the syntax make provision for parameters just in case there may be need for an extension in the future: Max-Breadth = "Max-Breadth" HCOLON 1*DIGIT *( SEMI generic-param ) Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 21 16:43:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICLnk-0000Yk-9e; Sat, 21 Jul 2007 16:43:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICLni-0000YV-BS for sip-confirm+ok@megatron.ietf.org; Sat, 21 Jul 2007 16:43:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICLnh-0000YN-Vb; Sat, 21 Jul 2007 16:43:42 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICLng-0003jz-Va; Sat, 21 Jul 2007 16:43:41 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Jul 2007 16:43:39 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4HAHYMokZAZnme/2dsb2JhbACCLjY X-IronPort-AV: i="4.16,567,1175486400"; d="scan'208,217"; a="126671085:sNHT48362078" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6LKhcdB029305; Sat, 21 Jul 2007 16:43:38 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6LKhPWI024142; Sat, 21 Jul 2007 20:43:25 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 16:43:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LCfor RFC Date: Sat, 21 Jul 2007 16:43:24 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LCfor RFC Thread-Index: AcfLpi72E4uz+FnVTwmkMQscEMfhaAAErYbwAAe45yU= From: "Jonathan Rosenberg \(jdrosen\)" To: "Henry Sinnreich" , "Jiri Kuthan" , "David Barrett" , "Jan Janak" , "Juha Heinanen" X-OriginalArrivalTime: 21 Jul 2007 20:43:25.0078 (UTC) FILETIME=[C8CF3B60:01C7CBD7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9155; t=1185050618; x=1185914618; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20=22Jonathan=20Rosenberg=20\(jdrosen\)=22=20 |Subject:=20RE=3A=20[MMUSIC]=20Re=3A=20[Sip]=20RE=3A=20[BEHAVE]=20Re=3A=2 0ICE=20deploymentdatabefore=20LCfor=20RFC |Sender:=20 |To:=20=22Henry=20Sinnreich=22=20, =20=22Jiri=20Kuthan =22=20, =0A=20=20=20=20=20=20=20=20=22David=20Barrett=22=20 , =20=22Jan=20Janak=22=20, =0A=20=20=2 0=20=20=20=20=20=22Juha=20Heinanen=22=20; bh=FeXTbE1vsDRwBwYW0xanIKHvkLx0HL6s83l09CenqQE=; b=sVXKLLnRkiYijmZD35FW/HSRsgr8ziSzwQUe5wVgRU42J2AamO4St22alANvAF4aNL0Op809 sxbGhYFz9iLu4UhFNB/3uMM4sHazhFvCP/6kBRQOWwiZIj1sbo++Dvy2; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: sip@ietf.org, mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1245905593==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1245905593== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CBD7.C8A4C4CE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CBD7.C8A4C4CE Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Of course they can bring such a thing to ietf. There is a long history = of new work improving on the old (ice improving on stun, v6 improving on = v4, ospf improving on rip, and so on). I look forward to your draft suggesting something better. Jonathan R. -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Saturday, July 21, 2007 01:11 PM Eastern Standard Time To: Jiri Kuthan; David Barrett; Jan Janak; Juha Heinanen Cc: sip@ietf.org; mmusic@ietf.org Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE = deploymentdatabefore LCfor RFC I fully agree with Jiri that this is an IETF problem and not an ICE problem. ICE-17 is a great document, no doubt about it. What happens however of someone finds an innovative approach that may work better? Will it be rejected because it will not be RFC standards compliant? What could an innovator tell customers about a solution that works better but is not IETF ICE RFC standards compliant? Henry -----Original Message----- From: Jiri Kuthan [mailto:jiri@iptel.org]=20 Sent: Saturday, July 21, 2007 9:48 AM To: David Barrett; 'Jan Janak'; 'Juha Heinanen' Cc: sip@ietf.org; mmusic@ietf.org Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC At 20:05 19/07/2007, David Barrett wrote: >> -----Original Message----- >> From: Jiri Kuthan [mailto:jiri@iptel.org] >> Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment databefore >> LC for RFC >>=20 >> So I think that the right course of action is that folks doubting ICE >> reliability >> make their case (by that I mean specific arguments rather than emotional >> debates >> about red-colored nails and other hardware). > >Er, my "specific argument" is "until it's been proven to work, it hasn't >been proven to work". It's tautological, but no less true for it. > >Indeed, if you're *not* doubting ICE, why aren't you? Hi David, I'm not entirely sure what is the step you are suggesting? I think ICE is architecturally right answer to the right problem. Notwithstanding that, there are certainly some things I prefer differently (e.g., the infamous debate about proactive hole punching) or may turn out to be bugs. I think though that the key problem at this point is of institutional nature. In the IETF language, "hasn't been proven to work" is adequate to "lacking running code" and this appears to be a phenomen which is indeed occuring in the IETF and is not unique to ICE. The question is how to get this fixed? Some other standardization bodies enjoying the amount of contributions and complexity as the IETF is enjoying now (S in SIP does not really stand for Simple), proceed with 'after-fact filters', in that they produce the initial specs faster and later produce 'profiles' which separate what has proved and what less. Plus -bis versions are produced for whatever appears worth puttting effort in it (i.e., for which there is running code and field evidence of improvement need).This could be=20 an approach which may be more feasible in today's IETF's dimension than trying to get back to historical roots. -jiri=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C7CBD7.C8A4C4CE Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore = LCfor RFC

        Of course they can bring such a thing to ietf. There = is a long history of new work improving on the old (ice improving on = stun, v6 improving on v4, ospf improving on rip, and so on).

        I look forward to your draft suggesting something better.

        Jonathan R.

         -----Original Message-----
        From:   Henry Sinnreich [mailto:hsinnrei@adobe.com]
        Sent:   Saturday, July 21, 2007 01:11 PM Eastern Standard = Time
        To:     Jiri Kuthan; David Barrett; Jan Janak; Juha = Heinanen
        Cc:     sip@ietf.org; mmusic@ietf.org
        Subject:        RE: [MMUSIC] Re: = [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LCfor RFC

        I fully agree with Jiri that this is an IETF problem and not an ICE
        problem.
        ICE-17 is a great document, no doubt about it.

        What happens however of someone finds an innovative approach that = may
        work better? Will it be rejected because it will not be RFC = standards
        compliant?

        What could an innovator tell customers about a solution that works
        better but is not IETF ICE RFC standards compliant?

        Henry

        -----Original Message-----
        From: Jiri Kuthan [mailto:jiri@iptel.org]
        Sent: Saturday, July 21, 2007 9:48 AM
        To: David Barrett; 'Jan Janak'; 'Juha Heinanen'
        Cc: sip@ietf.org; mmusic@ietf.org
        Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE
        deploymentdatabefore LC for RFC

        At 20:05 19/07/2007, David Barrett wrote:
        >> -----Original Message-----
        >> From: Jiri Kuthan [mailto:jiri@iptel.org]
        >> Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE = deployment
        databefore
        >> LC for RFC
        >>
        >> So I think that the right course of action is that folks = doubting ICE
        >> reliability
        >> make their case (by that I mean specific arguments rather = than
        emotional
        >> debates
        >> about red-colored nails and other hardware).
        >
        >Er, my "specific argument" is "until it's been proven = to work, it
        hasn't
        >been proven to work".  It's tautological, but no less true = for it.
        >
        >Indeed, if you're *not* doubting ICE, why aren't you?

        Hi David,

        I'm not entirely sure what is the step you are suggesting?

        I think ICE is architecturally right answer to the right problem.
        Notwithstanding that, there are certainly some things I prefer
        differently (e.g., the infamous debate about proactive hole = punching)
        or may turn out to be bugs. I think though that the key problem at
        this point is of institutional nature. In the IETF language, = "hasn't
        been proven to work" is adequate to "lacking running = code" and this
        appears to be a phenomen which is indeed occuring in the IETF and
        is not unique to ICE.

        The question is how to get this fixed?

        Some other standardization bodies enjoying the amount of = contributions
        and complexity as the IETF is enjoying now (S in SIP does not really
        stand for Simple), proceed with 'after-fact filters', in that they
        produce the initial specs faster and later produce 'profiles' which
        separate what has proved and what less. Plus -bis versions are = produced
        for whatever appears worth puttting effort in it (i.e., for which = there
        is running code and field evidence of improvement need).This could = be
        an approach  which may be more feasible in today's IETF's dimension = than

        trying to get back to historical roots.

        -jiri



        _______________________________________________
        Sip mailing list  https://www1.ietf.org= /mailman/listinfo/sip
        This list is for NEW development of the core SIP Protocol
        Use sip-implementors@cs.columbia.edu for questions on current sip
        Use sipping@ietf.org for new developments on the application of sip


        _______________________________________________
        Sip mailing list  https://www1.ietf.org= /mailman/listinfo/sip
        This list is for NEW development of the core SIP Protocol
        Use sip-implementors@cs.columbia.edu for questions on current sip
        Use sipping@ietf.org for new developments on the application of sip

        ------_=_NextPart_001_01C7CBD7.C8A4C4CE-- --===============1245905593== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1245905593==-- From sip-bounces@ietf.org Sat Jul 21 21:40:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICQQh-0004mn-Uf; Sat, 21 Jul 2007 21:40:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICQQg-0004mh-QC for sip-confirm+ok@megatron.ietf.org; Sat, 21 Jul 2007 21:40:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICQQe-0004mX-TD for sip@ietf.org; Sat, 21 Jul 2007 21:40:14 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICQQd-0005Kj-9f for sip@ietf.org; Sat, 21 Jul 2007 21:40:12 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6M1e5WI030422; Sat, 21 Jul 2007 18:40:05 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6M1e47G019840; Sat, 21 Jul 2007 18:40:04 -0700 Received: from 172.24.29.208 ([172.24.29.208]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 22 Jul 2007 01:40:04 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Sat, 21 Jul 2007 21:40:01 -0400 Subject: Re: [Sip] Re: AW: [Sipping] comments on draft-burger-sip-info-00 From: Eric Burger To: "Christer Holmberg (JO/LMF)" , "Jesske, R" Message-ID: Thread-Topic: [Sip] Re: AW: [Sipping] comments on draft-burger-sip-info-00 Thread-Index: AcfIkd0E2RdwcfmQTdmyoddqeaZ0uQAcuMuwAAoux7AAeGF/QQAdRisgAB9Hg1U= In-Reply-To: <7374777208BDC7449D5620EF942325670743C926@esealmw113.eemea.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: IETF SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org No, the point is you almost always use more messages by NOT using INFO. However, fewer messages and not interoperable is not as good as more messages and interoperable. On 7/21/07 2:51 PM, "Christer Holmberg (JO/LMF)" wrote: >=20 >=20 > Hi, >=20 >> [Moved to SIP by chair request] >>=20 >> MUMBLEBRATZ for UA-to-UA communication will always work if >> you own the endpoints. Might as well use INFO for MUMBLEBRATZ. >>=20 >> If one wants interoperable communication or if you want to >> deploy equipment from more than one vendor, or at least not >> having to specify exact behavior (i.e., creating your own >> proprietary protocol), INFO doesn't work, as already documented. >=20 > If you are going to use INFO to carry videoControl messages, of course th= ose > messages, and the meaning of those, must be defined and documented - in o= rder > to make them non-proprietary. >=20 > It's the same with ISUP. You use INFO to carry SPECIFIED ISUP messages, a= nd > endpoints supporting ISUP know the procedures how to deal with the messag= es, > because it is defined in standard documentation. >=20 >> For that matter, we can save a ton of messages if we drop all >> the pesky negotiation in SIP. Why bother if we just "know" >> what the endpoints will accept. We just need to start >> sending RTP and things will just work :-) >=20 > Please show me message you save by not using INFO. The negotiation can in= most > cases be "encapsulated" in SIP messages you are going to send anyway. >=20 > But, if you use an event based mechanism, you actually WILL get more SIP > messages, because you need to send the NOTIFY request(s). >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >>=20 >>=20 >> On 7/18/07 10:10 AM, "Jesske, R" wrote: >>=20 >>> Dear all, >>> I'm concerned about the discussion here and the aim of the draft to >>> restrict the use of INFO only to SIP-T and Q-SIG. >>>=20 >>> If you now change restrict the RFC2976 you will tear down each >>> implementation already done based on RFC2976. Like for DTMF that is >>> broadly used within the world. So you are against backward >> compatibility? >>>=20 >>> The draft is claiming that INFO has to be routed over each >> proxy where >>> the INVITE is routed to. I do not know what's the problem >> with that. A >>> proxy forwards and the question is how much load will this >> cause. UA's >>> can sent re-INVITES or REGISTER, RE-REGISTER a couple of >> times and nobody claims that. >>> INFO is used for UA to UA communication so is this not >> proper enough >>> that at least the UA's will know what to do with the MIME? >>> INFO is ideal to sent information that has to correlate with the >>> Dialog using other mechanisms like an 2nd stream like http or a >>> MESSAGE or a other control protocol can not fulfil this. >> Even it could >>> be get lost when you want to traverse several SIP domains >> or if you interwork with the PSTN/ISDN. >>>=20 >>> The Example of DTMF for INFO can only be done at mid dialog. >>>=20 >>> Using KPML --> We have minimum 4 more Messages. No additional Load? >>>=20 >>>=20 >>>=20 >>> Best Regards >>>=20 >>> Roland >>>=20 >>>=20 >>>=20 >>>> -----Urspr=FCngliche Nachricht----- >>>> Von: Christer Holmberg (JO/LMF) >>>> [mailto:christer.holmberg@ericsson.com] >>>> Gesendet: Mittwoch, 18. Juli 2007 12:18 >>>> An: Dean Willis >>>> Cc: IETF Sipping List >>>> Betreff: RE: [Sipping] comments on draft-burger-sip-info-00 >>>>=20 >>>>=20 >>>>=20 >>>> Hi, >>>>=20 >>>>>>>> - I disagree with the statement in chapter 1 regarding >>>> the "context >>>>>>>> for interpreting". The context is associated with the >>>> content type. >>>>>>>>=20 >>>>>>>=20 >>>>>>> Content type is, as I have repeatedly argued, completely >>>> insufficient >>>>=20 >>>>>>> for interpretation of context in the general case. What, >>>> for example, >>>>=20 >>>>>>> does it mean when an INFO shows up with a wav file >>>> attached? Play it? >>>>>>> Record it? Parse it using speech recognition and pass it >>>> to a command >>>>=20 >>>>>>> processor? >>>>>>=20 >>>>>> The dialog (you can't send INFOs out-of-dialog, as far as I >>>> know) will >>>>=20 >>>>>> be associated with an application, and if the application >>>> doesn't know >>>>=20 >>>>>> what to do with it, it can promt the user: "You have now >> received a >>>>>> file. What do you want to do with it? Save it? Play it? >> Display it? >>>>>> Delete it?". >>>>>=20 >>>>> And how does the receiver know what the sender intended? >>>>>=20 >>>>> Assume you're taking to my "phone" application. You send digits. >>>>> Should those be rendered to me, or fed into the user >> interface of a >>>>> phone-based game we happen to be playing? >>>>=20 >>>> How do you solve it with 2833? >>>>=20 >>>> How do you solve it with KPML? >>>>=20 >>>> You could even have the same problem with normal voice, e.g. >>>> if the game >>>> is controlled using voice recognition. Shall the received voice be >>>> fed to the speaker, or fed to the game application? >>>>=20 >>>> In some cases it may not matter if the data is fed to multiple >>>> applications. But, if you do need to dispatch data so specific >>>> applications you either need some kind of application >> reference, or >>>> you handle the dispatching locally in your device (the game >>>> application can tell it wants DTMFs, and/or the device chooses - >>>> either automatically or manually - which application will get the >>>> data etc). Or you use different SIP sessions. >>>>=20 >>>> In other cases you will not have the problem. For example, >>>> videoControl messages would normally be fed to a video control >>>> application, and nowhere else. >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Sipping mailing list >> https://www1.ietf.org/mailman/listinfo/sipping >>>> This list is for NEW development of the application of SIP Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sip@ietf.org for new developments of core SIP >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sip@ietf.org for new developments of core SIP >>=20 >>=20 >> Notice: This email message, together with any attachments, >> may contain information of BEA Systems, Inc., its >> subsidiaries and affiliated entities, that may be >> confidential, proprietary, copyrighted and/or legally >> privileged, and is intended solely for the use of the >> individual or entity named in this message. If you are not >> the intended recipient, and have received this message in >> error, please immediately return this by email and then delete it. >>=20 >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >>=20 >=20 Notice: This email message, together with any attachments, may contain inf= ormation of BEA Systems, Inc., its subsidiaries and affiliated entiti= es, that may be confidential, proprietary, copyrighted and/or legally p= rivileged, and is intended solely for the use of the individual or entity n= amed in this message. If you are not the intended recipient, and have recei= ved this message in error, please immediately return this by email and then= delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 21 21:41:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICQRy-0005jS-Up; Sat, 21 Jul 2007 21:41:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICQRw-0005if-3F for sip-confirm+ok@megatron.ietf.org; Sat, 21 Jul 2007 21:41:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICQRu-0005iW-Kb for sip@ietf.org; Sat, 21 Jul 2007 21:41:31 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICQRu-0005MH-2W for sip@ietf.org; Sat, 21 Jul 2007 21:41:30 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6M1fLRL032275; Sat, 21 Jul 2007 18:41:21 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6M1emRj009701; Sat, 21 Jul 2007 18:40:49 -0700 Received: from 172.24.29.208 ([172.24.29.208]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 22 Jul 2007 01:41:20 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Sat, 21 Jul 2007 21:41:18 -0400 Subject: Re: [Sip] INFO and Content Negotiation From: Eric Burger To: "Christer Holmberg (JO/LMF)" , IETF SIP Message-ID: Thread-Topic: [Sip] INFO and Content Negotiation Thread-Index: AcfLCn9Zvg80MTb9EdyGRgAWy4mm/wAepRIgAB8UkTU= In-Reply-To: <7374777208BDC7449D5620EF942325670743C925@esealmw113.eemea.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The point is that content type alone is not sufficient for INFO negotiation= . You are a RFC 4722-aware device. You advertise you accept a DTMF payload type. I am an INFO-aware device. I see you understand a DTMF payload, so = I send it to you in an *INFO* message. You barf, because you were expecting KPML. On 7/21/07 2:51 PM, "Christer Holmberg (JO/LMF)" wrote: >=20 >=20 > Hi, >=20 > I don't really understand your issue here... Did you send the text using = INFO, > or something? ;) >=20 > Regards, >=20 > Christer >=20 >> -----Original Message----- >> From: Eric Burger [mailto:eburger@bea.com] >> Sent: 20. hein=E4kuuta 2007 23:14 >> To: IETF SIP >> Subject: [Sip] INFO and Content Negotiation >>=20 >> 12 second proof point of why content type doesn't work. >>=20 >> So here comes an INVITE. I am an INFO-friendly UAS. I >> negotiate by using Accept. >>=20 >> This INVITE has the line: >> Accept: application/kpml-response+xml >>=20 >>=20 >> Wow! This is great! I know the UAC *wants* DTMF. Why? >> Because it accepts a DTMF content type. Excellent - I can >> now send them DTMF. >>=20 >> The user enters a digit, and I send an INFO with type >> application/kpml-response+xml. >>=20 >> UAC says, "What the heck was that?" >>=20 >>=20 >> Notice: This email message, together with any attachments, >> may contain information of BEA Systems, Inc., its >> subsidiaries and affiliated entities, that may be >> confidential, proprietary, copyrighted and/or legally >> privileged, and is intended solely for the use of the >> individual or entity named in this message. If you are not >> the intended recipient, and have received this message in >> error, please immediately return this by email and then delete it. >>=20 >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >>=20 >=20 Notice: This email message, together with any attachments, may contain inf= ormation of BEA Systems, Inc., its subsidiaries and affiliated entiti= es, that may be confidential, proprietary, copyrighted and/or legally p= rivileged, and is intended solely for the use of the individual or entity n= amed in this message. If you are not the intended recipient, and have recei= ved this message in error, please immediately return this by email and then= delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 21 21:45:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICQVU-0000dh-5j; Sat, 21 Jul 2007 21:45:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICQVQ-0000dU-PY for sip-confirm+ok@megatron.ietf.org; Sat, 21 Jul 2007 21:45:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICQVO-0000dJ-58 for sip@ietf.org; Sat, 21 Jul 2007 21:45:06 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICQVN-0000rr-CV for sip@ietf.org; Sat, 21 Jul 2007 21:45:05 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l6M1ixcx013021; Sat, 21 Jul 2007 20:44:59 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 20:45:01 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 03:44:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Jul 2007 03:44:54 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800147394E@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-polk-sip-rph-in-responses-00 Thread-Index: AcfMAebNG/TzLGM8RXGq1jjekOCwLQ== From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 22 Jul 2007 01:44:56.0530 (UTC) FILETIME=[E827BB20:01C7CC01] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: "James M. Polk" Subject: [Sip] Comments on draft-polk-sip-rph-in-responses-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org 1) IANA registry. The current IANA registry contents created by RFC 4412 is merely: Header Name compact Reference ----------------- ------- --------- Accept-Resource-Priority [RFC4412] Resource-Priority [RFC4412] The only IANA registry change required to to add this draft to the reference against Resource-Priority, and not to do what is currently listed in section 4. Additionally statements in section 1: This document IANA registers the Resource-Priority header for usage=20 in responses. And The above is to replace what is currently stated by RFC 4412, and=20 what is IANA registered. Should also be corrected. 2) Section 3.1 of RFC 4412 specifies: There is no protocol requirement that all requests within a SIP dialog or session use the 'Resource-Priority' header field. Local administrative policy MAY mandate the inclusion of the 'Resource-Priority' header field in all requests. Implementations of this specification MUST allow inclusion to be either by explicit user request or automatic for all requests. I assume that the usage of the header in responses is an extension of the administrative policy stated above, and therefore this linkage needs to be made. For example, I read the above text to indicate that a stateful proxy could receive the header in a initial INVITE request, and treat all requests and responses in the same dialog with priority. In this case, I therefore do not need the header in subsequent requests, and equally I don't need it in any responses either. 3) RFC 4412 divides the SIP methods into a set of classes giving various levels of support. I assume that these classes also apply for the support of responses, but I can currently find no text that indicates that. 4) RFC 4412 indicates for example: A SIP request with a 'Resource-Priority' indication can be treated differently in these situations: 1. The request can be given elevated priority for access to PSTN gateway resources, such as trunk circuits. 2. The request can interrupt lower-priority requests at a user terminal, such as an IP phone. 3. The request can carry information from one multi-level priority domain in the telephone network (e.g., using the facilities of Q.735.3 [Q.735.3]) to another, without the SIP proxies themselves inspecting or modifying the header field. 4. In SIP proxies and back-to-back user agents, requests of higher priorities may displace existing signaling requests or bypass PSTN gateway capacity limits in effect for lower priorities. This also applies equally for the responses discussed in this document. We probably need some general text that basically says that what RFC 4412 specifies for requests, also applies to responses when implementing this document. This is both at the requirement level and the discussion level. 5) Section 2.3 of this document indicates: SIP Proxies MAY process the Resource-Priority header in responses;=20 meaning, in certain environments, the choice of whether or not to=20 process the RPH will not be in doubt. =20 Section 4.7.3 of RFC 4412 states: SIP proxies MAY ignore the 'Resource-Priority' header field. SIP proxies MAY reject any unauthenticated request bearing that header field. However, I assume that what 2.3 is attempting to state is not the above for responses, but rather: Even though the proxy processes the header in requests, it may ignore the header in responses. Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 21 21:47:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICQXa-00021I-Mw; Sat, 21 Jul 2007 21:47:22 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICQXZ-00021B-9N for sip-confirm+ok@megatron.ietf.org; Sat, 21 Jul 2007 21:47:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICQXW-000212-Ue for sip@ietf.org; Sat, 21 Jul 2007 21:47:19 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICQXV-0005UB-JA for sip@ietf.org; Sat, 21 Jul 2007 21:47:18 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6M1lFfN008223; Sat, 21 Jul 2007 18:47:15 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6M1kgZu017797; Sat, 21 Jul 2007 18:46:43 -0700 Received: from 172.24.29.208 ([172.24.29.208]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 22 Jul 2007 01:47:14 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Sat, 21 Jul 2007 21:47:12 -0400 Subject: Re: [Sip] comments on draft-camarillo-sip-body-handling-01 From: Eric Burger To: Jonathan Rosenberg , IETF SIP List Message-ID: Thread-Topic: [Sip] comments on draft-camarillo-sip-body-handling-01 Thread-Index: AcfMAjjmdy4EgTf1EdyicAAWy4mm/w== In-Reply-To: <469E193A.4020402@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is the way MIME works. Please don't change it! On 7/18/07 9:44 AM, "Jonathan Rosenberg" wrote: [snip] > For multipart/alternative - I don't understand the requirement to order > them from least to most 'rich'. Is that a general MIME behavior or are > we defining it that way? If we want to prioritize, shouldn't we use an > explicit q-value or something? Using order seems like it will be brittle > (as it has been in SDP where m-lines were never numbered). [snip] Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 21 21:48:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICQYm-0002Yf-Nh; Sat, 21 Jul 2007 21:48:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICQYl-0002YT-BE for sip-confirm+ok@megatron.ietf.org; Sat, 21 Jul 2007 21:48:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICQYk-0002YH-02 for sip@ietf.org; Sat, 21 Jul 2007 21:48:34 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICQYi-0005VZ-LJ for sip@ietf.org; Sat, 21 Jul 2007 21:48:33 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6M1mI8H009558; Sat, 21 Jul 2007 18:48:18 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6M1lhTg018970; Sat, 21 Jul 2007 18:47:43 -0700 Received: from 172.24.29.208 ([172.24.29.208]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 22 Jul 2007 01:48:14 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Sat, 21 Jul 2007 21:48:12 -0400 Subject: Re: [Sip] comments on draft-camarillo-sip-body-handling-01 From: Eric Burger To: Qian Sun , Gonzalo Camarillo Message-ID: Thread-Topic: [Sip] comments on draft-camarillo-sip-body-handling-01 Thread-Index: AcfKMte8iABTRIOyQ5OAKtTf+AKf2gAaSDyQAFmY/0A= In-Reply-To: <007501c7caa3$b8f962e0$7c6c460a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Seems like a good idea. However, I would not go so far as to mandate iterative evaluation. I would offer that the UA evaluates as needed. On 7/20/07 3:58 AM, "Qian Sun" wrote: > Hi, > I suggest Content Indirection Mechanism defined in rfc4483 should also be > considered in this draft. > > It is a little special, an example from rfc4483: > 6.1. Single Content Indirection > > INVITE sip:boromir@example.com SIP/2.0 > Accept: message/external-body application/sdp > Content-Type: message/external-body; > ACCESS-TYPE=URL; > URL="http://www.example.net/party/06/2002/announcement"; > EXPIRATION="Sat, 20 Jun 2002 12:00:00 GMT"; > size=231 > Content-Length: 105 > > Content-Type: application/sdp > Content-Disposition: session > Content-ID: <4e5562cd1214427d@example.net> > > In addition, what happens to the INVITE request if the recipient can not get > the indirect content? > > Nits: a letter "l" is missing in the title. > Internet-Draft Message Body Hand"l"ing in SIP May 2007 > > Cheers, > Qian > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, July 20, 2007 2:30 AM > To: Gonzalo Camarillo > Cc: IETF SIP List > Subject: Re: [Sip] comments on draft-camarillo-sip-body-handling-01 > > Just one comment in addition to what Gonzalo said: > > Gonzalo Camarillo wrote: > >>> The use case described for multipart/alternative - new SDP mechanisms >>> - seems kind of bogus. We've decided not to pursue that. Do we have a >>> REAL use case for this? >> >> AFAICT, we have decided not to pursue SDPng but we still need a >> mechanism in order to be able to, at some point, migrate to new session >> description formats. The current consensus, as I understand it, is that >> multipart/alternative should not be used to provide alternative SDP >> descriptions, but that it could be used to provide alternative session >> descriptions written in different formats. > > The other classic example, because it is just like email, is MESSAGE > with a multipart/alternative containing plain text and html. > > Paul > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 21 21:50:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICQaG-0002x3-Gd; Sat, 21 Jul 2007 21:50:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICQaG-0002wy-0u for sip-confirm+ok@megatron.ietf.org; Sat, 21 Jul 2007 21:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICQaE-0002wq-MH for sip@ietf.org; Sat, 21 Jul 2007 21:50:06 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICQaD-0005Xn-Bc for sip@ietf.org; Sat, 21 Jul 2007 21:50:06 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6M1nwsw012314; Sat, 21 Jul 2007 18:49:58 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6M1nPVW021259; Sat, 21 Jul 2007 18:49:26 -0700 Received: from 172.24.29.208 ([172.24.29.208]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 22 Jul 2007 01:49:57 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Sat, 21 Jul 2007 21:49:55 -0400 Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides for body (MIME) handling) From: Eric Burger To: Paul Kyzivat , Gonzalo Camarillo Message-ID: Thread-Topic: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides for body (MIME) handling) Thread-Index: AcfMApoO2HNpYTf1EdyicAAWy4mm/w== In-Reply-To: <469F6E3A.3000203@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I would offer this is where we can "add value" to MIME for SIP usage. Note that I do not say, "deviate from MIME." I would suggest we NOT try to deviate from MIME in any respect. On 7/19/07 9:59 AM, "Paul Kyzivat" wrote: [snip] > I think we just have to grandfather the use of 'refer' in SIP, and > document that the usage in sip does not mean "render", but rather means > that the usage must be determined by other context - specifically the > type of message or response and the content type. IOW, 'render' in sip > can be thought of as a peculiar spelling for 'by-context'. It might be > helpful to give guidance for development of future specs about when > 'render' should be used vs defining a new disposition. [snip] Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 21 21:51:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICQby-0003nA-Us; Sat, 21 Jul 2007 21:51:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICQbx-0003mc-BC for sip-confirm+ok@megatron.ietf.org; Sat, 21 Jul 2007 21:51:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICQbw-0003mT-At for sip@ietf.org; Sat, 21 Jul 2007 21:51:52 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICQbv-0005Zt-0j for sip@ietf.org; Sat, 21 Jul 2007 21:51:52 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6M1phl9014667; Sat, 21 Jul 2007 18:51:43 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6M1pAxB023348; Sat, 21 Jul 2007 18:51:10 -0700 Received: from 172.24.29.208 ([172.24.29.208]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 22 Jul 2007 01:51:41 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Sat, 21 Jul 2007 21:51:39 -0400 Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides for body (MIME) handling) From: Eric Burger To: Qian Sun , Gonzalo Camarillo Message-ID: Thread-Topic: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides for body (MIME) handling) Thread-Index: AcfKMLSR55JFwCImSmeHx5F3gWmlCAAgQCMwAFRIu8M= In-Reply-To: <007601c7cab5$4dce3740$7c6c460a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: 'sip' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I respectfully disagree on this one. Here we are not talking about disposition, but about the context of the content. In the case of "advertisement", we are noting the context of the content. It is up to the application (user) to decide to display ads or block ads. It is NOT up to the sender. On 7/20/07 6:04 AM, "Qian Sun" wrote: > Hi, > > If we define a new Content Disposition type "advertisement" so that the > operator or service provider may insert advertisement in the all kinds of > message body. And we want the advertisement content 'render' to the users. > Could we use multiple content dispositions ("advertisement" and 'render') for > a single content part? Or only define a new Content Disposition Parameters > "advertisement" instead? > > This is a real requirement, OMA and GSM is developing the mobile advertisement > spec. the current advertisement way in Email or Webpage is very "evil", it is > difficult for the user's client to distinguish the real content from > advertisement, sometimes this is very disgusting or confusing. A new Content > Disposition type "advertisement" or something else could be helpful, the > advertisement may be displayed in a place different from the content. > > Cheers, > Qian > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, July 20, 2007 2:15 AM > To: Gonzalo Camarillo > Cc: sip > Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides for > body (MIME) handling) > > > > Gonzalo Camarillo wrote: >> Hi, >> >> yes, I agree there is a bigger issue with 'render'. Even though this >> bigger issue does not directly relate to multipart, we can also tackle >> it in the same draft and clarify how 'render' is used and what it means. > > Sounds good. Maybe its just a matter of changing the title of the draft > to match the scope. Something like: > draft-sipping-content-type-disp-clarification-nn.txt > > Paul > >> Cheers, >> >> Gonzalo >> >> >> Paul Kyzivat wrote: >>> >>> >>> Gonzalo Camarillo wrote: >>>> Hi Paul, >>>> >>>>> Regarding Content-Disposition in multiparts: >>>>> >>>>> While it seems "wrong" to me, I can live with using "render" as the >>>>> normal disposition for multipart, *if* we can do a careful job of >>>>> defining what "render" actually means for SIP. Used this way it >>>>> clearly doesn't always mean to display the content to a user. >>>> >>>> An entity receiving a 'multipart/mixed' body will process its body >>>> parts based on their disposition types.If the disposition type of a >>>> particular body part is not understood, it will be displayed to the >>>> user because the default disposition type is 'render'. >>> >>> There is a bigger problem with 'render' than just multipart. >>> >>> We have many uses of body parts that never mention Content-Disposition >>> at all. The related examples don't use it, and so they all get a >>> default of 'render'. This is particularly the case with events. E.g. >>> >>> - the notification for REFER contains type application/sipfrag. >>> Its probably not intended to be "rendered" in any literal sense, >>> though some conclusion about success or failure may be. >>> >>> - usage of filter bodies in presence subscriptions (RFC 4660) >>> doesn't have a specified disposition, so it implicitly uses render. >>> Its hard for me to convince myself that what the presence server >>> does with these can be described as rendering. >>> >>> - In fact, the only place I can think of where 'render' is (implicitly) >>> used in sip and has the appropriate connotation is in MESSAGE. >>> >>> I think we just have to grandfather the use of 'refer' in SIP, and >>> document that the usage in sip does not mean "render", but rather >>> means that the usage must be determined by other context - >>> specifically the type of message or response and the content type. >>> IOW, 'render' in sip can be thought of as a peculiar spelling for >>> 'by-context'. It might be helpful to give guidance for development of >>> future specs about when 'render' should be used vs defining a new >>> disposition. >>> >>>> Therefore, the 'multipart/mixed' body will never be processed based >>>> on its disposition type. >>> >>> Based on my discussion above, I would consider this a case of the >>> multipart being processed according to its context *because* its >>> content-disposition is 'refer'. If it had some other >>> content-disposition then that might mean that it should be processed >>> specially. E.g. if a multipart/mixed had disposition 'by-reference' >>> then that needs to be taken into account, and the processing of the >>> multipart becomes conditional on the reference. >>> >>> Also, there are only certain contexts in which multipart should be >>> processed "normally". Consider a NOTIFY from a REFER, with a >>> Content-Type of message/sipfrag, which happened to include a body as >>> part of the fragment. (This is legal.) That body might contain a >>> multipart/mixed, and that might contain other stuff. But I think the >>> processing of all of that is dependent on processing of the sipfrag. >>> For instance, if something inside that had handling=required, I don't >>> think that means that processing of the NOTIFY fails because the >>> recipient can't handle that. >>> >>>> This means that it does not make much sense to talk about its >>>> disposition type as a whole. >>> >>> Counterexample above. >>> >>>> However, we need to have one in order to be able to set its handling >>>> parameter. That's why we can either keep 'render' explaining that it >>>> is actually never used or define a new disposition type. >>> >>> I can go either way on that. But because there is existing usage, and >>> because 'render' semantics are already so messed up, I think it makes >>> more sense to stick with 'render' and just clarify its meaning. >>> >>>> Since existing implementations will not understand our newly defined >>>> disposition type, they will treat it as 'render' anyway... but the >>>> resulting behavior would be the same. That's why it may make sense to >>>> keep using 'render'. >>> >>> Yup. >>> >>>> On the other hand, semantically, it would make more sense to define a >>>> new disposition type. >>>> >>>> Also, if we decide to define the 'by-reference' disposition type (per >>>> a different email thread), it could be used here as well. >>> >>> It could be used when there is actually a reference to it. But it >>> would not be an appropriate disposition to use when there is no >>> reference to the multipart. >>> >>> Thanks, >>> Paul >>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >>>> >>>> >>>>> Gonzalo Camarillo wrote: >>>>>> Folks, >>>>>> >>>>>> here you have the slides I have put together for the body (MIME) >>>>>> handling presentation on Monday: >>>>>> >>>>>> http://users.piuha.net/gonzalo/temp/ietf69-sip-camarillo-body-handling.pp >>>>>> t >>>>>> >>>>>> >>>>>> These slides relate to this draft: >>>>>> >>>>>> http://www.ietf.org/internet-drafts/draft-camarillo-sip-body-handling-01. >>>>>> txt >>>>>> >>>>>> >>>>>> The slides discuss all the open issues that have been brought up in >>>>>> the list in the last months. >>>>>> >>>>>> Comments are welcome. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Gonzalo >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP Protocol >>>>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>>>> Use sipping@ietf.org for new developments on the application of sip >>>>>> >>>> >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 22 00:15:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICSrE-0001Un-5f; Sun, 22 Jul 2007 00:15:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICSrD-0001Ui-0C for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 00:15:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICSrC-0001Ua-Lr for sip@ietf.org; Sun, 22 Jul 2007 00:15:46 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICSrB-0008FZ-Dw for sip@ietf.org; Sun, 22 Jul 2007 00:15:46 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6M4FilU000093; Sat, 21 Jul 2007 23:15:44 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 23:15:43 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 06:15:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Jul 2007 06:15:39 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001473951@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-polk-sip-rph-new-namespaces-00 Thread-Index: AcfMFvYrs1jkKFRbQlentoZ1vrGQJA== From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 22 Jul 2007 04:15:41.0446 (UTC) FILETIME=[F7586260:01C7CC16] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: "James M. Polk" Subject: [Sip] Comments on draft-polk-sip-rph-new-namespaces-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org 1) I am not convinced this document does updated RFC 4412. RFC 4412 creates the namespace. This document merely adds new items to the IANA registry created by that document. The document header should be modified accordingly, and the following text in the abstract also corrected: This=20 document intends to update RFC 4412, as a Proposed Standard document if published by the RFC-Editor. 2) I believe the abstract could usefully summarise the new namespaces that are created (in the same way as most drafts that define new headers identify them in the abstract). 3) In section 3, I do not see the need to include the following text in the document, as it is already in RFC 4412, for which all the requirements apply, not just this one. As stated in Section 9 of RFC 4412 [RFC4412], an IANA registered=20 namespace SHOULD NOT change the number, and MUST NOT change the=20 relative priority order, of its assigned priority-values. 4) NIT. Tag all mentions of RFC4412 as references. Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 22 00:17:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICSsZ-0002LJ-Fh; Sun, 22 Jul 2007 00:17:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICSsY-0002LE-BP for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 00:17:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICSsY-0002L5-1R for sip@ietf.org; Sun, 22 Jul 2007 00:17:10 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICSsX-0008HF-KE for sip@ietf.org; Sun, 22 Jul 2007 00:17:10 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Jul 2007 00:17:09 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusRACR3okZAZnme/2dsb2JhbACIXpxd X-IronPort-AV: i="4.16,567,1175486400"; d="scan'208"; a="126680851:sNHT31657672" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6M4H9nq004245; Sun, 22 Jul 2007 00:17:09 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6M4H4EZ017830; Sun, 22 Jul 2007 04:17:04 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 00:17:04 -0400 Received: from [10.86.240.164] ([10.86.240.164]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 00:17:04 -0400 Message-ID: <46A2DA3F.4050602@cisco.com> Date: Sun, 22 Jul 2007 00:17:03 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Eric Burger Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides for body (MIME) handling) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2007 04:17:04.0121 (UTC) FILETIME=[289F9690:01C7CC17] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2054; t=1185077829; x=1185941829; c=relaxed/simple; s=rtpdkim1001; 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=20Content-Disposition=20in=20multiparts=20WAS=20(Re=3A= 20[Sip]=20Draft=20slides=0A=20for=20body=20(MIME)=20handling) |Sender:=20 |To:=20Eric=20Burger=20; bh=hQqJDX85Fe9s3fWxznVLUw4m2knUr1iNPmoMLhpeUTM=; b=Z8MuTmNHz5ZUUWuqEfIMJVwmHZgOXQbLAUmhwhhe2CEguwFyS542V3SpLGQz5byIbE4ZDy2m 1tiN8DHqjiq7AXjdXD0CwgI+GNda7gClqiu6XoAE1xqrvz8C9qg+VmkC; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sip , Gonzalo Camarillo X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Eric Burger wrote: > I would offer this is where we can "add value" to MIME for SIP usage. Note > that I do not say, "deviate from MIME." I would suggest we NOT try to > deviate from MIME in any respect. Oh MIME sage, your comment is inscrutable! :-) I don't understand in this case where the line is between "adding value" and "deviating". If we try to ascribe some common meaning to "render" then I believe sip is already violating it. If we have thus already "deviated" from MIME, which takes precedence: correcting the deviation, or backward compatibility. My assumption is that backward compatibility is more important. Paul > On 7/19/07 9:59 AM, "Paul Kyzivat" wrote: > [snip] >> I think we just have to grandfather the use of 'refer' in SIP, and >> document that the usage in sip does not mean "render", but rather means >> that the usage must be determined by other context - specifically the >> type of message or response and the content type. IOW, 'render' in sip >> can be thought of as a peculiar spelling for 'by-context'. It might be >> helpful to give guidance for development of future specs about when >> 'render' should be used vs defining a new disposition. > [snip] > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 22 00:21:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICSwT-0006Im-7J; Sun, 22 Jul 2007 00:21:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICSwQ-0006If-QL for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 00:21:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICSwQ-0006IX-Gl for sip@ietf.org; Sun, 22 Jul 2007 00:21:10 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICSwP-0008K9-IJ for sip@ietf.org; Sun, 22 Jul 2007 00:21:10 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Jul 2007 00:21:09 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusRAEd4okZAZnme/2dsb2JhbACIXpxe X-IronPort-AV: i="4.16,567,1175486400"; d="scan'208"; a="126680942:sNHT31401710" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6M4L9vW004948; Sun, 22 Jul 2007 00:21:09 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6M4L7EZ018685; Sun, 22 Jul 2007 04:21:07 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 00:21:06 -0400 Received: from [10.86.240.164] ([10.86.240.164]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 00:21:06 -0400 Message-ID: <46A2DB31.8080903@cisco.com> Date: Sun, 22 Jul 2007 00:21:05 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Eric Burger Subject: Re: [Sip] comments on draft-camarillo-sip-body-handling-01 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2007 04:21:06.0379 (UTC) FILETIME=[B90539B0:01C7CC17] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4214; t=1185078069; x=1185942069; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20comments=20on=20draft-camarillo-sip-body-hand ling-01 |Sender:=20 |To:=20Eric=20Burger=20; bh=iO4BzLZSJJaHdKQQdMITOFWZnyQmnofS99jjT/883sc=; b=Pcu737z8Z+vmXuX+I4hHKqqQW/UaLFb3xJWdxcJ5OJS3bVHKe7YZrhYL2hv2rPZncNVUJywh 1e7llQxCXFndA1OjzhHnUGyf9VLqYMjeqvLDvoWHtT43QYm3OAcfpRFX; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: 'IETF SIP List' , Gonzalo Camarillo X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org One of the tasks of the draft is to make support for at least some subtypes of multipart (e.g. mixed) mandatory. I hope this is not a suggestion to make dereferencing of external bodies mandatory. If the request is just to include some clarification of the use and handling of external bodies in this draft then I guess that does sound useful. Paul Eric Burger wrote: > Seems like a good idea. However, I would not go so far as to mandate > iterative evaluation. I would offer that the UA evaluates as needed. > > > On 7/20/07 3:58 AM, "Qian Sun" wrote: > >> Hi, >> I suggest Content Indirection Mechanism defined in rfc4483 should also be >> considered in this draft. >> >> It is a little special, an example from rfc4483: >> 6.1. Single Content Indirection >> >> INVITE sip:boromir@example.com SIP/2.0 >> Accept: message/external-body application/sdp >> Content-Type: message/external-body; >> ACCESS-TYPE=URL; >> URL="http://www.example.net/party/06/2002/announcement"; >> EXPIRATION="Sat, 20 Jun 2002 12:00:00 GMT"; >> size=231 >> Content-Length: 105 >> >> Content-Type: application/sdp >> Content-Disposition: session >> Content-ID: <4e5562cd1214427d@example.net> >> >> In addition, what happens to the INVITE request if the recipient can not get >> the indirect content? >> >> Nits: a letter "l" is missing in the title. >> Internet-Draft Message Body Hand"l"ing in SIP May 2007 >> >> Cheers, >> Qian >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, July 20, 2007 2:30 AM >> To: Gonzalo Camarillo >> Cc: IETF SIP List >> Subject: Re: [Sip] comments on draft-camarillo-sip-body-handling-01 >> >> Just one comment in addition to what Gonzalo said: >> >> Gonzalo Camarillo wrote: >> >>>> The use case described for multipart/alternative - new SDP mechanisms >>>> - seems kind of bogus. We've decided not to pursue that. Do we have a >>>> REAL use case for this? >>> AFAICT, we have decided not to pursue SDPng but we still need a >>> mechanism in order to be able to, at some point, migrate to new session >>> description formats. The current consensus, as I understand it, is that >>> multipart/alternative should not be used to provide alternative SDP >>> descriptions, but that it could be used to provide alternative session >>> descriptions written in different formats. >> The other classic example, because it is just like email, is MESSAGE >> with a multipart/alternative containing plain text and html. >> >> Paul >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 22 01:47:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICUHU-0003Hc-SX; Sun, 22 Jul 2007 01:47:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICUHT-0003HU-ET for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 01:46:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICUHS-0003HL-Vh for sip@ietf.org; Sun, 22 Jul 2007 01:46:59 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICUHS-0005ZH-9w for sip@ietf.org; Sun, 22 Jul 2007 01:46:58 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6M5krdv006848; Sat, 21 Jul 2007 22:46:53 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6M5kpi9015370; Sat, 21 Jul 2007 22:46:52 -0700 Received: from 172.24.29.106 ([172.24.29.106]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 22 Jul 2007 05:46:51 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Sun, 22 Jul 2007 01:46:49 -0400 Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides for body (MIME) handling) From: Eric Burger To: Paul Kyzivat Message-ID: Thread-Topic: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides for body (MIME) handling) Thread-Index: AcfMFy+eIJtCvbQTRYGOE1I1MKv1egADIKnI In-Reply-To: <46A2DA3F.4050602@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: sip , Gonzalo Camarillo X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Well, we are only sort-of munging MIME. The default is always RENDER. However, *what* is a render is an exercise for the protocol to specify. That is the wiggle room for SIP to say "render means by-context." What we do not have the wiggle room for is to say the default content-disposition is something other than RENDER. On 7/22/07 12:17 AM, "Paul Kyzivat" wrote: > > > > Eric Burger wrote: >> I would offer this is where we can "add value" to MIME for SIP usage. Note >> that I do not say, "deviate from MIME." I would suggest we NOT try to >> deviate from MIME in any respect. > > Oh MIME sage, your comment is inscrutable! :-) > > I don't understand in this case where the line is between "adding value" > and "deviating". > > If we try to ascribe some common meaning to "render" then I believe sip > is already violating it. If we have thus already "deviated" from MIME, > which takes precedence: correcting the deviation, or backward compatibility. > > My assumption is that backward compatibility is more important. > > Paul > >> On 7/19/07 9:59 AM, "Paul Kyzivat" wrote: >> [snip] >>> I think we just have to grandfather the use of 'refer' in SIP, and >>> document that the usage in sip does not mean "render", but rather means >>> that the usage must be determined by other context - specifically the >>> type of message or response and the content type. IOW, 'render' in sip >>> can be thought of as a peculiar spelling for 'by-context'. It might be >>> helpful to give guidance for development of future specs about when >>> 'render' should be used vs defining a new disposition. >> [snip] >> >> >> Notice: This email message, together with any attachments, may contain >> information of BEA Systems, Inc., its subsidiaries and affiliated >> entities, that may be confidential, proprietary, copyrighted and/or >> legally privileged, and is intended solely for the use of the individual or >> entity named in this message. If you are not the intended recipient, and have >> received this message in error, please immediately return this by email and >> then delete it. >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 22 01:48:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICUId-0004Vt-8S; Sun, 22 Jul 2007 01:48:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICUIb-0004Uw-WF for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 01:48:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICUIb-0004S3-IJ for sip@ietf.org; Sun, 22 Jul 2007 01:48:09 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICUIa-0005bD-QA for sip@ietf.org; Sun, 22 Jul 2007 01:48:09 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6M5m0YJ008274; Sat, 21 Jul 2007 22:48:00 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6M5lRRH013542; Sat, 21 Jul 2007 22:47:27 -0700 Received: from 172.24.29.106 ([172.24.29.106]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 22 Jul 2007 05:47:58 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Sun, 22 Jul 2007 01:47:55 -0400 Subject: Re: [Sip] comments on draft-camarillo-sip-body-handling-01 From: Eric Burger To: Paul Kyzivat Message-ID: Thread-Topic: [Sip] comments on draft-camarillo-sip-body-handling-01 Thread-Index: AcfMF8DuA7OGgw6rRyeH/FTbLnvr/QADBipM In-Reply-To: <46A2DB31.8080903@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: IETF SIP List , Gonzalo Camarillo X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The latter: be aware of indirection, but (1) not mandatory and in fact (2) don't bother to fetch the bits unless you absolutely have to. IMHO. Just one vote. On 7/22/07 12:21 AM, "Paul Kyzivat" wrote: > One of the tasks of the draft is to make support for at least some > subtypes of multipart (e.g. mixed) mandatory. > > I hope this is not a suggestion to make dereferencing of external bodies > mandatory. > > If the request is just to include some clarification of the use and > handling of external bodies in this draft then I guess that does sound > useful. > > Paul > > Eric Burger wrote: >> Seems like a good idea. However, I would not go so far as to mandate >> iterative evaluation. I would offer that the UA evaluates as needed. >> >> >> On 7/20/07 3:58 AM, "Qian Sun" wrote: >> >>> Hi, >>> I suggest Content Indirection Mechanism defined in rfc4483 should also be >>> considered in this draft. >>> >>> It is a little special, an example from rfc4483: >>> 6.1. Single Content Indirection >>> >>> INVITE sip:boromir@example.com SIP/2.0 >>> Accept: message/external-body application/sdp >>> Content-Type: message/external-body; >>> ACCESS-TYPE=URL; >>> URL="http://www.example.net/party/06/2002/announcement"; >>> EXPIRATION="Sat, 20 Jun 2002 12:00:00 GMT"; >>> size=231 >>> Content-Length: 105 >>> >>> Content-Type: application/sdp >>> Content-Disposition: session >>> Content-ID: <4e5562cd1214427d@example.net> >>> >>> In addition, what happens to the INVITE request if the recipient can not get >>> the indirect content? >>> >>> Nits: a letter "l" is missing in the title. >>> Internet-Draft Message Body Hand"l"ing in SIP May 2007 >>> >>> Cheers, >>> Qian >>> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Friday, July 20, 2007 2:30 AM >>> To: Gonzalo Camarillo >>> Cc: IETF SIP List >>> Subject: Re: [Sip] comments on draft-camarillo-sip-body-handling-01 >>> >>> Just one comment in addition to what Gonzalo said: >>> >>> Gonzalo Camarillo wrote: >>> >>>>> The use case described for multipart/alternative - new SDP mechanisms >>>>> - seems kind of bogus. We've decided not to pursue that. Do we have a >>>>> REAL use case for this? >>>> AFAICT, we have decided not to pursue SDPng but we still need a >>>> mechanism in order to be able to, at some point, migrate to new session >>>> description formats. The current consensus, as I understand it, is that >>>> multipart/alternative should not be used to provide alternative SDP >>>> descriptions, but that it could be used to provide alternative session >>>> descriptions written in different formats. >>> The other classic example, because it is just like email, is MESSAGE >>> with a multipart/alternative containing plain text and html. >>> >>> Paul >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> >> >> Notice: This email message, together with any attachments, may contain >> information of BEA Systems, Inc., its subsidiaries and affiliated >> entities, that may be confidential, proprietary, copyrighted and/or >> legally privileged, and is intended solely for the use of the individual or >> entity named in this message. If you are not the intended recipient, and have >> received this message in error, please immediately return this by email and >> then delete it. >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 22 02:52:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICVIf-0005d5-Uo; Sun, 22 Jul 2007 02:52:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICVIe-0005cv-9V for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 02:52:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICVIa-0005ck-Cl for sip@ietf.org; Sun, 22 Jul 2007 02:52:12 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICVIZ-0006tC-EI for sip@ietf.org; Sun, 22 Jul 2007 02:52:11 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l6M6pxp11403; Sat, 21 Jul 2007 23:51:59 -0700 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF115AFB45@zrc2hxm0.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437115AA5DDD@zrc2hxm2.corp.nortel.com> <08333B74-4516-4BF7-94EB-6559A6AF8AFF@ekabal.com> <1ECE0EB50388174790F9694F77522CCF115AF631@zrc2hxm0.corp.nortel.com> <4DF02533-B636-40AB-8957-2D791CC4C468@ekabal.com> <1ECE0EB50388174790F9694F77522CCF115AFB45@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9600471E-D73C-4FE1-AA8D-1CD54EB2A475@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Sat, 21 Jul 2007 23:51:59 -0700 To: "Francois Audet" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Cullen Jennings , Rohan Mahy , sip@ietf.org Subject: [Sip] Re: Clarification on draft-ietf-sip-outbound X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 20, 2007, at 4:08 PM, Francois Audet wrote: > > The last sentence of section 8 says "The SIP keepalive STUN usage > requires no backwards > compatibility.". > > It's not clear "with what". > > I'm assuming that you mean it works with rfc3489bis but not RFC 3489? correct. this is one of the things listed that a usage of stun needs to handle. i'll put this in the document. thanks, -rohan > Please clarify (in the document and on the mailing list). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 22 03:05:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICVVq-0000Vd-T2; Sun, 22 Jul 2007 03:05:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICVVo-0000VN-Mu for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 03:05:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICVVo-0000VC-BQ for sip@ietf.org; Sun, 22 Jul 2007 03:05:52 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICVVn-0007EC-2A for sip@ietf.org; Sun, 22 Jul 2007 03:05:52 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 46D2521526; Sun, 22 Jul 2007 09:05:50 +0200 (CEST) X-AuditID: c1b4fb3e-ae831bb0000007e1-5b-46a301cef65a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0F7B8214B3; Sun, 22 Jul 2007 09:05:50 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 09:05:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: AW: [Sipping] comments on draft-burger-sip-info-00 Date: Sun, 22 Jul 2007 09:05:45 +0200 Message-ID: <7374777208BDC7449D5620EF942325670743C978@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: AW: [Sipping] comments on draft-burger-sip-info-00 Thread-Index: AcfIkd0E2RdwcfmQTdmyoddqeaZ0uQAcuMuwAAoux7AAeGF/QQAdRisgAB9Hg1UACz8U8A== References: <7374777208BDC7449D5620EF942325670743C926@esealmw113.eemea.ericsson.se> From: "Christer Holmberg (JO/LMF)" To: "Eric Burger" , "Jesske, R" X-OriginalArrivalTime: 22 Jul 2007 07:05:49.0637 (UTC) FILETIME=[BBE6B750:01C7CC2E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: IETF SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >No, the point is you almost always use more messages by NOT using INFO. I think issues like that should also be documented in your draft. >However, fewer messages and not interoperable is not as good=20 >as more messages and interoperable. Well, the initeroperability issue is still under discussion. Regards, Christer > > Hi, > >=20 > >> [Moved to SIP by chair request] > >>=20 > >> MUMBLEBRATZ for UA-to-UA communication will always work if you own=20 > >> the endpoints. Might as well use INFO for MUMBLEBRATZ. > >>=20 > >> If one wants interoperable communication or if you want to deploy=20 > >> equipment from more than one vendor, or at least not having to=20 > >> specify exact behavior (i.e., creating your own proprietary=20 > >> protocol), INFO doesn't work, as already documented. > >=20 > > If you are going to use INFO to carry videoControl=20 > messages, of course=20 > > those messages, and the meaning of those, must be defined and=20 > > documented - in order to make them non-proprietary. > >=20 > > It's the same with ISUP. You use INFO to carry SPECIFIED ISUP=20 > > messages, and endpoints supporting ISUP know the procedures how to=20 > > deal with the messages, because it is defined in standard=20 > documentation. > >=20 > >> For that matter, we can save a ton of messages if we drop all the=20 > >> pesky negotiation in SIP. Why bother if we just "know" > >> what the endpoints will accept. We just need to start sending RTP=20 > >> and things will just work :-) > >=20 > > Please show me message you save by not using INFO. The=20 > negotiation can=20 > > in most cases be "encapsulated" in SIP messages you are=20 > going to send anyway. > >=20 > > But, if you use an event based mechanism, you actually WILL=20 > get more=20 > > SIP messages, because you need to send the NOTIFY request(s). > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >>=20 > >>=20 > >> On 7/18/07 10:10 AM, "Jesske, R" wrote: > >>=20 > >>> Dear all, > >>> I'm concerned about the discussion here and the aim of=20 > the draft to=20 > >>> restrict the use of INFO only to SIP-T and Q-SIG. > >>>=20 > >>> If you now change restrict the RFC2976 you will tear down each=20 > >>> implementation already done based on RFC2976. Like for=20 > DTMF that is=20 > >>> broadly used within the world. So you are against backward > >> compatibility? > >>>=20 > >>> The draft is claiming that INFO has to be routed over each > >> proxy where > >>> the INVITE is routed to. I do not know what's the problem > >> with that. A > >>> proxy forwards and the question is how much load will this > >> cause. UA's > >>> can sent re-INVITES or REGISTER, RE-REGISTER a couple of > >> times and nobody claims that. > >>> INFO is used for UA to UA communication so is this not > >> proper enough > >>> that at least the UA's will know what to do with the MIME? > >>> INFO is ideal to sent information that has to correlate with the=20 > >>> Dialog using other mechanisms like an 2nd stream like http or a=20 > >>> MESSAGE or a other control protocol can not fulfil this. > >> Even it could > >>> be get lost when you want to traverse several SIP domains > >> or if you interwork with the PSTN/ISDN. > >>>=20 > >>> The Example of DTMF for INFO can only be done at mid dialog. > >>>=20 > >>> Using KPML --> We have minimum 4 more Messages. No=20 > additional Load? > >>>=20 > >>>=20 > >>>=20 > >>> Best Regards > >>>=20 > >>> Roland > >>>=20 > >>>=20 > >>>=20 > >>>> -----Urspr=FCngliche Nachricht----- > >>>> Von: Christer Holmberg (JO/LMF) > >>>> [mailto:christer.holmberg@ericsson.com] > >>>> Gesendet: Mittwoch, 18. Juli 2007 12:18 > >>>> An: Dean Willis > >>>> Cc: IETF Sipping List > >>>> Betreff: RE: [Sipping] comments on draft-burger-sip-info-00 > >>>>=20 > >>>>=20 > >>>>=20 > >>>> Hi, > >>>>=20 > >>>>>>>> - I disagree with the statement in chapter 1 regarding > >>>> the "context > >>>>>>>> for interpreting". The context is associated with the > >>>> content type. > >>>>>>>>=20 > >>>>>>>=20 > >>>>>>> Content type is, as I have repeatedly argued, completely > >>>> insufficient > >>>>=20 > >>>>>>> for interpretation of context in the general case. What, > >>>> for example, > >>>>=20 > >>>>>>> does it mean when an INFO shows up with a wav file > >>>> attached? Play it? > >>>>>>> Record it? Parse it using speech recognition and pass it > >>>> to a command > >>>>=20 > >>>>>>> processor? > >>>>>>=20 > >>>>>> The dialog (you can't send INFOs out-of-dialog, as far as I > >>>> know) will > >>>>=20 > >>>>>> be associated with an application, and if the application > >>>> doesn't know > >>>>=20 > >>>>>> what to do with it, it can promt the user: "You have now > >> received a > >>>>>> file. What do you want to do with it? Save it? Play it? > >> Display it? > >>>>>> Delete it?". > >>>>>=20 > >>>>> And how does the receiver know what the sender intended? > >>>>>=20 > >>>>> Assume you're taking to my "phone" application. You send digits. > >>>>> Should those be rendered to me, or fed into the user > >> interface of a > >>>>> phone-based game we happen to be playing? > >>>>=20 > >>>> How do you solve it with 2833? > >>>>=20 > >>>> How do you solve it with KPML? > >>>>=20 > >>>> You could even have the same problem with normal voice, e.g. > >>>> if the game > >>>> is controlled using voice recognition. Shall the=20 > received voice be=20 > >>>> fed to the speaker, or fed to the game application? > >>>>=20 > >>>> In some cases it may not matter if the data is fed to multiple=20 > >>>> applications. But, if you do need to dispatch data so specific=20 > >>>> applications you either need some kind of application > >> reference, or > >>>> you handle the dispatching locally in your device (the game=20 > >>>> application can tell it wants DTMFs, and/or the device chooses -=20 > >>>> either automatically or manually - which application=20 > will get the=20 > >>>> data etc). Or you use different SIP sessions. > >>>>=20 > >>>> In other cases you will not have the problem. For example,=20 > >>>> videoControl messages would normally be fed to a video control=20 > >>>> application, and nowhere else. > >>>>=20 > >>>> Regards, > >>>>=20 > >>>> Christer > >>>>=20 > >>>>=20 > >>>>=20 > >>>> _______________________________________________ > >>>> Sipping mailing list > >> https://www1.ietf.org/mailman/listinfo/sipping > >>>> This list is for NEW development of the application of SIP Use=20 > >>>> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > >>>> sip@ietf.org for new developments of core SIP > >>>>=20 > >>>=20 > >>>=20 > >>> _______________________________________________ > >>> Sipping mailing list =20 > https://www1.ietf.org/mailman/listinfo/sipping > >>> This list is for NEW development of the application of SIP Use=20 > >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>> sip@ietf.org for new developments of core SIP > >>=20 > >>=20 > >> Notice: This email message, together with any attachments, may=20 > >> contain information of BEA Systems, Inc., its=20 > subsidiaries and =20 > >> affiliated entities, that may be confidential, proprietary, =20 > >> copyrighted and/or legally privileged, and is intended solely for=20 > >> the use of the individual or entity named in this message.=20 > If you are=20 > >> not the intended recipient, and have received this message=20 > in error,=20 > >> please immediately return this by email and then delete it. > >>=20 > >>=20 > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >>=20 > >=20 >=20 >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 22 03:10:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICVaD-0003KO-UO; Sun, 22 Jul 2007 03:10:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICVaC-0003IT-5d for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 03:10:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICVaB-0003IL-Ql for sip@ietf.org; Sun, 22 Jul 2007 03:10:23 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICVaB-0007OL-1c for sip@ietf.org; Sun, 22 Jul 2007 03:10:23 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 73EE321526; Sun, 22 Jul 2007 09:10:22 +0200 (CEST) X-AuditID: c1b4fb3e-b0034bb0000007e1-97-46a302de62c1 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4685521376; Sun, 22 Jul 2007 09:10:22 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 09:10:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO and Content Negotiation Date: Sun, 22 Jul 2007 09:10:18 +0200 Message-ID: <7374777208BDC7449D5620EF942325670743C97A@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO and Content Negotiation Thread-Index: AcfLCn9Zvg80MTb9EdyGRgAWy4mm/wAepRIgAB8UkTUAC10VEA== References: <7374777208BDC7449D5620EF942325670743C925@esealmw113.eemea.ericsson.se> From: "Christer Holmberg (JO/LMF)" To: "Eric Burger" , "IETF SIP" X-OriginalArrivalTime: 22 Jul 2007 07:10:22.0074 (UTC) FILETIME=[5E494DA0:01C7CC2F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Why would I be expecting KPML, if I have only indicated that I support = DTMF-over-INFO? If I was to expect KPML, I would first need to establish a subscription = for KPML (or, in our "controlled network", the subscription would be = established by default, and I would know you are going to send KPML). Regards, Christer =20 > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: 22. hein=E4kuuta 2007 4:41 > To: Christer Holmberg (JO/LMF); IETF SIP > Subject: Re: [Sip] INFO and Content Negotiation >=20 > The point is that content type alone is not sufficient for=20 > INFO negotiation. > You are a RFC 4722-aware device. You advertise you accept a=20 > DTMF payload type. I am an INFO-aware device. I see you=20 > understand a DTMF payload, so I send it to you in an *INFO*=20 > message. You barf, because you were expecting KPML. >=20 >=20 > On 7/21/07 2:51 PM, "Christer Holmberg (JO/LMF)" > wrote: >=20 > >=20 > >=20 > > Hi, > >=20 > > I don't really understand your issue here... Did you send the text=20 > > using INFO, or something? ;) > >=20 > > Regards, > >=20 > > Christer > >=20 > >> -----Original Message----- > >> From: Eric Burger [mailto:eburger@bea.com] > >> Sent: 20. hein=E4kuuta 2007 23:14 > >> To: IETF SIP > >> Subject: [Sip] INFO and Content Negotiation > >>=20 > >> 12 second proof point of why content type doesn't work. > >>=20 > >> So here comes an INVITE. I am an INFO-friendly UAS. I=20 > negotiate by=20 > >> using Accept. > >>=20 > >> This INVITE has the line: > >> Accept: application/kpml-response+xml > >>=20 > >>=20 > >> Wow! This is great! I know the UAC *wants* DTMF. Why? > >> Because it accepts a DTMF content type. Excellent - I can=20 > now send=20 > >> them DTMF. > >>=20 > >> The user enters a digit, and I send an INFO with type=20 > >> application/kpml-response+xml. > >>=20 > >> UAC says, "What the heck was that?" > >>=20 > >>=20 > >> Notice: This email message, together with any attachments, may=20 > >> contain information of BEA Systems, Inc., its=20 > subsidiaries and =20 > >> affiliated entities, that may be confidential, proprietary, =20 > >> copyrighted and/or legally privileged, and is intended solely for=20 > >> the use of the individual or entity named in this message.=20 > If you are=20 > >> not the intended recipient, and have received this message=20 > in error,=20 > >> please immediately return this by email and then delete it. > >>=20 > >>=20 > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >>=20 > >=20 >=20 >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 22 03:14:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICVdh-0005ez-2S; Sun, 22 Jul 2007 03:14:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICVdg-0005bq-5Q for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 03:14:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICVdf-0005ZW-Qd for sip@ietf.org; Sun, 22 Jul 2007 03:13:59 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICVdf-0002t1-3j for sip@ietf.org; Sun, 22 Jul 2007 03:13:59 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6M7DsJL010444; Sun, 22 Jul 2007 00:13:54 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6M7DrxD012709; Sun, 22 Jul 2007 00:13:53 -0700 Received: from 172.24.29.106 ([172.24.29.106]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 22 Jul 2007 07:13:52 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Sun, 22 Jul 2007 03:13:49 -0400 Subject: Re: [Sip] INFO and Content Negotiation From: Eric Burger To: "Christer Holmberg (JO/LMF)" , IETF SIP Message-ID: Thread-Topic: [Sip] INFO and Content Negotiation Thread-Index: AcfLCn9Zvg80MTb9EdyGRgAWy4mm/wAepRIgAB8UkTUAC10VEAAAP9lZ In-Reply-To: <7374777208BDC7449D5620EF942325670743C97A@esealmw113.eemea.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org That is the point - people have been saying, "I can negotiate INFO by using Content-Type." This is a tiny example where using Content-Type to negotiat= e "INFO Packages" falls apart. On 7/22/07 3:10 AM, "Christer Holmberg (JO/LMF)" wrote: >=20 >=20 > Why would I be expecting KPML, if I have only indicated that I support > DTMF-over-INFO? >=20 > If I was to expect KPML, I would first need to establish a subscription f= or > KPML (or, in our "controlled network", the subscription would be establis= hed > by default, and I would know you are going to send KPML). >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >> -----Original Message----- >> From: Eric Burger [mailto:eburger@bea.com] >> Sent: 22. hein=E4kuuta 2007 4:41 >> To: Christer Holmberg (JO/LMF); IETF SIP >> Subject: Re: [Sip] INFO and Content Negotiation >>=20 >> The point is that content type alone is not sufficient for >> INFO negotiation. >> You are a RFC 4722-aware device. You advertise you accept a >> DTMF payload type. I am an INFO-aware device. I see you >> understand a DTMF payload, so I send it to you in an *INFO* >> message. You barf, because you were expecting KPML. >>=20 >>=20 >> On 7/21/07 2:51 PM, "Christer Holmberg (JO/LMF)" >> wrote: >>=20 >>>=20 >>>=20 >>> Hi, >>>=20 >>> I don't really understand your issue here... Did you send the text >>> using INFO, or something? ;) >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>> -----Original Message----- >>>> From: Eric Burger [mailto:eburger@bea.com] >>>> Sent: 20. hein=E4kuuta 2007 23:14 >>>> To: IETF SIP >>>> Subject: [Sip] INFO and Content Negotiation >>>>=20 >>>> 12 second proof point of why content type doesn't work. >>>>=20 >>>> So here comes an INVITE. I am an INFO-friendly UAS. I >> negotiate by >>>> using Accept. >>>>=20 >>>> This INVITE has the line: >>>> Accept: application/kpml-response+xml >>>>=20 >>>>=20 >>>> Wow! This is great! I know the UAC *wants* DTMF. Why? >>>> Because it accepts a DTMF content type. Excellent - I can >> now send >>>> them DTMF. >>>>=20 >>>> The user enters a digit, and I send an INFO with type >>>> application/kpml-response+xml. >>>>=20 >>>> UAC says, "What the heck was that?" >>>>=20 >>>>=20 >>>> Notice: This email message, together with any attachments, may >>>> contain information of BEA Systems, Inc., its >> subsidiaries and >>>> affiliated entities, that may be confidential, proprietary, >>>> copyrighted and/or legally privileged, and is intended solely for >>>> the use of the individual or entity named in this message. >> If you are >>>> not the intended recipient, and have received this message >> in error, >>>> please immediately return this by email and then delete it. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sipping@ietf.org for new developments on the application of sip >>>>=20 >>>=20 >>=20 >>=20 >>=20 >> Notice: This email message, together with any attachments, >> may contain information of BEA Systems, Inc., its >> subsidiaries and affiliated entities, that may be >> confidential, proprietary, copyrighted and/or legally >> privileged, and is intended solely for the use of the >> individual or entity named in this message. If you are not >> the intended recipient, and have received this message in >> error, please immediately return this by email and then delete it. >>=20 >=20 Notice: This email message, together with any attachments, may contain inf= ormation of BEA Systems, Inc., its subsidiaries and affiliated entiti= es, that may be confidential, proprietary, copyrighted and/or legally p= rivileged, and is intended solely for the use of the individual or entity n= amed in this message. If you are not the intended recipient, and have recei= ved this message in error, please immediately return this by email and then= delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 22 03:18:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICViF-0002oC-I3; Sun, 22 Jul 2007 03:18:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICViE-0002o5-H0 for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 03:18:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICViE-0002nx-6e for sip@ietf.org; Sun, 22 Jul 2007 03:18:42 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICViC-0002xO-Nc for sip@ietf.org; Sun, 22 Jul 2007 03:18:42 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C46A52075B; Sun, 22 Jul 2007 09:18:39 +0200 (CEST) X-AuditID: c1b4fb3c-b1e82bb0000007e1-ea-46a304cfc416 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A2B5920054; Sun, 22 Jul 2007 09:18:39 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 09:18:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO and Content Negotiation Date: Sun, 22 Jul 2007 09:18:35 +0200 Message-ID: <7374777208BDC7449D5620EF942325670743C97B@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO and Content Negotiation Thread-Index: AcfLCn9Zvg80MTb9EdyGRgAWy4mm/wAepRIgAB8UkTUAC10VEAAAP9lZAAAoAIA= References: <7374777208BDC7449D5620EF942325670743C97A@esealmw113.eemea.ericsson.se> From: "Christer Holmberg (JO/LMF)" To: "Eric Burger" , "IETF SIP" X-OriginalArrivalTime: 22 Jul 2007 07:18:39.0391 (UTC) FILETIME=[86B5DAF0:01C7CC30] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I still don't get it, but let's take it face-to-face at some point :) Regards, Christer=20 > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: 22. hein=E4kuuta 2007 10:14 > To: Christer Holmberg (JO/LMF); IETF SIP > Subject: Re: [Sip] INFO and Content Negotiation >=20 > That is the point - people have been saying, "I can negotiate=20 > INFO by using Content-Type." This is a tiny example where=20 > using Content-Type to negotiate "INFO Packages" falls apart. >=20 >=20 > On 7/22/07 3:10 AM, "Christer Holmberg (JO/LMF)" > wrote: >=20 > >=20 > >=20 > > Why would I be expecting KPML, if I have only indicated=20 > that I support=20 > > DTMF-over-INFO? > >=20 > > If I was to expect KPML, I would first need to establish a=20 > > subscription for KPML (or, in our "controlled network", the=20 > > subscription would be established by default, and I would=20 > know you are going to send KPML). > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: Eric Burger [mailto:eburger@bea.com] > >> Sent: 22. hein=E4kuuta 2007 4:41 > >> To: Christer Holmberg (JO/LMF); IETF SIP > >> Subject: Re: [Sip] INFO and Content Negotiation > >>=20 > >> The point is that content type alone is not sufficient for INFO=20 > >> negotiation. > >> You are a RFC 4722-aware device. You advertise you accept a DTMF=20 > >> payload type. I am an INFO-aware device. I see you understand a=20 > >> DTMF payload, so I send it to you in an *INFO* message. You barf,=20 > >> because you were expecting KPML. > >>=20 > >>=20 > >> On 7/21/07 2:51 PM, "Christer Holmberg (JO/LMF)" > >> wrote: > >>=20 > >>>=20 > >>>=20 > >>> Hi, > >>>=20 > >>> I don't really understand your issue here... Did you send=20 > the text=20 > >>> using INFO, or something? ;) > >>>=20 > >>> Regards, > >>>=20 > >>> Christer > >>>=20 > >>>> -----Original Message----- > >>>> From: Eric Burger [mailto:eburger@bea.com] > >>>> Sent: 20. hein=E4kuuta 2007 23:14 > >>>> To: IETF SIP > >>>> Subject: [Sip] INFO and Content Negotiation > >>>>=20 > >>>> 12 second proof point of why content type doesn't work. > >>>>=20 > >>>> So here comes an INVITE. I am an INFO-friendly UAS. I > >> negotiate by > >>>> using Accept. > >>>>=20 > >>>> This INVITE has the line: > >>>> Accept: application/kpml-response+xml > >>>>=20 > >>>>=20 > >>>> Wow! This is great! I know the UAC *wants* DTMF. Why? > >>>> Because it accepts a DTMF content type. Excellent - I can > >> now send > >>>> them DTMF. > >>>>=20 > >>>> The user enters a digit, and I send an INFO with type=20 > >>>> application/kpml-response+xml. > >>>>=20 > >>>> UAC says, "What the heck was that?" > >>>>=20 > >>>>=20 > >>>> Notice: This email message, together with any attachments, may=20 > >>>> contain information of BEA Systems, Inc., its > >> subsidiaries and > >>>> affiliated entities, that may be confidential, proprietary,=20 > >>>> copyrighted and/or legally privileged, and is intended=20 > solely for=20 > >>>> the use of the individual or entity named in this message. > >> If you are > >>>> not the intended recipient, and have received this message > >> in error, > >>>> please immediately return this by email and then delete it. > >>>>=20 > >>>>=20 > >>>> _______________________________________________ > >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>> This list is for NEW development of the core SIP Protocol Use=20 > >>>> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > >>>> sipping@ietf.org for new developments on the application of sip > >>>>=20 > >>>=20 > >>=20 > >>=20 > >>=20 > >> Notice: This email message, together with any attachments, may=20 > >> contain information of BEA Systems, Inc., its=20 > subsidiaries and =20 > >> affiliated entities, that may be confidential, proprietary, =20 > >> copyrighted and/or legally privileged, and is intended solely for=20 > >> the use of the individual or entity named in this message.=20 > If you are=20 > >> not the intended recipient, and have received this message=20 > in error,=20 > >> please immediately return this by email and then delete it. > >>=20 > >=20 >=20 >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 22 08:55:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICaxi-0005Da-Uk; Sun, 22 Jul 2007 08:55:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICaxi-0005DV-1L for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 08:55:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICaxh-0005DK-Ls for sip@ietf.org; Sun, 22 Jul 2007 08:55:01 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICaxg-0001Qb-7G for sip@ietf.org; Sun, 22 Jul 2007 08:55:01 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l6MCsnN5013919; Sun, 22 Jul 2007 07:54:49 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 07:54:49 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 14:54:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] New draft modifying RFC 4412 for Responses Date: Sun, 22 Jul 2007 14:54:45 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800147396D@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New draft modifying RFC 4412 for Responses Thread-Index: Ace3W2JDuAgSyvPiQnmPNKG+uDSrTQVA7c9w References: From: "DRAGE, Keith \(Keith\)" To: "Janet P Gunn" , "James M. Polk" X-OriginalArrivalTime: 22 Jul 2007 12:54:46.0592 (UTC) FILETIME=[7B4C8400:01C7CC5F] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0936453087==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0936453087== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CC5F.7B1D8DA3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CC5F.7B1D8DA3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSBub3RpY2UgdGhhdCBvbiAxKSBiZWxvdyB5b3Ugc2VlbSB0byBkZWFsIHdpdGggZXJyb3IgcmVw b3J0aW5nIHJhdGhlciB0aGFuIHByaW9yaXR5Lg0KIA0KSW4gUkZDIDQ0MTIgdGhlIHNlbWFudGlj cyBhcmUgdG8gdHJlYXQgdGhlIHJlcXVlc3QsIHRoZSB0cmFuc2FjdGlvbiAoYW5kIHBvc3NpYmx5 IHRoZSBkaWFsb2cpIHdpdGggcHJpb3JpdHkgYWNjb3JkaW5nIHRvIHRoZSBnaXZlbiBuYW1lc3Bh Y2UuDQogDQpJbiBKYW1lcyBkcmFmdCwgdGhlIHNlbWFudGljcyB3b3VsZCBhcHBlYXIgdG8gYmUg dG8gdHJlYXQgdGhlIHJlc3BvbnNlIHdpdGggcHJpb3JpdHkgYWNjb3JkaW5nIHRvIHRoZSBnaXZl biBuYW1lc3BhY2UuDQogDQpXaGF0IHlvdSBzZWVtIHRvIGJlIHJlcXVlc3RpbmcgaGVyZSBpcyB0 aGF0IGFueSA0eHggcmVzcG9uc2Ugd2l0aCBhIFJQSCBoZWFkZXIgaXMgaW5kaWNhdGluZyB0aGUg bmFtZXNwYWNlIHVzYWdlIHRoYXQgd2FzIGluIGVycm9yLg0KIA0KVGhhdCBzZWVtcyB0byBiZSBv dmVybG9hZGluZyB0aGUgc2VtYW50aWNzIG9mIHRoZSBoZWFkZXIgc29tZXdoYXQuDQogDQpyZWdh cmRzDQogDQpLZWl0aA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCglG cm9tOiBKYW5ldCBQIEd1bm4gW21haWx0bzpqZ3VubjZAY3NjLmNvbV0gDQoJU2VudDogTW9uZGF5 LCBKdW5lIDI1LCAyMDA3IDg6MDIgUE0NCglUbzogSmFtZXMgTS4gUG9saw0KCUNjOiBzaXBAaWV0 Zi5vcmcNCglTdWJqZWN0OiBSZTogW1NpcF0gTmV3IGRyYWZ0IG1vZGlmeWluZyBSRkMgNDQxMiBm b3IgUmVzcG9uc2VzDQoJDQoJDQoNCgkNCgkNCgkNCglJbiB3b3JraW5nIG9uIHNwZWNpZnlpbmcg YW5kIGRlcGxveWluZyBzeXN0ZW1zIHRoYXQgd2lsbCBhY3R1YWxseSB1c2UgdGhlIFJQSCB3aXRo IHRoZSBldHMgYW5kIHdwcyBuYW1lc3BhY2VzLCB3ZSBoYXZlIGZvdW5kIHNldmVyYWwgY29udGV4 dHMgaW4gd2hpY2ggdGhlIFJQSCAgb24gdGhlIHJlc3BvbnNlIGlzIHZlcnkgdXNlZnVsLiANCgkN CgkxKSAgICAgICAgRXJyb3IgcmVwb3J0aW5nLiAgUkZDIDQ0MTIgZG9lcyBub3QgZ2l2ZSBjbGVh ciBkaXJlY3Rpb24gb24gdGhlIHRyZWF0bWVudCBvZiBSUEggd2l0aCBzeW50YXggZXJyb3JzIChv dXQgb2YgcmFuZ2UgcHJpb3JpdHkgdmFsdWVzLCBkdXBsaWNhdGUgbmFtZXNwYWNlcywgZXRjLikg IFdlIGhhdmUgZm91bmQgdGhhdCBpbmNsdWRpbmcgdGhlIFJQSCBpbiB0aGUgIDR4eCByZXNwb25z ZXMgaXMgdXNlc2Z1bCBpbiBhZGRyZXNzaW5nIHRoZSBlcnJvcnMuIA0KCTIpICAgICAgICBJbiBv dXIgc3lzdGVtLCB3ZSBvZnRlbiBzZXQgdGhlIGV0cyAgUlBIICh3aXRoIGRlZmF1bHQgcHJpb3Jp dHkpICBiYXNlZCBvbiB0aGUg4oCcRVRTLURO4oCd4oCcZGlhbGVkIG51bWJlcuKAnSBvciB1cmks IGJlZm9yZSBhdXRoZW50aWNhdGlvbiBhbmQgYmVmb3JlIGtub3dpbmcgdGhlIGNvcnJlY3QgcHJp b3JpdHkgdmFsdWUuICBJbmNsdWRpbmcgdGhlIFJQSCBpbiB0aGUgcmVzcG9uc2UgaXMgYSB1c2Vm dWwgd2F5IG9mIGNvbnZleWluZyB0aGUgY29ycmVjdCBwcmlvcml0eSB2YWx1ZSBiYWNrIHRvIG5v ZGVzIGVhcmxpZXIgaW4gdGhlIOKAnGNhbGwgZmxvd+KAnS4gDQoJMykgICAgICAgIFNpbWlsYXJs eSwgaWYgYW4gUlAgYWN0b3IgcmVjZWl2ZXMgYSBTSVAgSU5WSVRFIHdpdGggdGhlIEVUUy1ETiwg YnV0IG5vIFJQSCBpdCBtYXksIGFmdGVyIGF1dGhlbnRpY2F0aW5nIHRoZSBjYWxsLCBpbmNsdWRl IFJQSCBpbiB0aGUgcmVzcG9uc2VzIGluIG9yZGVyIHRvIGluZm9ybSAgbm9kZXMgZWFybGllciBp biB0aGUgY2FsbCBmbG93IHRoYXQgdGhpcyBpcyBhIHByaW9yaXR5IGNhbGwuIA0KCTQpICAgICAg ICBJZiB0aGUgUlBIIGlzIGJlaW5nIHVzZWQgdG8gcHJpb3JpdGl6ZSBwcm9jZXNzaW5nIChvZiBi b3RoIG1lc3NhZ2VzIGFuZCByZXNwb25zZXMpIGluIHRoZSBTSVAgdXNlciBhZ2VudCwgaW5jbHVk aW5nIHRoZSBSUEggaW4gdGhlIHJlc3BvbnNlIGFsbG93cyB0aGUgcmVjZWl2aW5nIFJQIGFjdG9y IHRvIGdpdmUgdGhlIHJlc3BvbnNlIOKAnEVUUyB0cmVhdG1lbnTigJ0gYmVmb3JlIGNoZWNraW5n IG9uIHRoZSDigJxzdGF0ZeKAnSBvZiB0aGUgY2FsbC4gIFRoaXMgaXMgcGFydGljdWxhcmx5IHJl bGV2YW50IHdoZW4gdGhlIFJQIGFjdG9yIGl0c2VsZiBpcyBjb25nZXN0ZWQuIA0KCQ0KCUphbmV0 DQoJDQoJDQoJIkphbWVzIE0uIFBvbGsiIDxqbXBvbGtAY2lzY28uY29tPiB3cm90ZSBvbiAwNi8x Ni8yMDA3IDA1OjEzOjM3IFBNOg0KCQ0KCT4gU0lQIFdHDQoJPiANCgk+IEhlcmUgaXMgYSBuZXcg SUQgSSd2ZSB3cml0dGVuIGJlY2F1c2Ugb2YgaW1wbGVtZW50YXRpb24gDQoJPiBjb25zaWRlcmF0 aW9ucyB0byBhbGxvdyBhIFNJUCBSZXNvdXJjZS1Qcmlvcml0eSBoZWFkZXIgKFJQSCkgaW4gDQoJ PiByZXNwb25zZXMsIHdoaWNoIFJGQyA0NDEyIGN1cnJlbnRseSBkaXNhbGxvd3MsIGFzc3VtaW5n IG9ubHkgdGhhdCANCgk+IHN0YXRlZnVsIGRldmljZXMgd2lsbCB1c2UgUlBILiAgVGhlcmUgaGF2 ZSBiZWVuIG1hbnkgcmVxdWVzdHMgdG8gaGF2ZSANCgk+IHRoaXMgIm9ubHkgc3RhdGVmdWwgZGV2 aWNlcyIgcmVzdHJpY3Rpb24gcmVsYXhlZCwgaW4gY2VydGFpbiANCgk+IHNjZW5hcmlvcy4gIFRo aXMgSUQgZG9lcyB0aGlzLCBhbmQgcHJvcG9zZXMgaG93IElBTkEgaXMgY2hhbmdlZCANCgk+IGFj Y29yZGluZ2x5IHdydCBSUEguICBUaGlzIElEIGRvZXMgbm90aGluZyBlbHNlLg0KCT4gDQoJPiBD b21tZW50cyBhcmUgYXBwcmVjaWF0ZWQuDQoJPiANCgk+ID5BIE5ldyBJbnRlcm5ldC1EcmFmdCBp cyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCgk+ID5kaXJlY3Rv cmllcy4NCgk+ID4NCgk+ID4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBBbGxvd2luZyBTSVAg UmVzb3VyY2UgUHJpb3JpdHkgSGVhZGVyIGluIA0KCT4gPiBTSVAgUmVzcG9uc2VzDQoJPiA+ICAg ICAgICAgQXV0aG9yKHMpICAgICAgIDogSi4gUG9saw0KCT4gPiAgICAgICAgIEZpbGVuYW1lICAg ICAgICA6IGRyYWZ0LXBvbGstc2lwLXJwaC1pbi1yZXNwb25zZXMtMDAudHh0DQoJPiA+ICAgICAg ICAgUGFnZXMgICAgICAgICAgIDogNg0KCT4gPiAgICAgICAgIERhdGUgICAgICAgICAgICA6IDIw MDctNi0xNQ0KCT4gPg0KCT4gPiAgICBUaGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChT SVApIFJlc291cmNlIFByaW9yaXR5IEhlYWRlcg0KCT4gPiAgICAoUlBIKSwgaW4gaXRzIGN1cnJl bnQgZm9ybSwgaXMgaWdub3JlZCBpbiBTSVAgcmVzcG9uc2VzLiAgVGhpcyB3YXMgYQ0KCT4gPiAg ICBkZXNpZ24gY2hvaWNlIGR1cmluZyBSRkMgNDQxMidzIGRldmVsb3BtZW50LiBUaGlzIGlzIG5v dyBjb25zaWRlcmVkDQoJPiA+ICAgIGEgYmFkIGRlc2lnbiBjaG9pY2UgaW4gY2VydGFpbiBzY2Vu YXJpb3MuICBUaGlzIGRvY3VtZW50IGNvcnJlY3RzDQoJPiA+ICAgIFJGQyA0NDEyJ3MgY29tbXVu aWNhdGlvbnMgbW9kZWwgYnkgb3B0aW9uYWxseSBhbGxvd2luZyBhIFNJUCBzZXJ2ZXINCgk+ID4g ICAgb3IgdXNlciBhZ2VudCBjbGllbnQgdG8gcHJvY2VzcyB0aGUgUmVzb3VyY2UtUHJpb3JpdHkg SGVhZGVyIGluIGENCgk+ID4gICAgcmVzcG9uc2UuDQoJPiA+DQoJPiA+QSBVUkwgZm9yIHRoaXMg SW50ZXJuZXQtRHJhZnQgaXM6DQoJPiA+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtcG9say1zaXAtcnBoLWluLXJlc3BvbnNlcy0wMC50eHQNCgk+IA0KCT4gDQoJPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCT4gU2lwIG1h aWxpbmcgbGlzdCAgaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwDQoJ PiBUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJvdG9j b2wNCgk+IFVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25z IG9uIGN1cnJlbnQgc2lwDQoJPiBVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3Bt ZW50cyBvbiB0aGUgYXBwbGljYXRpb24gb2Ygc2lwDQoJDQoNCg== ------_=_NextPart_001_01C7CC5F.7B1D8DA3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzEzMiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWIGRpcj1s dHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz01MjMwMjUyMTItMjIwNzIwMDc+PEZPTlQgZmFjZT1B cmlhbCANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPkkgbm90aWNlIHRoYXQgb24gMSkgYmVsb3cgeW91 IHNlZW0gdG8gZGVhbCB3aXRoIGVycm9yIA0KcmVwb3J0aW5nIHJhdGhlciB0aGFuIHByaW9yaXR5 LjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFz cz01MjMwMjUyMTItMjIwNzIwMDc+PEZPTlQgZmFjZT1BcmlhbCANCmNvbG9yPSMwMDAwZmYgc2l6 ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48 U1BBTiBjbGFzcz01MjMwMjUyMTItMjIwNzIwMDc+PEZPTlQgZmFjZT1BcmlhbCANCmNvbG9yPSMw MDAwZmYgc2l6ZT0yPkluIFJGQyA0NDEyIHRoZSBzZW1hbnRpY3MgYXJlIHRvIHRyZWF0IHRoZSBy ZXF1ZXN0LCB0aGUgDQp0cmFuc2FjdGlvbiAoYW5kIHBvc3NpYmx5IHRoZSBkaWFsb2cpIHdpdGgg cHJpb3JpdHkgYWNjb3JkaW5nIHRvIHRoZSBnaXZlbiANCm5hbWVzcGFjZS48L0ZPTlQ+PC9TUEFO PjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NTIzMDI1MjEyLTIy MDcyMDA3PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9T UEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NTIz MDI1MjEyLTIyMDcyMDA3PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj5J biBKYW1lcyBkcmFmdCwgdGhlIHNlbWFudGljcyB3b3VsZCBhcHBlYXIgdG8gYmUgdG8gdHJlYXQg DQp0aGUgcmVzcG9uc2Ugd2l0aCBwcmlvcml0eSBhY2NvcmRpbmcgdG8gdGhlIGdpdmVuIG5hbWVz cGFjZS48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4g Y2xhc3M9NTIzMDI1MjEyLTIyMDcyMDA3PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZm IHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxl ZnQ+PFNQQU4gY2xhc3M9NTIzMDI1MjEyLTIyMDcyMDA3PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xv cj0jMDAwMGZmIHNpemU9Mj5XaGF0IHlvdSBzZWVtIHRvIGJlIHJlcXVlc3RpbmcgaGVyZSBpcyB0 aGF0IGFueSA0eHggDQpyZXNwb25zZSB3aXRoIGEgUlBIIGhlYWRlciBpcyBpbmRpY2F0aW5nIHRo ZSBuYW1lc3BhY2UgdXNhZ2UgdGhhdCB3YXMgaW4gDQplcnJvci48L0ZPTlQ+PC9TUEFOPjwvRElW Pg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NTIzMDI1MjEyLTIyMDcyMDA3 PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZu YnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NTIzMDI1MjEy LTIyMDcyMDA3PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj5UaGF0IHNl ZW1zIHRvIGJlIG92ZXJsb2FkaW5nIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIGhlYWRlciANCnNvbWV3 aGF0LjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBj bGFzcz01MjMwMjUyMTItMjIwNzIwMDc+PEZPTlQgZmFjZT1BcmlhbCANCmNvbG9yPSMwMDAwZmYg c2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVm dD48U1BBTiBjbGFzcz01MjMwMjUyMTItMjIwNzIwMDc+PEZPTlQgZmFjZT1BcmlhbCANCmNvbG9y PSMwMDAwZmYgc2l6ZT0yPnJlZ2FyZHM8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRy IGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NTIzMDI1MjEyLTIyMDcyMDA3PjxGT05UIGZhY2U9QXJp YWwgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJ ViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NTIzMDI1MjEyLTIyMDcyMDA3PjxGT05U IGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj5LZWl0aDwvRk9OVD48L1NQQU4+PC9E SVY+PEJSPg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0iUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1M RUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMGZmIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAw cHgiPg0KICA8RElWIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVhZGVyIGxhbmc9ZW4tdXMgZGlyPWx0 ciBhbGlnbj1sZWZ0Pg0KICA8SFIgdGFiSW5kZXg9LTE+DQogIDxGT05UIGZhY2U9VGFob21hIHNp emU9Mj48Qj5Gcm9tOjwvQj4gSmFuZXQgUCBHdW5uIFttYWlsdG86amd1bm42QGNzYy5jb21dIA0K ICA8QlI+PEI+U2VudDo8L0I+IE1vbmRheSwgSnVuZSAyNSwgMjAwNyA4OjAyIFBNPEJSPjxCPlRv OjwvQj4gSmFtZXMgTS4gDQogIFBvbGs8QlI+PEI+Q2M6PC9CPiBzaXBAaWV0Zi5vcmc8QlI+PEI+ U3ViamVjdDo8L0I+IFJlOiBbU2lwXSBOZXcgZHJhZnQgDQogIG1vZGlmeWluZyBSRkMgNDQxMiBm b3IgUmVzcG9uc2VzPEJSPjwvRk9OVD48QlI+PC9ESVY+DQogIDxESVY+PC9ESVY+PEJSPjxGT05U IGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PEJSPjxCUj48QlI+PC9GT05UPjxGT05UIA0KICBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz5JbiB3b3JraW5nIG9uIHNwZWNpZnlpbmcgYW5kIGRl cGxveWluZyBzeXN0ZW1zIA0KICB0aGF0IHdpbGwgYWN0dWFsbHkgdXNlIHRoZSBSUEggd2l0aCB0 aGUgZXRzIGFuZCB3cHMgbmFtZXNwYWNlcywgd2UgaGF2ZSBmb3VuZCANCiAgc2V2ZXJhbCBjb250 ZXh0cyBpbiB3aGljaCB0aGUgUlBIICZuYnNwO29uIHRoZSByZXNwb25zZSBpcyB2ZXJ5IHVzZWZ1 bC48L0ZPTlQ+IA0KICA8QlI+PEJSPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0z PjEpICZuYnNwOyAmbmJzcDsgJm5ic3A7IA0KICAmbmJzcDtFcnJvciByZXBvcnRpbmcuICZuYnNw O1JGQyA0NDEyIGRvZXMgbm90IGdpdmUgY2xlYXIgZGlyZWN0aW9uIG9uIHRoZSANCiAgdHJlYXRt ZW50IG9mIFJQSCB3aXRoIHN5bnRheCBlcnJvcnMgKG91dCBvZiByYW5nZSBwcmlvcml0eSB2YWx1 ZXMsIGR1cGxpY2F0ZSANCiAgbmFtZXNwYWNlcywgZXRjLikgJm5ic3A7V2UgaGF2ZSBmb3VuZCB0 aGF0IGluY2x1ZGluZyB0aGUgUlBIIGluIHRoZSAmbmJzcDs0eHggDQogIHJlc3BvbnNlcyBpcyB1 c2VzZnVsIGluIGFkZHJlc3NpbmcgdGhlIGVycm9ycy48L0ZPTlQ+IDxCUj48Rk9OVCANCiAgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+MikgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 SW4gb3VyIHN5c3RlbSwgd2UgDQogIG9mdGVuIHNldCB0aGUgZXRzICZuYnNwO1JQSCAod2l0aCBk ZWZhdWx0IHByaW9yaXR5KSAmbmJzcDtiYXNlZCBvbiB0aGUgDQogIOKAnEVUUy1ETuKAneKAnGRp YWxlZCBudW1iZXLigJ0gb3IgdXJpLCBiZWZvcmUgYXV0aGVudGljYXRpb24gYW5kIGJlZm9yZSBr bm93aW5nIHRoZSANCiAgY29ycmVjdCBwcmlvcml0eSB2YWx1ZS4gJm5ic3A7SW5jbHVkaW5nIHRo ZSBSUEggaW4gdGhlIHJlc3BvbnNlIGlzIGEgdXNlZnVsIA0KICB3YXkgb2YgY29udmV5aW5nIHRo ZSBjb3JyZWN0IHByaW9yaXR5IHZhbHVlIGJhY2sgdG8gbm9kZXMgZWFybGllciBpbiB0aGUg4oCc Y2FsbCANCiAgZmxvd+KAnS48L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i IHNpemU9Mz4zKSAmbmJzcDsgJm5ic3A7ICZuYnNwOyANCiAgJm5ic3A7U2ltaWxhcmx5LCBpZiBh biBSUCBhY3RvciByZWNlaXZlcyBhIFNJUCBJTlZJVEUgd2l0aCB0aGUgRVRTLUROLCBidXQgbm8g DQogIFJQSCBpdCBtYXksIGFmdGVyIGF1dGhlbnRpY2F0aW5nIHRoZSBjYWxsLCBpbmNsdWRlIFJQ SCBpbiB0aGUgcmVzcG9uc2VzIGluIA0KICBvcmRlciB0byBpbmZvcm0gJm5ic3A7bm9kZXMgZWFy bGllciBpbiB0aGUgY2FsbCBmbG93IHRoYXQgdGhpcyBpcyBhIHByaW9yaXR5IA0KICBjYWxsLjwv Rk9OVD4gPEJSPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjQpICZuYnNwOyAm bmJzcDsgJm5ic3A7IA0KICAmbmJzcDtJZiB0aGUgUlBIIGlzIGJlaW5nIHVzZWQgdG8gcHJpb3Jp dGl6ZSBwcm9jZXNzaW5nIChvZiBib3RoIG1lc3NhZ2VzIGFuZCANCiAgcmVzcG9uc2VzKSBpbiB0 aGUgU0lQIHVzZXIgYWdlbnQsIGluY2x1ZGluZyB0aGUgUlBIIGluIHRoZSByZXNwb25zZSBhbGxv d3MgdGhlIA0KICByZWNlaXZpbmcgUlAgYWN0b3IgdG8gZ2l2ZSB0aGUgcmVzcG9uc2Ug4oCcRVRT IHRyZWF0bWVudOKAnSBiZWZvcmUgY2hlY2tpbmcgb24gdGhlIA0KICDigJxzdGF0ZeKAnSBvZiB0 aGUgY2FsbC4gJm5ic3A7VGhpcyBpcyBwYXJ0aWN1bGFybHkgcmVsZXZhbnQgd2hlbiB0aGUgUlAg YWN0b3IgDQogIGl0c2VsZiBpcyBjb25nZXN0ZWQuPC9GT05UPiA8QlI+PEJSPjxGT05UIGZhY2U9 c2Fucy1zZXJpZiANCiAgc2l6ZT0yPkphbmV0PEJSPjwvRk9OVD48QlI+PEJSPjxGT05UIHNpemU9 Mj48VFQ+IkphbWVzIE0uIFBvbGsiIA0KICAmbHQ7am1wb2xrQGNpc2NvLmNvbSZndDsgd3JvdGUg b24gMDYvMTYvMjAwNyAwNToxMzozNyBQTTo8QlI+PEJSPiZndDsgU0lQIA0KICBXRzxCUj4mZ3Q7 IDxCUj4mZ3Q7IEhlcmUgaXMgYSBuZXcgSUQgSSd2ZSB3cml0dGVuIGJlY2F1c2Ugb2YgaW1wbGVt ZW50YXRpb24gDQogIDxCUj4mZ3Q7IGNvbnNpZGVyYXRpb25zIHRvIGFsbG93IGEgU0lQIFJlc291 cmNlLVByaW9yaXR5IGhlYWRlciAoUlBIKSBpbiANCiAgPEJSPiZndDsgcmVzcG9uc2VzLCB3aGlj aCBSRkMgNDQxMiBjdXJyZW50bHkgZGlzYWxsb3dzLCBhc3N1bWluZyBvbmx5IHRoYXQgDQogIDxC Uj4mZ3Q7IHN0YXRlZnVsIGRldmljZXMgd2lsbCB1c2UgUlBILiAmbmJzcDtUaGVyZSBoYXZlIGJl ZW4gbWFueSByZXF1ZXN0cyB0byANCiAgaGF2ZSA8QlI+Jmd0OyB0aGlzICJvbmx5IHN0YXRlZnVs IGRldmljZXMiIHJlc3RyaWN0aW9uIHJlbGF4ZWQsIGluIGNlcnRhaW4gDQogIDxCUj4mZ3Q7IHNj ZW5hcmlvcy4gJm5ic3A7VGhpcyBJRCBkb2VzIHRoaXMsIGFuZCBwcm9wb3NlcyBob3cgSUFOQSBp cyBjaGFuZ2VkIA0KICA8QlI+Jmd0OyBhY2NvcmRpbmdseSB3cnQgUlBILiAmbmJzcDtUaGlzIElE IGRvZXMgbm90aGluZyBlbHNlLjxCUj4mZ3Q7IA0KICA8QlI+Jmd0OyBDb21tZW50cyBhcmUgYXBw cmVjaWF0ZWQuPEJSPiZndDsgPEJSPiZndDsgJmd0O0EgTmV3IEludGVybmV0LURyYWZ0IA0KICBp cyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHM8QlI+Jmd0OyAmZ3Q7 ZGlyZWN0b3JpZXMuPEJSPiZndDsgDQogICZndDs8QlI+Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBUaXRsZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyANCiAgJm5ic3A7ICZuYnNw OyA6IEFsbG93aW5nIFNJUCBSZXNvdXJjZSBQcmlvcml0eSBIZWFkZXIgaW4gPEJSPiZndDsgJmd0 OyBTSVAgDQogIFJlc3BvbnNlczxCUj4mZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IEF1dGhvcihzKSAmbmJzcDsgJm5ic3A7IA0KICAmbmJzcDsgOiBKLiBQb2xrPEJSPiZndDsg Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRmlsZW5hbWUgJm5ic3A7IA0KICAmbmJz cDsgJm5ic3A7ICZuYnNwOzogZHJhZnQtcG9say1zaXAtcnBoLWluLXJlc3BvbnNlcy0wMC50eHQ8 QlI+Jmd0OyAmZ3Q7IA0KICAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGFnZXMgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IA0KICA2PEJSPiZndDsgJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgRGF0ZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgDQog ICZuYnNwOyAmbmJzcDs6IDIwMDctNi0xNTxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDtUaGUgU2Vzc2lvbiANCiAgSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBSZXNvdXJj ZSBQcmlvcml0eSBIZWFkZXI8QlI+Jmd0OyAmZ3Q7ICZuYnNwOyANCiAgJm5ic3A7KFJQSCksIGlu IGl0cyBjdXJyZW50IGZvcm0sIGlzIGlnbm9yZWQgaW4gU0lQIHJlc3BvbnNlcy4gJm5ic3A7VGhp cyB3YXMgDQogIGE8QlI+Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtkZXNpZ24gY2hvaWNlIGR1cmlu ZyBSRkMgNDQxMidzIGRldmVsb3BtZW50LiBUaGlzIA0KICBpcyBub3cgY29uc2lkZXJlZDxCUj4m Z3Q7ICZndDsgJm5ic3A7ICZuYnNwO2EgYmFkIGRlc2lnbiBjaG9pY2UgaW4gY2VydGFpbiANCiAg c2NlbmFyaW9zLiAmbmJzcDtUaGlzIGRvY3VtZW50IGNvcnJlY3RzPEJSPiZndDsgJmd0OyAmbmJz cDsgJm5ic3A7UkZDIDQ0MTIncyANCiAgY29tbXVuaWNhdGlvbnMgbW9kZWwgYnkgb3B0aW9uYWxs eSBhbGxvd2luZyBhIFNJUCBzZXJ2ZXI8QlI+Jmd0OyAmZ3Q7ICZuYnNwOyANCiAgJm5ic3A7b3Ig dXNlciBhZ2VudCBjbGllbnQgdG8gcHJvY2VzcyB0aGUgUmVzb3VyY2UtUHJpb3JpdHkgSGVhZGVy IGluIA0KICBhPEJSPiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7cmVzcG9uc2UuPEJSPiZndDsgJmd0 OzxCUj4mZ3Q7ICZndDtBIFVSTCBmb3IgdGhpcyANCiAgSW50ZXJuZXQtRHJhZnQgaXM6PEJSPiZn dDsgDQogICZndDtodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1wb2xr LXNpcC1ycGgtaW4tcmVzcG9uc2VzLTAwLnR4dDxCUj4mZ3Q7IA0KICA8QlI+Jmd0OyA8QlI+Jmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4mZ3Q7 IFNpcCANCiAgbWFpbGluZyBsaXN0ICZuYnNwO2h0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NpcDxCUj4mZ3Q7IFRoaXMgDQogIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVu dCBvZiB0aGUgY29yZSBTSVAgUHJvdG9jb2w8QlI+Jmd0OyBVc2UgDQogIHNpcC1pbXBsZW1lbnRv cnNAY3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlvbnMgb24gY3VycmVudCBzaXA8QlI+Jmd0OyBV c2UgDQogIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9wbWVudHMgb24gdGhlIGFwcGxp Y2F0aW9uIG9mIA0Kc2lwPEJSPjwvQkxPQ0tRVU9URT48L1RUPjwvRk9OVD48L0JPRFk+PC9IVE1M Pg0K ------_=_NextPart_001_01C7CC5F.7B1D8DA3-- --===============0936453087== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0936453087==-- From sip-bounces@ietf.org Sun Jul 22 09:48:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICbnP-0004tQ-I4; Sun, 22 Jul 2007 09:48:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICbnN-0004tG-Mb for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 09:48:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICbnN-0004t8-Bu for sip@ietf.org; Sun, 22 Jul 2007 09:48:25 -0400 Received: from smtp3.versatel.nl ([62.58.50.90]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICbnM-0002Hx-K2 for sip@ietf.org; Sun, 22 Jul 2007 09:48:25 -0400 Received: (qmail 1468 invoked by uid 0); 22 Jul 2007 13:48:01 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 22 Jul 2007 13:48:01 -0000 Message-ID: <002d01c7cc66$8f2d9c50$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Cullen Jennings" , "Rohan Mahy" Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-10.txt Date: Sun, 22 Jul 2007 15:45:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 2.2 (++) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Extra line of requirement text for section 4.2 on registrations: When the UAC includes a 'reg-id' parameter in a Contact, it MUST include the same parameter and value in refreshes and deregistrations for that Contact. (could be combined with the remark on re-registrations at the end, the latter should also mention de-registrations) This is needed in (or at least greatly simplifies) a deployment where the registrar is separate from the edge proxy, in which case the registrar may not be able to determine which flow is being refreshed / deregistered (e.g. when TCP connections between the edge proxies and the registrar got recycled) You may want to say a few words on the processing of refreshes and deregistrations in section 6, as the matching of bindings is now different from RFC3261 (it now includes the instance-id & reg-id) Regards, Jeroen > Internet-Drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Session Initiation Protocol Working >>> Group of the IETF. >>> >>> Title : Managing Client Initiated Connections in the Session >>> Initiation Protocol (SIP) Author(s) : C. Jennings, R. Mahy >>> Filename : draft-ietf-sip-outbound-10.txt >>> Pages : 42 >>> Date : 2007-7-12 >>> >>> The Session Initiation Protocol (SIP) allows proxy servers to >>> initiate TCP connections and send asynchronous UDP datagrams to >>> User Agents in order to deliver requests. However, many practical >>> considerations, such as the existence of firewalls and Network >>> Address Translators (NATs), prevent servers from connecting to >>> User Agents in this way. This specification defines behaviors >>> for User Agents, registrars and proxy servers that allow requests >>> to be delivered on existing connections established by the User >>> Agent. It also defines keep alive behaviors needed to keep NAT >>> bindings open and specifies the usage of multiple connections. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-10.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the body >>> of >>> the message. >>> You can also visit >>> https://www1.ietf.org/mailman/listinfo/I-D-announce >>> to change your subscription settings. >>> >>> Internet-Drafts are also available by anonymous FTP. Login with the >>> username "anonymous" and a password of your e-mail address. After >>> logging in, type "cd internet-drafts" and then >>> "get draft-ietf-sip-outbound-10.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE /internet-drafts/draft-ietf-sip-outbound-10.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >> >> >> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 22 10:13:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICcBB-0007w2-Ug; Sun, 22 Jul 2007 10:13:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICcBA-0007vk-HW for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 10:13:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICcBA-0007vb-7v for sip@ietf.org; Sun, 22 Jul 2007 10:13:00 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICcB8-0006BW-SR for sip@ietf.org; Sun, 22 Jul 2007 10:13:00 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6MECv7s024964 for ; Sun, 22 Jul 2007 09:12:58 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 09:13:00 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 16:12:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Slides for IETF#69 Date: Sun, 22 Jul 2007 16:12:54 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001473972@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE291800147358A@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Slides for IETF#69 Thread-Index: AcfKQKw9PkKc27peQkuinyWd4J+6BACKO2hA References: <5D1A7985295922448D5550C94DE291800147358A@DEEXC1U01.de.lucent.com> From: "DRAGE, Keith \(Keith\)" To: "DRAGE, Keith \(Keith\)" , X-OriginalArrivalTime: 22 Jul 2007 14:12:55.0047 (UTC) FILETIME=[65D5F970:01C7CC6A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org We have now reached the 24 hour deadline for session #1 and the results are to say the least DISAPPOINTING. We have slides for the SIPS slot and for the essential corrections slot at: https://datatracker.ietf.org/meeting/69/materials.html We have apparently not yet received session#1 slides for: outbound (Rohan) resource priority header issues (James) Delivering R-URI and Parameters to UA (Jonathan) MIME Body Handling (Gonzalo) There were some slides on the MIME body handling being circulated by Gonzalo - are those the ones you intend to use Gonzalo, or is there a replacement set? So please get these slides to us as soon as possible - that is assuming you want to use slides in the session! The deadline for session#2 slides in 9:00 Monday morning. Regards Keith =09 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: Thursday, July 19, 2007 9:09 PM > To: sip@ietf.org > Subject: [Sip] Slides for IETF#69 >=20 > (as WG chair) >=20 > To all presenters on Monday and Tuesday. >=20 > If you are presenting slides in the SIP sessions, we would=20 > like these posted to the meeting presentations site well=20 > before the meeting session begins. >=20 > That means you need to get them to the chairs at least 24=20 > hours in advance of session start (and not 25 minutes after). >=20 > We will be projecting from what is on the meeting=20 > presentations site (no > exceptions) and therefore if your slides are not there, you=20 > will be presenting to a blank screen. >=20 > Remember that as well as people trying to address your issues=20 > in the meeting, we will have people trying to follow the=20 > discussion remotely. > Access to the slides in advance helps everybody. >=20 > And remember, we are looking for issues for the meeting to=20 > discuss, not tutorials on the document contents - everyone is=20 > expected to have read those. >=20 > Regards >=20 > Keith >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 22 10:19:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICcHH-00055r-Ju; Sun, 22 Jul 2007 10:19:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICcHG-00055l-0t for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 10:19:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICcHF-00055c-MV for sip@ietf.org; Sun, 22 Jul 2007 10:19:17 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICcHF-0002kx-8D for sip@ietf.org; Sun, 22 Jul 2007 10:19:17 -0400 Received: from localhost.localdomain (ppp-70-249-155-15.dsl.rcsntx.swbell.net [70.249.155.15]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6MEJ8pG038292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jul 2007 09:19:10 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <46A36757.7020500@nostrum.com> Date: Sun, 22 Jul 2007 09:19:03 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] INFO and Content Negotiation References: <7374777208BDC7449D5620EF942325670743C97A@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF942325670743C97B@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF942325670743C97B@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Received-SPF: pass (nostrum.com: 70.249.155.15 is authenticated by a trusted mechanism) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by nostrum.com id l6MEJ8pG038292 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: IETF SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org To rephrase what Eric is saying here in base principles: _inferring_=20 what can be done with INFO by examining supported content types is a "Do=20 What I Mean" mechanism (as opposed to a "Do What I Say" mechanism). "Do=20 What I Mean" is a well-known recipe for interoperability failure. (For a=20 well constructed discussion of this, see Jonathan's service indication=20 draft). This is, for example, why we have an "Event" header field in RFC 3265=20 instead of simply inferring the event package from MIME type. (In fact,=20 this is why I started the draft that became 3265 in the first place --=20 with the dual uses of PINT and presence threatening to take the=20 SUBSCRIBE method down the path that INFO unfortunately ended up taking,=20 an intervention was necessary). To re-cast Eric's example from a slightly different angle: imagine that=20 a desired usage of INFO most naturally used application/sdp as its=20 payload. How would one indicate support for such a usage? /a Christer Holmberg (JO/LMF) wrote: > Hi, > > I still don't get it, but let's take it face-to-face at some point :) > > Regards, > > Christer=20 > > =20 >> -----Original Message----- >> From: Eric Burger [mailto:eburger@bea.com]=20 >> Sent: 22. hein=E4kuuta 2007 10:14 >> To: Christer Holmberg (JO/LMF); IETF SIP >> Subject: Re: [Sip] INFO and Content Negotiation >> >> That is the point - people have been saying, "I can negotiate=20 >> INFO by using Content-Type." This is a tiny example where=20 >> using Content-Type to negotiate "INFO Packages" falls apart. >> >> >> On 7/22/07 3:10 AM, "Christer Holmberg (JO/LMF)" >> wrote: >> >> =20 >>> Why would I be expecting KPML, if I have only indicated=20 >>> =20 >> that I support=20 >> =20 >>> DTMF-over-INFO? >>> >>> If I was to expect KPML, I would first need to establish a=20 >>> subscription for KPML (or, in our "controlled network", the=20 >>> subscription would be established by default, and I would=20 >>> =20 >> know you are going to send KPML). >> =20 >>> Regards, >>> >>> Christer >>> >>> =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 22 10:42:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICcdu-0006M3-KA; Sun, 22 Jul 2007 10:42:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICcds-0006Ly-VR for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 10:42:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICcds-0006Lq-LH for sip@ietf.org; Sun, 22 Jul 2007 10:42:40 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICcds-0003Lu-7D for sip@ietf.org; Sun, 22 Jul 2007 10:42:40 -0400 Received: from [192.168.2.235] (pool-71-164-165-100.dllstx.fios.verizon.net [71.164.165.100]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6MEgYLC039484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 22 Jul 2007 09:42:35 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <46A13517.8000406@cisco.com> References: <46A13517.8000406@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8ACAD5AC-8741-4C18-9D3D-445D1558C1CA@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Comment on draft-ietf-sip-fork-loop-fix-05 Date: Sun, 22 Jul 2007 09:42:31 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 71.164.165.100 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The thing you describe is not a proxy :) Seriously, we don't put a lot of work into specifying behavior when things violate the specification. I'd be willing to add a paragraph of general tone noting that the loop detection mechanism breaks if you remove other people's vias. (If there were two of the things you describe in the network, removing each other's vias, then there is no hope of ever detecting a loop). RjS On Jul 20, 2007, at 5:20 PM, Paul Kyzivat wrote: > Just catching up :-( > > One thing occurred to me - this document goes out of its way to say > that a proxy need not do the loop check unless it forks. In general > that makes sense, but in one case it does not: > > Some proxies hide/suppress/obfuscate via headers, and then reverse > the process on responses. A proxy that does so breaks loop checking > by any of the proxies whose vias it hid. So I think a proxy that > does this MUST perform a loop check itself even if it does not fork. > > Thanks, > Paul > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 22 11:28:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICdMB-0000Ui-Ta; Sun, 22 Jul 2007 11:28:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICdM9-0000Ua-9J for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 11:28:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICdM8-0000US-Vx for sip@ietf.org; Sun, 22 Jul 2007 11:28:24 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICdM8-0007j5-4t for sip@ietf.org; Sun, 22 Jul 2007 11:28:24 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Jul 2007 11:28:24 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusRAF8Uo0ZAZnme/2dsb2JhbACIX5xH X-IronPort-AV: i="4.16,569,1175486400"; d="scan'208"; a="126696068:sNHT33602272" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6MFSNB3024836; Sun, 22 Jul 2007 11:28:23 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6MFSNWI007357; Sun, 22 Jul 2007 15:28:23 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); Sun, 22 Jul 2007 11:28:23 -0400 Received: from [10.86.240.164] ([10.86.240.164]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 11:28:22 -0400 Message-ID: <46A37796.2060501@cisco.com> Date: Sun, 22 Jul 2007 11:28:22 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Eric Burger Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides for body (MIME) handling) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2007 15:28:22.0974 (UTC) FILETIME=[F0B0CDE0:01C7CC74] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3549; t=1185118103; x=1185982103; c=relaxed/simple; s=rtpdkim1001; 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=20Content-Disposition=20in=20multiparts=20WAS=20(Re=3A= 20[Sip]=20Draft=20slides=0A=20for=20body=20(MIME)=20handling) |Sender:=20 |To:=20Eric=20Burger=20; bh=5FFfNDhoi7FUBkcc+2JSg5jb8teiqh9xEwgyoraLXwI=; b=Y1DH+zNBpfC9qqQ28dmsZUwEWLwu72HKXRgocaWUyu62efVwIt7aqEyzYaS4FdC4FTDECIE3 QEvnquwLgpUGsgGIrX6ygCA8JZ21xXrR7k24+48LI4Gt5GYLKMcnQcxF; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: sip , Gonzalo Camarillo X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Eric Burger wrote: > Well, we are only sort-of munging MIME. The default is always RENDER. > However, *what* is a render is an exercise for the protocol to specify. > That is the wiggle room for SIP to say "render means by-context." > > What we do not have the wiggle room for is to say the default > content-disposition is something other than RENDER. Well, we have *already* said that the default Content-Disposition is something other than "render" for certain Content-Types. E.g. for C-T of application/sdp the default disposition is "session". There are other special cases for some other content types as well. Is that really kosher for MIME, or did we already do something bad? In any case, what I was suggesting is that we spend some effort defining what "render" means for SIP. Paul > On 7/22/07 12:17 AM, "Paul Kyzivat" wrote: > >> >> >> Eric Burger wrote: >>> I would offer this is where we can "add value" to MIME for SIP usage. Note >>> that I do not say, "deviate from MIME." I would suggest we NOT try to >>> deviate from MIME in any respect. >> Oh MIME sage, your comment is inscrutable! :-) >> >> I don't understand in this case where the line is between "adding value" >> and "deviating". >> >> If we try to ascribe some common meaning to "render" then I believe sip >> is already violating it. If we have thus already "deviated" from MIME, >> which takes precedence: correcting the deviation, or backward compatibility. >> >> My assumption is that backward compatibility is more important. >> >> Paul >> >>> On 7/19/07 9:59 AM, "Paul Kyzivat" wrote: >>> [snip] >>>> I think we just have to grandfather the use of 'refer' in SIP, and >>>> document that the usage in sip does not mean "render", but rather means >>>> that the usage must be determined by other context - specifically the >>>> type of message or response and the content type. IOW, 'render' in sip >>>> can be thought of as a peculiar spelling for 'by-context'. It might be >>>> helpful to give guidance for development of future specs about when >>>> 'render' should be used vs defining a new disposition. >>> [snip] >>> >>> >>> Notice: This email message, together with any attachments, may contain >>> information of BEA Systems, Inc., its subsidiaries and affiliated >>> entities, that may be confidential, proprietary, copyrighted and/or >>> legally privileged, and is intended solely for the use of the individual or >>> entity named in this message. If you are not the intended recipient, and have >>> received this message in error, please immediately return this by email and >>> then delete it. >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> > > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 22 11:41:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICdYc-0007RS-To; Sun, 22 Jul 2007 11:41:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICdYb-0007R6-0s for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 11:41:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICdYa-0007Qy-NS for sip@ietf.org; Sun, 22 Jul 2007 11:41:16 -0400 Received: from mail85.messagelabs.com ([216.82.240.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ICdYZ-0007wQ-LC for sip@ietf.org; Sun, 22 Jul 2007 11:41:16 -0400 X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-9.tower-85.messagelabs.com!1185118873!34258440!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [20.137.52.151] Received: (qmail 27020 invoked from network); 22 Jul 2007 15:41:14 -0000 Received: from amer-mta07.csc.com (HELO amer-mta07.csc.com) (20.137.52.151) by server-9.tower-85.messagelabs.com with AES256-SHA encrypted SMTP; 22 Jul 2007 15:41:14 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id l6MFfSMR029531 for ; Sun, 22 Jul 2007 11:41:28 -0400 (EDT) In-Reply-To: <5D1A7985295922448D5550C94DE291800147396D@DEEXC1U01.de.lucent.com> To: "DRAGE, Keith \(Keith\)" Subject: RE: [Sip] New draft modifying RFC 4412 for Responses MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Sun, 22 Jul 2007 11:41:10 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1 HF180|March 29, 2007) at 07/22/2007 11:39:54 AM, Serialize complete at 07/22/2007 11:39:54 AM X-Spam-Score: -4.0 (----) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: sip@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1310044988==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1310044988== Content-Type: multipart/alternative; boundary="=_alternative 00562A6485257320_=" This is a multipart message in MIME format. --=_alternative 00562A6485257320_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 WWVzLCB3ZSBwcm9iYWJseSBhcmUgZ3VpbHR5IG9mICJvdmVybG9hZGluZyIgdG8gYSBjZXJ0YWlu IGV4dGVudC4gIEJ1dCBubywgDQpJIGRpZCBub3QgbWVhbiAiYW55IDR4eCByZXNwb25zZSB3aXRo IGEgUlBIIGhlYWRlciBpcyBpbmRpY2F0aW5nIHRoZSANCm5hbWVzcGFjZSB1c2FnZSB0aGF0IHdh cyBpbiBlcnJvci4iICBJdCBpcyBvbmx5IG9uIGEgZmV3IHNwZWNpZmljIGVycm9yIA0KbWVzc2Fn ZXMgKGJhc2VkIG9uIHRoZSBjb21iaW5hdGlvbiBvZiA0eHggdmFsdWUgYW5kIHRoZSBSZWFzb24g SGVhZGVyKSANCnRoYXQgd2Ugd291bGQgYmUgbG9va2luZyBhdCB0aGUgIFJQSCBpbiBvcmRlciB0 byBsb2cgdGhlIGVycm9yZWQgUlBILiAgSW4gDQphbGwgY2FzZXMsIHRoZSByZXNwb25zZSAod2hl dGhlciA0eHggb3Igb3RoZXIpIHdvdWxkIGJlIHRyZWF0ZWQgIndpdGggDQpwcmlvcml0eSBhY2Nv cmRpbmcgdG8gdGhlIGdpdmVuIG5hbWVzcGFjZS4iDQoNCkphbmV0DQoNCiJEUkFHRSwgS2VpdGgg XChLZWl0aFwpIiA8ZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tPiB3cm90ZSBvbiAwNy8yMi8yMDA3 IA0KMDg6NTQ6NDUgQU06DQoNCj4gSSBub3RpY2UgdGhhdCBvbiAxKSBiZWxvdyB5b3Ugc2VlbSB0 byBkZWFsIHdpdGggZXJyb3IgcmVwb3J0aW5nIA0KPiByYXRoZXIgdGhhbiBwcmlvcml0eS4NCj4g DQo+IEluIFJGQyA0NDEyIHRoZSBzZW1hbnRpY3MgYXJlIHRvIHRyZWF0IHRoZSByZXF1ZXN0LCB0 aGUgdHJhbnNhY3Rpb24gDQo+IChhbmQgcG9zc2libHkgdGhlIGRpYWxvZykgd2l0aCBwcmlvcml0 eSBhY2NvcmRpbmcgdG8gdGhlIGdpdmVuIA0KbmFtZXNwYWNlLg0KPiANCj4gSW4gSmFtZXMgZHJh ZnQsIHRoZSBzZW1hbnRpY3Mgd291bGQgYXBwZWFyIHRvIGJlIHRvIHRyZWF0IHRoZSANCj4gcmVz cG9uc2Ugd2l0aCBwcmlvcml0eSBhY2NvcmRpbmcgdG8gdGhlIGdpdmVuIG5hbWVzcGFjZS4NCj4g DQo+IFdoYXQgeW91IHNlZW0gdG8gYmUgcmVxdWVzdGluZyBoZXJlIGlzIHRoYXQgYW55IDR4eCBy ZXNwb25zZSB3aXRoIGEgDQo+IFJQSCBoZWFkZXIgaXMgaW5kaWNhdGluZyB0aGUgbmFtZXNwYWNl IHVzYWdlIHRoYXQgd2FzIGluIGVycm9yLg0KPiANCj4gVGhhdCBzZWVtcyB0byBiZSBvdmVybG9h ZGluZyB0aGUgc2VtYW50aWNzIG9mIHRoZSBoZWFkZXIgc29tZXdoYXQuDQo+IA0KPiByZWdhcmRz DQo+IA0KPiBLZWl0aA0KPiANCj4gRnJvbTogSmFuZXQgUCBHdW5uIFttYWlsdG86amd1bm42QGNz Yy5jb21dIA0KPiBTZW50OiBNb25kYXksIEp1bmUgMjUsIDIwMDcgODowMiBQTQ0KPiBUbzogSmFt ZXMgTS4gUG9saw0KPiBDYzogc2lwQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbU2lwXSBOZXcg ZHJhZnQgbW9kaWZ5aW5nIFJGQyA0NDEyIGZvciBSZXNwb25zZXMNCg0KPiANCj4gDQo+IA0KPiAN Cj4gSW4gd29ya2luZyBvbiBzcGVjaWZ5aW5nIGFuZCBkZXBsb3lpbmcgc3lzdGVtcyB0aGF0IHdp bGwgYWN0dWFsbHkgDQo+IHVzZSB0aGUgUlBIIHdpdGggdGhlIGV0cyBhbmQgd3BzIG5hbWVzcGFj ZXMsIHdlIGhhdmUgZm91bmQgc2V2ZXJhbCANCj4gY29udGV4dHMgaW4gd2hpY2ggdGhlIFJQSCAg b24gdGhlIHJlc3BvbnNlIGlzIHZlcnkgdXNlZnVsLiANCj4gDQo+IDEpICAgICAgICBFcnJvciBy ZXBvcnRpbmcuICBSRkMgNDQxMiBkb2VzIG5vdCBnaXZlIGNsZWFyIGRpcmVjdGlvbiANCj4gb24g dGhlIHRyZWF0bWVudCBvZiBSUEggd2l0aCBzeW50YXggZXJyb3JzIChvdXQgb2YgcmFuZ2UgcHJp b3JpdHkgDQo+IHZhbHVlcywgZHVwbGljYXRlIG5hbWVzcGFjZXMsIGV0Yy4pICBXZSBoYXZlIGZv dW5kIHRoYXQgaW5jbHVkaW5nIA0KPiB0aGUgUlBIIGluIHRoZSAgNHh4IHJlc3BvbnNlcyBpcyB1 c2VzZnVsIGluIGFkZHJlc3NpbmcgdGhlIGVycm9ycy4gDQo+IDIpICAgICAgICBJbiBvdXIgc3lz dGVtLCB3ZSBvZnRlbiBzZXQgdGhlIGV0cyAgUlBIICh3aXRoIGRlZmF1bHQgDQo+IHByaW9yaXR5 KSAgYmFzZWQgb24gdGhlIOKAnEVUUy1ETuKAneKAnGRpYWxlZCBudW1iZXLigJ0gb3IgdXJpLCBi ZWZvcmUgDQo+IGF1dGhlbnRpY2F0aW9uIGFuZCBiZWZvcmUga25vd2luZyB0aGUgY29ycmVjdCBw cmlvcml0eSB2YWx1ZS4gDQo+IEluY2x1ZGluZyB0aGUgUlBIIGluIHRoZSByZXNwb25zZSBpcyBh IHVzZWZ1bCB3YXkgb2YgY29udmV5aW5nIHRoZSANCj4gY29ycmVjdCBwcmlvcml0eSB2YWx1ZSBi YWNrIHRvIG5vZGVzIGVhcmxpZXIgaW4gdGhlIOKAnGNhbGwgZmxvd+KAnS4gDQo+IDMpICAgICAg ICBTaW1pbGFybHksIGlmIGFuIFJQIGFjdG9yIHJlY2VpdmVzIGEgU0lQIElOVklURSB3aXRoIHRo ZSANCj4gRVRTLUROLCBidXQgbm8gUlBIIGl0IG1heSwgYWZ0ZXIgYXV0aGVudGljYXRpbmcgdGhl IGNhbGwsIGluY2x1ZGUgDQo+IFJQSCBpbiB0aGUgcmVzcG9uc2VzIGluIG9yZGVyIHRvIGluZm9y bSAgbm9kZXMgZWFybGllciBpbiB0aGUgY2FsbCANCj4gZmxvdyB0aGF0IHRoaXMgaXMgYSBwcmlv cml0eSBjYWxsLiANCj4gNCkgICAgICAgIElmIHRoZSBSUEggaXMgYmVpbmcgdXNlZCB0byBwcmlv cml0aXplIHByb2Nlc3NpbmcgKG9mIGJvdGgNCj4gbWVzc2FnZXMgYW5kIHJlc3BvbnNlcykgaW4g dGhlIFNJUCB1c2VyIGFnZW50LCBpbmNsdWRpbmcgdGhlIFJQSCBpbiANCj4gdGhlIHJlc3BvbnNl IGFsbG93cyB0aGUgcmVjZWl2aW5nIFJQIGFjdG9yIHRvIGdpdmUgdGhlIHJlc3BvbnNlIOKAnEVU Uw0KPiB0cmVhdG1lbnTigJ0gYmVmb3JlIGNoZWNraW5nIG9uIHRoZSDigJxzdGF0ZeKAnSBvZiB0 aGUgY2FsbC4gIFRoaXMgaXMgDQo+IHBhcnRpY3VsYXJseSByZWxldmFudCB3aGVuIHRoZSBSUCBh Y3RvciBpdHNlbGYgaXMgY29uZ2VzdGVkLiANCj4gDQo+IEphbmV0DQo+IA0KPiANCj4gIkphbWVz IE0uIFBvbGsiIDxqbXBvbGtAY2lzY28uY29tPiB3cm90ZSBvbiAwNi8xNi8yMDA3IDA1OjEzOjM3 IFBNOg0KPiANCj4gPiBTSVAgV0cNCj4gPiANCj4gPiBIZXJlIGlzIGEgbmV3IElEIEkndmUgd3Jp dHRlbiBiZWNhdXNlIG9mIGltcGxlbWVudGF0aW9uIA0KPiA+IGNvbnNpZGVyYXRpb25zIHRvIGFs bG93IGEgU0lQIFJlc291cmNlLVByaW9yaXR5IGhlYWRlciAoUlBIKSBpbiANCj4gPiByZXNwb25z ZXMsIHdoaWNoIFJGQyA0NDEyIGN1cnJlbnRseSBkaXNhbGxvd3MsIGFzc3VtaW5nIG9ubHkgdGhh dCANCj4gPiBzdGF0ZWZ1bCBkZXZpY2VzIHdpbGwgdXNlIFJQSC4gIFRoZXJlIGhhdmUgYmVlbiBt YW55IHJlcXVlc3RzIHRvIGhhdmUgDQo+ID4gdGhpcyAib25seSBzdGF0ZWZ1bCBkZXZpY2VzIiBy ZXN0cmljdGlvbiByZWxheGVkLCBpbiBjZXJ0YWluIA0KPiA+IHNjZW5hcmlvcy4gIFRoaXMgSUQg ZG9lcyB0aGlzLCBhbmQgcHJvcG9zZXMgaG93IElBTkEgaXMgY2hhbmdlZCANCj4gPiBhY2NvcmRp bmdseSB3cnQgUlBILiAgVGhpcyBJRCBkb2VzIG5vdGhpbmcgZWxzZS4NCj4gPiANCj4gPiBDb21t ZW50cyBhcmUgYXBwcmVjaWF0ZWQuDQo+ID4gDQo+ID4gPkEgTmV3IEludGVybmV0LURyYWZ0IGlz IGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPiA+ID5kaXJlY3Rv cmllcy4NCj4gPiA+DQo+ID4gPiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IEFsbG93aW5nIFNJ UCBSZXNvdXJjZSBQcmlvcml0eSBIZWFkZXIgaW4gDQo+ID4gPiBTSVAgUmVzcG9uc2VzDQo+ID4g PiAgICAgICAgIEF1dGhvcihzKSAgICAgICA6IEouIFBvbGsNCj4gPiA+ICAgICAgICAgRmlsZW5h bWUgICAgICAgIDogZHJhZnQtcG9say1zaXAtcnBoLWluLXJlc3BvbnNlcy0wMC50eHQNCj4gPiA+ ICAgICAgICAgUGFnZXMgICAgICAgICAgIDogNg0KPiA+ID4gICAgICAgICBEYXRlICAgICAgICAg ICAgOiAyMDA3LTYtMTUNCj4gPiA+DQo+ID4gPiAgICBUaGUgU2Vzc2lvbiBJbml0aWF0aW9uIFBy b3RvY29sIChTSVApIFJlc291cmNlIFByaW9yaXR5IEhlYWRlcg0KPiA+ID4gICAgKFJQSCksIGlu IGl0cyBjdXJyZW50IGZvcm0sIGlzIGlnbm9yZWQgaW4gU0lQIHJlc3BvbnNlcy4gIFRoaXMgDQp3 YXMgYQ0KPiA+ID4gICAgZGVzaWduIGNob2ljZSBkdXJpbmcgUkZDIDQ0MTIncyBkZXZlbG9wbWVu dC4gVGhpcyBpcyBub3cgDQpjb25zaWRlcmVkDQo+ID4gPiAgICBhIGJhZCBkZXNpZ24gY2hvaWNl IGluIGNlcnRhaW4gc2NlbmFyaW9zLiAgVGhpcyBkb2N1bWVudCBjb3JyZWN0cw0KPiA+ID4gICAg UkZDIDQ0MTIncyBjb21tdW5pY2F0aW9ucyBtb2RlbCBieSBvcHRpb25hbGx5IGFsbG93aW5nIGEg U0lQIA0Kc2VydmVyDQo+ID4gPiAgICBvciB1c2VyIGFnZW50IGNsaWVudCB0byBwcm9jZXNzIHRo ZSBSZXNvdXJjZS1Qcmlvcml0eSBIZWFkZXIgaW4gYQ0KPiA+ID4gICAgcmVzcG9uc2UuDQo+ID4g Pg0KPiA+ID5BIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4gPiANCj5odHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1wb2xrLXNpcC1ycGgtaW4tcmVzcG9u c2VzLTAwLnR4dA0KPiA+IA0KPiA+IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gU2lwIG1haWxpbmcgbGlzdCAgaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwDQo+ID4gVGhpcyBsaXN0IGlzIGZvciBORVcgZGV2 ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29sDQo+ID4gVXNlIHNpcC1pbXBsZW1lbnRv cnNAY3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlvbnMgb24gY3VycmVudCBzaXANCj4gPiBVc2Ug c2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50cyBvbiB0aGUgYXBwbGljYXRpb24g b2YgDQo+IHNpcF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IFNpcCBtYWlsaW5nIGxpc3QgIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpcA0KPiBUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBT SVAgUHJvdG9jb2wNCj4gVXNlIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBx dWVzdGlvbnMgb24gY3VycmVudCBzaXANCj4gVXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBk ZXZlbG9wbWVudHMgb24gdGhlIGFwcGxpY2F0aW9uIG9mIHNpcA0K --=_alternative 00562A6485257320_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjxicj4NClll cywgd2UgcHJvYmFibHkgYXJlIGd1aWx0eSBvZiAmcXVvdDtvdmVybG9hZGluZyZxdW90OyB0byBh IGNlcnRhaW4gZXh0ZW50Lg0KJm5ic3A7QnV0IG5vLCBJIGRpZCBub3QgbWVhbiAmcXVvdDs8L2Zv bnQ+PGZvbnQgc2l6ZT0yPjx0dD5hbnkgNHh4IHJlc3BvbnNlDQp3aXRoIGEgUlBIIGhlYWRlciBp cyBpbmRpY2F0aW5nIHRoZSBuYW1lc3BhY2UgdXNhZ2UgdGhhdCB3YXMgaW4gZXJyb3IuPC90dD48 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90Ow0KJm5ic3A7SXQgaXMg b25seSBvbiBhIGZldyBzcGVjaWZpYyBlcnJvciBtZXNzYWdlcyAoYmFzZWQgb24gdGhlIGNvbWJp bmF0aW9uDQpvZiA0eHggdmFsdWUgYW5kIHRoZSBSZWFzb24gSGVhZGVyKSB0aGF0IHdlIHdvdWxk IGJlIGxvb2tpbmcgYXQgdGhlICZuYnNwO1JQSA0KaW4gb3JkZXIgdG8gbG9nIHRoZSBlcnJvcmVk IFJQSC4gJm5ic3A7SW4gYWxsIGNhc2VzLCB0aGUgcmVzcG9uc2UgKHdoZXRoZXINCjR4eCBvciBv dGhlcikgd291bGQgYmUgdHJlYXRlZCAmcXVvdDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0dD53aXRo IHByaW9yaXR5DQphY2NvcmRpbmcgdG8gdGhlIGdpdmVuIG5hbWVzcGFjZS48L3R0PjwvZm9udD48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7PC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5KYW5ldDwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTI+PHR0PiZxdW90O0RSQUdFLCBLZWl0aCBcKEtlaXRoXCkmcXVvdDsgJmx0O2RyYWdl QGFsY2F0ZWwtbHVjZW50LmNvbSZndDsNCndyb3RlIG9uIDA3LzIyLzIwMDcgMDg6NTQ6NDUgQU06 PGJyPg0KPGJyPg0KJmd0OyBJIG5vdGljZSB0aGF0IG9uIDEpIGJlbG93IHlvdSBzZWVtIHRvIGRl YWwgd2l0aCBlcnJvciByZXBvcnRpbmcgPGJyPg0KJmd0OyByYXRoZXIgdGhhbiBwcmlvcml0eS48 L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7PC90dD48L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IEluIFJGQyA0NDEyIHRoZSBzZW1hbnRpY3MgYXJl IHRvIHRyZWF0IHRoZSByZXF1ZXN0LA0KdGhlIHRyYW5zYWN0aW9uIDxicj4NCiZndDsgKGFuZCBw b3NzaWJseSB0aGUgZGlhbG9nKSB3aXRoIHByaW9yaXR5IGFjY29yZGluZyB0byB0aGUgZ2l2ZW4g bmFtZXNwYWNlLjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyAmbmJzcDs8 L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgSW4gSmFtZXMgZHJhZnQsIHRo ZSBzZW1hbnRpY3Mgd291bGQgYXBwZWFyIHRvDQpiZSB0byB0cmVhdCB0aGUgPGJyPg0KJmd0OyBy ZXNwb25zZSB3aXRoIHByaW9yaXR5IGFjY29yZGluZyB0byB0aGUgZ2l2ZW4gbmFtZXNwYWNlLjwv dHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyAmbmJzcDs8L3R0PjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgV2hhdCB5b3Ugc2VlbSB0byBiZSByZXF1ZXN0aW5n IGhlcmUgaXMgdGhhdCBhbnkNCjR4eCByZXNwb25zZSB3aXRoIGEgPGJyPg0KJmd0OyBSUEggaGVh ZGVyIGlzIGluZGljYXRpbmcgdGhlIG5hbWVzcGFjZSB1c2FnZSB0aGF0IHdhcyBpbiBlcnJvci48 L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7PC90dD48L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IFRoYXQgc2VlbXMgdG8gYmUgb3ZlcmxvYWRpbmcg dGhlIHNlbWFudGljcyBvZg0KdGhlIGhlYWRlciBzb21ld2hhdC48L3R0PjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y Pjx0dD4mZ3Q7IHJlZ2FyZHM8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsg Jm5ic3A7PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IEtlaXRoPC90dD48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IDxicj4NCiZndDsgRnJvbTogSmFuZXQg UCBHdW5uIFttYWlsdG86amd1bm42QGNzYy5jb21dIDxicj4NCiZndDsgU2VudDogTW9uZGF5LCBK dW5lIDI1LCAyMDA3IDg6MDIgUE08YnI+DQomZ3Q7IFRvOiBKYW1lcyBNLiBQb2xrPGJyPg0KJmd0 OyBDYzogc2lwQGlldGYub3JnPGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW1NpcF0gTmV3IGRyYWZ0 IG1vZGlmeWluZyBSRkMgNDQxMiBmb3IgUmVzcG9uc2VzPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxi cj4NCiZndDsgSW4gd29ya2luZyBvbiBzcGVjaWZ5aW5nIGFuZCBkZXBsb3lpbmcgc3lzdGVtcyB0 aGF0IHdpbGwgYWN0dWFsbHkNCjxicj4NCiZndDsgdXNlIHRoZSBSUEggd2l0aCB0aGUgZXRzIGFu ZCB3cHMgbmFtZXNwYWNlcywgd2UgaGF2ZSBmb3VuZCBzZXZlcmFsDQo8YnI+DQomZ3Q7IGNvbnRl eHRzIGluIHdoaWNoIHRoZSBSUEggJm5ic3A7b24gdGhlIHJlc3BvbnNlIGlzIHZlcnkgdXNlZnVs LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgMSkgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RXJy b3IgcmVwb3J0aW5nLiAmbmJzcDtSRkMgNDQxMiBkb2VzDQpub3QgZ2l2ZSBjbGVhciBkaXJlY3Rp b24gPGJyPg0KJmd0OyBvbiB0aGUgdHJlYXRtZW50IG9mIFJQSCB3aXRoIHN5bnRheCBlcnJvcnMg KG91dCBvZiByYW5nZSBwcmlvcml0eQ0KPGJyPg0KJmd0OyB2YWx1ZXMsIGR1cGxpY2F0ZSBuYW1l c3BhY2VzLCBldGMuKSAmbmJzcDtXZSBoYXZlIGZvdW5kIHRoYXQgaW5jbHVkaW5nDQo8YnI+DQom Z3Q7IHRoZSBSUEggaW4gdGhlICZuYnNwOzR4eCByZXNwb25zZXMgaXMgdXNlc2Z1bCBpbiBhZGRy ZXNzaW5nIHRoZSBlcnJvcnMuDQo8YnI+DQomZ3Q7IDIpICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO0luIG91ciBzeXN0ZW0sIHdlIG9mdGVuIHNldCB0aGUgZXRzDQombmJzcDtSUEggKHdpdGgg ZGVmYXVsdCA8YnI+DQomZ3Q7IHByaW9yaXR5KSAmbmJzcDtiYXNlZCBvbiB0aGUg4oCcRVRTLURO 4oCd4oCcZGlhbGVkIG51bWJlcuKAnSBvciB1cmksIGJlZm9yZQ0KPGJyPg0KJmd0OyBhdXRoZW50 aWNhdGlvbiBhbmQgYmVmb3JlIGtub3dpbmcgdGhlIGNvcnJlY3QgcHJpb3JpdHkgdmFsdWUuICZu YnNwOzxicj4NCiZndDsgSW5jbHVkaW5nIHRoZSBSUEggaW4gdGhlIHJlc3BvbnNlIGlzIGEgdXNl ZnVsIHdheSBvZiBjb252ZXlpbmcgdGhlDQo8YnI+DQomZ3Q7IGNvcnJlY3QgcHJpb3JpdHkgdmFs dWUgYmFjayB0byBub2RlcyBlYXJsaWVyIGluIHRoZSDigJxjYWxsIGZsb3figJ0uDQo8YnI+DQom Z3Q7IDMpICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1NpbWlsYXJseSwgaWYgYW4gUlAgYWN0 b3IgcmVjZWl2ZXMgYQ0KU0lQIElOVklURSB3aXRoIHRoZSA8YnI+DQomZ3Q7IEVUUy1ETiwgYnV0 IG5vIFJQSCBpdCBtYXksIGFmdGVyIGF1dGhlbnRpY2F0aW5nIHRoZSBjYWxsLCBpbmNsdWRlDQo8 YnI+DQomZ3Q7IFJQSCBpbiB0aGUgcmVzcG9uc2VzIGluIG9yZGVyIHRvIGluZm9ybSAmbmJzcDtu b2RlcyBlYXJsaWVyIGluIHRoZQ0KY2FsbCA8YnI+DQomZ3Q7IGZsb3cgdGhhdCB0aGlzIGlzIGEg cHJpb3JpdHkgY2FsbC4gPGJyPg0KJmd0OyA0KSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJ ZiB0aGUgUlBIIGlzIGJlaW5nIHVzZWQgdG8gcHJpb3JpdGl6ZQ0KcHJvY2Vzc2luZyAob2YgYm90 aDxicj4NCiZndDsgbWVzc2FnZXMgYW5kIHJlc3BvbnNlcykgaW4gdGhlIFNJUCB1c2VyIGFnZW50 LCBpbmNsdWRpbmcgdGhlIFJQSCBpbg0KPGJyPg0KJmd0OyB0aGUgcmVzcG9uc2UgYWxsb3dzIHRo ZSByZWNlaXZpbmcgUlAgYWN0b3IgdG8gZ2l2ZSB0aGUgcmVzcG9uc2Ug4oCcRVRTPGJyPg0KJmd0 OyB0cmVhdG1lbnTigJ0gYmVmb3JlIGNoZWNraW5nIG9uIHRoZSDigJxzdGF0ZeKAnSBvZiB0aGUg Y2FsbC4gJm5ic3A7VGhpcw0KaXMgPGJyPg0KJmd0OyBwYXJ0aWN1bGFybHkgcmVsZXZhbnQgd2hl biB0aGUgUlAgYWN0b3IgaXRzZWxmIGlzIGNvbmdlc3RlZC4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IEphbmV0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJnF1b3Q7SmFtZXMgTS4gUG9s ayZxdW90OyAmbHQ7am1wb2xrQGNpc2NvLmNvbSZndDsgd3JvdGUgb24gMDYvMTYvMjAwNw0KMDU6 MTM6MzcgUE06PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgU0lQIFdHPGJyPg0KJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyBIZXJlIGlzIGEgbmV3IElEIEkndmUgd3JpdHRlbiBiZWNhdXNlIG9m IGltcGxlbWVudGF0aW9uIDxicj4NCiZndDsgJmd0OyBjb25zaWRlcmF0aW9ucyB0byBhbGxvdyBh IFNJUCBSZXNvdXJjZS1Qcmlvcml0eSBoZWFkZXIgKFJQSCkNCmluIDxicj4NCiZndDsgJmd0OyBy ZXNwb25zZXMsIHdoaWNoIFJGQyA0NDEyIGN1cnJlbnRseSBkaXNhbGxvd3MsIGFzc3VtaW5nIG9u bHkNCnRoYXQgPGJyPg0KJmd0OyAmZ3Q7IHN0YXRlZnVsIGRldmljZXMgd2lsbCB1c2UgUlBILiAm bmJzcDtUaGVyZSBoYXZlIGJlZW4gbWFueSByZXF1ZXN0cw0KdG8gaGF2ZSA8YnI+DQomZ3Q7ICZn dDsgdGhpcyAmcXVvdDtvbmx5IHN0YXRlZnVsIGRldmljZXMmcXVvdDsgcmVzdHJpY3Rpb24gcmVs YXhlZCwgaW4NCmNlcnRhaW4gPGJyPg0KJmd0OyAmZ3Q7IHNjZW5hcmlvcy4gJm5ic3A7VGhpcyBJ RCBkb2VzIHRoaXMsIGFuZCBwcm9wb3NlcyBob3cgSUFOQSBpcw0KY2hhbmdlZCA8YnI+DQomZ3Q7 ICZndDsgYWNjb3JkaW5nbHkgd3J0IFJQSC4gJm5ic3A7VGhpcyBJRCBkb2VzIG5vdGhpbmcgZWxz ZS48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IENvbW1lbnRzIGFyZSBhcHByZWNpYXRl ZC48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDtBIE5ldyBJbnRlcm5ldC1EcmFm dCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHM8YnI+DQomZ3Q7 ICZndDsgJmd0O2RpcmVjdG9yaWVzLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRpdGxlICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7IDogQWxsb3dpbmcgU0lQIFJlc291cmNlIFByaW9yaXR5IEhlYWRl ciBpbiA8YnI+DQomZ3Q7ICZndDsgJmd0OyBTSVAgUmVzcG9uc2VzPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEF1dGhvcihzKSAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KOiBKLiBQb2xrPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IEZpbGVuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs6IGRyYWZ0LXBvbGst c2lwLXJwaC1pbi1yZXNwb25zZXMtMDAudHh0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IFBhZ2VzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7IDogNjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBE YXRlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOzogMjAwNy02LTE1 PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7VGhl IFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBSZXNvdXJjZQ0KUHJpb3JpdHkgSGVh ZGVyPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyhSUEgpLCBpbiBpdHMgY3VycmVu dCBmb3JtLCBpcyBpZ25vcmVkIGluIFNJUA0KcmVzcG9uc2VzLiAmbmJzcDtUaGlzIHdhcyBhPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO2Rlc2lnbiBjaG9pY2UgZHVyaW5nIFJGQyA0 NDEyJ3MgZGV2ZWxvcG1lbnQuDQpUaGlzIGlzIG5vdyBjb25zaWRlcmVkPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJm5ic3A7ICZuYnNwO2EgYmFkIGRlc2lnbiBjaG9pY2UgaW4gY2VydGFpbiBzY2VuYXJp b3MuICZuYnNwO1RoaXMNCmRvY3VtZW50IGNvcnJlY3RzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5i c3A7ICZuYnNwO1JGQyA0NDEyJ3MgY29tbXVuaWNhdGlvbnMgbW9kZWwgYnkgb3B0aW9uYWxseQ0K YWxsb3dpbmcgYSBTSVAgc2VydmVyPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO29y IHVzZXIgYWdlbnQgY2xpZW50IHRvIHByb2Nlc3MgdGhlIFJlc291cmNlLVByaW9yaXR5DQpIZWFk ZXIgaW4gYTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtyZXNwb25zZS48YnI+DQom Z3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7QSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQt RHJhZnQgaXM6PGJyPg0KJmd0OyAmZ3Q7ICZndDtodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1wb2xrLXNpcC1ycGgtaW4tcmVzcG9uc2VzLTAwLnR4dDxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IFNpcCBtYWlsaW5nIGxp c3QgJm5ic3A7aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwPGJyPg0K Jmd0OyAmZ3Q7IFRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRoZSBjb3JlIFNJ UCBQcm90b2NvbDxicj4NCiZndDsgJmd0OyBVc2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJp YS5lZHUgZm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50DQpzaXA8YnI+DQomZ3Q7ICZndDsgVXNlIHNp cHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9wbWVudHMgb24gdGhlIGFwcGxpY2F0aW9uDQpv ZiA8YnI+DQomZ3Q7IHNpcF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KJmd0OyBTaXAgbWFpbGluZyBsaXN0ICZuYnNwO2h0dHBzOi8vd3d3MS5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcDxicj4NCiZndDsgVGhpcyBsaXN0IGlzIGZvciBORVcg ZGV2ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29sPGJyPg0KJmd0OyBVc2Ugc2lwLWlt cGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50IHNpcDxi cj4NCiZndDsgVXNlIHNpcHBpbmdAaWV0Zi5vcmcgZm9yIG5ldyBkZXZlbG9wbWVudHMgb24gdGhl IGFwcGxpY2F0aW9uIG9mIHNpcDwvdHQ+PC9mb250Pg0K --=_alternative 00562A6485257320_=-- --===============1310044988== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1310044988==-- From sip-bounces@ietf.org Sun Jul 22 12:11:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICe2A-0002Nl-Az; Sun, 22 Jul 2007 12:11:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICe28-0002Kr-0P for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 12:11:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICe27-0002Ke-Lg for sip@ietf.org; Sun, 22 Jul 2007 12:11:47 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICe27-0004zW-8n for sip@ietf.org; Sun, 22 Jul 2007 12:11:47 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2007 12:11:47 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusRAL4do0ZAZnme/2dsb2JhbACIX5xj X-IronPort-AV: i="4.16,569,1175486400"; d="scan'208"; a="65819631:sNHT27628934" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6MGBkIi031889; Sun, 22 Jul 2007 12:11:46 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6MGBkWI017013; Sun, 22 Jul 2007 16:11:46 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 12:11:46 -0400 Received: from [10.86.240.164] ([10.86.240.164]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 12:11:46 -0400 Message-ID: <46A381C1.7000103@cisco.com> Date: Sun, 22 Jul 2007 12:11:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Sip] Comment on draft-ietf-sip-fork-loop-fix-05 References: <46A13517.8000406@cisco.com> <8ACAD5AC-8741-4C18-9D3D-445D1558C1CA@nostrum.com> In-Reply-To: <8ACAD5AC-8741-4C18-9D3D-445D1558C1CA@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2007 16:11:46.0258 (UTC) FILETIME=[005E6B20:01C7CC7B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1810; t=1185120706; x=1185984706; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20Comment=20on=20draft-ietf-sip-fork-loop-fix-0 5 |Sender:=20 |To:=20Robert=20Sparks=20; bh=Dqusadc5Bu1BTM1BzFXiFAE3BCxcKSQCYaSTdC1pPY8=; b=ORfyA1TYQvJGDANdeBUwcuYtIJ330xv6YcVqjhEo3+I6klR2ref9hyFPWncEenjfVvHPM9K+ 2z7lN5fI1Nybvt0DFkqoxtGx0iYP58CSMzVPanoglMFY03JX08LWG7pO; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Robert Sparks wrote: > The thing you describe is not a proxy :) > > Seriously, we don't put a lot of work into specifying behavior when > things violate the specification. > > I'd be willing to add a paragraph of general tone noting that the loop > detection mechanism breaks if you remove other people's vias. That works for me. The technique is in widespread use. Often the things doing it are clearly B2BUAs (though that doesn't mitigate the looping problem), but I have certainly heard of things that are otherwise proxies that do this. I think it behooves us to point out when techniques that people think are reasonable actually cause real problems. > (If there were two of the things you describe in the network, removing > each other's vias, then there is no hope of ever detecting a loop). Right. :-( Paul > RjS > > On Jul 20, 2007, at 5:20 PM, Paul Kyzivat wrote: > >> Just catching up :-( >> >> One thing occurred to me - this document goes out of its way to say >> that a proxy need not do the loop check unless it forks. In general >> that makes sense, but in one case it does not: >> >> Some proxies hide/suppress/obfuscate via headers, and then reverse the >> process on responses. A proxy that does so breaks loop checking by any >> of the proxies whose vias it hid. So I think a proxy that does this >> MUST perform a loop check itself even if it does not fork. >> >> Thanks, >> Paul >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 22 12:24:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICeEg-0003eP-UE; Sun, 22 Jul 2007 12:24:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICeEf-0003bJ-EG for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 12:24:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICeEf-0003aY-4L for sip@ietf.org; Sun, 22 Jul 2007 12:24:45 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICeEe-00006a-8A for sip@ietf.org; Sun, 22 Jul 2007 12:24:45 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6MGOYtL027770; Sun, 22 Jul 2007 11:24:39 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 11:24:38 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 18:24:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Jul 2007 18:24:31 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001473975@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some comments on draft-ietf-sips-05 Thread-Index: AcfMfMg2umylmt0YTm6ZBga6G+x+YA== From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 22 Jul 2007 16:24:33.0075 (UTC) FILETIME=[C96D6830:01C7CC7C] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: Francois Audet Subject: [Sip] Some comments on draft-ietf-sips-05 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Some late WGLC comments on this. Don't think there are any showstoppers here. 1) I am not seeing the separation of UAC, UAS, and proxy requirements required by RFC 4485. Please do not write one requirement covering two of these entities, and ideally separate these requirements into separate sections. To me this also means separating UAC and registrar requirements (which for example impacts 4.1.1). The point of this is to make it easy for an implementor of a particular item of equipment (e.g. a terminal, or a proxy including a registrar) to clearly identify their own requirements they have to meet. 2) Section 3.1.3: In fact, implementations SHOULD try to establish a TLS connection when using a SIP URI. Not sure the RFC 2119 language is appropriate here. Surely this should be covered by more specific RFC 2119 language in section 4. 3) Section 4.1.3: As a general principle, derived dialogs and transactions MUST NOT result in an effective downgrading of SIPS to SIP, without the explicit authorization of the entities involved. Not sure how we can demonstrate true compliance against this, and therefore do not believe the RFC 2119 language is appropriate. 4) Section 4.1.4: Again, the general principle is that these mechanism SHOULD NOT result in an effective downgrading of SIPS to SIP, without the proper authorization. Again, not sure how we can demonstrate true compliance against this, and therefore do not believe the RFC 2119 language is appropriate. 5) Section 4.2: Some proxies MAY have policies that prohibits sending any request over anything but TLS. In the context, this is just explaining the previous SHOULD. I don't think the RFC 2119 language is appropriate. Similarly for this text in the same section: Some proxies MAY have a policy of not forwarding at all requests using a non-SIPS Request-URI if the UAS had registered using a SIPS Contact header fields. 6) Section 4.2: The "transport=3Dtls" parameter must not be used by proxies that conform to this specification. Is this a restatement of the text in RFC 3261 (in which case I would prefer quoting the RFC 3261 text) and saying that there is no change from this: Note that in the SIPS URI scheme, transport is independent of TLS, and thus "sips:alice@atlanta.com;transport=3Dtcp" and "sips:alice@atlanta.com;transport=3Dsctp" are both valid (although note that UDP is not a valid transport for SIPS). The use of "transport=3Dtls" has consequently been deprecated, partly because it was specific to a single hop of the request. This is a change since RFC 2543. Or is it a new normative requirement in its own right, in which case the we need "MUST NOT". 7) Section 5.1: This response differs from 416 because the UAS or proxy recognizes the SIPS URI but it is not allowed, and because the UAC SHOULD NOT retry the request automatically using a SIP URI. Is this attempting to state (in which case it should be elsewhere): If a 418 (SIPS Not Allowed) is received, the UAC SHOULD NOT retry the request automatically using a SIP URI. Or is it just defining the semantics of the 418 in which case the RFC 2119 language is not appropriate. 8) Section 5.2: The UAC SHOULD retry the request automatically using a SIPS URI. Again not convinced that the RFC 2119 language is appropriate here. This should be defining the semantics of the response code. 9) Section 7: For mutual TLS, it means that one should be very careful that the architecture of the network is such that connections are made between entities that have access to each other's certificates. Record-Route [RFC3261] and Path [RFC3327] are very useful in ensuring that previously established TLS connections can be re-used. Other mechanisms may also be used in certain circumstances: for example, using root certificates that are widely recognized may allow for more easily created TLS connections. Does this not get covered by the connect-reuse draft, if we ever get that finished. NITS: ----- A) There is significant usage of lower case RFC 2119 language, particularly "must". I believe it is desirable to avoid this type of usage if possible, as it only takes a slip of the editor for it to become a "MUST" and we have a new requirement that was not agreed by the WG. I think it is possible to find alternatives. B) There are a number of instances of "it" where I would prefer "the proxy" or whatever, e.g. in structures such as:=20 When a proxy inserts a Record-Route entry, it must take care in using the proper scheme=20 Should become "the proxy". I don't want people fighting their way back in the sentence to find the real subject. And If the proxy needs to reject the request for that reason, it MUST reject it with a 418 (SIPS Not Allowed). Should become: If the proxy needs to reject the request for that reason, the proxy MUST reject it with a 418 (SIPS Not Allowed). C) Ensure that all request names, e.g "REGISTER" are followed by "request", i.e. "REGISTER request". D) Section 4.1.2: Because registering with a SIPS Contact header field implies a binding of both a SIPS Contact and a corresponding SIP Contact to the AOR, a UA MUST NOT include both the SIPS and the SIP version of the same Contact header field in a REGISTER: it MUST only use the SIPS version in this case. ":" --> ";", and also as in B) above "it" --> "the UA" E) Capitalisation. "proxy", "redirect server" etc are not proper nouns, therefore please use lower case initial letters. F) Section 4.1.2: If all the Contact header fields in a REGISTER are SIPS, a SIPS AOR MUST be used by the UAC in the REGISTER. If at least one of the Contact header fields is SIP or is neither SIP nor SIPS (e.g., mailto, tel, http, https), a SIP AOR MUST also be used by the UAC.=20 Rewrite as If all the Contact header fields in a REGISTER request are SIPS, a the UAC=20 MUST use a SIPS AOR in the REGISTER request. If at least one of the Contact header fields is SIP or is neither SIP nor SIPS (e.g., mailto, tel, http, https), the UAC MUST also use a SIP AOR. G) Section 4.1.3: If the top Route header field does not contain a SIPS URI, the Contact header field MUST be a SIP URI, even if the request is sent over a secure transport (e.g., the first hop could be re-using a TLS connection to the proxy as would be the case with [I-D.ietf-sip-outbound]). Rewrite to clearly indicate a UAC requirement, ie. "the UAC must..." H) Section 4.1.4: If that initial dialog was established using SIPS, then the new one MUST NOT be established using SIP, unless there is an explicit authorization given by the recipient of the REFER. Rewrite to clearly indicate a UAC requirement, ie. "the UAC must..." I) Appendix B: If the address-of-record in the To header field of a REGISTER request is a SIPS URI, then any Contact header field value in the request MUST also be SIPS URIs. Rewrite as UAC requirement: If the address-of-record in the To header field of a REGISTER request is a SIPS URI, then the UAC MUST also include only SIPS URIs in any Contact header field value in the request. Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 22 13:40:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICfQF-0007fV-Cj; Sun, 22 Jul 2007 13:40:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICfQD-0007fB-Vg for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 13:40:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICfQD-0007f0-LF for sip@ietf.org; Sun, 22 Jul 2007 13:40:45 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICfQD-0006nY-4Y for sip@ietf.org; Sun, 22 Jul 2007 13:40:45 -0400 Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l6MHegLQ011853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jul 2007 12:40:42 -0500 (CDT) Received: from [127.0.0.1] (volkerh.lra.lucent.com [135.244.33.61]) by umail.lucent.com (8.13.8/TPES) with ESMTP id l6MHeZRc029808; Sun, 22 Jul 2007 12:40:42 -0500 (CDT) Message-ID: <46A39693.4000707@bell-labs.com> Date: Sun, 22 Jul 2007 13:40:35 -0400 From: Volker Hilt User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] I-D ACTION:draft-hilt-sip-correction-503-01.txt References: <4693F5F9.2010608@bell-labs.com> <200707121731.l6CHVCbV007856@dragon.ariadne.com> In-Reply-To: <200707121731.l6CHVCbV007856@dragon.ariadne.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.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dale.Worley@comcast.net wrote: > From: Volker Hilt > > I've submitted a new version of the "Essential Correction to the Session > Initiation Protocol (SIP) 503 (Service Unavailable) Response": > http://www.ietf.org/internet-drafts/draft-hilt-sip-correction-503-01.txt > > This work is important, but I don't see how it fits in the category > "essential correction", as a SIP system can function without it. > Perhaps you could add a section explaining why it is an essential > correction. > The problem is that, with the current mechanism, a SIP system won't function properly when it is in overload in many deployments. Since it seems close to impossible to dimension a SIP system so that it will never experience overload, I think fixing this is important for the functioning of a SIP system. I'll add a section explaining this to the next rev of the draft. Thanks, Volker > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 22 18:10:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICjcz-0007NS-WC; Sun, 22 Jul 2007 18:10:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICjcy-0007NN-47 for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 18:10:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICjcx-0007NF-Qo for sip@ietf.org; Sun, 22 Jul 2007 18:10:11 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICjcx-0005rj-E8 for sip@ietf.org; Sun, 22 Jul 2007 18:10:11 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Jul 2007 18:10:11 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOJxo0ZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,569,1175486400"; d="scan'208"; a="126708074:sNHT27137030" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6MMAB2Z002062; Sun, 22 Jul 2007 18:10:11 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6MMAAEZ022975; Sun, 22 Jul 2007 22:10:10 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 18:10:10 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.20.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jul 2007 18:10:10 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 22 Jul 2007 17:10:08 -0500 To: "DRAGE, Keith \(Keith\)" , From: "James M. Polk" In-Reply-To: <5D1A7985295922448D5550C94DE2918001473951@DEEXC1U01.de.luce nt.com> References: <5D1A7985295922448D5550C94DE2918001473951@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 22 Jul 2007 22:10:10.0553 (UTC) FILETIME=[11ED6E90:01C7CCAD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1946; t=1185142211; x=1186006211; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20Comments=20on=20draft-polk-sip-rph-new-namespaces-00 |Sender:=20 |To:=20=22DRAGE, =20Keith=20\(Keith\)=22=20, =20< sip@ietf.org>; bh=R5HkUnNii33JgQwD76Kkr/jxUIzYfse8BeOfr0/lHPE=; b=KWnN0iNuMDUfuGA86aD6AX/mhG/Ob2Le1+UHGjtQrXvsbznEZfom5Pc+zDrRluZSvWCn2ZrC ReSp1WP9UlUrDb2DE3oKzYyaTQpNDM0Cr+1UJQ9XHRNfWle+NVh7yxw1; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Subject: [Sip] Re: Comments on draft-polk-sip-rph-new-namespaces-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 11:15 PM 7/21/2007, DRAGE, Keith \(Keith\) wrote: >1) I am not convinced this document does updated RFC 4412. this ID is creating the OPTIONAL delimiter, which would be opaque to implementers otherwise, and potentially causing implementations to not process the header (therefore message) correctly. I know this is a *really* small update, but since this delimiter is splitting the namespace into two-parts, when the '-' character appears, it requires coders to code differently according to this document - were they to chose to support this extension to RFC4412. Coders will look for the '-' character anywhere in a namespace, and have special process(es) for namespaces that have this delimiter. >RFC 4412 >creates the namespace. This document merely adds new items to the IANA >registry created by that document. and the delimiter >The document header should be >modified accordingly, and the following text in the abstract also >corrected: > > This > document intends to update RFC 4412, as a Proposed Standard document > if published by the RFC-Editor. once we agree, yes >2) I believe the abstract could usefully summarise the new >namespaces that are created (in the same way as most drafts that define >new headers identify them in the abstract). I'm open to how to summarize the new namespaces. Should the abstract state the namespaces are for DISA? >3) In section 3, I do not see the need to include the following >text in the document, as it is already in RFC 4412, for which all the >requirements apply, not just this one. > > As stated in Section 9 of RFC 4412 [RFC4412], an IANA registered > namespace SHOULD NOT change the number, and MUST NOT change the > relative priority order, of its assigned priority-values. fair point >4) NIT. Tag all mentions of RFC4412 as references. will do >Regards > >Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 22 20:27:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IClld-0000Ed-KG; Sun, 22 Jul 2007 20:27:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICllc-0000ER-Dg for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 20:27:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICllc-0000EJ-2z for sip@ietf.org; Sun, 22 Jul 2007 20:27:16 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICllb-0005gG-D1 for sip@ietf.org; Sun, 22 Jul 2007 20:27:15 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6FEA52063C; Mon, 23 Jul 2007 02:27:14 +0200 (CEST) X-AuditID: c1b4fb3c-b1681bb0000007e1-23-46a3f5e28edd Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 49D09203E6; Mon, 23 Jul 2007 02:27:14 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 02:27:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO and Content Negotiation Date: Mon, 23 Jul 2007 02:27:11 +0200 Message-ID: <7374777208BDC7449D5620EF9423256707479CEF@esealmw113.eemea.ericsson.se> In-Reply-To: <46A36757.7020500@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO and Content Negotiation Thread-Index: AcfMa0mHQI3e7XDcRjaXnHidtQ0wFQAVISQg References: <7374777208BDC7449D5620EF942325670743C97A@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF942325670743C97B@esealmw113.eemea.ericsson.se> <46A36757.7020500@nostrum.com> From: "Christer Holmberg (JO/LMF)" To: "Adam Roach" X-OriginalArrivalTime: 23 Jul 2007 00:27:13.0597 (UTC) FILETIME=[373E5ED0:01C7CCC0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: IETF SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I think it is clearly said that INFO is not to be used to directly = modify the SIP session, so unless there is an application on top of the = SIP session that understands this information it would simply be = rejected. Regards, Christer =20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 22. hein=E4kuuta 2007 17:19 > To: Christer Holmberg (JO/LMF) > Cc: Eric Burger; IETF SIP > Subject: Re: [Sip] INFO and Content Negotiation >=20 > To rephrase what Eric is saying here in base principles:=20 > _inferring_ what can be done with INFO by examining supported=20 > content types is a "Do What I Mean" mechanism (as opposed to=20 > a "Do What I Say" mechanism). "Do What I Mean" is a=20 > well-known recipe for interoperability failure. (For a well=20 > constructed discussion of this, see Jonathan's service=20 > indication draft). >=20 > This is, for example, why we have an "Event" header field in=20 > RFC 3265 instead of simply inferring the event package from=20 > MIME type. (In fact, this is why I started the draft that=20 > became 3265 in the first place -- with the dual uses of PINT=20 > and presence threatening to take the SUBSCRIBE method down=20 > the path that INFO unfortunately ended up taking, an=20 > intervention was necessary). >=20 > To re-cast Eric's example from a slightly different angle:=20 > imagine that a desired usage of INFO most naturally used=20 > application/sdp as its payload. How would one indicate=20 > support for such a usage? >=20 > /a >=20 > Christer Holmberg (JO/LMF) wrote: > > Hi, > > > > I still don't get it, but let's take it face-to-face at=20 > some point :) > > > > Regards, > > > > Christer > > > > =20 > >> -----Original Message----- > >> From: Eric Burger [mailto:eburger@bea.com] > >> Sent: 22. hein=E4kuuta 2007 10:14 > >> To: Christer Holmberg (JO/LMF); IETF SIP > >> Subject: Re: [Sip] INFO and Content Negotiation > >> > >> That is the point - people have been saying, "I can=20 > negotiate INFO by=20 > >> using Content-Type." This is a tiny example where using=20 > Content-Type=20 > >> to negotiate "INFO Packages" falls apart. > >> > >> > >> On 7/22/07 3:10 AM, "Christer Holmberg (JO/LMF)" > >> wrote: > >> > >> =20 > >>> Why would I be expecting KPML, if I have only indicated > >>> =20 > >> that I support > >> =20 > >>> DTMF-over-INFO? > >>> > >>> If I was to expect KPML, I would first need to establish a=20 > >>> subscription for KPML (or, in our "controlled network", the=20 > >>> subscription would be established by default, and I would > >>> =20 > >> know you are going to send KPML). > >> =20 > >>> Regards, > >>> > >>> Christer > >>> > >>> =20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 22 20:37:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IClvO-0006fX-GQ; Sun, 22 Jul 2007 20:37:22 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IClvN-0006fR-Cr for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 20:37:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IClvN-0006fJ-3I for sip@ietf.org; Sun, 22 Jul 2007 20:37:21 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IClvM-0008J0-D4 for sip@ietf.org; Sun, 22 Jul 2007 20:37:21 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DE6EE20650; Mon, 23 Jul 2007 02:37:19 +0200 (CEST) X-AuditID: c1b4fb3c-b1e82bb0000007e1-92-46a3f83feb92 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BEFE3204B1; Mon, 23 Jul 2007 02:37:19 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 02:37:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO and Content Negotiation Date: Mon, 23 Jul 2007 02:37:18 +0200 Message-ID: <7374777208BDC7449D5620EF9423256707479CF2@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256707479CEF@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO and Content Negotiation Thread-Index: AcfMa0mHQI3e7XDcRjaXnHidtQ0wFQAVISQgAABdQmA= References: <7374777208BDC7449D5620EF942325670743C97A@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF942325670743C97B@esealmw113.eemea.ericsson.se><46A36757.7020500@nostrum.com> <7374777208BDC7449D5620EF9423256707479CEF@esealmw113.eemea.ericsson.se> From: "Christer Holmberg (JO/LMF)" To: "Adam Roach" X-OriginalArrivalTime: 23 Jul 2007 00:37:19.0606 (UTC) FILETIME=[A0740160:01C7CCC1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: IETF SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I forgot the part about the indication of the support. I agree that Accept: application/sdp itself may not be enough to = indicate the support for the specific usage. So, either you could have e.g. an option-tag, some application = identifier, an extention to the Accept header - or we would simply say = that INFO cannot be used to transport SDP (as I've said many times, I am = not proposing to allow to use INFO for whatever people want to). Regards, Christer=20 > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: 23. hein=E4kuuta 2007 3:27 > To: Adam Roach > Cc: IETF SIP > Subject: RE: [Sip] INFO and Content Negotiation >=20 >=20 > Hi, >=20 > I think it is clearly said that INFO is not to be used to=20 > directly modify the SIP session, so unless there is an=20 > application on top of the SIP session that understands this=20 > information it would simply be rejected. >=20 > Regards, >=20 > Christer >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Adam Roach [mailto:adam@nostrum.com] > > Sent: 22. hein=E4kuuta 2007 17:19 > > To: Christer Holmberg (JO/LMF) > > Cc: Eric Burger; IETF SIP > > Subject: Re: [Sip] INFO and Content Negotiation > >=20 > > To rephrase what Eric is saying here in base principles:=20 > > _inferring_ what can be done with INFO by examining=20 > supported content=20 > > types is a "Do What I Mean" mechanism (as opposed to a "Do=20 > What I Say"=20 > > mechanism). "Do What I Mean" is a well-known recipe for=20 > > interoperability failure. (For a well constructed=20 > discussion of this,=20 > > see Jonathan's service indication draft). > >=20 > > This is, for example, why we have an "Event" header field=20 > in RFC 3265=20 > > instead of simply inferring the event package from MIME type. (In=20 > > fact, this is why I started the draft that became 3265 in the first=20 > > place -- with the dual uses of PINT and presence=20 > threatening to take=20 > > the SUBSCRIBE method down the path that INFO unfortunately ended up=20 > > taking, an intervention was necessary). > >=20 > > To re-cast Eric's example from a slightly different angle:=20 > > imagine that a desired usage of INFO most naturally used=20 > > application/sdp as its payload. How would one indicate support for=20 > > such a usage? > >=20 > > /a > >=20 > > Christer Holmberg (JO/LMF) wrote: > > > Hi, > > > > > > I still don't get it, but let's take it face-to-face at > > some point :) > > > > > > Regards, > > > > > > Christer > > > > > > =20 > > >> -----Original Message----- > > >> From: Eric Burger [mailto:eburger@bea.com] > > >> Sent: 22. hein=E4kuuta 2007 10:14 > > >> To: Christer Holmberg (JO/LMF); IETF SIP > > >> Subject: Re: [Sip] INFO and Content Negotiation > > >> > > >> That is the point - people have been saying, "I can > > negotiate INFO by > > >> using Content-Type." This is a tiny example where using > > Content-Type > > >> to negotiate "INFO Packages" falls apart. > > >> > > >> > > >> On 7/22/07 3:10 AM, "Christer Holmberg (JO/LMF)" > > >> wrote: > > >> > > >> =20 > > >>> Why would I be expecting KPML, if I have only indicated > > >>> =20 > > >> that I support > > >> =20 > > >>> DTMF-over-INFO? > > >>> > > >>> If I was to expect KPML, I would first need to establish a=20 > > >>> subscription for KPML (or, in our "controlled network", the=20 > > >>> subscription would be established by default, and I would > > >>> =20 > > >> know you are going to send KPML). > > >> =20 > > >>> Regards, > > >>> > > >>> Christer > > >>> > > >>> =20 > >=20 > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 22 20:40:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IClyR-0002bD-9r; Sun, 22 Jul 2007 20:40:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IClyQ-0002b6-HA for sip-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 20:40:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IClyQ-0002aw-7O for sip@ietf.org; Sun, 22 Jul 2007 20:40:30 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IClyO-0008PK-0h for sip@ietf.org; Sun, 22 Jul 2007 20:40:29 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 383C0200F2; Mon, 23 Jul 2007 02:40:27 +0200 (CEST) X-AuditID: c1b4fb3e-af032bb0000007e1-cc-46a3f8fb7d51 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 07830201C2; Mon, 23 Jul 2007 02:40:27 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 02:40:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO and Content Negotiation Date: Mon, 23 Jul 2007 02:40:25 +0200 Message-ID: <7374777208BDC7449D5620EF9423256707479CF4@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256707479CF2@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO and Content Negotiation Thread-Index: AcfMa0mHQI3e7XDcRjaXnHidtQ0wFQAVISQgAABdQmAAACmV8A== References: <7374777208BDC7449D5620EF942325670743C97A@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF942325670743C97B@esealmw113.eemea.ericsson.se><46A36757.7020500@nostrum.com><7374777208BDC7449D5620EF9423256707479CEF@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256707479CF2@esealmw113.eemea.ericsson.se> From: "Christer Holmberg (JO/LMF)" To: "Adam Roach" X-OriginalArrivalTime: 23 Jul 2007 00:40:26.0327 (UTC) FILETIME=[0FBF5E70:01C7CCC2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: IETF SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 ...and I guess you would also use another content-disposition value than = "session" in your usage (again, since INFO cannot be used to directly = modify the SIP session). NOW I'm done with the reply to your e-mail ;) Regards, Christer > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: 23. hein=E4kuuta 2007 3:37 > To: Adam Roach > Cc: IETF SIP > Subject: RE: [Sip] INFO and Content Negotiation >=20 >=20 > Hi, >=20 > I forgot the part about the indication of the support. >=20 > I agree that Accept: application/sdp itself may not be enough=20 > to indicate the support for the specific usage. >=20 > So, either you could have e.g. an option-tag, some=20 > application identifier, an extention to the Accept header -=20 > or we would simply say that INFO cannot be used to transport=20 > SDP (as I've said many times, I am not proposing to allow to=20 > use INFO for whatever people want to). >=20 > Regards, >=20 > Christer=20 >=20 >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: 23. hein=E4kuuta 2007 3:27 > > To: Adam Roach > > Cc: IETF SIP > > Subject: RE: [Sip] INFO and Content Negotiation > >=20 > >=20 > > Hi, > >=20 > > I think it is clearly said that INFO is not to be used to directly=20 > > modify the SIP session, so unless there is an application on top of=20 > > the SIP session that understands this information it would=20 > simply be=20 > > rejected. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Adam Roach [mailto:adam@nostrum.com] > > > Sent: 22. hein=E4kuuta 2007 17:19 > > > To: Christer Holmberg (JO/LMF) > > > Cc: Eric Burger; IETF SIP > > > Subject: Re: [Sip] INFO and Content Negotiation > > >=20 > > > To rephrase what Eric is saying here in base principles:=20 > > > _inferring_ what can be done with INFO by examining > > supported content > > > types is a "Do What I Mean" mechanism (as opposed to a "Do > > What I Say"=20 > > > mechanism). "Do What I Mean" is a well-known recipe for=20 > > > interoperability failure. (For a well constructed > > discussion of this, > > > see Jonathan's service indication draft). > > >=20 > > > This is, for example, why we have an "Event" header field > > in RFC 3265 > > > instead of simply inferring the event package from MIME type. (In=20 > > > fact, this is why I started the draft that became 3265 in=20 > the first=20 > > > place -- with the dual uses of PINT and presence > > threatening to take > > > the SUBSCRIBE method down the path that INFO=20 > unfortunately ended up=20 > > > taking, an intervention was necessary). > > >=20 > > > To re-cast Eric's example from a slightly different angle:=20 > > > imagine that a desired usage of INFO most naturally used=20 > > > application/sdp as its payload. How would one indicate=20 > support for=20 > > > such a usage? > > >=20 > > > /a > > >=20 > > > Christer Holmberg (JO/LMF) wrote: > > > > Hi, > > > > > > > > I still don't get it, but let's take it face-to-face at > > > some point :) > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > =20 > > > >> -----Original Message----- > > > >> From: Eric Burger [mailto:eburger@bea.com] > > > >> Sent: 22. hein=E4kuuta 2007 10:14 > > > >> To: Christer Holmberg (JO/LMF); IETF SIP > > > >> Subject: Re: [Sip] INFO and Content Negotiation > > > >> > > > >> That is the point - people have been saying, "I can > > > negotiate INFO by > > > >> using Content-Type." This is a tiny example where using > > > Content-Type > > > >> to negotiate "INFO Packages" falls apart. > > > >> > > > >> > > > >> On 7/22/07 3:10 AM, "Christer Holmberg (JO/LMF)" > > > >> wrote: > > > >> > > > >> =20 > > > >>> Why would I be expecting KPML, if I have only indicated > > > >>> =20 > > > >> that I support > > > >> =20 > > > >>> DTMF-over-INFO? > > > >>> > > > >>> If I was to expect KPML, I would first need to establish a=20 > > > >>> subscription for KPML (or, in our "controlled network", the=20 > > > >>> subscription would be established by default, and I would > > > >>> =20 > > > >> know you are going to send KPML). > > > >> =20 > > > >>> Regards, > > > >>> > > > >>> Christer > > > >>> > > > >>> =20 > > >=20 > > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 23 07:03:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICvhQ-0006p6-Fu; Mon, 23 Jul 2007 07:03:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICvhO-0006p1-PI for sip-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 07:03:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICvhO-0006ot-Fm for sip@ietf.org; Mon, 23 Jul 2007 07:03:34 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICvhM-0002S6-Kd for sip@ietf.org; Mon, 23 Jul 2007 07:03:34 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLM003PWPDVA8@usaga01-in.huawei.com> for sip@ietf.org; Mon, 23 Jul 2007 04:03:31 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLM00DFGPDTW3@usaga01-in.huawei.com> for sip@ietf.org; Mon, 23 Jul 2007 04:03:31 -0700 (PDT) Received: from [172.24.1.6] (Forwarded-For: [67.97.210.2]) by szxmc04-in.huawei.com (mshttpd); Mon, 23 Jul 2007 19:03:28 +0800 Date: Mon, 23 Jul 2007 19:03:28 +0800 From: sunqian 32328 Subject: Re: [Sip] comments on draft-camarillo-sip-body-handling-01 In-reply-to: <46A2DB31.8080903@cisco.com> To: Paul Kyzivat Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: <46A2DB31.8080903@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: 'IETF SIP List' , Gonzalo Camarillo X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Could different SIP methods (INVITE, MESSAGE) be given different Levels of Support for Multipart? Best Regards, Qian Sun ----- Original Message ----- From: Paul Kyzivat Date: Sunday, July 22, 2007 12:21 pm Subject: Re: [Sip] comments on draft-camarillo-sip-body-handling-01 > One of the tasks of the draft is to make support for at least some > subtypes of multipart (e.g. mixed) mandatory. > > I hope this is not a suggestion to make dereferencing of external > bodies > mandatory. > > If the request is just to include some clarification of the use > and > handling of external bodies in this draft then I guess that does > sound > useful. > > Paul > > Eric Burger wrote: > > Seems like a good idea. However, I would not go so far as to > mandate> iterative evaluation. I would offer that the UA > evaluates as needed. > > > > > > On 7/20/07 3:58 AM, "Qian Sun" wrote: > > > >> Hi, > >> I suggest Content Indirection Mechanism defined in rfc4483 > should also be > >> considered in this draft. > >> > >> It is a little special, an example from rfc4483: > >> 6.1. Single Content Indirection > >> > >> INVITE sip:boromir@example.com SIP/2.0 > >> Accept: message/external-body application/sdp > >> Content-Type: message/external-body; > >> ACCESS-TYPE=URL; > >> > URL="http://www.example.net/party/06/2002/announcement";>> > EXPIRATION="Sat, 20 Jun 2002 12:00:00 GMT"; > >> size=231 > >> Content-Length: 105 > >> > >> Content-Type: application/sdp > >> Content-Disposition: session > >> Content-ID: <4e5562cd1214427d@example.net> > >> > >> In addition, what happens to the INVITE request if the > recipient can not get > >> the indirect content? > >> > >> Nits: a letter "l" is missing in the title. > >> Internet-Draft Message Body Hand"l"ing in SIP > May 2007 > >> > >> Cheers, > >> Qian > >> > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Friday, July 20, 2007 2:30 AM > >> To: Gonzalo Camarillo > >> Cc: IETF SIP List > >> Subject: Re: [Sip] comments on draft-camarillo-sip-body- > handling-01 > >> > >> Just one comment in addition to what Gonzalo said: > >> > >> Gonzalo Camarillo wrote: > >> > >>>> The use case described for multipart/alternative - new SDP > mechanisms>>>> - seems kind of bogus. We've decided not to pursue > that. Do we have a > >>>> REAL use case for this? > >>> AFAICT, we have decided not to pursue SDPng but we still need a > >>> mechanism in order to be able to, at some point, migrate to > new session > >>> description formats. The current consensus, as I understand > it, is that > >>> multipart/alternative should not be used to provide > alternative SDP > >>> descriptions, but that it could be used to provide alternative > session>>> descriptions written in different formats. > >> The other classic example, because it is just like email, is > MESSAGE>> with a multipart/alternative containing plain text and html. > >> > >> Paul > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > >> > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > > > > > > Notice: This email message, together with any attachments, may > contain information of BEA Systems, Inc., its subsidiaries > and affiliated entities, that may be confidential, proprietary, > copyrighted and/or legally privileged, and is intended solely > for the use of the individual or entity named in this message. If > you are not the intended recipient, and have received this message > in error, please immediately return this by email and then delete it. > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 23 09:03:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICxZ4-00034X-6u; Mon, 23 Jul 2007 09:03:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICxZ2-00034K-KC for sip-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 09:03:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICxZ2-00034A-7A for sip@ietf.org; Mon, 23 Jul 2007 09:03:04 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICxZ0-0004U8-Bh for sip@ietf.org; Mon, 23 Jul 2007 09:03:04 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 23 Jul 2007 09:03:01 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAFVEpEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,570,1175486400"; d="scan'208"; a="65869722:sNHT48686584" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6ND31X6022684 for ; Mon, 23 Jul 2007 09:03:01 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6ND2gFD013997 for ; Mon, 23 Jul 2007 13:03:01 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 09:02:54 -0400 Received: from [10.86.243.5] ([10.86.243.5]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 09:02:54 -0400 Message-ID: <46A4A706.4020508@cisco.com> Date: Mon, 23 Jul 2007 09:03:02 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 13:02:54.0331 (UTC) FILETIME=[C86D54B0:01C7CD29] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=16561; t=1185195781; x=1186059781; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20comments=20on=20draft-ietf-sip-sips |Sender:=20 |To:=20IETF=20SIP=20List=20; bh=BwHsUWP4DR5mPCMkeGuYrrQy8P7docPTcQhQ2Pq6a7c=; b=IuFkIGlevQHtraqsyl7p4fz3nsLh3J86ZTTnZIXj/HT+ZuxX4xbn7ddkMKITdnZFmiIlKDrF 69k36gfD7RujfifdngFk5Ah006QwKcrZSSzgk3LYVQPhh0tTiQywY4It; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad Subject: [Sip] comments on draft-ietf-sip-sips X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My two main large comments are organizational, but they are important: 1. the draft reads like a union of an informational overview of sips and a normative specification of sips. If this draft is meant to normatively describe sips, section 3 needs to turn into a proper overview of operations section. Right now it is enormous, way out of wack for what it should be. 2. the normative rules are very hard to follow. They need to be split up in the way described in rfc4596, and have clear rules for UAC, UAS and proxy. They should separately handle dialog forming requests, mid-dialog requests, registrations, and non-dialog requests for all three. Some more specific comments: > While SIPS is useful to request that a resource be contacted > securely, it is not useful as an indication that a resource was in > fact contacted securely. This is not quite true; its an indication that, if you trust all proxies, the resource will be contacted securely. > There is > currently no mechanism to provide an indication of end-to-end > security for SIP. I think its worth noting here that this is a consequence of the difficulty in doing this. The fact that we have both signaling and media, that the connectivity is between two endpoints and not just client/server, and things like conferences and PSTN gateways make this incredibly complicated - far more than a web server. > Some have asked why is SIPS useful in a global open environment such > as the Internet, if (when used in a Request-URI) it is not an > absolute guarantee that the request will in fact be delivered over > TLS on each hop? Why is SIPS any different than just using TLS > transport with SIP? there are two separate questions here and your text that follows answers only the second. To answer the first, I think its important to point out that, a large number of deployments make an assumption that the servers are trusted. In such a deployment, sips provides protection against a large number of attacks that would otherwise be possible. It prevents against eavesdropping of signaling, modification of signaling, and other attacks by any outsider. The only attack it does not mitigate is ones where the network infrastructure itself is the attacker. However, the view is that its level of security is satisfactory for many applications. > It is outside of the scope of this document to specify what > happens when a SIPS URI identifies a UAS resource that "maps" outside > of the SIP network, for example, to other networks such as the PSTN. A SIPS URI never identifies a resource outside of SIP; its definition is that it identifies a sip resource. That resource may just happen to be a number on a PSTN gateway, which the gateway then chooses to contact through the PSTN. The main point is that SIPS protects only within the SIP network, from UAC to UAS. Section 3.2.1 is really short and its not clear why its not just folded into 3.2, or else 3.2 should be split up more. > Since upgrading from SIP to SIPS is allowed in other circumstances > (e.g., a user "guessing" a SIPS AOR from a SIP AOR on a business > card), I think its important to be clear here that this upgrading is by a human user and not by a proxy. Also the term guessing is wrong since its not a guess at all that this is the right URI. It is. Its only a guess about whether it will work. Of course you can't know in advance if a call to a non-SIPS URI will work either. So I'd suggest nuking the 'guessing' term. Section 3.3 is pretty clear on downgrading but is very vague on upgrading. Some clear statements here are needed. > to describe how to achieve backward compatibility. If a proxy > conforms to this specification, the procedures in this section are > not used. If we have eliminated changing from SIP to SIPS we should nuke this section. Anyway double record-routing is now documented in the record-route-fix draft so why do we need it here. > The reinstatement of the transport=tls parameter, or of an > alternative mechanism for indicating the use of the TLS on a single > hop in a URI, is outside the scope of this specification (see > Appendix A.3). Its really odd that we have a whole section explaining how it works, followed by a statement that says ignore the previous section since we are not re-instating it. If its in, we should describe it. If its out, we should say so, and thats it. I personally think real world experience has shown it useful and we should keep it. > When presented with a SIPS URI, a UAC or UAS MUST NOT change it to a > SIP URI. For example, if a directory entry includes a SIPS AOR, the > UAC must not send requests to that AOR using a SIP Request-URI. > Similarly, if a user reads a business card with a SIPS URI, he should > not infer a SIP URI. If a 3XX response includes a SIPS Contact > header field, the UAC MUST NOT replace it with a SIP Request-URI > (e.g., by replacing the SIPS scheme with a SIP scheme) when sending a > request as a result of the redirection. I think with user interaction this is fine, and certainly cannot be prevented. > If a UAS does not wish to be reached with a SIPS URI but only with a > SIP URI, it SHOULD respond with a 418 (SIPS Not Allowed). Respond to what? I think you need to say, "request whose request-URI is a SIP URI" > Upon receiving a 416 or 418, a UAC MUST NOT re- > attempt the request by automatically replacing the SIPS scheme with a > SIP scheme as described in [RFC3261]/8.1.3.5 as it would be a > security vulnerability. If the UAC does re-attempt the call with a > SIP URI, it SHOULD get a confirmation from the user to authorize re- > initiating the session with a SIP Request-URI instead of a SIPS > Request-URI. These two sentences are contradictory. Section 4 really needs to have separate behaviors for UAC and UAS, proxy and registrar. > The UAC registers Contacts header fields to either a SIPS or a SIP > AOR. From a routing perspective, it does not matter which one is > used for registration as they identify the same resource. the part, "which one is used" could refer to either contact or AOR. You should clarify you mean AOR in the To header field. > Similarly, a UA SHOULD NOT register both a SIP > Contact header field and a SIPS Contact header field in separate > registrations as the SIP Contact header field would be superfluous. What should proxy routing logic be in this case? Should clarify. > If all the Contact header fields in a REGISTER are SIPS, a SIPS AOR > MUST be used by the UAC in the REGISTER. If at least one of the > Contact header fields is SIP or is neither SIP nor SIPS (e.g., > mailto, tel, http, https), a SIP AOR MUST also be used by the UAC. > However, the registrar MUST treat the SIP and SIPS schemes of the AOR > the same way (i.e., it MUST not care if it is SIP or SIPS). These > are purely mechanical rules with no influence on routing. The MUST requirement for setting the AOR in the To header field doesn't make sense when combined with the requirement that proxies MUST treat sip and sips the same. The requirement on the AOR in the To from a UAC probably should be a SHOULD. Also you should be clear that when you say AOR you mean To header field since there is an AOR in the From header field also. > Furthermore, it is a matter of local policy for a UA to accept > incoming requests addressed to a URI scheme that does not correspond > to what it used for registration. For example, a UA with a policy of > "always SIPS" would address the Registrar using a SIPS Request-URI > over TLS, This is the first mention of setting the R-URI in REGISTER. I think its important. Indeed this paragraph provides the clearest guidance on what to do, and its not normative text.. > A registrar MUST only accept a binding to a SIPS Contact header field > if all the appropriate URIs are of the SIPS scheme, otherwise there > could be an inadvertent binding of a secure resource (SIPS) to an > unsecured one (SIP). This includes the Request-URI, the Contacts and > all the Path headers, but does not include the From and To headers. > If the URIs are not of the proper SIPS scheme, the registrar MUST > reject the REGISTER with a 419 (SIPS Required). You need to define 'appropriate'. Please state explicit cases and behaviors that are required. > If the Request-URI in a request that initiates a dialog is a SIP URI, > then the UAC needs to be careful about what to use in the Contact > header field (in case Record-Route is not used for this hop). If the > > > > Audet Expires December 27, 2007 [Page 17] > > Internet-Draft SIPS June 2007 > > > Contact header field was a SIPS URI, it would mean that it would only > accept mid-dialog requests that are sent over secure transport on > each hop. I thought we were going to forbid this case. If the R-URI is SIP, then Contact, Route, etc. are all SIP. If the R-URI is SIPS, then Route and Contact are SIPS. Mixed modes not allowed. > When a target refresh occurs within a dialog (e.g., re-INVITE, > UPDATE), the UAC and UAS MUST include a Contact header field with a > SIPS URI if the original request used a SIPS Request-URI. You'll get this for free as a side effect of normal dialog processing rules. > Note that a REFER may also be used for referring to resources that do > not result in dialogs being created. In fact, a REFER may be used to > point to resources that are of a different type than the original one > (i.e., not SIP or SIPS). Please see [RFC3515]/5.2 for security > considerations related to this. So what is the normative requirement here. Is it allowed to send a REFER on a SIPS dialog, to an http URI? > If the wrong scheme is received in the GRUU (which would be an error > in the registrar), the UAC SHOULD treat it as if the proper scheme > was used (i.e., it SHOULD replace the scheme with the proper scheme > before using the GRUU). what is the value in having this behavior? I think handling of errors in registrar like this is out of scope. > When a proxy receives a request with a SIP Request-URI, the proxy > MUST NOT forward the request to a SIPS Request-URI. If the target > UAS had registered previously using a SIPS Contact header field, and > the proxy decides to forward the request, it MUST replace that SIPS > scheme with a SIP scheme while leaving the rest of the URI as is, and > use the resulting URI as the Request-URI of the forwarded request. > The proxy MUST use TLS to forward the request to the UAS. when the R-URI is SIP, you MUST use TLS?? > 4.2. Proxy Behavior This section is missing an essential behavior somewhere, that needs to be very clear that when targeting a SIPS URI, you MUST send over TLS. > Using a Redirect Server with TLS instead of using a Proxy has some > limitations that have to be taken into account. Since there no pre- > established connection between the Proxy and the UAS (such as with > [I-D.ietf-sip-outbound]), it is only appropriate for scenarios where > inbound connections are allowed. I don't follow this. You can have redirects and redirect servers with pre-established connections. What use case are you referring to here? From the paragraph below it seems you are assuming that the redirect is at the home proxy, redirecting to the registered UA's Contact. I agree this is not likely to work but its not likely to work without sips either. > When a redirect server receives a request with a SIP Request-URI, the > redirect server MAY redirect with a 3XX response to either a SIP or a > SIPS Contact header field. If the target UAS had registered > previously using a SIPS Contact header field, the redirect server > SHOULD return a SIPS Contact header field if it is in an environment > where TLS is usable (as described in the previous paragraph). If the > target UAS had registered previously using a SIP Contact header > field, the redirect server MUST return a SIP Contact header field in > a 3XX response if it redirects the request. > > When a redirect server receives a request with a SIPS Request-URI, > the redirect server MAY redirect with a 3XX response to either a SIP > or a SIPS Contact header field. If the target UAS had registered > previously using a SIPS Contact header field, the redirect server > SHOULD return a SIPS Contact header field if it is in an environment > where TLS is usable. If the target UAS had registered previously > using a SIP Contact header field, the redirect server MUST return a > SIP Contact header field in a 3XX response if it chooses to redirect; > otherwise it may reject the request with a 418 (SIPS Not Allowed). these two paragraphs are nearly identical. Should merge them or something. Also this section treats only the case of a redirect server that is redirecting to registered contacts. This never really happens. most redirect servers are things like route servers that return PSTN gateway routes. You should handle this case and I think say that a server receiving a SIPS r-uri SHOULD redirect to SIPS. > The UAS or proxy cannot process the request because the SIPS scheme > is not allowed. This response differs from 416 because the UAS or > proxy recognizes the SIPS URI but it is not allowed, and because the > UAC SHOULD NOT retry the request automatically using a SIP URI. why shouldn't it retry? * draft should probably talk about the tel URI, and discuss how to handle it Minor/Nits: > In this model, both the TLS client and the TLS server provide a > certificate in the TLS handshake phase. When no TLS connection is in > place, the UAC would therefore take on the role of the TLS Client and > the UAS would therefore take on the role of the TLS server. Since in > SIP, a UA or a Proxy act both as UAC and UAS depending on if they are > sending or receiving requests, the symmetrical nature of mutual TLS > is very convenient. This paragraph is confusing. The discussion on UAC and UAS is misleading since its only true for UA to UA communications. Also a proxy is not a UAC or UAS; the terms are client and server. > UA a Proxy UA b > > -------REQUEST sips:-------->-------REQUEST sip:---------> > Record-Route: , > > > <------Response sips:-------<-------Response sip:--------- > Record-Route: Record-Route: , > > > Record routing from SIPS to SIP The terms 'Response sips' and 'Response sip' are kind of meaningless since there is no such URI in the response. Suggest you clarify instead where there is TLS and relabel REQUEST to REQUEST-URI. > When [I-D.ietf-sip-outbound] is used, a transport parameter in a > REGISTER message would normally be ignored since the existing > connection is re-used instead. This is true for Contact, not for other fields. > In a Contact header field in a dialog-creating request, it would only > be useful in the cases where Record-Route is not used. However, as > described in this specification, this is extremely unlikely to work > because of the difficulty in establishing the TLS connection between > peers (i.e., they would need to have certificates). too many 'its' and 'this' in this paragraph - needs clarification. > The UAC registers Contacts header fields to either a SIPS or a SIP > AOR. s/contacts/contact -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 23 09:57:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICyPK-0006l4-Hy; Mon, 23 Jul 2007 09:57:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICyPI-0006ia-LU for sip-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 09:57:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICyPI-0006iS-BA for sip@ietf.org; Mon, 23 Jul 2007 09:57:04 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICyPI-0005qS-1N for sip@ietf.org; Mon, 23 Jul 2007 09:57:04 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLM003P8XEZH4@usaga01-in.huawei.com> for sip@ietf.org; Mon, 23 Jul 2007 06:57:00 -0700 (PDT) Received: from jys3105061845kf (dhcp-1368.ietf69.org [130.129.19.104]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLM00MDJXESL6@usaga01-in.huawei.com> for sip@ietf.org; Mon, 23 Jul 2007 06:56:59 -0700 (PDT) Date: Mon, 23 Jul 2007 08:56:53 -0500 From: Peili Xu To: IETF SIP List Message-id: <007b01c7cd31$55e6a920$68138182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfNAgtZ7zk2vSVjTCWshX7QnRaUbAALzuuA X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Sip] comments on draft-rosenberg-sip-ua-loose-route-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jonathan et al, After reviewing the draft and mailing list discussion, I'd like to share my view for your consideration. Assuming we could group the problem statements into 3 categories: a) Conversion for contact binding; b) conversion for routing resolution and c) conversion for services. 1: I'd suggest using P-Called-Party-ID to for category a) problem and loose routing for the other 2. 2: When would proxy apply loose route after conversion for category 2/3 is subject to local policy or Some kind of indication provided by external conversion service. 3: How to define a uri parameter for sub-address purpose is somewhat independent from the draft to me. But it's interesting. I'd suggest specifying it separately and with thorough considerations for how to implement sub-address like services in SIP. Best regards Peili _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 23 10:19:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICyki-0004CX-OE; Mon, 23 Jul 2007 10:19:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICykg-0004CR-NL for sip-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 10:19:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICykg-0004CJ-CO for sip@ietf.org; Mon, 23 Jul 2007 10:19:10 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICykf-0006Im-Sg for sip@ietf.org; Mon, 23 Jul 2007 10:19:10 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6NEID924780; Mon, 23 Jul 2007 14:18:13 GMT 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, 23 Jul 2007 09:18:11 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437115B748E2@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Another comment on the outbound draft Thread-Index: AcfK61gcb9Pe3f9aRDmK77vndCxk+QCSAlsg References: <6FC4416DDE56C44DA0AEE67BC7CA437115AA5DFF@zrc2hxm2.corp.nortel.com> From: "Brian Stucker" To: "Rohan Mahy" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Cullen Jennings , sip@ietf.org, Francois Audet , Gonzalo Camarillo , cboulton@ubiquitysoftware.com Subject: [Sip] RE: Another comment on the outbound draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Rohan Mahy [mailto:rohan@ekabal.com]=20 > Sent: Friday, July 20, 2007 11:31 AM > To: Stucker, Brian (RICH1:AR00) > Cc: Rohan Mahy; Cullen Jennings; sipping@ietf.org; Audet,=20 > Francois (SC100:3055); cboulton@ubiquitysoftware.com;=20 > Jonathan Rosenberg; Gonzalo Camarillo > Subject: Re: Another comment on the outbound draft >=20 >=20 > On Jul 19, 2007, at 10:47 PM, Brian Stucker wrote: >=20 > > Rohan/Cullen, > > > > One other comment on the outbound draft... I think a=20 > statement needs=20 > > to be added to the draft to cover the following situation: > > > > Let's say a UAC is registering from behind a NAT. If the outbound=20 > > proxy does not support outbound (i.e. does not put 'ob' in the Path=20 > > header) then the resulting registration will contain an=20 > address that=20 > > is likely not reachable by the local outbound proxy after the NAT=20 > > binding has expired. The UAC can detect that this may occur=20 > by looking=20 > > for the 'outbound' tag in the supported header of the registration=20 > > response and act accordingly. However, in section 4.2 the=20 > text in the=20 > > third paragraph on page 15 shows that checking the=20 > supported header to=20 > > see if outbound processing occurred is only a MAY instead of a MUST. > > > > I believe that the UAC must do this checking unless they know for a=20 > > fact that their contact address is globally routable (or at least=20 > > reachable by the local outbound proxy at all times), and if not,=20 > > re-register using their server reflexive address in the contact URI=20 > > via STUN or derived through some other means (observation of=20 > > received/rport values in the registration response Via header, etc). >=20 > Hi Brian, >=20 > Originally I was thinking that the UAC might not care. If=20 > the UAC already set its Contact prepared for the possibility=20 > of both outbound and non-outbound cases, it won't need to do=20 > anything differently in its initial REGISTER request. =20 > However, the UAC MUST check if the 'outbound' tag was in the=20 > Require header (see Adam's note on tags) to see if outbound=20 > was applied, so it can add or not add the 'ob' =20 > parameter to the UACs Contact URI. >=20 > thanks, > -rohan >=20 Hi Rohan, Sorry for the delay in replying. There's a blurb in section 4.3 (third paragraph) that seems to throw a possible wrench into that logic...=20 The contact is formed normally in that the UAC uses the IP address of the device (even if the device is behind a NAT). The section on registrations (4.2) does not state anything in particular about the content of the Contact URI other than the parameters that are specific to the outbound draft itself. So, if in general, the expectation (from section 4.3) is that the contact is composed of the IP address of the device (wondering why it shouldn't generally be the contact it registered) and there's nothing stated in 4.2 specifically, it may follow that the UAC implementation doesn't consider the case I am raising and is left without a usable registration. Regards, Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 23 10:21:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICymq-00072R-DB; Mon, 23 Jul 2007 10:21:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICymp-0006zc-02 for sip-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 10:21:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICymo-0006zU-Kh for sip@ietf.org; Mon, 23 Jul 2007 10:21:22 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICymn-0006MK-UN for sip@ietf.org; Mon, 23 Jul 2007 10:21:22 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2007 10:21:21 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusRAKJWpEZAZnme/2dsb2JhbACIX51H X-IronPort-AV: i="4.16,570,1175486400"; d="scan'208"; a="126761195:sNHT42692944" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6NELKCn019183; Mon, 23 Jul 2007 10:21:21 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6NEL26m003776; Mon, 23 Jul 2007 14:21:20 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 10:21:18 -0400 Received: from [10.86.241.164] ([10.86.241.164]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 10:21:18 -0400 Message-ID: <46A4B95D.4030703@cisco.com> Date: Mon, 23 Jul 2007 10:21:17 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: sunqian 32328 Subject: Re: [Sip] comments on draft-camarillo-sip-body-handling-01 References: <46A2DB31.8080903@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 14:21:18.0550 (UTC) FILETIME=[BC5C2F60:01C7CD34] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5169; t=1185200481; x=1186064481; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20comments=20on=20draft-camarillo-sip-body-hand ling-01 |Sender:=20 |To:=20sunqian=2032328=20; bh=nngwKEbYDNikrlkttjnYYguh7BsRaa/Cu7M1TIzXCGQ=; b=C39kT+RzuHGXuLGn5eczjVh6b61dh9hxaciQLCAJJHxa1XwDCVCpPAVKePOSDc+3/rEZ1tE2 EuH5uct5ntwf+7PKTxIhyo1QNp1i8866khVJ3E6+wE9//S6AoKqj7N2e; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: 'IETF SIP List' , Gonzalo Camarillo X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I find it quite plausible that an implementation might support multipart for some methods and not for others. Currently it is difficult/impossible to reflect that distinction in signaling. So far we have punted making changes to indicate such distinctions - thinking that doing so is not worth the trouble. Paul sunqian 32328 wrote: > Hi, > > Could different SIP methods (INVITE, MESSAGE) be given different Levels of Support for Multipart? > > Best Regards, > Qian Sun > > ----- Original Message ----- > From: Paul Kyzivat > Date: Sunday, July 22, 2007 12:21 pm > Subject: Re: [Sip] comments on draft-camarillo-sip-body-handling-01 > >> One of the tasks of the draft is to make support for at least some >> subtypes of multipart (e.g. mixed) mandatory. >> >> I hope this is not a suggestion to make dereferencing of external >> bodies >> mandatory. >> >> If the request is just to include some clarification of the use >> and >> handling of external bodies in this draft then I guess that does >> sound >> useful. >> >> Paul >> >> Eric Burger wrote: >>> Seems like a good idea. However, I would not go so far as to >> mandate> iterative evaluation. I would offer that the UA >> evaluates as needed. >>> >>> On 7/20/07 3:58 AM, "Qian Sun" wrote: >>> >>>> Hi, >>>> I suggest Content Indirection Mechanism defined in rfc4483 >> should also be >>>> considered in this draft. >>>> >>>> It is a little special, an example from rfc4483: >>>> 6.1. Single Content Indirection >>>> >>>> INVITE sip:boromir@example.com SIP/2.0 >>>> Accept: message/external-body application/sdp >>>> Content-Type: message/external-body; >>>> ACCESS-TYPE=URL; >>>> >> URL="http://www.example.net/party/06/2002/announcement";>> >> EXPIRATION="Sat, 20 Jun 2002 12:00:00 GMT"; >>>> size=231 >>>> Content-Length: 105 >>>> >>>> Content-Type: application/sdp >>>> Content-Disposition: session >>>> Content-ID: <4e5562cd1214427d@example.net> >>>> >>>> In addition, what happens to the INVITE request if the >> recipient can not get >>>> the indirect content? >>>> >>>> Nits: a letter "l" is missing in the title. >>>> Internet-Draft Message Body Hand"l"ing in SIP >> May 2007 >>>> Cheers, >>>> Qian >>>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Friday, July 20, 2007 2:30 AM >>>> To: Gonzalo Camarillo >>>> Cc: IETF SIP List >>>> Subject: Re: [Sip] comments on draft-camarillo-sip-body- >> handling-01 >>>> Just one comment in addition to what Gonzalo said: >>>> >>>> Gonzalo Camarillo wrote: >>>> >>>>>> The use case described for multipart/alternative - new SDP >> mechanisms>>>> - seems kind of bogus. We've decided not to pursue >> that. Do we have a >>>>>> REAL use case for this? >>>>> AFAICT, we have decided not to pursue SDPng but we still need a >>>>> mechanism in order to be able to, at some point, migrate to >> new session >>>>> description formats. The current consensus, as I understand >> it, is that >>>>> multipart/alternative should not be used to provide >> alternative SDP >>>>> descriptions, but that it could be used to provide alternative >> session>>> descriptions written in different formats. >>>> The other classic example, because it is just like email, is >> MESSAGE>> with a multipart/alternative containing plain text and html. >>>> Paul >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>> >>> Notice: This email message, together with any attachments, may >> contain information of BEA Systems, Inc., its subsidiaries >> and affiliated entities, that may be confidential, proprietary, >> copyrighted and/or legally privileged, and is intended solely >> for the use of the individual or entity named in this message. If >> you are not the intended recipient, and have received this message >> in error, please immediately return this by email and then delete it. >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 23 10:22:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICyoB-00087t-1g; Mon, 23 Jul 2007 10:22:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICyo7-00087U-Pd for sip-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 10:22:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICyo6-00087I-4D for sip@ietf.org; Mon, 23 Jul 2007 10:22:43 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICyo5-0006Nm-Ey for sip@ietf.org; Mon, 23 Jul 2007 10:22:41 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6NEM2YN015552 for ; Mon, 23 Jul 2007 17:22:37 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 17:22:09 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 17:22:09 +0300 Received: from [10.241.59.79] (daec-linuxvpn05979.americas.nokia.com [10.241.59.79]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6NEM7Et031491 for ; Mon, 23 Jul 2007 17:22:08 +0300 Message-ID: <46A4B98E.1050302@nokia.com> Date: Mon, 23 Jul 2007 17:22:06 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] Re: Model for entity-tags in subnot-etags References: <003601c7c8eb$d99e04b0$7c6c460a@china.huawei.com> <200707190419.l6J4Jpad014623@dragon.ariadne.com> <469F408D.2040704@nokia.com> <200707191411.l6JEBuOc025832@dragon.ariadne.com> <46A07879.5090403@nokia.com> <200707201105.l6KB5RSE020456@dragon.ariadne.com> In-Reply-To: <200707201105.l6KB5RSE020456@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 14:22:09.0784 (UTC) FILETIME=[DAE5DF80:01C7CD34] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Dale, ext sip-bounces@ietf.org wrote: > > Often a subscriber will send the SUBSCRIBE to a URI which is not the > > request-URI of the SUBSCRIBE when it reaches the notifier agent. This > > happens due to normal SIP request routing, but the routing can also > > change with time. > > Correct, but are you saying there might be more than one agent with a > different idea on the entity-tags of entities pertaining to a certain > resource? In other words, that the resource has multiple agents that may > have a different view of the resource state? > > I believe this is disallowed per RFC3265 already. > > I doubt things could work with multiple agents that have a different > view of the resource state. > > But there might be multiple agents with different addresses, from whom > you request the state of the same resource using different SIP URIs. > (Which ultimately might all be destinations reached by sending > requests to the same AOR.) > > I don't think it interferes with the subnot mechanism, but my point is > that a resource might *not* have a single, specific SIP URI, either as > the request-URI when the SUBSCRIBE reaches the agent(s) which can > deliver its state, or as the address to which UAs subscribe. That's fine. I think aliases work as long as the relationship is clear. A single resource can have multiple URIs pointing to it, and each resource will only ever have a single agent responsible for it. > All you need to make subnot work is that every UA agrees on which > subscriptions are "for the same resource", and that all notifiers for > "the same resource" generate the same etags for the same state, and > different etags for different state. Right, that would need to be spelled out in section 5.1., I think. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 23 10:27:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICysS-0002ut-Vu; Mon, 23 Jul 2007 10:27:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICysS-0002un-7k for sip-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 10:27:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICysR-0002ua-U4 for sip@ietf.org; Mon, 23 Jul 2007 10:27:11 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICysR-0007pm-Cr for sip@ietf.org; Mon, 23 Jul 2007 10:27:11 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l6NEPQn12895 for ; Mon, 23 Jul 2007 14:25:27 GMT 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, 23 Jul 2007 09:26:55 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437115B74937@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question about keep-alives in Outbound draft Thread-Index: AcfKiYBPu3mbnHPoSXu2cJcDDdqPvACq+/Kw From: "Brian Stucker" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [Sip] FW: Question about keep-alives in Outbound draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sorry for the clutter...=20 Posting to SIP list (stupid auto-complete feature hosed me). Regards, Brian -----Original Message----- From: Stucker, Brian (RICH1:AR00)=20 Sent: Thursday, July 19, 2007 11:51 PM To: 'Cullen Jennings'; 'Rohan Mahy' Cc: sipping@ietf.org; Audet, Francois (SC100:3055) Subject: Question about keep-alives in Outbound draft Cullen/Rohan, I have a question about keep-alive behavior in the -10 version of the outbound draft. How far are keep-alives propagated along the flow created at registration? The text seems a bit hazy on how far it is expected for a keep-alive to be propagated along the flow. Section 8 has text in the last paragraph on page 25 that seems to imply that STUN keep-alives go no further than the edge proxy immediately adjacent to the client device. Section 4.4.3 seems to also limit generation of STUN keep-alives to the User-Agent only. Likewise, section 4.4.1 and 5.4 seem to limit the TCP CRLF response to the first edge-proxy as well. Inclusion of the keep-stun or keep-crlf parameters for a Path URI inserted by an edge proxy or registrar outside of the one in the outbound-proxy-set seems moot as earlier edge-proxies that don't support these mechanisms would ostensibly drop the keep-alives. Further, you only show a NAT/FW between the first edge-proxy and the User-Agent in the figure for section 3.4. However, the spec never really says very clearly what should occur at the edge-proxy: should it check for freshness of the next-hop towards the registrar or not, based upon what it observed in the Path header coming back in the registration response? Is there a reason that edge-proxies are not expected to regenerate/relay the appropriate keep-alive message to the next entry on the Path vector? Not doing so means that some other mechanism must be employed to keep bindings/pinholes open between the various edge-proxies and the registrar proxy. For instance, in IMS you can have a P-CSCF in the visited network talking to an IBCF in the visited network that is connected to an IBCF in the home network that finally terminates at the S-CSCF in the home network of the user that is registering. A NAT/FW is likely to exist between the UA and the visited P-CSCF as well as between the IBCF in the visited network and the IBCF in the home network. Another possible example (I believe) would be in the case of p2psip where you may have multiple hops between the client and the node acting as a registrar for the DHT algorithm. Wouldn't you want to keep the entire path to the node storing your contact information in the DHT alive or is there some other property of the DHT algorithm that ensures that this is always the case even though outbound only keeps the last hop fresh? Regards, Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 23 10:27:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICysY-00037L-O3; Mon, 23 Jul 2007 10:27:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICysX-000334-EF for sip-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 10:27:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICysW-0002z2-JD for sip@ietf.org; Mon, 23 Jul 2007 10:27:16 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICysV-0006UK-Jj for sip@ietf.org; Mon, 23 Jul 2007 10:27:15 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6NERCm18360 for ; Mon, 23 Jul 2007 14:27:13 GMT 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, 23 Jul 2007 09:27:10 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437115B7493B@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Another comment on the outbound draft Thread-Index: AcfKiYBPu3mbnHPoSXu2cJcDDdqPvAABXpgwAKmjdoA= From: "Brian Stucker" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [Sip] FW: Another comment on the outbound draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sorry for the clutter...=20 Posting to SIP list (stupid auto-complete feature hosed me). Regards, Brian -----Original Message----- From: Stucker, Brian (RICH1:AR00)=20 Sent: Friday, July 20, 2007 12:47 AM To: 'Cullen Jennings'; 'Rohan Mahy' Cc: 'sipping@ietf.org'; Audet, Francois (SC100:3055); 'cboulton@ubiquitysoftware.com'; Jonathan Rosenberg; Gonzalo Camarillo Subject: Another comment on the outbound draft Rohan/Cullen, One other comment on the outbound draft... I think a statement needs to be added to the draft to cover the following situation: Let's say a UAC is registering from behind a NAT. If the outbound proxy does not support outbound (i.e. does not put 'ob' in the Path header) then the resulting registration will contain an address that is likely not reachable by the local outbound proxy after the NAT binding has expired. The UAC can detect that this may occur by looking for the 'outbound' tag in the supported header of the registration response and act accordingly. However, in section 4.2 the text in the third paragraph on page 15 shows that checking the supported header to see if outbound processing occurred is only a MAY instead of a MUST. I believe that the UAC must do this checking unless they know for a fact that their contact address is globally routable (or at least reachable by the local outbound proxy at all times), and if not, re-register using their server reflexive address in the contact URI via STUN or derived through some other means (observation of received/rport values in the registration response Via header, etc). Otherwise, the client may have successfully registered an unroutable address without realizing it thinking that the connection to the outbound proxy obviated the need to specify a globally routable address in the contact URI. The BCP for NAT traversal only points off to outbound (although the citation is very stale in the draft, along with the even more stale reference to ANAT as a draft, although it has a more recent ICE reference) and does not discuss this failure case either. In fact, it directly washes it's hands of it:=20 [outbound] exonerates the need to manipulate contact header URI's to represent a globally routable address as perceived on the public side of a NAT. Regards, Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 23 11:28:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICzpm-0000q8-I1; Mon, 23 Jul 2007 11:28:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ICzpl-0000pp-Vf for sip-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 11:28:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICzpl-0000pY-Lc for sip@ietf.org; Mon, 23 Jul 2007 11:28:29 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICzpk-0000vg-EN for sip@ietf.org; Mon, 23 Jul 2007 11:28:29 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 23 Jul 2007 08:28:28 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGdlpEarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,570,1175497200"; d="scan'208"; a="506011681:sNHT29494196" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6NFSRPG016532; Mon, 23 Jul 2007 08:28:27 -0700 Received: from [130.129.101.253] (sjc-vpn2-1088.cisco.com [10.21.116.64]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6NFSLA2012387; Mon, 23 Jul 2007 15:28:27 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6A4080A3-94B9-453D-99B5-971635CB669A@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Mon, 23 Jul 2007 09:38:34 -0500 To: SIP X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=156; t=1185204507; x=1186068507; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20419=20status=20code |Sender:=20; bh=+5fK/f9mr+rnQErVyvxexTVel50ip9MNxMGARHSlpPs=; b=OcePCHKZ4ZEU2DjDP28vNLn/U26mpGVEw4X8lGz+w+aGLYSrbbXKwtIDbUadVzcrjlsqPz33 Zn2k7cKuopgw9lEqumM0EW1q5yGucnUFbjwFMukU07ZrqBPyQktuCGq2; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Francois Audet Subject: [Sip] 419 status code X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Like to point out there are some experimental implications that are using the 419 status code for spam stuff and we might no want to use that one. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 23 15:45:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID3qQ-0005F3-Hn; Mon, 23 Jul 2007 15:45:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ID3qO-00056x-Il for sip-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 15:45:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID3qO-00056c-7m for sip@ietf.org; Mon, 23 Jul 2007 15:45:24 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID3qM-0001Ga-RY for sip@ietf.org; Mon, 23 Jul 2007 15:45:24 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6NJj9wC018493; Mon, 23 Jul 2007 14:45:09 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 14:45:11 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 21:45:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] comments on draft-camarillo-sip-body-handling-01 Date: Mon, 23 Jul 2007 21:45:06 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001473D77@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on draft-camarillo-sip-body-handling-01 Thread-Index: AcfNGTLoEbatvksER8aP5cOEqbKGgwARfoEQ References: <46A2DB31.8080903@cisco.com> From: "DRAGE, Keith \(Keith\)" To: "sunqian 32328" , "Paul Kyzivat" X-OriginalArrivalTime: 23 Jul 2007 19:45:06.0584 (UTC) FILETIME=[F85EE980:01C7CD61] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: IETF SIP List , Gonzalo Camarillo X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org They could, but I suspect we would end up in a discussion with the APPS area of why we are trying to.=20 Either we implement MIME or we don't.=20 But to continue the discussion - if you want to do this, then you are going to have to motivate it. I don't see us taking a hum per method and arbitrarily going one way on one method and another way on another. And I don't see the WG being motivated by prior implementation either. I believe we are at the point where we need to make a clear statement on what SIP needs going forwards, not a kludge based on what some existing implementations require to validate their conformance to the new requirements. Regards Keith =20 > -----Original Message----- > From: sunqian 32328 [mailto:sunqian@huawei.com]=20 > Sent: Monday, July 23, 2007 12:03 PM > To: Paul Kyzivat > Cc: 'IETF SIP List'; Gonzalo Camarillo > Subject: Re: [Sip] comments on draft-camarillo-sip-body-handling-01 >=20 > Hi, >=20 > Could different SIP methods (INVITE, MESSAGE) be given=20 > different Levels of Support for Multipart? >=20 > Best Regards, > Qian Sun >=20 > ----- Original Message ----- > From: Paul Kyzivat > Date: Sunday, July 22, 2007 12:21 pm > Subject: Re: [Sip] comments on draft-camarillo-sip-body-handling-01 >=20 > > One of the tasks of the draft is to make support for at least some=20 > > subtypes of multipart (e.g. mixed) mandatory. > >=20 > > I hope this is not a suggestion to make dereferencing of external=20 > > bodies mandatory. > >=20 > > If the request is just to include some clarification of the use and=20 > > handling of external bodies in this draft then I guess that=20 > does sound=20 > > useful. > >=20 > > Paul > >=20 > > Eric Burger wrote: > > > Seems like a good idea. However, I would not go so far as to > > mandate> iterative evaluation. I would offer that the UA > > evaluates as needed. > > >=20 > > >=20 > > > On 7/20/07 3:58 AM, "Qian Sun" wrote: > > >=20 > > >> Hi, > > >> I suggest Content Indirection Mechanism defined in rfc4483 > > should also be > > >> considered in this draft. > > >> > > >> It is a little special, an example from rfc4483: > > >> 6.1. Single Content Indirection > > >> > > >> INVITE sip:boromir@example.com SIP/2.0 > > >> Accept: message/external-body application/sdp > > >> Content-Type: message/external-body; > > >> ACCESS-TYPE=3DURL; > > >> =20 > > URL=3D"http://www.example.net/party/06/2002/announcement";>> = > > EXPIRATION=3D"Sat, 20 Jun 2002 12:00:00 GMT"; > > >> size=3D231 > > >> Content-Length: 105 > > >> > > >> Content-Type: application/sdp > > >> Content-Disposition: session > > >> Content-ID: <4e5562cd1214427d@example.net> > > >> > > >> In addition, what happens to the INVITE request if the > > recipient can not get > > >> the indirect content? > > >> > > >> Nits: a letter "l" is missing in the title. > > >> Internet-Draft Message Body Hand"l"ing in SIP =20 > > May 2007 > > >> > > >> Cheers, > > >> Qian > > >> > > >> -----Original Message----- > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >> Sent: Friday, July 20, 2007 2:30 AM > > >> To: Gonzalo Camarillo > > >> Cc: IETF SIP List > > >> Subject: Re: [Sip] comments on draft-camarillo-sip-body- > > handling-01 > > >> > > >> Just one comment in addition to what Gonzalo said: > > >> > > >> Gonzalo Camarillo wrote: > > >> > > >>>> The use case described for multipart/alternative - new SDP > > mechanisms>>>> - seems kind of bogus. We've decided not to pursue > > that. Do we have a > > >>>> REAL use case for this? > > >>> AFAICT, we have decided not to pursue SDPng but we still need a=20 > > >>> mechanism in order to be able to, at some point, migrate to > > new session > > >>> description formats. The current consensus, as I understand > > it, is that > > >>> multipart/alternative should not be used to provide > > alternative SDP > > >>> descriptions, but that it could be used to provide alternative > > session>>> descriptions written in different formats. > > >> The other classic example, because it is just like email, is > > MESSAGE>> with a multipart/alternative containing plain=20 > text and html. > > >> > > >> Paul > > >> > > >> > > >> _______________________________________________ > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >> This list is for NEW development of the core SIP Protocol Use=20 > > >> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > >> sipping@ietf.org for new developments on the application of sip > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >> This list is for NEW development of the core SIP Protocol Use=20 > > >> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > >> sipping@ietf.org for new developments on the application of sip > > >=20 > > >=20 > > > Notice: This email message, together with any attachments, may > > contain information of BEA Systems, Inc., its subsidiaries and =20 > > affiliated entities, that may be confidential, proprietary,=20 > > copyrighted and/or legally privileged, and is intended=20 > solely for the=20 > > use of the individual or entity named in this message. If=20 > you are not=20 > > the intended recipient, and have received this message in error,=20 > > please immediately return this by email and then delete it. > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 23 15:56:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID40q-00012w-LA; Mon, 23 Jul 2007 15:56:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ID40n-0000uS-9x for sip-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 15:56:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID40m-0000t9-2B; Mon, 23 Jul 2007 15:56:08 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID40l-0000LV-JA; Mon, 23 Jul 2007 15:56:07 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2007 15:56:07 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACalpEZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,572,1175486400"; d="scan'208"; a="126801974:sNHT29190148" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6NJu6Zx023742; Mon, 23 Jul 2007 15:56:06 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6NJtvWs017987; Mon, 23 Jul 2007 19:56:06 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); Mon, 23 Jul 2007 15:55:41 -0400 Received: from [10.86.242.144] ([10.86.242.144]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 15:55:41 -0400 Message-ID: <46A507C5.5060206@cisco.com> Date: Mon, 23 Jul 2007 15:55:49 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: IETF SIP List , IETF Sipping List , IETF MMUSIC WG , Behave WG , P2PSIP WG , rai@ietf.org, "'avt@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 19:55:41.0404 (UTC) FILETIME=[72C0C1C0:01C7CD63] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1840; t=1185220566; x=1186084566; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20ICE=20tutorial=20in=20Chicago=20is=20CONFIRMED=20[DO=20NOT=20 REPLY]=20-=20lunch=20logistics=0A=20below |Sender:=20 |To:=20IETF=20SIP=20List=20, =20IETF=20Sipping=20List=20, =0A=20=20=20=20=20=20=20=20IETF=20MMUSIC=20WG=20, =20Behave=20WG=20, =0A=20=20=20=20=20=20=20=20P2PSI P=20WG=20, =20rai@ietf.org, =0A=20=20=20=20=20=20=20=20=22' avt@ietf.org'=22=20; bh=KpxqDxUhtprUSwrX98Ct3c1X0mBsvpY4gzyMN2aH5Go=; b=Ncyw7y256jwE7lC5Q5QuZfDCdjVn1oabrjGvlOL+VyhF0ZalmP15rKSMhRmaAGHHsSvG2PuK zZyuKd5iE8415bdWZIZuxeIGqTOje15E+zSKCePNlEj5RGkZbwjUABDm; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [Sip] ICE tutorial in Chicago is CONFIRMED [DO NOT REPLY] - lunch logistics below X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-17.txt) Slides: http://www.jdrosen.net/papers/ice-ietf-tutorial2.ppt WHEN: Tuesday, July 24, 2007, 1145-1245 lunch will be available to those who RSVPd previously sandwiches, chips, salad and drinks $20/head - please pay Jonathan R. after the tutorial WHERE: Red Lacquar MP3 streaming hopefully available at: http://videolab.uoregon.edu/events/ietf/ietf694.m3u WHO: Anyone that would like to learn more about ICE. WHY: ICE, developed by the mmusic working group, has been defined as the IETF tool for NAT traversal for SIP-based media. It is also seeing increased usage for traversal for other kinds of application traffic - anything worrying about any-to-any communications. In this tutorial, we will overview the background of the problem, consider the requirements driving ICE, and provide an overview of how ICE works. An understanding of SIP is not required. The tutorial will be based on the pending -17 version. RSVP: Anyone may attend without RSVP, but lunch may not be there for you if you have not RSVPd previously. I've ordered a few extra !DO NOT REPLY TO THIS NOTE! -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 23 16:51:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID4sY-000807-RH; Mon, 23 Jul 2007 16:51:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ID4sW-0007xL-HX for sip-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 16:51:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID4sW-0007xD-5B; Mon, 23 Jul 2007 16:51:40 -0400 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID4sV-00023m-DI; Mon, 23 Jul 2007 16:51:40 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id EC8031811206; Mon, 23 Jul 2007 22:51:40 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Jul 2007 22:37:31 +0200 To: "Henry Sinnreich" , "David Barrett" ,"Jan Janak" , "Juha Heinanen" From: Jiri Kuthan Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe. com> References: <20070719145334.2EA8B1810C50@mail.iptel.org> <20070719180614.85AB218115BC@mail.iptel.org> <20070721144803.41B4F1810C56@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20070723205140.EC8031811206@mail.iptel.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sip@ietf.org, mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 19:10 21/07/2007, Henry Sinnreich wrote: >I fully agree with Jiri that this is an IETF problem and not an ICE >problem. >ICE-17 is a great document, no doubt about it. > >What happens however of someone finds an innovative approach that may >work better? Will it be rejected because it will not be RFC standards >compliant? I don't think so, IETF is having a history of working on competing standards, jabber and simple being a prominent and recent example thereof. I think that's actually with current IETF's size and dynamics a fairly good strategy to eliminate single points of failure. -jiri >What could an innovator tell customers about a solution that works >better but is not IETF ICE RFC standards compliant? > >Henry > >-----Original Message----- >From: Jiri Kuthan [mailto:jiri@iptel.org] >Sent: Saturday, July 21, 2007 9:48 AM >To: David Barrett; 'Jan Janak'; 'Juha Heinanen' >Cc: sip@ietf.org; mmusic@ietf.org >Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE >deploymentdatabefore LC for RFC > >At 20:05 19/07/2007, David Barrett wrote: >>> -----Original Message----- >>> From: Jiri Kuthan [mailto:jiri@iptel.org] >>> Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment >databefore >>> LC for RFC >>> >>> So I think that the right course of action is that folks doubting ICE >>> reliability >>> make their case (by that I mean specific arguments rather than >emotional >>> debates >>> about red-colored nails and other hardware). >> >>Er, my "specific argument" is "until it's been proven to work, it >hasn't >>been proven to work". It's tautological, but no less true for it. >> >>Indeed, if you're *not* doubting ICE, why aren't you? > >Hi David, > >I'm not entirely sure what is the step you are suggesting? > >I think ICE is architecturally right answer to the right problem. >Notwithstanding that, there are certainly some things I prefer >differently (e.g., the infamous debate about proactive hole punching) >or may turn out to be bugs. I think though that the key problem at >this point is of institutional nature. In the IETF language, "hasn't >been proven to work" is adequate to "lacking running code" and this >appears to be a phenomen which is indeed occuring in the IETF and >is not unique to ICE. > >The question is how to get this fixed? > >Some other standardization bodies enjoying the amount of contributions >and complexity as the IETF is enjoying now (S in SIP does not really >stand for Simple), proceed with 'after-fact filters', in that they >produce the initial specs faster and later produce 'profiles' which >separate what has proved and what less. Plus -bis versions are produced >for whatever appears worth puttting effort in it (i.e., for which there >is running code and field evidence of improvement need).This could be >an approach which may be more feasible in today's IETF's dimension than > >trying to get back to historical roots. > >-jiri > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 23 17:02:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID52W-0001vQ-EQ; Mon, 23 Jul 2007 17:02:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ID52U-0001vG-Kj for sip-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 17:01:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID52T-0001v7-TS for sip@ietf.org; Mon, 23 Jul 2007 17:01:57 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID52T-0003ZS-JQ for sip@ietf.org; Mon, 23 Jul 2007 17:01:57 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc11) with ESMTP id <20070723210156m110051utge>; Mon, 23 Jul 2007 21:01:56 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6NL1t8t001879 for ; Mon, 23 Jul 2007 17:01:55 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6NL1tLu001875; Mon, 23 Jul 2007 17:01:55 -0400 Date: Mon, 23 Jul 2007 17:01:55 -0400 Message-Id: <200707232101.l6NL1tLu001875@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <46A4B98E.1050302@nokia.com> (aki.niemi@nokia.com) Subject: Re: [Sip] Re: Model for entity-tags in subnot-etags References: <003601c7c8eb$d99e04b0$7c6c460a@china.huawei.com> <200707190419.l6J4Jpad014623@dragon.ariadne.com> <469F408D.2040704@nokia.com> <200707191411.l6JEBuOc025832@dragon.ariadne.com> <46A07879.5090403@nokia.com> <200707201105.l6KB5RSE020456@dragon.ariadne.com> <46A4B98E.1050302@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Aki Niemi > All you need to make subnot work is that every UA agrees on which > subscriptions are "for the same resource", and that all notifiers for > "the same resource" generate the same etags for the same state, and > different etags for different state. Right, that would need to be spelled out in section 5.1., I think. I probably didn't make myself clear, in that this is just a matter of wording and terminology. But if the RFC isn't worded correctly, people might create non-workable implementations. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 23 18:22:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID6Ho-0008AA-Od; Mon, 23 Jul 2007 18:21:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1ID6Hn-0008A0-MQ for sip-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 18:21:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID6Hn-00089m-9p for sip@ietf.org; Mon, 23 Jul 2007 18:21:51 -0400 Received: from submit01.sysedata.no ([195.159.29.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID6Hm-0004DT-Oa for sip@ietf.org; Mon, 23 Jul 2007 18:21:51 -0400 Received: from [84.215.127.238] (helo=[10.0.0.4]) by submit01.sysedata.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.62) (envelope-from ) id 1ID6Hf-0003Ud-GW; Tue, 24 Jul 2007 00:21:43 +0200 Message-ID: <46A52ACF.3030402@db.org> Date: Tue, 24 Jul 2007 00:25:19 +0200 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.12 (X11/20070606) MIME-Version: 1.0 To: Rohan Mahy , Cullen Jennings , SIP IETF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Subject: [Sip] Comments on draft-ietf-sip-outbound-10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Comments on draft-ietf-sip-outbound-10 by Alfred E. Heggestad 23. July 2007 > 3.2. Single Registrar and UA > > REGISTER sip:example.com;keep-crlf SIP/2.0 > Via: SIP/2.0/TCP 192.0.2.1;branch=z9hG4bK-bad0ce-11-1036 > Max-Forwards: 70 > From: Bob ;tag=d879h76 > To: Bob > Call-ID: 8921348ju72je840.204 > CSeq: 1 REGISTER > Supported: path > Contact: ; reg-id=1; > ;+sip.instance="" > Content-Length: 0 I find this example SIP message a bit strange. If the message is sent over TCP, shouldn't the URI in the Contact header contain ";transport=tcp" ? Also, is the IP address in the Via header supposed to be a private IP address (192.168.x.y) or a public IP address? > 3.5.3. STUN Keepalive Technique > > This technique can only be used for transports, such as UDP, that are > not connection oriented. Suggest rewriting this sentence: "This approach MUST only be used with connection-less transports such as UDP." > 4.4.3. Keepalive with STUN > > This approach MUST only be used with transports, such as UDP, that > are not connection oriented. same as above > 12.2. SIP/SIPS URI Parameters > > Parameter Name Predefined Values Reference > ____________________________________________ > keep-crlf No [RFC AAAA] > keep-stun No [RFC AAAA] suggest to merge these two parameters to "keepalive" > 12.2. SIP/SIPS URI Parameters > > Parameter Name Predefined Values Reference > ____________________________________________ > timed-keepalive No [RFC AAAA] > ^^^^^^^^^^^^^^^ This URI parameter is referred to as 'timed-keepalives' (with the trailing 's') a total of 4 locations in the document. They should be updated to read "timed-keepalive" apart from these comments, the document is well structured and easy to read. /alfred _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 00:23:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDBvz-0006xn-H2; Tue, 24 Jul 2007 00:23:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDBvy-0006xd-Li for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 00:23:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDBvx-0006xT-QM for sip@ietf.org; Tue, 24 Jul 2007 00:23:41 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDBvw-0003oa-Fp for sip@ietf.org; Tue, 24 Jul 2007 00:23:41 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6O4NV1Y023728; Mon, 23 Jul 2007 23:23:31 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 23:23:33 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 06:23:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Jul 2007 06:23:26 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001473D89@DEEXC1U01.de.lucent.com> In-Reply-To: <46966F52.9040004@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Correction: WGLC for draft-ietf-sip-outbound Thread-Index: AcfEr8bwDjeX+w6IT/G/gD+4aUr5kwI+i2JA References: <46928F5F.3080502@softarmor.com> <46966F52.9040004@softarmor.com> From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 24 Jul 2007 04:23:28.0148 (UTC) FILETIME=[6258F540:01C7CDAA] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Cullen Jennings , Rohan Mahy Subject: [Sip] RE: Correction: WGLC for draft-ietf-sip-outbound X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A reminder of the ongoing WGLC on the above document This WGLC period runs through IETF and hopefully close August 6, 2007. That gives you about a week after the end of IETF - please schedule some = time for doing this. Regards Keith =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Thursday, July 12, 2007 7:14 PM > To: Dean Willis > Cc: sip@ietf.org; Cullen Jennings; DRAGE, Keith (Keith) > Subject: Correction: WGLC for draft-ietf-sip-outbound >=20 > Dean Willis wrote: > > I'd like to start a long working group last call for: > > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-09.txt > > >=20 > My error. This should have referred to=20 > draft-ietf-sip-outbound-10, not -09. It was busy working its=20 > way through the posting system and I grabbed a pointer to the=20 > wrong one. >=20 > Sorry about that, folks. >=20 > -- > Dean >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 00:32:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDC4a-00026d-4c; Tue, 24 Jul 2007 00:32:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDC4Y-00026W-L5 for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 00:32:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDC4Y-00026O-B9 for sip@ietf.org; Tue, 24 Jul 2007 00:32:34 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDC4X-00040H-BV for sip@ietf.org; Tue, 24 Jul 2007 00:32:34 -0400 Received: by py-out-1112.google.com with SMTP id f31so5756437pyh for ; Mon, 23 Jul 2007 21:32:33 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=VDz63gaTA3WPifV/qtGJHcJi9rHT8vZyP8r8nq5Uy5O8qSEmOFVM4R405j0bJdvLKoQRllqkObzlXlIIg/zMf5aFrHn8WuEcy7JzyHwkdQAOsv4sIcYcsvm1YPcS+39vrHymAnxKEd7qxm+JzFuH93vUSfiuvb++IwltLCHKwic= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=hZ9S7lyvfbB7yUKImjmiWS8euuBvPGLWNIomAJLmJobVvNVb1BHnjBKYQD40C2gDO1ncsuKuYrLB6dc6E3todLsCqOQZ+Tc+hc0lLjwZ3fBXWgwwEIEx+1VGpMYdHB1wDXXyTq7MdIGsuoWPUiF/r5MWyDDd8IpbmwESEccPYhE= Received: by 10.35.121.12 with SMTP id y12mr7181664pym.1185251552641; Mon, 23 Jul 2007 21:32:32 -0700 (PDT) Received: by 10.35.52.9 with HTTP; Mon, 23 Jul 2007 21:32:32 -0700 (PDT) Message-ID: <21964a950707232132g462b6bb0if3f8a4296bf89d88@mail.gmail.com> Date: Mon, 23 Jul 2007 21:32:32 -0700 From: "Nasir Khan" To: "Robert Sparks" Subject: Re: [Sip] Changes to the INVITE transaction to address bug 769 In-Reply-To: <54DA9005-F247-467B-BDE1-8E3FF2FBB2C5@estacado.net> MIME-Version: 1.0 References: <21964a950707162342h65f14291i605eb2c5da7fda33@mail.gmail.com> <54DA9005-F247-467B-BDE1-8E3FF2FBB2C5@estacado.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1835008945==" Errors-To: sip-bounces@ietf.org --===============1835008945== Content-Type: multipart/alternative; boundary="----=_Part_98713_26869202.1185251552584" ------=_Part_98713_26869202.1185251552584 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Should there be one more change to 3261 for invfix? Section 14.1 para 6 point # 2 should include the Accepted state? "If there is an ongoing INVITE server transaction, the TU MUST wait until the transaction reaches the confirmed, *accepted* or terminated state before initiating the new INVITE" Thanks Nasir Khan BEA Systems Inc. On 7/17/07, Robert Sparks wrote: > > > On Jul 17, 2007, at 1:42 AM, Nasir Khan wrote: > > Hi Robert, > > I have 3 comments / suggestions w.r.t this ID. > > Comment-1 > ---------------- > Should there be any change with respect to receiving CANCEL in Accepted > state? Hitherto the UAC was getting a 481/CANCEL in such cases. Now we will > get 200/CANCEL with no effect on IST. > The reason for this question is backwards compatibility, however I can > myself argue both ways on this one. What do you think? > > > I don't see any issue here. The UAC already has to be prepared for either > response. > > > > > Comment-2 > ----------------- > In section 6.7 of the ID about the Timer-L you say - "and the amount of > time this (or any downstream) UAS core might be retransmitting the 2xx while > waiting for an ACK. " > > How does 2xx retransmission timer affect the choice of Timer L? > > > > Comment-3 > ----------------- > Shouldnt the Timer L be set to T4 which represents the amount of time the > network will take to clear messages between client and server transactions? > Since 2xx is sent reliably anyway, IMHO we do not need to link Timer L to > Timer B. > > > For both of these comments - Timer L is keeping the transaction in place > while the TU on top of this server transaction finishes its > job of retrasmitting 200s until it gets an ACK. It's not just clearing > messages that are already in the network. Remember that those > 200s might get lost, and timers on the UAC's side will cause the INVITE > request to be retransmitted. This Timer makes sure the > server transaction is still there to receive that retransmitted INVITE. > Does this clear up the questions you had? > > > > Thanks > > Nasir Khan > BEA Systems Inc. > > > On 6/27/07, Robert Sparks wrote: > > > > Everyone - > > > > I've put together a proposal for addressing the spec bug captured at > > http://bugs.sipit.net/show_bug.cgi?id=769 > > > > Please read through > > http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-00.txt > > and comment. > > > > RjS > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > > -- > Discuss SIP Servlets at http://groups.google.com/group/sipservlets/ > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > -- Discuss SIP Servlets at http://groups.google.com/group/sipservlets/ ------=_Part_98713_26869202.1185251552584 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Should there be one more change to 3261 for invfix?

        Section 14.1 para 6 point # 2 should include the Accepted state?

        "If there is an ongoing INVITE server transaction, the TU MUST wait until the transaction reaches the confirmed, *accepted* or terminated state before initiating the new INVITE"

        Thanks

        Nasir Khan

        BEA Systems Inc.

        On 7/17/07, Robert Sparks <rjsparks@estacado.net> wrote:

        On Jul 17, 2007, at 1:42 AM, Nasir Khan wrote:

        Hi Robert,

        I have 3 comments / suggestions w.r.t this ID.

        Comment-1
        ----------------
        Should there be any change with respect to receiving CANCEL in Accepted state? Hitherto the UAC was getting a 481/CANCEL in such cases. Now we will get 200/CANCEL with no effect on IST.
        The reason for this question is backwards compatibility, however I can myself argue both ways on this one. What do you think?

        I don't see any issue here. The UAC already has to be prepared for either response. 
         


        Comment-2
        -----------------
        In section 6.7 of the ID about the Timer-L you say - "and the amount of time this (or any downstream) UAS core might be retransmitting the 2xx while waiting for an ACK. "

        How does 2xx retransmission timer affect the choice of Timer L? 


        Comment-3
        -----------------
        Shouldnt the Timer L be set to T4 which represents the amount of time the network will take to clear messages between client and server transactions?
        Since 2xx is sent reliably anyway, IMHO we do not need to link Timer L to Timer B.

        For both of these comments - Timer L is keeping the transaction in place while the TU on top of this server transaction finishes its
        job of retrasmitting 200s until it gets an ACK. It's not just clearing messages that are already in the network. Remember that those
        200s might get lost, and timers on the UAC's side will cause the INVITE request to be retransmitted. This Timer makes sure the
        server transaction is still there to receive that retransmitted INVITE.  Does this clear up the questions you had?



        Thanks

        Nasir Khan
        BEA Systems Inc.


        On 6/27/07, Robert Sparks <rjsparks@estacado.net> wrote:
        Everyone -

        I've put together a proposal for addressing the spec bug captured at
        http://bugs.sipit.net/show_bug.cgi?id=769

        Please read through
        http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-00.txt
        and comment.

        RjS


        _______________________________________________
        Sip mailing list   https://www1.ietf.org/mailman/listinfo/sip
        This list is for NEW development of the core SIP Protocol
        Use sip-implementors@cs.columbia.edu for questions on current sip
        Use sipping@ietf.org for new developments on the application of sip



        --
        Discuss SIP Servlets at http://groups.google.com/group/sipservlets/
        _______________________________________________
        This list is for NEW development of the core SIP Protocol
        Use sip-implementors@cs.columbia.edu for questions on current sip
        Use sipping@ietf.org for new developments on the application of sip




        --
        Discuss SIP Servlets at http://groups.google.com/group/sipservlets/ ------=_Part_98713_26869202.1185251552584-- --===============1835008945== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1835008945==-- From sip-bounces@ietf.org Tue Jul 24 00:45:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDCGr-0003pI-K0; Tue, 24 Jul 2007 00:45:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDCGp-0003p3-C9 for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 00:45:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDCGp-0003ov-2C for sip@ietf.org; Tue, 24 Jul 2007 00:45:15 -0400 Received: from an-out-0708.google.com ([209.85.132.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDCGn-0004Ci-Sg for sip@ietf.org; Tue, 24 Jul 2007 00:45:15 -0400 Received: by an-out-0708.google.com with SMTP id c17so400643anc for ; Mon, 23 Jul 2007 21:45:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=CQNphwOM8ofPmLSKyBmTmtaG/pRHmxuq5jHtMcFhqmB56Ct5Et4/CImJnVXUutF8/rLM4wPhvY1gcuLl7ByIfI5WrStahYnT83OhthSu5BVT9C9HAU3LXbKadHxPSGuVK2rnpmjEM+jaFxdmeDqGKFwr225X8sbIv4irieFP7dM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=t5MGgRHHVx4d1ayrTQ9aaxGJlQYolWqqGSHF5qvKpz9oT1nCZDfyEM2MgtbZggOhsaASutdnyH7zyLdIyuGO78sFXuXoR9Di+tJNl6RHlet+Mo9BH+byNxQUoMiS/5k5KYuaY8YAzXWk0yygRicbs6r0AhnascNHZo9FpTzey/w= Received: by 10.100.143.11 with SMTP id q11mr2080877and.1185252313317; Mon, 23 Jul 2007 21:45:13 -0700 (PDT) Received: by 10.100.189.2 with HTTP; Mon, 23 Jul 2007 21:45:13 -0700 (PDT) Message-ID: <458913680707232145w5cd54ee6n43c15a0bcc07f774@mail.gmail.com> Date: Mon, 23 Jul 2007 23:45:13 -0500 From: "Xavier Marjou" To: "Eric Burger" Subject: Re: [Sip] INFO and Content Negotiation In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: de4e503c873a2baa X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: IETF SIP , Christer Holmberg X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Eric, I also do not understand why it would not be possible to indicate in the transaction of the initial INVITE what type of INFO is exactly required/supported (negotiation and subscription stage) and to send the event information with an INFO during the dialog (notification stage). Concerning draft-burger-sip-info-00, I think the draft is not fair with this poor INFO message. Indeed, the INFO message helps a lot to quickly implement/have some features (e.g. full intra requests of mmusic-xml-media-control, DTMF, MSCML, ...) while waiting for implementations of the IETF standardized solutions (e.g. rtcp-feedback, kpml, media-control, ...). Though I agree there are some cons with features based on INFOs messages, there are also some pros with this approach, (ie: same as for everything ;-) but I won't go over such details. Thus, I think that even if the IETF does not want to recommend the INFO message, the IETF should at least recognize it for experimental uses (i.e. roughly an equivalent of RTCP APP packet) and even documents these uses. Otherwise, we can end up with some types of INFO messages that are broadly used but that are even not documented within IETF documents (e.g. application/dtmf-relay for INFO with DTMF) Xavier On 7/20/07, Eric Burger wrote: > 12 second proof point of why content type doesn't work. > > So here comes an INVITE. I am an INFO-friendly UAS. I negotiate by using > Accept. > > This INVITE has the line: > Accept: application/kpml-response+xml > > > Wow! This is great! I know the UAC *wants* DTMF. Why? Because it accepts > a DTMF content type. Excellent - I can now send them DTMF. > > The user enters a digit, and I send an INFO with type > application/kpml-response+xml. > > UAC says, "What the heck was that?" > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 08:10:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDJDw-0004B5-0V; Tue, 24 Jul 2007 08:10:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDJDu-0004Ak-Dr for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 08:10:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDJDt-0004AN-NZ for sip@ietf.org; Tue, 24 Jul 2007 08:10:41 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDJDt-0005Ih-3H for sip@ietf.org; Tue, 24 Jul 2007 08:10:41 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 24 Jul 2007 08:10:31 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKuJpUZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,574,1175486400"; d="scan'208"; a="126864579:sNHT3386465660" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6OCAUjG014182 for ; Tue, 24 Jul 2007 08:10:30 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6OC2gWs017688 for ; Tue, 24 Jul 2007 12:10:33 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 08:10:16 -0400 Received: from [10.86.240.46] ([10.86.240.46]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 08:10:16 -0400 Message-ID: <46A5EC30.7000503@cisco.com> Date: Tue, 24 Jul 2007 08:10:24 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2007 12:10:16.0343 (UTC) FILETIME=[98885A70:01C7CDEB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3582; t=1185279030; x=1186143030; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20comments=20on=20draft-munakata-sip-privacy-new |Sender:=20 |To:=20IETF=20SIP=20List=20; bh=eMBGVGiK3WZ3cXanpcviP072lr3A7LV9xYJMAq1/FsE=; b=ZFA0iS2Y4EbdvFwz5O0kTqhr06LZHtdEDuMnCwx1fL59GhPjxBJbN+zpIugC5butHnMXK+dg YkAd4TzwBfuwlphYxzVwJ2FhQHENZeBxxIq3u5r9hkcnUwza9hczidd6; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Subject: [Sip] comments on draft-munakata-sip-privacy-new X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Overall this draft is excellent and exactly what I think it should be for this. Some comments below, major and nits: Major: Section 1: There are some additional problems worth noting: * privacy service has to be a b2bua and thus interferes with security mechanisms that break in the face of b2bua, such as sip identity (which provides message integrity and works well here too to provide the remote side an assurance of authenticated identity, just one that is not provided), which in turn breaks dtls-srtp * because of the need to signal from the UA to the privacy service exactly the desired functionality, the set of functionalities possible, in terms of what is anonyzmized and what is not, is bounded and required detailed specification. > The user agent setting the "temp-gruu" as a GRUU SHOULD set > "Anonymous" as a display name in any header where the display name of > the originator is set. That indicates the anonymity of the request > to intermediaries that may invoke some services based on the > anonymity of the call. Hmm, I'd prefer something explicit. There are problems with using human-readable and locale-specific text like display name to signal to automata. > Note: A relayed IP address may be used for a Via header, but some > commented that is not an appropriate to be used for signaling. > There was a comment about the IP address in Via being stripped > by the proxy, but that would require that a proxy compliant to > this specification is in the signaling path. I think it was me you said you didn't need this. You make a good point here however. > Note: The mechanism of the flag is FFS. From text above I thought it was presence of the Anonymous in display name, which is bad. I personally like the Privacy: id value since its effectively what everyone is using and also backwards compatible. I also think we need something to make sure the terminating UA doesn't try to render the From or P-A-ID if someone should insert. > Proxy Behavior The draft should talk about RFC 3325 in particular. Nits: > privacy service. This document proposes a new privacy mechanism that > a user agent can facilitate to conceal privacy-sensitive information > without the need for aid from a privacy service. This is somehwat misleading; there is a privacy service in the form of turn servers and proxies. > The protection of network > privacy (e.g., topology hiding) is outside the scope of this > document. You need to clarify what this means. > A user agent wanting to obtain functional anonymous URI SHOULD > support and SHOULD utilize the Global Routable User Agent URI (GRUU) > mechanism. Isn't this going to need to be a MUST? > response for a "temp-gruu" URI parameter, which provides the desired > privacy property. provides URI with the desired property > It is assumed that a user agent is either manually or automatically > configured through means such as a configuration framework with one > or more STUN relay servers. terminology has changed again; these are now called TURN servers once more. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 08:17:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDJKJ-0000FQ-H2; Tue, 24 Jul 2007 08:17:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDJKI-0000FH-3X for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 08:17:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDJKH-0000F9-Q9 for sip@ietf.org; Tue, 24 Jul 2007 08:17:17 -0400 Received: from [66.248.192.39] (helo=repmmg02.bea.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDJKG-0005TQ-Uc for sip@ietf.org; Tue, 24 Jul 2007 08:17:17 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6OCGZBq031720; Tue, 24 Jul 2007 05:16:35 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6OCGVq0029332; Tue, 24 Jul 2007 05:16:31 -0700 Received: from 172.24.28.130 ([172.24.28.130]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Jul 2007 12:16:31 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 24 Jul 2007 07:16:28 -0500 Subject: Re: [Sip] INFO and Content Negotiation From: Eric Burger To: Xavier Marjou Message-ID: Thread-Topic: [Sip] INFO and Content Negotiation Thread-Index: AcfNrXEejTNx1WiuSZ+j5lqwURy5nQAPwTwx In-Reply-To: <458913680707232145w5cd54ee6n43c15a0bcc07f774@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: IETF SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Indicating the package is possible; it is what Dean's draft of 4 years ago proposed. However, it is not what is there today. Moreover, it is doubtful that any of the myriad INFO exploits would use the mechanism. If one is going to upgrade one's mechanism, one might as well do the right thing. I would also offer we learn the lesson from the e-mail world of X-mumble headers. It is true that we need a mechanism to experiment with new extensions to SIP. However, formalizing that mechanism is asking for a rash of incompatible half-baked protocols, some of which, while broken, hijack SIP. The INFO draft as it currently stands still "allows" for such experimentation with INFO. It sounds like if we do want to work on this draft, the language needs to be clearer that (1) INFO is not gone and (2) INFO is *not* how you deploy something outside of the lab. Just for those who may have missed it, Section 4 states: In recognition of existing, proprietary use of INFO, proxies MUST NOT take any action other than that described by RFC 3261 and RFC 2976 with respect to handling INFO requests. This is the escape clause. On 7/23/07 11:45 PM, "Xavier Marjou" wrote: > Hi Eric, > > I also do not understand why it would not be possible to indicate in > the transaction of the initial INVITE what type of INFO is exactly > required/supported (negotiation and subscription stage) and to send > the event information with an INFO during the dialog (notification > stage). > > Concerning draft-burger-sip-info-00, I think the draft is not fair > with this poor INFO message. Indeed, the INFO message helps a lot to > quickly implement/have some features (e.g. full intra requests of > mmusic-xml-media-control, DTMF, MSCML, ...) while waiting for > implementations of the IETF standardized solutions (e.g. > rtcp-feedback, kpml, media-control, ...). Though I agree there are > some cons with features based on INFOs messages, there are also some > pros with this approach, (ie: same as for everything ;-) but I won't > go over such details. Thus, I think that even if the IETF does not > want to recommend the INFO message, the IETF should at least recognize > it for experimental uses (i.e. roughly an equivalent of RTCP APP > packet) and even documents these uses. Otherwise, we can end up with > some types of INFO messages that are broadly used but that are even > not documented within IETF documents (e.g. application/dtmf-relay for > INFO with DTMF) > > Xavier > > > > On 7/20/07, Eric Burger wrote: >> 12 second proof point of why content type doesn't work. >> >> So here comes an INVITE. I am an INFO-friendly UAS. I negotiate by using >> Accept. >> >> This INVITE has the line: >> Accept: application/kpml-response+xml >> >> >> Wow! This is great! I know the UAC *wants* DTMF. Why? Because it accepts >> a DTMF content type. Excellent - I can now send them DTMF. >> >> The user enters a digit, and I send an INFO with type >> application/kpml-response+xml. >> >> UAC says, "What the heck was that?" >> >> >> Notice: This email message, together with any attachments, may contain >> information of BEA Systems, Inc., its subsidiaries and affiliated >> entities, that may be confidential, proprietary, copyrighted and/or >> legally privileged, and is intended solely for the use of the individual or >> entity named in this message. If you are not the intended recipient, and have >> received this message in error, please immediately return this by email and >> then delete it. >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 09:17:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDKFz-0006Zu-SK; Tue, 24 Jul 2007 09:16:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDKFy-0006Zj-CL for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 09:16:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDKFy-0006Zb-1J for sip@ietf.org; Tue, 24 Jul 2007 09:16:54 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDKFx-0001ff-Gj for sip@ietf.org; Tue, 24 Jul 2007 09:16:53 -0400 Received: from [130.129.22.70] (dhcp-1646.ietf69.org [130.129.22.70]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6ODGeMw036318 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jul 2007 08:16:40 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <5D1A7985295922448D5550C94DE2918001473D89@DEEXC1U01.de.lucent.com> References: <46928F5F.3080502@softarmor.com> <46966F52.9040004@softarmor.com> <5D1A7985295922448D5550C94DE2918001473D89@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] RE: Correction: WGLC for draft-ietf-sip-outbound Date: Tue, 24 Jul 2007 08:16:37 -0500 To: "DRAGE, Keith \(Keith\)" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 130.129.22.70 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: sip@ietf.org, Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Keith/Rohan - There's a moderate list of changes we already know are going to be made to the document. Everyone who wasn't in Chicago's Monday SIP meeting should look at http://www3.ietf.org/proceedings/07jul/slides/sip-3.pdf for the bigger ones. Rohan has indicated a few smaller ones on list. Would it be possible to get a list of the known expected changes in one place? RjS On Jul 23, 2007, at 11:23 PM, DRAGE, Keith ((Keith)) wrote: > A reminder of the ongoing WGLC on the above document > > This WGLC period runs through IETF and hopefully close August 6, 2007. > > That gives you about a week after the end of IETF - please schedule > some time for doing this. > > Regards > > Keith > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Thursday, July 12, 2007 7:14 PM >> To: Dean Willis >> Cc: sip@ietf.org; Cullen Jennings; DRAGE, Keith (Keith) >> Subject: Correction: WGLC for draft-ietf-sip-outbound >> >> Dean Willis wrote: >>> I'd like to start a long working group last call for: >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-09.txt >>> >> >> My error. This should have referred to >> draft-ietf-sip-outbound-10, not -09. It was busy working its >> way through the posting system and I grabbed a pointer to the >> wrong one. >> >> Sorry about that, folks. >> >> -- >> Dean >> >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 09:36:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDKYz-0001b1-On; Tue, 24 Jul 2007 09:36:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDKYy-0001au-VP for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 09:36:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDKYy-0001am-Lf for sip@ietf.org; Tue, 24 Jul 2007 09:36:32 -0400 Received: from estacado-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:266::2] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDKYw-0007GC-Sh for sip@ietf.org; Tue, 24 Jul 2007 09:36:32 -0400 Received: from [130.129.22.70] (dhcp-1646.ietf69.org [130.129.22.70]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l6ODaMS8019121 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jul 2007 08:36:27 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: <21964a950707232132g462b6bb0if3f8a4296bf89d88@mail.gmail.com> References: <21964a950707162342h65f14291i605eb2c5da7fda33@mail.gmail.com> <54DA9005-F247-467B-BDE1-8E3FF2FBB2C5@estacado.net> <21964a950707232132g462b6bb0if3f8a4296bf89d88@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <38CF228C-9E17-4350-9C0A-00E2BC710A77@estacado.net> From: Robert Sparks Subject: Re: [Sip] Changes to the INVITE transaction to address bug 769 Date: Tue, 24 Jul 2007 08:36:20 -0500 To: "Nasir Khan" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -1.4 (-) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1590420777==" Errors-To: sip-bounces@ietf.org --===============1590420777== Content-Type: multipart/alternative; boundary=Apple-Mail-27-818549893 --Apple-Mail-27-818549893 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Yes - thanks! I'll comb for related text. RjS On Jul 23, 2007, at 11:32 PM, Nasir Khan wrote: > Should there be one more change to 3261 for invfix? > > Section 14.1 para 6 point # 2 should include the Accepted state? > > "If there is an ongoing INVITE server transaction, the TU MUST wait > until the transaction reaches the confirmed, *accepted* or > terminated state before initiating the new INVITE" > > Thanks > > Nasir Khan > > BEA Systems Inc. > > On 7/17/07, Robert Sparks wrote: > > On Jul 17, 2007, at 1:42 AM, Nasir Khan wrote: > >> Hi Robert, >> >> I have 3 comments / suggestions w.r.t this ID. >> >> Comment-1 >> ---------------- >> Should there be any change with respect to receiving CANCEL in >> Accepted state? Hitherto the UAC was getting a 481/CANCEL in such >> cases. Now we will get 200/CANCEL with no effect on IST. >> The reason for this question is backwards compatibility, however I >> can myself argue both ways on this one. What do you think? > > I don't see any issue here. The UAC already has to be prepared for > either response. > >> >> >> Comment-2 >> ----------------- >> In section 6.7 of the ID about the Timer-L you say - "and the >> amount of time this (or any downstream) UAS core might be >> retransmitting the 2xx while waiting for an ACK. " >> >> How does 2xx retransmission timer affect the choice of Timer L? >> >> >> Comment-3 >> ----------------- >> Shouldnt the Timer L be set to T4 which represents the amount of >> time the network will take to clear messages between client and >> server transactions? >> Since 2xx is sent reliably anyway, IMHO we do not need to link >> Timer L to Timer B. > > For both of these comments - Timer L is keeping the transaction in > place while the TU on top of this server transaction finishes its > job of retrasmitting 200s until it gets an ACK. It's not just > clearing messages that are already in the network. Remember that those > 200s might get lost, and timers on the UAC's side will cause the > INVITE request to be retransmitted. This Timer makes sure the > server transaction is still there to receive that retransmitted > INVITE. Does this clear up the questions you had? > > >> >> Thanks >> >> Nasir Khan >> BEA Systems Inc. >> >> >> On 6/27/07, Robert Sparks wrote: >> Everyone - >> >> I've put together a proposal for addressing the spec bug captured at >> http://bugs.sipit.net/show_bug.cgi?id=769 >> >> Please read through >> http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-00.txt >> and comment. >> >> RjS >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> >> >> >> -- >> Discuss SIP Servlets at http://groups.google.com/group/sipservlets/ >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > > > -- > Discuss SIP Servlets at http://groups.google.com/group/sipservlets/ > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --Apple-Mail-27-818549893 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Yes - thanks! I'll comb for = related text.

        RjS

        O= n Jul 23, 2007, at 11:32 PM, Nasir Khan wrote:

        Should = there be one more change to 3261 for invfix?

        Section 14.1 para = 6 point # 2 should include the Accepted state?

        "If there is an = ongoing INVITE server transaction, the TU MUST wait until the = transaction reaches the confirmed, *accepted* or terminated state before = initiating the new INVITE"

        Thanks

        Nasir Khan

        = BEA Systems Inc.

        On 7/17/07, = Robert Sparks <rjsparks@estacado.net> = wrote:

        On Jul 17, 2007, = at 1:42 AM, Nasir Khan wrote:

        Hi = Robert,

        I have 3 comments / suggestions w.r.t this ID.
        =
        Comment-1
        ----------------
        Should there be any change with = respect to receiving CANCEL in Accepted state? Hitherto the UAC was = getting a 481/CANCEL in such cases. Now we will get 200/CANCEL with no = effect on IST.
        The reason for this question is backwards = compatibility, however I can myself argue both ways on this one. What do = you think?

        I don't see any issue = here. The UAC already has to be prepared for either response.=A0 =
        =A0


        = Comment-2
        -----------------
        In section 6.7 of the ID about the = Timer-L you say - "and the amount of time this (or any downstream) UAS = core might be retransmitting the 2xx while waiting for an ACK. "
        =
        How does 2xx retransmission timer affect the choice of Timer = L?=A0


        Comment-3
        -----------------
        Shouldnt = the Timer L be set to T4 which represents the amount of time the network = will take to clear messages between client and server transactions?
        = Since 2xx is sent reliably anyway, IMHO we do not need to link Timer L = to Timer B.

        For both of these = comments - Timer L is keeping the transaction in place while the TU on = top of this server transaction finishes its
        job of = retrasmitting 200s until it gets an ACK. It's not just clearing messages = that are already in the network. Remember that those
        200s = might get lost, and timers on the UAC's side will cause the INVITE = request to be retransmitted. This Timer makes sure the
        server = transaction is still there to receive that retransmitted INVITE.=A0 Does = this clear up the questions you had? =


        =
        Thanks

        Nasir Khan
        BEA Systems Inc.
        =

        On 6/27/07, Robert Sparks <rjsparks@estacado.net> = wrote:
        Everyone -

        I've put together a proposal for addressing the = spec bug captured at
        http://bugs.sipit.net/show_bug.cgi?= id=3D769

        Please read through
        http://www.ietf.org/internet-drafts= /draft-sparks-sip-invfix-00.txt
        and = comment.

        RjS


        ___________________________________________= ____
        Sip mailing list=A0=A0 = https://www1.ietf.org/mailman/listinfo/sip
        This list is for NEW = development of the core SIP Protocol
        Use = sip-implementors@cs.columbia.edu for questions on current sip
        Use = sipping@ietf.org for new = developments on the application of sip



        --
        Discuss SIP Servlets at http://groups.google.com/group/sips= ervlets/
        _______________________________________________
        This list is for NEW development of the core SIP = Protocol
        Use = sip-implementors@cs.columbia.edu for questions on current = sip
        Use sipping@ietf.org for new = developments on the application of sip
        =




        --
        Discuss SIP Servlets at = http://groups.google.com/group/sipservlets/
        This list is = for NEW development of the core SIP Protocol
        Use sip-implementors@cs.colum= bia.edu for questions on current sip
        Use sipping@ietf.org for new = developments on the application of sip
        =

        = --Apple-Mail-27-818549893-- --===============1590420777== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1590420777==-- From sip-bounces@ietf.org Tue Jul 24 10:37:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLVL-0007ti-Oc; Tue, 24 Jul 2007 10:36:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDLVK-0007ta-PJ for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 10:36:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLVK-0007tS-CA for sip@ietf.org; Tue, 24 Jul 2007 10:36:50 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDLVJ-0003ZV-CT for sip@ietf.org; Tue, 24 Jul 2007 10:36:50 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 24 Jul 2007 07:36:48 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAC+rpUarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,574,1175497200"; d="scan'208"; a="506424788:sNHT32303658" 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 l6OEamFH031186 for ; Tue, 24 Jul 2007 07:36:48 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6OEag6I001544 for ; Tue, 24 Jul 2007 14:36:48 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 10:36:45 -0400 Received: from [10.86.242.79] ([10.86.242.79]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 10:36:45 -0400 Message-ID: <46A60E86.7030209@cisco.com> Date: Tue, 24 Jul 2007 10:36:54 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2007 14:36:45.0810 (UTC) FILETIME=[0F769520:01C7CE00] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5378; t=1185287808; x=1186151808; 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:=20comments=20on=20draft-ietf-sip-subnot-etags-00 |Sender:=20; bh=VcT88gkMv2W0JjgycbMzt2cdL6E1U9/ORCdt26NjzRE=; b=svuk0csTDk+CzWDft8sGlKlOcw7ubhajjyi17dSZoPUsWkX8T4MZ8xecuWw9XsoaC1V1av70 SgDdOca2IX1QTZbobLHSxQImHDrod7OAfwQWyfRWo7B5E4AxsKdJ99CN; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Subject: [Sip] comments on draft-ietf-sip-subnot-etags-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Overall I think this document is in great shape. Some comments below, mostly minor: > Changes in connectivity represent another impetus for a subscriber > re-subscribing. If the subscriber's point of attachment to the > Internet changes, e.g., due to dynamic address allocation, the > subscriber needs to re-subscribe in order to update the dialog > endpoint, which is carried in the Contact header field of the > SUBSCRIBE request. > > Another option for reducing connectivity induced subscription > refreshes is to use the Globally Routable User Agent (UA) URI > (GRUU) [10] as a stable endpoint contact for subscriptions. Yes, exactly. And here it works really well. So I would remove this paragraph as a motivation. > The same problem affects fetching and polling of resource state as > well. As a benchmark, if we look at the performance of HTTP [9] in > similar scenarios, it performs substantially better using conditional > requests. I'm curious if you have actual data on this, or just speculation. most HTTP resources are dynamic so its not clear it actually helps http. > NOTIFY request. The entity tag is unique for that particular > resource and event notification. You should clarify what it means to be unique for a resource *and* event notification. So this means if I fetch the resource with http it has a differnet entity tag? > The two types of conditions available for a SUBSCRIBE are a Suppress- > Body-If-Match and a Suppress-Notify-If-Match; each of these header > fields contains the last entity-tag seen by the subscriber. If the > condition evaluates to true, the first of these conditions will > instruct the notifier to suppress the body of the next notification > and the second the entire notification. Is there a reason we need both? Could we just have Suppress-Body-If-Match and if the subscription state is anything besides active and the subscription duration anything different than the Expires in the request, a NOTIFY is sent without a body? > There is also a wildcard entity-tag with > a special value of "*" that always matches. what is the use-case for this? * I think you can actually implement this without option tags. The presence of the Suppress-* header fields basically plays that role. Supported is needed if the UA is not asking for some feature in a request, but merely saying, its supported. > uppress-Body-If-Match: if this condition evaluates to true, the > notifier is instructed to suppress (i.e., remove) the body of the > first NOTIFY request following the SUBSCRIBE. If false, the > notifier follows the default behavior. Its not 'first' - its any subsequet NOTIFY whose body, had this specification not be in use, would contain the resource with that entity tag. > Suppress-Notify-If-Match: if this condition evaluates to true, the > notifier is instructed to suppress (i.e., block) the entire first > NOTIFY request following the SUBSCRIBE, and instead send a 204 (No > Notification) response. If false, the notifier again follows the > default behavior. I don't think we need a new response code. What is the justification? > The conditional header field can also be wildcarded using the special > "*" entity-tag value. Such a condition always evaluates to true > regardless of the value of the current entity-tag for the resource. > > Example: > > Suppress-Notify-If-Match: * This seems like a bad idea in fact. Why is it here? * Section 4 needs to cover handling of the response to SUBSCRIBE (what happens when a 204 comes), and NOTIFY (store entity tag). Also needs to handle what to do in the case where the notifier doesn't support the mechanism. > A notifier MUST generate entity tags for each resource it is > responsible for. > > The views might correspond to different groups of users that have > varying levels of access rights to the resource state, or to > subscribers that have modified their subscription using event > notification filtering [11]. For example, in presence [6] > watchers may get different levels of accuracy in geolocation > information, based on the presentity's privacy settings. What do views have to do with this? Nits: > These procedures have a serious > deficiency in that they do not allow state to persist over a > subscription refresh, or between two consecutive polls. State can persist at the UA; its just that you get notified of stuff you already know. > An entity-tag is a token carried in the SIP-ETag header field, and it > is opaque to the client. The notifier is free to decide the means > for generating an entity-tag, except for the special "*" value. I think you mean, "The notifier is free to decide on any means for generating the entity-tag. It can have any value, except for "*"" -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 10:48:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLgl-0008PQ-3s; Tue, 24 Jul 2007 10:48:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDLgj-0008K4-GM for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 10:48:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLgj-0008Hk-4k for sip@ietf.org; Tue, 24 Jul 2007 10:48:37 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDLgi-0000SX-HE for sip@ietf.org; Tue, 24 Jul 2007 10:48:37 -0400 Received: from dhcp-1629.ietf69.org (dhcp-1629.ietf69.org [130.129.22.41]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6OEmSYx041243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Jul 2007 09:48:29 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <46A6113A.9000500@nostrum.com> Date: Tue, 24 Jul 2007 09:48:26 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: SIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.22.41 is authenticated by a trusted mechanism) X-Spam-Score: -1.4 (-) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Sip] Two minor Max-Breadth comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org During today's meeting, a point was raised surrounding whether the max-breadth approach should limit the total number of requests or merely the number of requests in flight at once. The statement is that limiting only the ones in flight simultaneously ultimately results in the same number of messages as would result without the extension. While there has been a token mention of Timer C, I think we're underestimating the mitigating effect of Timer C. As an additional point, I think it's worth pointing out that the victim, if they recognize they are being subjected to this style of attack, can tear the entire tree down fairly rapidly by throwing a 600-class response. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 11:00:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLsQ-00012i-Hh; Tue, 24 Jul 2007 11:00:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDLsN-00012N-L3 for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 11:00:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLsN-00012E-Ad for sip@ietf.org; Tue, 24 Jul 2007 11:00:39 -0400 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDLsN-00045F-05 for sip@ietf.org; Tue, 24 Jul 2007 11:00:39 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc12) with ESMTP id <20070724150038b1200ddonke>; Tue, 24 Jul 2007 15:00:38 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6OF0b8t016023 for ; Tue, 24 Jul 2007 11:00:37 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6OF0bML016019; Tue, 24 Jul 2007 11:00:37 -0400 Date: Tue, 24 Jul 2007 11:00:37 -0400 Message-Id: <200707241500.l6OF0bML016019@dragon.ariadne.com> From: Dale Worley To: sip@ietf.org In-reply-to: <46A6113A.9000500@nostrum.com> (adam@nostrum.com) Subject: Re: [Sip] Two minor Max-Breadth comments References: <46A6113A.9000500@nostrum.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Adam Roach During today's meeting, a point was raised surrounding whether the max-breadth approach should limit the total number of requests or merely the number of requests in flight at once. The statement is that limiting only the ones in flight simultaneously ultimately results in the same number of messages as would result without the extension. While there has been a token mention of Timer C, I think we're underestimating the mitigating effect of Timer C. As an additional point, I think it's worth pointing out that the victim, if they recognize they are being subjected to this style of attack, can tear the entire tree down fairly rapidly by throwing a 600-class response. Also, the UAC, if it is not perverse, will ultimately cancel the request. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 11:01:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLtd-0002pt-L4; Tue, 24 Jul 2007 11:01:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDLtZ-0002kC-OO for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 11:01:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLtZ-0002i0-2O for sip@ietf.org; Tue, 24 Jul 2007 11:01:53 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDLtT-00048o-NH for sip@ietf.org; Tue, 24 Jul 2007 11:01:52 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLO002LUV2X8A@usaga01-in.huawei.com> for sip@ietf.org; Tue, 24 Jul 2007 08:01:46 -0700 (PDT) Received: from s73602 (dhcp-1722.ietf69.org [130.129.23.34]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLO00BRZV2U94@usaga01-in.huawei.com> for sip@ietf.org; Tue, 24 Jul 2007 08:01:45 -0700 (PDT) Date: Tue, 24 Jul 2007 09:58:34 -0500 From: Spencer Dawkins To: sip@ietf.org Message-id: <123f01c7ce03$1bc35b80$fb0111ac@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Subject: [Sip] Notes on Idraft-burger-sip-info-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I finally got to look at draft-burger-sip-info-00. I like what I see. I did notice some nits, and am willing to provide a more formal review, but I support adoption of this draft as a WG deliverable, even in its current form. You may have noticed that the MEDIACTRL WG editors were forced to discuss INFO in their specifications, because we currently have one draft providing guidance on INFO that people seem to generally agree with, but it expired years ago. I Thanks, Eric, for taking this on. Spencer detailed comments... Intended status: Standards Track Could/should this be a BCP? Informational isn't strong enough, but... 2. Flaws With INFO I'm remembering one other painful point - that INFO didn't provide a way to specify content-disposition if there is more than one reasonable choice. Did I make this up? An interesting issue is every INFO request traverses the same proxy path as any other dialog-related SIP request. Proxies in the path that have no interest in INFO requests still must process the request. This may put undue load on those proxies. What makes this issue interesting, and not necessarily a proxy, is one may wish the Not sure what "and not necessarily a proxy" was supposed to actually be - edit error? request to traverse the proxy. The problem is there is no way for proxies to not whether or not they have an interest in INFO requests. Getting the requests is an all-or-nothing proposition, driven by Record-Route. 3. INFO Alternatives What if you think you need UA-to-UA application session signaling? This sounds like an invitation to therapy :D. Perhaps "If your new application requires UA-to-UA session level signaling, what alternatives exist that provide this without using INFO?" There are four broad classes of session signaling available. The choice depends on the circumstances. o State updates o User stimulus o Direct signaling channel o Proxy-aware signaling 3.1. State Updates This is the broad class of one User Agent updating another with changes in state. Clearly, state updates are the provenance of the SUBSCRIBE/NOTIFY [8] event framework. Excellent vocabulary. Perhaps "Clearly the SUBSCRIBE/NOTIFY [8] event framework was specifically designed to meet this need" might be more accessible? 3.2. User Stimulus: Touch Tones and Others This is the class of the user entering stimulus at one User Agent, and the User Agent transporting that stimulus to the other. A key thing to realize is key presses on the telephone keypad is user stimulus. Thus, the appropriate mechanism to use here is KPML [9]. 3.3. Direct Signaling Channel State updates and user stimulus tend to have relatively few messages per session. Sometimes, User Agents have a need for exchanging a s/have a need for exchanging/need to exchange/ relatively high number of messages. In addition, User Agents may have a need for a relatively low-latency exchange of messages. In this latter case, the User Agent may not be able to tolerate the latency introduced by intermediate proxies. Likewise, the intermediate proxies may have no interest in processing all of that data. ... and it's not obvious how they would process it anyway, if the INFO payload is really only meaningful to UAs. In this case, establishing a separate, direct control channel, as in MSRP [10] or MRCPv2 [11] is appropriate. 3.4. Proxy-Aware Signaling Sometimes, one does want proxies to be in the signaling path for UA- to-UA application signaling. In this case, the use of a SIP request is appropriate. To date, there are no mechanisms for completely disambiguating INFO requests. For example, one could create a registry of INFO packages. The definition of the package would define the contexts for the various MIME Content-Types, as well as the context of the request itself. However, a package can have multiple content types. Moreover, having the context, or package identifier, at the SIP level precludes bundling multiple contexts responding in the same INFO request. For example, a User Agent might want to bundle two different responses in a multipart/mixed MIME body type. Because there is no difference in either the protocol machinery or registration process due to these factors, we will not create an INFO framework. If one needs a SIP User Agent-to-SIP User Agent application session signaling transport protocol that touches all Record-Route proxies in a path, one MUST create a new SIP method as described in Section 27.4 of RFC 3261 [2]. 4. INFO Use Clarification There is no way to unambiguously use the INFO request in a general framework. The IETF has already standardized use of INFO for SIP-T [4]. Thus we will not deprecate the use of INFO for that purpose. However, this document explicitly updates INFO [3], in that one MUST NOT use the INFO request for anything other than the use described by SIP-T. I'm confused here. Is it "one MUST NOT use INFO" or that "new applications MUST NOT define new uses for INFO"? In recognition of existing, proprietary use of INFO, proxies MUST NOT take any action other than that described by RFC 3261 and RFC 2976 with respect to handling INFO requests. OPEN ISSUE: Do we bow to reality, and say, "INFO is the Port 80 of the 2000's. SBC's will never keep up with newly minted SIP method requests, so we keep INFO so we can have a poliferation of protocols tunneled over SIP?" Well, I think your point is actually that SIP is the Port 80 of the 2000s, and INFO is the port 80 of SIP signaling, so the situation is even more frustrating than your text suggests. My preference is to remove this OPEN ISSUE text and publish the draft so we will all drop INFO as a choice for future applications. Appendix A. Acknowledgements Standing on the shoulders of giants. Jonathan Rosenberg did the original "INFO Considered Harmful" on 26 December 2002, which influenced the work group and this document. Likewise, Dean Willis influenced the text from his "Packaging and Negotiation of INFO Methods for the Session Initiation Protocol" of 15 January 2003. My, we have been working on this for a long time! Could you mention that these were both Internet-Drafts (ex. "in an Internet-Draft submitted on 26 December 2002")? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 11:08:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLzt-0000Cm-Rs; Tue, 24 Jul 2007 11:08:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDLzs-0000BD-1T for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 11:08:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLzr-0000B5-O9 for sip@ietf.org; Tue, 24 Jul 2007 11:08:23 -0400 Received: from rwcrmhc14.comcast.net ([216.148.227.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDLzr-0000yy-C4 for sip@ietf.org; Tue, 24 Jul 2007 11:08:23 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc14) with ESMTP id <20070724150822m140021soqe>; Tue, 24 Jul 2007 15:08:22 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6OF8L8t016583 for ; Tue, 24 Jul 2007 11:08:21 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6OF8LDW016579; Tue, 24 Jul 2007 11:08:21 -0400 Date: Tue, 24 Jul 2007 11:08:21 -0400 Message-Id: <200707241508.l6OF8LDW016579@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <46A6113A.9000500@nostrum.com> (adam@nostrum.com) References: <46A6113A.9000500@nostrum.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Sip] Max-Breadth options X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org One difficulty with Max-Breadth or any similar feature is: When forking, how do I allocate the incoming Max-Breadth to the outgoing forks? The obvious solution is to split it equally, but the result is that the depth of the tree is limited to log(Max-Breadth) forks. One can easily construct somewhat realistic examples that demand a large Max-Breadth in order to succeed: UAC Max-Breadth = 16 / \ / \ Max-Breadth = 8 v v 404 proxy / \ / \ Max-Breadth = 4 v v 404 proxy / \ / \ Max-Breadth = 2 v v proxy 404 / \ / \ Max-Breadth = 1 v v 200 404 That generates only 5 forks but requires a Max-Breadth of 16 to succeed. And under Option 2, even using serial forking has this problem, though the message load is rather light. However, if we choose Option 1, so that the Max-Breadth allocated to a canceled fork can be reclaimed for use on other forks, then a proxy can always fall back from parallel forking to serial forking. This allows the forking tree to be explored to Max-Forwards depth, although extreme cases will explore the deeper leaves serially rather than parallely, which is a user-visible performance impact (if the UASs do not respond promptly) but doesn't cause call failure. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 11:11:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDM2u-0001gw-PX; Tue, 24 Jul 2007 11:11:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDM2s-0001fC-SH for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 11:11:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDM2s-0001f4-Ie for sip@ietf.org; Tue, 24 Jul 2007 11:11:30 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDM2r-00012o-Tr for sip@ietf.org; Tue, 24 Jul 2007 11:11:30 -0400 Received: from dhcp-1629.ietf69.org (dhcp-1629.ietf69.org [130.129.22.41]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6OFBRNM042682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jul 2007 10:11:28 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <46A6169D.2030106@nostrum.com> Date: Tue, 24 Jul 2007 10:11:25 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] comments on draft-ietf-sip-subnot-etags-00 References: <46A60E86.7030209@cisco.com> In-Reply-To: <46A60E86.7030209@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.22.41 is authenticated by a trusted mechanism) X-Spam-Score: -1.4 (-) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 7/24/07 9:36 AM, Jonathan Rosenberg wrote: > >> The conditional header field can also be wildcarded using the special >> "*" entity-tag value. Such a condition always evaluates to true >> regardless of the value of the current entity-tag for the resource. >> >> Example: >> >> Suppress-Notify-If-Match: * We discussed this briefly at the microphone -- the answer can be paraphrased as "about half the stuff in Mohammad's notify-pause draft that we'll be discussing in SIPPING on Thursday." If we move forward with the notify-pause stuff (which I think would be a good idea), then we need to have clarity around how these two mechanisms interact -- and whether it even makes sense in the etags document if we're going to develop a more complete way to address these use cases in the pause draft. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 11:18:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDM98-00034B-Hk; Tue, 24 Jul 2007 11:17:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDM97-0002u0-1k for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 11:17:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDM96-0002ts-Mv for sip@ietf.org; Tue, 24 Jul 2007 11:17:56 -0400 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDM96-0004ng-CA for sip@ietf.org; Tue, 24 Jul 2007 11:17:56 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc14) with ESMTP id <20070724151755014001agh4e>; Tue, 24 Jul 2007 15:17:55 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6OFHt8t017294 for ; Tue, 24 Jul 2007 11:17:55 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6OFHtKH017290; Tue, 24 Jul 2007 11:17:55 -0400 Date: Tue, 24 Jul 2007 11:17:55 -0400 Message-Id: <200707241517.l6OFHtKH017290@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Sip] Essential corrections X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I would like to praise the current proposal, viz., providing each change in two forms: one as a textual difference to the relevant RFC and the other as a prose narrative of the new behavior. (There should also be discussion of what the difference is and what the motivation is, but I'm not addressing that here.) And both descriptions should be *normative*. The reason is that it makes the revision process much more robust against error -- though it's unfortunately easy to make errors in either diff form or in narrative form, it is difficult to make the *same* error in both forms. Contradictions between the two forms show that an error has been made in the error correction. (Yuck.) This is similar to putting comments in code -- one of the major tools for debugging code is to notice that the comments and the code do not match. (Designating one or the other as the sole normative form would make the normative meaning of the correction unambiguous if there was a contradiction, but it would not raise the probability that the normative meaning was correct or was what was intended. Similarly, when a comment does not match code, either one might be wrong.) Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 11:40:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMUx-0002Zi-4I; Tue, 24 Jul 2007 11:40:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDMUw-0002ZW-LI for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 11:40:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMUw-0002ZJ-8O for sip@ietf.org; Tue, 24 Jul 2007 11:40:30 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDMUv-0005hs-PF for sip@ietf.org; Tue, 24 Jul 2007 11:40:30 -0400 Received: from [130.129.22.70] (dhcp-1646.ietf69.org [130.129.22.70]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6OFeS6E055748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jul 2007 10:40:29 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <46A6113A.9000500@nostrum.com> References: <46A6113A.9000500@nostrum.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <55027AE0-ABD0-4853-9AD7-37B8265D7CE5@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Two minor Max-Breadth comments Date: Tue, 24 Jul 2007 10:40:24 -0500 To: Adam Roach X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 130.129.22.70 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: SIP WG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org These are important points - adding max-breadth makes the effects of responses from the endpoints and CANCELS (from the originator or from proxies) meaningful. (In the original attack, the cancel could never catch up with the request). For the last point - Throwing the 600 doesn't tear the whole tree down immediately. The 600 will be held by each node until all branches under it complete. Once that happens it moves upstream. When it moves upstream, the next node starts canceling other branches. Those CANCELs still won't catch the request, but the number of things it has to chase is bounded above by a constant. RjS On Jul 24, 2007, at 9:48 AM, Adam Roach wrote: > During today's meeting, a point was raised surrounding whether the > max-breadth approach should limit the total number of requests or > merely the number of requests in flight at once. The statement is > that limiting only the ones in flight simultaneously ultimately > results in the same number of messages as would result without the > extension. > > While there has been a token mention of Timer C, I think we're > underestimating the mitigating effect of Timer C. > > As an additional point, I think it's worth pointing out that the > victim, if they recognize they are being subjected to this style of > attack, can tear the entire tree down fairly rapidly by throwing a > 600-class response. > > /a > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 11:41:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMVh-0002zH-RW; Tue, 24 Jul 2007 11:41:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDMVg-0002yq-8X for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 11:41:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMVf-0002yi-V9 for sip@ietf.org; Tue, 24 Jul 2007 11:41:15 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDMVf-0002Hu-Gn for sip@ietf.org; Tue, 24 Jul 2007 11:41:15 -0400 Received: from dhcp-1629.ietf69.org (dhcp-1629.ietf69.org [130.129.22.41]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6OFfEOX055786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Jul 2007 10:41:14 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <46A61D97.5030204@nostrum.com> Date: Tue, 24 Jul 2007 10:41:11 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: SIP WG Subject: Re: [Sip] Two minor Max-Breadth comments References: <46A6113A.9000500@nostrum.com> In-Reply-To: <46A6113A.9000500@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.22.41 is authenticated by a trusted mechanism) X-Spam-Score: -1.4 (-) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 7/24/07 9:48 AM, Adam Roach wrote: > > As an additional point, I think it's worth pointing out that the > victim, if they recognize they are being subjected to this style of > attack, can tear the entire tree down fairly rapidly by throwing a > 600-class response. To put a finer point on this: by "fairly rapidly," I mean "O(log(n))" where n=max-breadth at the root of the tree. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 11:51:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMfr-0004kl-ID; Tue, 24 Jul 2007 11:51:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDMfp-0004ka-6s for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 11:51:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMfo-0004kS-S1 for sip@ietf.org; Tue, 24 Jul 2007 11:51:44 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDMfo-0005wa-5G for sip@ietf.org; Tue, 24 Jul 2007 11:51:44 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6OFoxwh006785; Tue, 24 Jul 2007 18:51:37 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 18:51:01 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 18:51:01 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 18:51:01 +0300 Received: from [10.241.58.185] (daec-linuxvpn058185.americas.nokia.com [10.241.58.185]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6OFowAB006923; Tue, 24 Jul 2007 18:50:58 +0300 Message-ID: <46A61FE0.2020202@nokia.com> Date: Tue, 24 Jul 2007 18:50:56 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: ext Adam Roach Subject: Re: [Sip] comments on draft-ietf-sip-subnot-etags-00 References: <46A60E86.7030209@cisco.com> <46A6169D.2030106@nostrum.com> In-Reply-To: <46A6169D.2030106@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2007 15:51:01.0244 (UTC) FILETIME=[6F1BDBC0:01C7CE0A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Inline. ext Adam Roach wrote: > On 7/24/07 9:36 AM, Jonathan Rosenberg wrote: >> >>> The conditional header field can also be wildcarded using the special >>> "*" entity-tag value. Such a condition always evaluates to true >>> regardless of the value of the current entity-tag for the resource. >>> >>> Example: >>> >>> Suppress-Notify-If-Match: * > > We discussed this briefly at the microphone -- the answer can be > paraphrased as "about half the stuff in Mohammad's notify-pause draft > that we'll be discussing in SIPPING on Thursday." As I said in the session today, this is not to pause a subscription at all; it only affects the very next NOTIFY that the SUBSCRIBE is about to generate. So I don't see where the overlap here is. (However, there is considerable overlap with the notify-pause and the throttle draft, which I used to author long ago when my hair was a lot shorter...) The use-cases for the wildcard are as follows (also mentioned at the end of 4.3.): - Heartbeat, or liveliness check. Using Suppress-Notify-If-Match: *, the watcher can check whether a resource is alive: a 204 response says it is, a 404 says it is not. - Meta-data retrieval. Just like a HEAD in HTTP, a SUBSCRIBE with Suppress-Body-If-Match: * will generate a NOTIFY without the body but with the full header, including the current SIP-ETag. I agree that these are not cornerstone use-cases for this draft, but they represent some low-hanging fruit that would be difficult to add as an extension. I think it is beneficial to make notifiers understand wildcards from the very beginning. (I believe it is also a trivial implementation effort. I mean it's a single additional string comparison in addition to matching the given etag value with the current etag value of the resource, which the notifier in any case needs to perform.) Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 12:05:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMsr-0000Dn-8e; Tue, 24 Jul 2007 12:05:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDMsn-0000CY-FP for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 12:05:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMsn-0000CO-5W for sip@ietf.org; Tue, 24 Jul 2007 12:05:09 -0400 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDMsm-0002na-Qp for sip@ietf.org; Tue, 24 Jul 2007 12:05:09 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc11) with ESMTP id <2007072416050801100rs1qke>; Tue, 24 Jul 2007 16:05:08 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6OG578t020722 for ; Tue, 24 Jul 2007 12:05:07 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6OG57VQ020718; Tue, 24 Jul 2007 12:05:07 -0400 Date: Tue, 24 Jul 2007 12:05:07 -0400 Message-Id: <200707241605.l6OG57VQ020718@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <46A36757.7020500@nostrum.com> (adam@nostrum.com) References: <7374777208BDC7449D5620EF942325670743C97A@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF942325670743C97B@esealmw113.eemea.ericsson.se> <46A36757.7020500@nostrum.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Sip] INFO, Mime-multipart, and Content Negotiation (oh, my!) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org These issues seem to be all related. E-mail Mime can make do with Content-Type because e-mail's sole function is to present information to the user. The only information needed is "What is this?" because "What should I do with this?" is constant. In SIP, we have the Content-Disposition, with the defined values "session", "render", "alert", and "icon". This answers the question "What should I do with this?", which is independent of "What is this?". We've been quite sloppy about this issue because for most methods "What should I do with this?" is strongly implied by the method or the context or the Content-Type. But with INFO, unless there is a tightly constrained context from some non-SIP feature, there is complete decoupling between "What is this?" and "What should I do with this?". That is, any body part needs a Content-Disposition that identifies what should be done with the information (= what application the information should be delivered to). But we have no method for negotiating what Content-Dispositions are supported by a given SIP UA. So of course it doesn't work well. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 12:26:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDNDb-0003TV-FL; Tue, 24 Jul 2007 12:26:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDNDa-0003TN-0B for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 12:26:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDNDZ-0003TC-Mb for sip@ietf.org; Tue, 24 Jul 2007 12:26:37 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDNDX-0004Nz-Qw for sip@ietf.org; Tue, 24 Jul 2007 12:26:37 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLO00JK3Z0ACV@usaga01-in.huawei.com> for sip@ietf.org; Tue, 24 Jul 2007 09:26:34 -0700 (PDT) Received: from s73602 (dhcp-1722.ietf69.org [130.129.23.34]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLO00EUWZ08S1@usaga01-in.huawei.com> for sip@ietf.org; Tue, 24 Jul 2007 09:26:34 -0700 (PDT) Date: Tue, 24 Jul 2007 11:23:24 -0500 From: Spencer Dawkins Subject: Re: [Sip] Notes on Idraft-burger-sip-info-00 To: sip@ietf.org Message-id: <130901c7ce0e$f5c54a40$fb0111ac@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <123f01c7ce03$1bc35b80$fb0111ac@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I spoke at the mike a minute ago about having this draft done in SIP, and then Rohan suggested that BLISS would be the right place to do the work. I would be OK with that, too, if others see it the same way. Dean called the question as "do something IN THIS WG", which is fair (because that's the WG he chairs), but I would support "doing something IN THE RIGHT WG", if the chairs and ADs think there's a better home for the work. Pointing to a MEDIACTRL draft is not the right thing to do, and pointing to a long-expired draft that people may or may not have agreed with at the time is even worse. Spencer >I finally got to look at draft-burger-sip-info-00. I like what I see. I did > notice some nits, and am willing to provide a more formal review, but I > support adoption of this draft as a WG deliverable, even in its current > form. > > You may have noticed that the MEDIACTRL WG editors were forced to discuss > INFO in their specifications, because we currently have one draft > providing guidance on INFO that people seem to generally agree with, but > it expired years ago. I > > Thanks, Eric, for taking this on. > > Spencer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 12:36:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDNN4-0007xf-6Q; Tue, 24 Jul 2007 12:36:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDNN2-0007eZ-9e for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 12:36:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDNN1-0007au-R8 for sip@ietf.org; Tue, 24 Jul 2007 12:36:23 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDNN0-0004gf-5S for sip@ietf.org; Tue, 24 Jul 2007 12:36:23 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6OGaIWW011672; Tue, 24 Jul 2007 19:36:18 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 19:36:14 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 19:36:14 +0300 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.1830); Tue, 24 Jul 2007 19:36:13 +0300 Received: from [10.241.58.185] (daec-linuxvpn058185.americas.nokia.com [10.241.58.185]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6OGa9Ec000552; Tue, 24 Jul 2007 19:36:11 +0300 Message-ID: <46A62A78.1030200@nokia.com> Date: Tue, 24 Jul 2007 19:36:08 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Sip] comments on draft-ietf-sip-subnot-etags-00 References: <46A60E86.7030209@cisco.com> In-Reply-To: <46A60E86.7030209@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2007 16:36:13.0324 (UTC) FILETIME=[BFA26CC0:01C7CE10] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jonathan, Thanks for the feedback. Inline. ext Jonathan Rosenberg wrote: > Overall I think this document is in great shape. Some comments below, > mostly minor: > >> Changes in connectivity represent another impetus for a subscriber >> re-subscribing. If the subscriber's point of attachment to the >> Internet changes, e.g., due to dynamic address allocation, the >> subscriber needs to re-subscribe in order to update the dialog >> endpoint, which is carried in the Contact header field of the >> SUBSCRIBE request. >> >> Another option for reducing connectivity induced subscription >> refreshes is to use the Globally Routable User Agent (UA) URI >> (GRUU) [10] as a stable endpoint contact for subscriptions. > > Yes, exactly. And here it works really well. So I would remove this > paragraph as a motivation. Done. >> The same problem affects fetching and polling of resource state as >> well. As a benchmark, if we look at the performance of HTTP [9] in >> similar scenarios, it performs substantially better using conditional >> requests. > > I'm curious if you have actual data on this, or just speculation. most > HTTP resources are dynamic so its not clear it actually helps http. I haven't looked at any empirical data on this. This comment is more about the protocol itself, not the web as such. And while most actual content may be dynamic, think of the dozens of pictures that a typical web page has as backgrounds, delimiters, and other graphics. These things rarely change, even if the actual content of the page changes; a refresh GET really should not replay all those jpegs. I would make a simile here to a typical SIP notification generated because of a refresh. >> NOTIFY request. The entity tag is unique for that particular >> resource and event notification. > > You should clarify what it means to be unique for a resource *and* event > notification. So this means if I fetch the resource with http it has a > differnet entity tag? My working copy says: The entity-tag MUST be unique across all versions of all entities for a resource. I think we should also add "...and event package" just to be clear. I think we should also add that the subscriber should never assume that the entity-tags are shared between notification and, say, SIP event publication or HTTP. >> The two types of conditions available for a SUBSCRIBE are a Suppress- >> Body-If-Match and a Suppress-Notify-If-Match; each of these header >> fields contains the last entity-tag seen by the subscriber. If the >> condition evaluates to true, the first of these conditions will >> instruct the notifier to suppress the body of the next notification >> and the second the entire notification. > > Is there a reason we need both? Could we just have > Suppress-Body-If-Match and if the subscription state is anything besides > active and the subscription duration anything different than the Expires > in the request, a NOTIFY is sent without a body? This would be a very drastic simplification, and it would not work for polling, which was one of the original use-cases. In fact, another way of doing this is to *always* use Suppress-Body-If-Match: * in refreshes, according to the current draft. I still believe the ability to suppress the entire NOTIFY is a valuable feature, but as Rohan pointed out, it may also have backwards compatibility issues, as it is a more substantial change to RFC3265. >> There is also a wildcard entity-tag with >> a special value of "*" that always matches. > > what is the use-case for this? > > * I think you can actually implement this without option tags. The > presence of the Suppress-* header fields basically plays that role. > Supported is needed if the UA is not asking for some feature in a > request, but merely saying, its supported. The only reason it's there, actually, is for the subscriber to give a hint to the notifier, that etags are supported. This is when a SUBSCRIBE has no Suppress-*, i.e., it's the very first SUBSCRIBE. However, I agree it adds very, very little value. I'll remove it. >> uppress-Body-If-Match: if this condition evaluates to true, the >> notifier is instructed to suppress (i.e., remove) the body of the >> first NOTIFY request following the SUBSCRIBE. If false, the >> notifier follows the default behavior. > > Its not 'first' - its any subsequet NOTIFY whose body, had this > specification not be in use, would contain the resource with that entity > tag. Ahh, I see. Now I understand why Adam was seeing the overlap with notify-pause. It's 'first' intentionally. The mechanism is supposed to only affect the very NOTIFY that the SUBSCRIBE is about to generate. It could be 'any subsequent' but would there be any reason that a notifier replays notifications if there's no change? >> Suppress-Notify-If-Match: if this condition evaluates to true, the >> notifier is instructed to suppress (i.e., block) the entire first >> NOTIFY request following the SUBSCRIBE, and instead send a 204 (No >> Notification) response. If false, the notifier again follows the >> default behavior. > > I don't think we need a new response code. What is the justification? It is to enable the subscriber to destroy its handle as soon as the 204 is received, instead of keeping it indefinitely in case there is a NOTIFY forthcoming (it may not ever come). > * Section 4 needs to cover handling of the response to SUBSCRIBE (what > happens when a 204 comes), and NOTIFY (store entity tag). Also needs to > handle what to do in the case where the notifier doesn't support the > mechanism. I can add text to the numbered lists of 4.x sections about storing the entity tags. The very last bullets of each of 4.x sections do talk about what the subscriber is to do with the 204. Should there be a sub-section in section 4 that has normative text on these though? > >> A notifier MUST generate entity tags for each resource it is >> responsible for. >> >> The views might correspond to different groups of users that have >> varying levels of access rights to the resource state, or to >> subscribers that have modified their subscription using event >> notification filtering [11]. For example, in presence [6] >> watchers may get different levels of accuracy in geolocation >> information, based on the presentity's privacy settings. > > What do views have to do with this? Here view == entity, but clearly the view should be in double quotes, as it's not a term that is clearly defined anywhere. However, The next version will have section 5.1. strengthened to make this part of the model (hopefully) clear. > Nits: > > > >> These procedures have a serious >> deficiency in that they do not allow state to persist over a >> subscription refresh, or between two consecutive polls. > > State can persist at the UA; its just that you get notified of stuff you > already know. True. I'll reword: ...deficiency in that they provide no tools to avoid replaying event notifications that are already known to the UA. >> An entity-tag is a token carried in the SIP-ETag header field, and it >> is opaque to the client. The notifier is free to decide the means >> for generating an entity-tag, except for the special "*" value. > > I think you mean, "The notifier is free to decide on any means for > generating the entity-tag. It can have any value, except for "*"" True, this is already fixed in my working copy. Dale made the same correction. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 12:38:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDNP5-0001Lf-HM; Tue, 24 Jul 2007 12:38:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDNP4-0001LW-5m for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 12:38:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDNP3-0001LM-S2 for sip@ietf.org; Tue, 24 Jul 2007 12:38:29 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDNP3-0004oD-Ef for sip@ietf.org; Tue, 24 Jul 2007 12:38:29 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 24 Jul 2007 12:38:29 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusRAALIpUZAZnmf/2dsb2JhbACIX59Y X-IronPort-AV: i="4.16,574,1175486400"; d="scan'208"; a="66015987:sNHT37236978" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6OGcSnl012711; Tue, 24 Jul 2007 12:38:28 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6OGbsFB026513; Tue, 24 Jul 2007 16:38:28 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, 24 Jul 2007 12:38:26 -0400 Received: from [10.86.242.201] ([10.86.242.201]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 12:38:26 -0400 Message-ID: <46A62B01.7050509@cisco.com> Date: Tue, 24 Jul 2007 12:38:25 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Spencer Dawkins Subject: Re: [Sip] Notes on Idraft-burger-sip-info-00 References: <123f01c7ce03$1bc35b80$fb0111ac@china.huawei.com> <130901c7ce0e$f5c54a40$fb0111ac@china.huawei.com> In-Reply-To: <130901c7ce0e$f5c54a40$fb0111ac@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2007 16:38:26.0485 (UTC) FILETIME=[0F012E50:01C7CE11] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1804; t=1185295108; x=1186159108; c=relaxed/simple; s=rtpdkim2001; 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[Sip]=20Notes=20on=20Idraft-burger-sip-info-00 |Sender:=20 |To:=20Spencer=20Dawkins=20; bh=PrdjybhmH4XCnUW+3Q/vRImtoACBiQHHiabsUbkfsdY=; b=uQ4PSBSJP6dj1XVCl4q+hBgW2K7C/se7mmZylzEiS4K39Hhdw6IxaNGh+Xzixpf27tFHS8am lufSavS83t5RjgXznFKLCB2kz6yD5swYlTWysq1PdqkrF5a/8YEyaB7w; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I was thinking the same thing. Dealing with this in the context of "features" that use it has some promise of at least demonstrating the problems with existing approaches to those that matter. Paul Spencer Dawkins wrote: > I spoke at the mike a minute ago about having this draft done in SIP, > and then Rohan suggested that BLISS would be the right place to do the > work. I would be OK with that, too, if others see it the same way. > > Dean called the question as "do something IN THIS WG", which is fair > (because that's the WG he chairs), but I would support "doing something > IN THE RIGHT WG", if the chairs and ADs think there's a better home for > the work. > > Pointing to a MEDIACTRL draft is not the right thing to do, and pointing > to a long-expired draft that people may or may not have agreed with at > the time is even worse. > > Spencer > > >> I finally got to look at draft-burger-sip-info-00. I like what I see. >> I did >> notice some nits, and am willing to provide a more formal review, but >> I support adoption of this draft as a WG deliverable, even in its >> current form. >> >> You may have noticed that the MEDIACTRL WG editors were forced to >> discuss INFO in their specifications, because we currently have one >> draft providing guidance on INFO that people seem to generally agree >> with, but it expired years ago. I >> >> Thanks, Eric, for taking this on. >> >> Spencer > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 13:33:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDOGT-00080f-H9; Tue, 24 Jul 2007 13:33:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDOGS-00080Y-05 for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 13:33:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDOGR-00080K-LH for sip@ietf.org; Tue, 24 Jul 2007 13:33:39 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDOGP-0001jn-81 for sip@ietf.org; Tue, 24 Jul 2007 13:33:37 -0400 Received: from hkaplan [67.97.210.2] by acmepacket.com with ESMTP (SMTPD-9.10) id A7DB0188; Tue, 24 Jul 2007 13:33:15 -0400 From: "Hadriel Kaplan" To: "'Eric Burger'" , "'Xavier Marjou'" References: <458913680707232145w5cd54ee6n43c15a0bcc07f774@mail.gmail.com> Subject: RE: [Sip] INFO and Content Negotiation Date: Tue, 24 Jul 2007 13:33:14 -0400 Message-ID: <036e01c7ce18$b76b7bc0$6410a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfNrXEejTNx1WiuSZ+j5lqwURy5nQAPwTwxAAq4gUA= In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 'IETF SIP' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Inline... > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com] > Sent: Tuesday, July 24, 2007 8:16 AM > To: Xavier Marjou > Cc: IETF SIP > Subject: Re: [Sip] INFO and Content Negotiation > > Indicating the package is possible; it is what Dean's draft of 4 years ago > proposed. However, it is not what is there today. Moreover, it is > doubtful > that any of the myriad INFO exploits would use the mechanism. If one is > going to upgrade one's mechanism, one might as well do the right thing. I'm actually not convinced of that. I don't think people only use INFO because it was convenient for experimentation, and that given the choice of modifying it to fix some issues vs. completely changing how they implement feature XYZ, that they would choose the latter. I think they use INFO because it achieves what they need to do in the simplest and most scalable way, and the KISS principle is strong motivation for many. In particular, for the DTMF use of INFO my guess is many vendors would be willing to add explicit negotiation, rather than doing subscribe-KPML. (so long as the negotiation itself was simple) -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 16:52:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRM2-0005Or-3A; Tue, 24 Jul 2007 16:51:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDRM0-0005Oj-JY for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 16:51:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRM0-0005Ns-9K; Tue, 24 Jul 2007 16:51:36 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDRLz-0002l4-E9; Tue, 24 Jul 2007 16:51:36 -0400 Received: from source ([192.150.11.134]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Tue, 24 Jul 2007 13:51:27 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6OKo2ot020617; Tue, 24 Jul 2007 13:50:03 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6OKpJ0c002568; Tue, 24 Jul 2007 13:51:19 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 13:51:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC Date: Tue, 24 Jul 2007 13:48:34 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22B32036@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC Thread-Index: AcfOLkcd4W3U2DmDRkKJoVjFQ5z8VQABO4Ug References: <20070719145334.2EA8B1810C50@mail.iptel.org> <20070719180614.85AB218115BC@mail.iptel.org> <20070721144803.41B4F1810C56@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com> <20070723205140.EC8031811206@mail.iptel.org> From: "Henry Sinnreich" To: "Adam Fisk" , "Jiri Kuthan" X-OriginalArrivalTime: 24 Jul 2007 20:51:18.0957 (UTC) FILETIME=[6280ADD0:01C7CE34] X-Spam-Score: -4.0 (----) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Cc: sip@ietf.org, Juha Heinanen , Jan Janak , mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1156517535==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1156517535== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CE34.6066DD19" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CE34.6066DD19 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Adam, =20 I fully agree with your positive assessment of the ICE-17 document. =20 Do you by any chance plan to also develop a test tool for testing the NAT environment and the success/failure cases, connection times, etc., to measure results? =20 Or maybe you know someone who does? =20 Thanks, Henry =20 ________________________________ From: adamfisk@gmail.com [mailto:adamfisk@gmail.com] On Behalf Of Adam Fisk Sent: Tuesday, July 24, 2007 3:08 PM To: Jiri Kuthan Cc: Henry Sinnreich; David Barrett; Jan Janak; Juha Heinanen; sip@ietf.org; mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC =20 I've followed ICE development on the sidelines for years now, and I'm currently implementing ICE 17. I've implemented what will be open source implementations of STUN and TURN, both client and server. Here are the key points I've taken away from that experience:=20 1) The patience of Jonathan and everyone else in meticulously getting to the current draft is astonishing. 2) ICE is complex as hell and a pain in the ^#* to implement. I was surprised at how hard it was, particularly for a draft that's so close to becoming an RFC.=20 3) ICE is solving a very tricky problem. I like Phillip's earlier suggestion that the draft stay in the "almost done" state like used to happen in the Routing group. I realize that's asking a lot given how much work has gone into it and how eager everyone is to finalize it. I think the problem is that standardizing NAT traversal is just hard, and hard problems are difficult to make simpler. In my implementation of ICE, I do think it could be done more simply, but I don't have concrete suggestions right now because I'm still pulling my hair out with the implementation. I'm not talking about drastic changes anywhere, but all the checklist fiddling sure takes a lot of patience to write. Simplifications might just be in the description and not necessarily the algorithm.=20 I think it's a hard enough and important enough problem that we owe it to ourselves to be even more patient with an "almost done" state that adds the final touches based on real-world feedback. I don't doubt for a second that ICE works, but it's so complex that I worry no one outside huge companies will ever implement it. That would be a huge hindrance to ICE's adoption and power.=20 -Adam ------_=_NextPart_001_01C7CE34.6066DD19 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

        Adam,

         

        I fully agree with your positive = assessment of the ICE-17 document.

         

        Do you by any chance plan to also = develop a test tool for testing the NAT environment and the success/failure = cases, connection times, etc., to measure results?

         

        Or maybe you know someone who = does?

         

        Thanks, = Henry

         

        From: adamfisk@gmail.com [mailto:adamfisk@gmail.com] On Behalf Of Adam Fisk
        Sent: Tuesday, July 24, = 2007 3:08 PM
        To: Jiri Kuthan
        Cc: Henry Sinnreich; David = Barrett; Jan Janak; Juha Heinanen; sip@ietf.org; mmusic@ietf.org
        Subject: Re: [MMUSIC] Re: = [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for = RFC

         

        I've followed = ICE development on the sidelines for years now, and I'm currently = implementing ICE 17.  I've implemented what will be open source implementations of = STUN and TURN, both client and server.  Here are the key points I've taken = away from that experience:

        1) The patience of Jonathan and everyone else in meticulously getting to = the current draft is astonishing.
        2) ICE is complex as hell and a pain in the ^#* to implement.  I = was surprised at how hard it was, particularly for a draft that's so close = to becoming an RFC.
        3) ICE is solving a very tricky problem.

        I like Phillip's earlier suggestion that the draft stay in the = "almost done" state like used to happen in the Routing group.  I = realize that's asking a lot given how much work has gone into it and how eager = everyone is to finalize it.  I think the problem is that standardizing NAT = traversal is just hard, and hard problems are difficult to make simpler.  In = my implementation of ICE, I do think it could be done more simply, but I = don't have concrete suggestions right now because I'm still pulling my hair = out with the implementation.  I'm not talking about drastic changes = anywhere, but all the checklist fiddling sure takes a lot of patience to write.  Simplifications might just be in the description and not necessarily the algorithm.

        I think it's a hard enough and important enough problem that we owe it = to ourselves to be even more patient with an "almost done" state = that adds the final touches based on real-world feedback.  I don't doubt = for a second that ICE works, but it's so complex that I worry no one outside = huge companies will ever implement it.  That would be a huge hindrance = to ICE's adoption and power.

        -Adam

        ------_=_NextPart_001_01C7CE34.6066DD19-- --===============1156517535== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1156517535==-- From sip-bounces@ietf.org Tue Jul 24 17:04:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRYa-0006Zc-5x; Tue, 24 Jul 2007 17:04:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDQfO-0007YG-2a for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 16:07:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQfN-0007Y2-Fr for sip@ietf.org; Tue, 24 Jul 2007 16:07:33 -0400 Received: from wx-out-0506.google.com ([66.249.82.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDQfM-0001si-W3 for sip@ietf.org; Tue, 24 Jul 2007 16:07:33 -0400 Received: by wx-out-0506.google.com with SMTP id h27so1825919wxd for ; Tue, 24 Jul 2007 13:07:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=n6EVJzDDLCEBdBXxOil+vFnGXpisymoA6UGcqgEui7+LTL/bP36ZRG4hpj/sNVyPHWuo4nWsdyp2kPO7HhdC6LCWT69DBXxzEIjxSxjv6t2nr4CB952aHNC82nRFPWZAaLUaQgZDSjvm/9PPX//PoSEVtrx3fUTkgxfLT90JFkQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=t7gGdNSdweZNgu94fHwt3Uzc37/DeECuCo9bCeGY+luySDhIHuirpXKrDuKm2+zxMPOFcsRZ2svhQuMMDm5NuXYc95SD6M9q7DY0bukEjPwMuswXyRu1hOmh7iKtidSn2ueG1yxtCEMGKnjzh5yrpi4R7t61Zsuuf9zzQfErmFs= Received: by 10.90.118.12 with SMTP id q12mr3760495agc.1185307652470; Tue, 24 Jul 2007 13:07:32 -0700 (PDT) Received: by 10.70.38.2 with HTTP; Tue, 24 Jul 2007 13:07:32 -0700 (PDT) Message-ID: Date: Tue, 24 Jul 2007 16:07:32 -0400 From: "Adam Fisk" To: "Jiri Kuthan" Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC In-Reply-To: <20070723205140.EC8031811206@mail.iptel.org> MIME-Version: 1.0 References: <20070719145334.2EA8B1810C50@mail.iptel.org> <20070719180614.85AB218115BC@mail.iptel.org> <20070721144803.41B4F1810C56@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com> <20070723205140.EC8031811206@mail.iptel.org> X-Google-Sender-Auth: e83d915c39d3890a X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-Mailman-Approved-At: Tue, 24 Jul 2007 17:04:34 -0400 Cc: mmusic@ietf.org, sip@ietf.org, Juha Heinanen , Henry Sinnreich , Jan Janak X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0046633270==" Errors-To: sip-bounces@ietf.org --===============0046633270== Content-Type: multipart/alternative; boundary="----=_Part_87196_32586101.1185307652344" ------=_Part_87196_32586101.1185307652344 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I've followed ICE development on the sidelines for years now, and I'm currently implementing ICE 17. I've implemented what will be open source implementations of STUN and TURN, both client and server. Here are the key points I've taken away from that experience: 1) The patience of Jonathan and everyone else in meticulously getting to the current draft is astonishing. 2) ICE is complex as hell and a pain in the ^#* to implement. I was surprised at how hard it was, particularly for a draft that's so close to becoming an RFC. 3) ICE is solving a very tricky problem. I like Phillip's earlier suggestion that the draft stay in the "almost done" state like used to happen in the Routing group. I realize that's asking a lot given how much work has gone into it and how eager everyone is to finalize it. I think the problem is that standardizing NAT traversal is just hard, and hard problems are difficult to make simpler. In my implementation of ICE, I do think it could be done more simply, but I don't have concrete suggestions right now because I'm still pulling my hair out with the implementation. I'm not talking about drastic changes anywhere, but all the checklist fiddling sure takes a lot of patience to write. Simplifications might just be in the description and not necessarily the algorithm. I think it's a hard enough and important enough problem that we owe it to ourselves to be even more patient with an "almost done" state that adds the final touches based on real-world feedback. I don't doubt for a second that ICE works, but it's so complex that I worry no one outside huge companies will ever implement it. That would be a huge hindrance to ICE's adoption and power. -Adam ------=_Part_87196_32586101.1185307652344 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I've followed ICE development on the sidelines for years now, and I'm currently implementing ICE 17.  I've implemented what will be open source implementations of STUN and TURN, both client and server.  Here are the key points I've taken away from that experience:

        1) The patience of Jonathan and everyone else in meticulously getting to the current draft is astonishing.
        2) ICE is complex as hell and a pain in the ^#* to implement.  I was surprised at how hard it was, particularly for a draft that's so close to becoming an RFC.
        3) ICE is solving a very tricky problem.

        I like Phillip's earlier suggestion that the draft stay in the "almost done" state like used to happen in the Routing group.  I realize that's asking a lot given how much work has gone into it and how eager everyone is to finalize it.  I think the problem is that standardizing NAT traversal is just hard, and hard problems are difficult to make simpler.  In my implementation of ICE, I do think it could be done more simply, but I don't have concrete suggestions right now because I'm still pulling my hair out with the implementation.  I'm not talking about drastic changes anywhere, but all the checklist fiddling sure takes a lot of patience to write.  Simplifications might just be in the description and not necessarily the algorithm.

        I think it's a hard enough and important enough problem that we owe it to ourselves to be even more patient with an "almost done" state that adds the final touches based on real-world feedback.  I don't doubt for a second that ICE works, but it's so complex that I worry no one outside huge companies will ever implement it.  That would be a huge hindrance to ICE's adoption and power.

        -Adam


        ------=_Part_87196_32586101.1185307652344-- --===============0046633270== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0046633270==-- From sip-bounces@ietf.org Tue Jul 24 17:15:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRj3-00064M-64; Tue, 24 Jul 2007 17:15:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDRj0-00063D-1t for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 17:15:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRiz-000632-Mz for sip@ietf.org; Tue, 24 Jul 2007 17:15:21 -0400 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDRiz-0006yd-AX for sip@ietf.org; Tue, 24 Jul 2007 17:15:21 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc15) with ESMTP id <200707242115200150022m4me>; Tue, 24 Jul 2007 21:15:20 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6OLFK8t011005 for ; Tue, 24 Jul 2007 17:15:20 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6OLFKBL011001; Tue, 24 Jul 2007 17:15:20 -0400 Date: Tue, 24 Jul 2007 17:15:20 -0400 Message-Id: <200707242115.l6OLFKBL011001@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <200707241605.l6OG57VQ020718@dragon.ariadne.com> (Dale.Worley@comcast.net) Subject: Re: [Sip] INFO, Mime-multipart, and Content Negotiation (oh, my!) References: <7374777208BDC7449D5620EF942325670743C97A@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF942325670743C97B@esealmw113.eemea.ericsson.se> <46A36757.7020500@nostrum.com> <200707241605.l6OG57VQ020718@dragon.ariadne.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Dale.Worley@comcast.net These issues seem to be all related. E-mail Mime can make do with Content-Type because e-mail's sole function is to present information to the user. The only information needed is "What is this?" because "What should I do with this?" is constant. In SIP, we have the Content-Disposition, with the defined values "session", "render", "alert", and "icon". This answers the question "What should I do with this?", which is independent of "What is this?". We've been quite sloppy about this issue because for most methods "What should I do with this?" is strongly implied by the method or the context or the Content-Type. But with INFO, unless there is a tightly constrained context from some non-SIP feature, there is complete decoupling between "What is this?" and "What should I do with this?". That is, any body part needs a Content-Disposition that identifies what should be done with the information (= what application the information should be delivered to). But we have no method for negotiating what Content-Dispositions are supported by a given SIP UA. So of course it doesn't work well. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 17:18:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRlm-0000Xy-1l; Tue, 24 Jul 2007 17:18:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDRlk-0000Xs-Fo for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 17:18:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRlk-0000Xk-56 for sip@ietf.org; Tue, 24 Jul 2007 17:18:12 -0400 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDRlj-00074P-PV for sip@ietf.org; Tue, 24 Jul 2007 17:18:12 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc11) with ESMTP id <20070724211810m1100546t5e>; Tue, 24 Jul 2007 21:18:10 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6OLI98t011205 for ; Tue, 24 Jul 2007 17:18:09 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6OLI9xH011201; Tue, 24 Jul 2007 17:18:09 -0400 Date: Tue, 24 Jul 2007 17:18:09 -0400 Message-Id: <200707242118.l6OLI9xH011201@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <200707241605.l6OG57VQ020718@dragon.ariadne.com> (Dale.Worley@comcast.net) Subject: Re: [Sip] INFO, Mime-multipart, and Content Negotiation (oh, my!) References: <7374777208BDC7449D5620EF942325670743C97A@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF942325670743C97B@esealmw113.eemea.ericsson.se> <46A36757.7020500@nostrum.com> <200707241605.l6OG57VQ020718@dragon.ariadne.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I sent that last message too quickly: From: Dale.Worley@comcast.net But we have no method for negotiating what Content-Dispositions are supported by a given SIP UA. So of course it doesn't work well. But as someone suggested at the microphone, if people coin new methods (starting with "X-"), those methods *can* encode "What should I do with this?" And the Allow header allows UAs to negotiate what methods are supported. I see no problem with proliferating methods, as that is no worse than proliferating Content-Dispositions. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 17:25:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRsU-0005Yi-7l; Tue, 24 Jul 2007 17:25:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDRsT-0005YY-8Z for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 17:25:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRsS-0005YQ-VA; Tue, 24 Jul 2007 17:25:08 -0400 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDRsR-0003Ns-LJ; Tue, 24 Jul 2007 17:25:08 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 4029E181124D; Tue, 24 Jul 2007 23:25:09 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 24 Jul 2007 23:25:04 +0200 To: "Adam Fisk" From: Jiri Kuthan Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC In-Reply-To: References: <20070719145334.2EA8B1810C50@mail.iptel.org> <20070719180614.85AB218115BC@mail.iptel.org> <20070721144803.41B4F1810C56@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com> <20070723205140.EC8031811206@mail.iptel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20070724212509.4029E181124D@mail.iptel.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: mmusic@ietf.org, sip@ietf.org, Juha Heinanen , Henry Sinnreich , Jan Janak X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 22:07 24/07/2007, Adam Fisk wrote: >I've followed ICE development on the sidelines for years now, and I'm currently implementing ICE 17. I've implemented what will be open source implementations of STUN and TURN, both client and server. That's marvellous news -- can you send me a pointer to that? > Here are the key points I've taken away from that experience: > >1) The patience of Jonathan and everyone else in meticulously getting to the current draft is astonishing. >2) ICE is complex as hell and a pain in the ^#* to implement. I was surprised at how hard it was, particularly for a draft that's so close to becoming an RFC. >3) ICE is solving a very tricky problem. All three points are wholeheartly easy to agree with. I would have added too ICE is the "right" solution. The question to me is whether Mr. Time and Mr. $ are not against us. That question was asked couple of meetings ago by Spencer D. in an 'sbc bar bof' -- basically fingerpointing at the NAT experience, "right" solution (IPv6) and the outcome. The concern is that by time we have ICE, everyone will have the problem solved using media relays and mass economy will make it a more viable solution than anything else. Future is generally hard to predict (that's why analysts like to predict past :-)), so I think it would be at least a proper step to document current practices (media relays) so that the IETF's picture stays grounded (whatever the risky comeout of work on "right" solutions may be.) -jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 17:28:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRw5-0000cm-9R; Tue, 24 Jul 2007 17:28:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDRw3-0000cg-31 for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 17:28:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRw2-0000cX-OI for sip@ietf.org; Tue, 24 Jul 2007 17:28:50 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDRw1-0007Eh-Hz for sip@ietf.org; Tue, 24 Jul 2007 17:28:49 -0400 Received: (qmail 24903 invoked by uid 0); 24 Jul 2007 21:28:45 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 24 Jul 2007 21:28:45 -0000 Message-ID: <006e01c7ce39$335b55f0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: , References: <7374777208BDC7449D5620EF942325670743C97A@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF942325670743C97B@esealmw113.eemea.ericsson.se><46A36757.7020500@nostrum.com><200707241605.l6OG57VQ020718@dragon.ariadne.com> <200707242118.l6OLI9xH011201@dragon.ariadne.com> Subject: Re: [Sip] INFO, Mime-multipart, and Content Negotiation (oh, my!) Date: Tue, 24 Jul 2007 23:25:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > I see no problem with proliferating methods, as that is no worse than > proliferating Content-Dispositions. > Well, for one it could cause existing proxies to Record-Route such requests as they would not know the method and would therefore be forced to assume it to be dialog creating. So there is some overhead, compared to C-D as extension point Also, in practice I would expect unknown content-dispositions to interwork better than unknown methods, especially through proxies Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 20:21:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDUd9-0005Dj-6R; Tue, 24 Jul 2007 20:21:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDUd6-0005De-V1 for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 20:21:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDUd6-0005DQ-Ia for sip@ietf.org; Tue, 24 Jul 2007 20:21:28 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDUd5-0001s8-HD for sip@ietf.org; Tue, 24 Jul 2007 20:21:28 -0400 Received: from sfs2.omr.ecl.ntt.co.jp (IDENT:mirapoint@sfs2.omr.ecl.ntt.co.jp [129.60.39.117]) by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l6P0LOxe013420; Wed, 25 Jul 2007 09:21:24 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by sfs2.omr.ecl.ntt.co.jp (MOS 3.8.4-GA) with ESMTP id ASZ53110; Wed, 25 Jul 2007 09:21:24 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l6P0LN1Q020660; Wed, 25 Jul 2007 09:21:23 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l6P0LNNg010290; Wed, 25 Jul 2007 09:21:23 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l6P0LNpr016744; Wed, 25 Jul 2007 09:21:23 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (imf0.m.ecl.ntt.co.jp [129.60.5.144]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l6P0LMJQ016734; Wed, 25 Jul 2007 09:21:23 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (webmail.ecl.ntt.co.jp [129.60.39.130]) by imf.m.ecl.ntt.co.jp (8.13.8/8.13.8) with SMTP id l6P0LMmG024461; Wed, 25 Jul 2007 09:21:22 +0900 (JST) Message-Id: <200707250021.l6P0LMmG024461@imf.m.ecl.ntt.co.jp> To: jdrosen@cisco.com Subject: Re: [Sip] comments on draft-munakata-sip-privacy-new From: Mayumi Munakata Date: Wed, 25 Jul 2007 09:21:22 +0900 X-Mailer: WebMail V3.5.1 PL3 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan, Thank you for the comments for the privacy-new draft. See inline. > Section 1: There are some additional problems worth noting: > * privacy service has to be a b2bua and thus interferes with security mechanisms that break in the face of b2bua, such as sip identity (which provides message integrity and works well here too to provide the remote side an assurance of authenticated identity, just one that is not provided), which in turn breaks dtls-srtp > > * because of the need to signal from the UA to the privacy service exactly the desired functionality, the set of functionalities possible, in terms of what is anonyzmized and what is not, is bounded and required detailed specification. Will add this in the section 1. > > >> The user agent setting the "temp-gruu" as a GRUU SHOULD set >> "Anonymous" as a display name in any header where the display name of >> the originator is set. That indicates the anonymity of the request >> to intermediaries that may invoke some services based on the >> anonymity of the call. > > Hmm, I'd prefer something explicit. There are problems with using human-readable and locale-specific text like display name to signal to automata. "Anonymous" display name is not used for explicit indication of anonymity to the intermediaries, rather this is specified to be aligned with the ACR draft. AFAIK the ACR draft explicitly states the spelling of display-name to be either "Anonymous" or "anonymous". > >> Note: The mechanism of the flag is FFS. > > From text above I thought it was presence of the Anonymous in display name, which is bad. I personally like the Privacy: id value since its effectively what everyone is using and also backwards compatible. This is based on few assumption. 1. privacy value beside "id" is not used. >> This sounds almost true, but I have heard several vendors and providers actually utilizing these values to micro manage the privacy treatment of messages, in which case overloading the semantics of "id" may be problematic when older privacy service is treating the message as noted on the slide today. 2. information beside what's inserted by the UA is not a privacy concern. >> Information readily added by the intermediaries such as Record-Route, Via etc. are not privacy sensitive. You have to be making this assumption to overload the "id", as it is possible that older privacy service would only remove the P-A-ID and forward the listed values above which are considered to be a target of privacy in RFC 3323. Anyhow, without thorough knowledge of what's really deployed in the wild, it is rather dangerous to make any assumption and overload the "id" value. > > I also think we need something to make sure the terminating UA doesn't try to render the From or P-A-ID if someone should insert. Good point. AFAIK, the Privacy header is removed when the last value for the privacy header is removed so something is needed. Having that said, you seemed to be implying that something needs to be there to convey that UAC is requesting the privacy, yet survives translation and treatment of privacy service and other intermediaries. > >> Proxy Behavior > > The draft should talk about RFC 3325 in particular. Okay. > > Nits: > > >> privacy service. This document proposes a new privacy mechanism that >> a user agent can facilitate to conceal privacy-sensitive information >> without the need for aid from a privacy service. > > This is somehwat misleading; there is a privacy service in the form of turn servers and proxies. Right, I think we simply copied the terminology from the RFC3323, will modify the text to be more concise. > >> The protection of network >> privacy (e.g., topology hiding) is outside the scope of this >> document. > > You need to clarify what this means. Will do. > >> A user agent wanting to obtain functional anonymous URI SHOULD >> support and SHOULD utilize the Global Routable User Agent URI (GRUU) >> mechanism. > > Isn't this going to need to be a MUST? I guess we will rewrite it to say, URI SHOULD support and if support MUST utilize the GRUU mechanism. > >> response for a "temp-gruu" URI parameter, which provides the desired >> privacy property. > provides URI with the desired property Will fix. > >> It is assumed that a user agent is either manually or automatically >> configured through means such as a configuration framework with one >> or more STUN relay servers. > > terminology has changed again; these are now called TURN servers once more. Will fix. Thanks, Mayumi > > > > Thanks, > Jonathan R. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 24 23:52:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDXvZ-0002R7-FB; Tue, 24 Jul 2007 23:52:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDXvW-0002Qw-3P for sip-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 23:52:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDXvV-0002Qo-Pi for sip@ietf.org; Tue, 24 Jul 2007 23:52:41 -0400 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDXvV-0002SI-GD for sip@ietf.org; Tue, 24 Jul 2007 23:52:41 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc12) with ESMTP id <20070725035240m1200fo1see>; Wed, 25 Jul 2007 03:52:40 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6P3qd8t007766 for ; Tue, 24 Jul 2007 23:52:39 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6P3qdYB007762; Tue, 24 Jul 2007 23:52:39 -0400 Date: Tue, 24 Jul 2007 23:52:39 -0400 Message-Id: <200707250352.l6P3qdYB007762@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <006e01c7ce39$335b55f0$0601a8c0@BEMBUSTER> (jbemmel@zonnet.nl) Subject: Re: [Sip] INFO, Mime-multipart, and Content Negotiation (oh, my!) References: <7374777208BDC7449D5620EF942325670743C97A@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF942325670743C97B@esealmw113.eemea.ericsson.se><46A36757.7020500@nostrum.com><200707241605.l6OG57VQ020718@dragon.ariadne.com> <200707242118.l6OLI9xH011201@dragon.ariadne.com> <006e01c7ce39$335b55f0$0601a8c0@BEMBUSTER> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Jeroen van Bemmel" > I see no problem with proliferating methods, as that is no worse than > proliferating Content-Dispositions. Well, for one it could cause existing proxies to Record-Route such requests as they would not know the method and would therefore be forced to assume it to be dialog creating. So there is some overhead, compared to C-D as extension point IIRC, there's a set of rules that avoid Record-Routing except in the first request or two of a dialog. Scott Lawrence once explained them to me, and I checked them, and they're method-independent (as one would expect). Also, in practice I would expect unknown content-dispositions to interwork better than unknown methods, especially through proxies Proxies shouldn't care about the method. SBCs might be more trouble, but I expect quality SBCs to be method-agnostic too. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 25 01:14:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDZCm-0004iH-9E; Wed, 25 Jul 2007 01:14:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDZCk-0004iC-PQ for sip-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 01:14:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDZCk-0004i4-4X for sip@ietf.org; Wed, 25 Jul 2007 01:14:34 -0400 Received: from web56508.mail.re3.yahoo.com ([66.196.97.37]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IDZCj-0007jC-Jd for sip@ietf.org; Wed, 25 Jul 2007 01:14:33 -0400 Received: (qmail 85401 invoked by uid 60001); 25 Jul 2007 05:14:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=BM59kkdoKyZ/OyI+tXMMa0IPW61U628DOtM8Bgk7tzWtaBPZXbDYbZBdeCf0k4A3CMoNKsloDnQY9JqdMmctRQ8cFuyOIclqWsF2H3rr699Nqh9PpSFGtQlNuM9TSX7+OjlO4RuVM5nsxFnFeKGOmybxHh7UkSALgsexQHr9MHA=; X-YMail-OSG: a_J5898VM1mJZdtnyFchS3MNxpdwart38_to9ZWUv2W.D5tHhuN9KoLj0NxoInDls8Run3sSygEmesrm2vdy1Idgqg6_I3n6rjQaUWd_q_gNGpesGuL_89EBItYP Received: from [202.54.176.11] by web56508.mail.re3.yahoo.com via HTTP; Tue, 24 Jul 2007 22:14:33 PDT Date: Tue, 24 Jul 2007 22:14:33 -0700 (PDT) From: sengottuvelan srirangan To: sip@ietf.org MIME-Version: 1.0 Message-ID: <363005.85035.qm@web56508.mail.re3.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Sip] Doubt about ACK and BYE X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1597068789==" Errors-To: sip-bounces@ietf.org --===============1597068789== Content-Type: multipart/alternative; boundary="0-785377551-1185340473=:85035" Content-Transfer-Encoding: 8bit --0-785377551-1185340473=:85035 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi SIP-experts, I have doubt in a specific Scenario where SIP client is set to send INVITE messages via outbound proxy. The setup is like below: SIP-client 1---------------------------SIP outbound---------------------SIP proxy2---------------SIP client2 proxy1 Here SIP client1 is registered with Proxy2 and set outbound proxy as proxy1. Outbound proxy1 is set not to include its ip address in the Record-Route header. After SIP 200 OK message is received in SIP-client1 which is still sending ACK and BYE messages via outbound proxy1 instead proxy2. Could you anyone clarify that how can i send ACK and BYE messages to Registered proxy2 instead outbound proxy1? Regards Sengottuvelan --------------------------------- Shape Yahoo! in your own image. Join our Network Research Panel today! --0-785377551-1185340473=:85035 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
        Hi SIP-experts,
         
        I have doubt in a specific Scenario where SIP client is set to send INVITE messages via outbound proxy. The setup is like below:
         
         
        SIP-client 1---------------------------SIP outbound---------------------SIP proxy2---------------SIP client2
                                                        proxy1
         
        Here SIP client1 is registered with Proxy2 and set outbound proxy as proxy1. Outbound proxy1 is set not to include its ip address in the Record-Route header. After SIP 200 OK message is received in SIP-client1 which is still sending ACK and BYE messages via outbound proxy1 instead proxy2.
         
        Could you anyone clarify that how can i send ACK and BYE messages to Registered proxy2 instead outbound proxy1?
         
        Regards
        Sengottuvelan
         
         
         

        Shape Yahoo! in your own image. Join our Network Research Panel today! --0-785377551-1185340473=:85035-- --===============1597068789== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1597068789==-- From sip-bounces@ietf.org Wed Jul 25 03:08:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDaym-000495-Ez; Wed, 25 Jul 2007 03:08:16 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDayl-00048y-Fl for sip-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 03:08:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDayh-00048c-PY for sip@ietf.org; Wed, 25 Jul 2007 03:08:11 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDayg-0006OI-G3 for sip@ietf.org; Wed, 25 Jul 2007 03:08:11 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l6P77qcZ007941; Wed, 25 Jul 2007 02:07:58 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 02:07:53 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 09:07:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Correction: WGLC for draft-ietf-sip-outbound Date: Wed, 25 Jul 2007 09:07:50 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180014B69A8@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Correction: WGLC for draft-ietf-sip-outbound Thread-Index: AcfN9O74LL3HQnuCTPC/DcLlOrRQywAbXRXQ References: <46928F5F.3080502@softarmor.com> <46966F52.9040004@softarmor.com> <5D1A7985295922448D5550C94DE2918001473D89@DEEXC1U01.de.lucent.com> From: "DRAGE, Keith \(Keith\)" To: "Robert Sparks" X-OriginalArrivalTime: 25 Jul 2007 07:07:51.0036 (UTC) FILETIME=[837FFBC0:01C7CE8A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip@ietf.org, Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Just to indicate that what I don't think we want during the middle of the WGLC is a -11 version. I think we need all comments made during this last call to be made against -10. What I would like is a compilation of all the comments made like we did for GRUU - they are still up on softarmor. I would consider that we could start plugging the proposed resolution into such a document. I don't know what Dean's availability is in this respect, but I haven't got time to devote to this until late next week.=20 Regards Keith > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 > Sent: Tuesday, July 24, 2007 2:17 PM > To: DRAGE, Keith (Keith) > Cc: sip@ietf.org; Cullen Jennings; Rohan Mahy > Subject: Re: [Sip] RE: Correction: WGLC for draft-ietf-sip-outbound >=20 > Keith/Rohan - >=20 > There's a moderate list of changes we already know are going=20 > to be made to the document. >=20 > Everyone who wasn't in Chicago's Monday SIP meeting should=20 > look at=20 > http://www3.ietf.org/proceedings/07jul/slides/sip-3.pdf for=20 > the bigger ones. > Rohan has indicated a few smaller ones on list. >=20 > Would it be possible to get a list of the known expected=20 > changes in one place? >=20 > RjS >=20 > On Jul 23, 2007, at 11:23 PM, DRAGE, Keith ((Keith)) wrote: >=20 > > A reminder of the ongoing WGLC on the above document > > > > This WGLC period runs through IETF and hopefully close=20 > August 6, 2007. > > > > That gives you about a week after the end of IETF - please schedule=20 > > some time for doing this. > > > > Regards > > > > Keith > > > > > >> -----Original Message----- > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > >> Sent: Thursday, July 12, 2007 7:14 PM > >> To: Dean Willis > >> Cc: sip@ietf.org; Cullen Jennings; DRAGE, Keith (Keith) > >> Subject: Correction: WGLC for draft-ietf-sip-outbound > >> > >> Dean Willis wrote: > >>> I'd like to start a long working group last call for: > >>> > >>> http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-09.txt > >>> > >> > >> My error. This should have referred to draft-ietf-sip-outbound-10,=20 > >> not -09. It was busy working its way through the posting=20 > system and I=20 > >> grabbed a pointer to the wrong one. > >> > >> Sorry about that, folks. > >> > >> -- > >> Dean > >> > >> > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 25 03:08:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDaz1-0004Cr-JY; Wed, 25 Jul 2007 03:08:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDaz0-0004Cm-ON for sip-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 03:08:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDaz0-0004Ce-ES for sip@ietf.org; Wed, 25 Jul 2007 03:08:30 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDayy-0006Oo-VV for sip@ietf.org; Wed, 25 Jul 2007 03:08:30 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6P7871u023543; Wed, 25 Jul 2007 02:08:08 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 02:08:10 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 09:08:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Two minor Max-Breadth comments Date: Wed, 25 Jul 2007 09:08:04 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180014B69AB@DEEXC1U01.de.lucent.com> In-Reply-To: <200707241500.l6OF0bML016019@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Two minor Max-Breadth comments Thread-Index: AcfOA3JWYPRasPdYQc+ZoAP3LWHQjAAY9Odg References: <46A6113A.9000500@nostrum.com> <200707241500.l6OF0bML016019@dragon.ariadne.com> From: "DRAGE, Keith \(Keith\)" To: "Dale Worley" , X-OriginalArrivalTime: 25 Jul 2007 07:08:04.0411 (UTC) FILETIME=[8B78D8B0:01C7CE8A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org How does the UAC cancelling the request help. Surely all we end up with is the CANCEL request desperatly trying to catch up with all the propagated INVITE requests. I see nothing in the transaction model that helps it catch up, and I suspect (based on experience in non-SIP systems) that it never will in most people's implementations. It will always be pretty much the same number of steps behind. Regards Keith=20 > -----Original Message----- > From: Dale Worley [mailto:worley@dworley.hsd1.ma.comcast.net]=20 > Sent: Tuesday, July 24, 2007 4:01 PM > To: sip@ietf.org > Subject: Re: [Sip] Two minor Max-Breadth comments >=20 > From: Adam Roach >=20 > During today's meeting, a point was raised surrounding whether the=20 > max-breadth approach should limit the total number of=20 > requests or merely=20 > the number of requests in flight at once. The statement is=20 > that limiting=20 > only the ones in flight simultaneously ultimately results=20 > in the same=20 > number of messages as would result without the extension. >=20 > While there has been a token mention of Timer C, I think we're=20 > underestimating the mitigating effect of Timer C. >=20 > As an additional point, I think it's worth pointing out=20 > that the victim,=20 > if they recognize they are being subjected to this style=20 > of attack, can=20 > tear the entire tree down fairly rapidly by throwing a=20 > 600-class response. >=20 > Also, the UAC, if it is not perverse, will ultimately cancel=20 > the request. >=20 > Dale >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 25 03:08:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDaym-000495-Ez; Wed, 25 Jul 2007 03:08:16 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDayl-00048y-Fl for sip-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 03:08:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDayh-00048c-PY for sip@ietf.org; Wed, 25 Jul 2007 03:08:11 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDayg-0006OI-G3 for sip@ietf.org; Wed, 25 Jul 2007 03:08:11 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l6P77qcZ007941; Wed, 25 Jul 2007 02:07:58 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 02:07:53 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 09:07:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: Correction: WGLC for draft-ietf-sip-outbound Date: Wed, 25 Jul 2007 09:07:50 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180014B69A8@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Correction: WGLC for draft-ietf-sip-outbound Thread-Index: AcfN9O74LL3HQnuCTPC/DcLlOrRQywAbXRXQ References: <46928F5F.3080502@softarmor.com> <46966F52.9040004@softarmor.com> <5D1A7985295922448D5550C94DE2918001473D89@DEEXC1U01.de.lucent.com> From: "DRAGE, Keith \(Keith\)" To: "Robert Sparks" X-OriginalArrivalTime: 25 Jul 2007 07:07:51.0036 (UTC) FILETIME=[837FFBC0:01C7CE8A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip@ietf.org, Cullen Jennings , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Just to indicate that what I don't think we want during the middle of the WGLC is a -11 version. I think we need all comments made during this last call to be made against -10. What I would like is a compilation of all the comments made like we did for GRUU - they are still up on softarmor. I would consider that we could start plugging the proposed resolution into such a document. I don't know what Dean's availability is in this respect, but I haven't got time to devote to this until late next week.=20 Regards Keith > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 > Sent: Tuesday, July 24, 2007 2:17 PM > To: DRAGE, Keith (Keith) > Cc: sip@ietf.org; Cullen Jennings; Rohan Mahy > Subject: Re: [Sip] RE: Correction: WGLC for draft-ietf-sip-outbound >=20 > Keith/Rohan - >=20 > There's a moderate list of changes we already know are going=20 > to be made to the document. >=20 > Everyone who wasn't in Chicago's Monday SIP meeting should=20 > look at=20 > http://www3.ietf.org/proceedings/07jul/slides/sip-3.pdf for=20 > the bigger ones. > Rohan has indicated a few smaller ones on list. >=20 > Would it be possible to get a list of the known expected=20 > changes in one place? >=20 > RjS >=20 > On Jul 23, 2007, at 11:23 PM, DRAGE, Keith ((Keith)) wrote: >=20 > > A reminder of the ongoing WGLC on the above document > > > > This WGLC period runs through IETF and hopefully close=20 > August 6, 2007. > > > > That gives you about a week after the end of IETF - please schedule=20 > > some time for doing this. > > > > Regards > > > > Keith > > > > > >> -----Original Message----- > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > >> Sent: Thursday, July 12, 2007 7:14 PM > >> To: Dean Willis > >> Cc: sip@ietf.org; Cullen Jennings; DRAGE, Keith (Keith) > >> Subject: Correction: WGLC for draft-ietf-sip-outbound > >> > >> Dean Willis wrote: > >>> I'd like to start a long working group last call for: > >>> > >>> http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-09.txt > >>> > >> > >> My error. This should have referred to draft-ietf-sip-outbound-10,=20 > >> not -09. It was busy working its way through the posting=20 > system and I=20 > >> grabbed a pointer to the wrong one. > >> > >> Sorry about that, folks. > >> > >> -- > >> Dean > >> > >> > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 25 03:08:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDaz1-0004Cr-JY; Wed, 25 Jul 2007 03:08:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDaz0-0004Cm-ON for sip-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 03:08:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDaz0-0004Ce-ES for sip@ietf.org; Wed, 25 Jul 2007 03:08:30 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDayy-0006Oo-VV for sip@ietf.org; Wed, 25 Jul 2007 03:08:30 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6P7871u023543; Wed, 25 Jul 2007 02:08:08 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 02:08:10 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 09:08:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Two minor Max-Breadth comments Date: Wed, 25 Jul 2007 09:08:04 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180014B69AB@DEEXC1U01.de.lucent.com> In-Reply-To: <200707241500.l6OF0bML016019@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Two minor Max-Breadth comments Thread-Index: AcfOA3JWYPRasPdYQc+ZoAP3LWHQjAAY9Odg References: <46A6113A.9000500@nostrum.com> <200707241500.l6OF0bML016019@dragon.ariadne.com> From: "DRAGE, Keith \(Keith\)" To: "Dale Worley" , X-OriginalArrivalTime: 25 Jul 2007 07:08:04.0411 (UTC) FILETIME=[8B78D8B0:01C7CE8A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org How does the UAC cancelling the request help. Surely all we end up with is the CANCEL request desperatly trying to catch up with all the propagated INVITE requests. I see nothing in the transaction model that helps it catch up, and I suspect (based on experience in non-SIP systems) that it never will in most people's implementations. It will always be pretty much the same number of steps behind. Regards Keith=20 > -----Original Message----- > From: Dale Worley [mailto:worley@dworley.hsd1.ma.comcast.net]=20 > Sent: Tuesday, July 24, 2007 4:01 PM > To: sip@ietf.org > Subject: Re: [Sip] Two minor Max-Breadth comments >=20 > From: Adam Roach >=20 > During today's meeting, a point was raised surrounding whether the=20 > max-breadth approach should limit the total number of=20 > requests or merely=20 > the number of requests in flight at once. The statement is=20 > that limiting=20 > only the ones in flight simultaneously ultimately results=20 > in the same=20 > number of messages as would result without the extension. >=20 > While there has been a token mention of Timer C, I think we're=20 > underestimating the mitigating effect of Timer C. >=20 > As an additional point, I think it's worth pointing out=20 > that the victim,=20 > if they recognize they are being subjected to this style=20 > of attack, can=20 > tear the entire tree down fairly rapidly by throwing a=20 > 600-class response. >=20 > Also, the UAC, if it is not perverse, will ultimately cancel=20 > the request. >=20 > Dale >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 25 03:16:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDb6Q-0008Vc-5q; Wed, 25 Jul 2007 03:16:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDb6O-0008VX-RU for sip-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 03:16:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDb6O-0008VP-Dx for sip@ietf.org; Wed, 25 Jul 2007 03:16:08 -0400 Received: from cluster-f.mailcontrol.com ([85.119.2.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDb6N-0002F0-DU for sip@ietf.org; Wed, 25 Jul 2007 03:16:08 -0400 Received: from rly11f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly11f.srv.mailcontrol.com (MailControl) with ESMTP id l6P7G5ES023320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Jul 2007 08:16:05 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly11f.srv.mailcontrol.com (MailControl) id l6P7Fd1I022995 for sip@ietf.org; Wed, 25 Jul 2007 08:15:39 +0100 Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12]) by rly11f-eth0.srv.mailcontrol.com (envelope-sender attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id l6P7Fdnw022984; Wed, 25 Jul 2007 08:15:39 +0100 (BST) Received: from ExBE03.nasstar-t1.net ([10.2.10.102]) by exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 08:15:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Doubt about ACK and BYE Date: Wed, 25 Jul 2007 08:15:38 +0100 Message-ID: <165288C2C3E29449AFDE022DD10CC47106120971@ExBE03.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Doubt about ACK and BYE Thread-Index: AcfOesqXHutlXbWPRauw+V+7afvyIQAD96Mw From: "Attila Sipos" To: "sengottuvelan srirangan" , X-OriginalArrivalTime: 25 Jul 2007 07:15:53.0087 (UTC) FILETIME=[A2D320F0:01C7CE8B] X-Scanned-By: MailControl A-07-08-00 (www.mailcontrol.com) on 10.70.1.121 X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0541968353==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0541968353== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CE8B.A220015C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CE8B.A220015C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 It is some configuration issue (or maybe a bug) in the SIP client 1 I think. =20 Once the call is established and the route has been learnt (using Record-Route), any new requests should only be sent to the proxies on that learnt route. Unfortunately I have heard that some SIP clients break this rule and send EVERY message to the outbound proxy even when the outbound proxy did not add a Record-Route header. =20 >>Could you anyone clarify that how can i send ACK and BYE messages to Registered proxy2 instead outbound proxy1? Of course, it should only get sent to proxy 2 if proxy 2 had added a Record-Route. Like I say, to fix the problem, I think it's either a bug or configuration issue for SIP client 1. =20 Regards, Attila =20 =20 ________________________________ From: sengottuvelan srirangan [mailto:sengottuvelan_s@yahoo.com]=20 Sent: 25 July 2007 06:15 To: sip@ietf.org Subject: [Sip] Doubt about ACK and BYE=20 Hi SIP-experts, =20 I have doubt in a specific Scenario where SIP client is set to send INVITE messages via outbound proxy. The setup is like below: SIP-client 1---------------------------SIP outbound---------------------SIP proxy2---------------SIP client2 &n! bsp; proxy1 =20 Here SIP client1 is registered with Proxy2 and set outbound proxy as proxy1. Outbound proxy1 is set not to include its ip address in the Record-Route header. After SIP 200 OK message is received in SIP-client1 which is still sending ACK and BYE messages via outbound proxy1 instead proxy2. =20 Could you anyone clarify that how can i send ACK and BYE messages to Registered proxy2 instead outbound proxy1? =20 Regards Sengottuvelan =20 =20 =20 ________________________________ Shape Yahoo! in your own image. Join our Network Research Panel today! =20 ------_=_NextPart_001_01C7CE8B.A220015C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
         
        It is some configuration issue (or maybe a bug) = in the SIP=20 client 1 I think.
         
        Once the call is established and the route has = been learnt=20 (using Record-Route), any new
        requests should only be sent to the proxies on = that=20 learnt route.
        Unfortunately I have heard that some SIP = clients break this=20 rule and send EVERY message to
        the outbound proxy even when=20 the outbound proxy did not add a Record-Route = header.
         
        >>Could you anyone=20 clarify that how can i send ACK and BYE messages to Registered proxy2 = instead=20 outbound proxy1?
        Of course, it should only get sent to proxy 2 = if proxy 2=20 had added a Record-Route.
        Like I say, to fix the problem, I think it's = either a bug=20 or configuration issue for SIP client 1.
         
        Regards,

        Attila
         
         

        From: sengottuvelan srirangan=20 [mailto:sengottuvelan_s@yahoo.com]
        Sent: 25 July 2007=20 06:15
        To: sip@ietf.org
        Subject: [Sip] Doubt about = ACK and=20 BYE

        Hi SIP-experts,
         
        I have doubt in a specific Scenario where SIP client = is set to=20 send INVITE messages via outbound proxy. The setup is like=20 below:
        SIP-client=20 1---------------------------SIP outbound---------------------SIP=20 proxy2---------------SIP client2
                   =             &= nbsp;           &n= bsp;       &n!=20 bsp;    proxy1
         
        Here SIP=20 client1 is registered with Proxy2 and set outbound proxy as proxy1. = Outbound proxy1 is set not to include its ip address in the Record-Route = header.=20 After SIP 200 OK message is received in SIP-client1 which is = still=20 sending ACK and BYE messages via outbound proxy1 instead=20 proxy2.
         
        Could you=20 anyone clarify that how can i send ACK and BYE messages to Registered = proxy2=20 instead outbound proxy1?
         
        Regards
        Sengottuvelan
         
         
         

        Shape Yahoo! in your own image. Join=20 our Network Research Panel today! ------_=_NextPart_001_01C7CE8B.A220015C-- --===============0541968353== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0541968353==-- From sip-bounces@ietf.org Wed Jul 25 08:44:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDgDT-0004Te-EM; Wed, 25 Jul 2007 08:43:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDgDR-0004TW-Iy for sip-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 08:43:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDgDR-0004TN-54 for sip@ietf.org; Wed, 25 Jul 2007 08:43:45 -0400 Received: from web56504.mail.re3.yahoo.com ([66.196.97.33]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IDgDQ-0006fg-Ho for sip@ietf.org; Wed, 25 Jul 2007 08:43:45 -0400 Received: (qmail 55685 invoked by uid 60001); 25 Jul 2007 12:43:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=AmaQrPQ6vQC2nKikXBBCWtBxPwQq9o5XZu9Uym43+zn60PUQSicbbhwtOJqP8PW/f4F02sSjzOtUUt+f8hjSpfO48a9vOwwkQHSC9z+Ny+VSQlDUxyvMtE1VV+gObKWLGsrx/By4PEBzwXYd/xH7GbC9ZQuYTdrpHSueKgcQoy8=; X-YMail-OSG: DcFX8TcVM1nZC01Mcv25zUxLBxRIF5GTddQdWHWPaOWvKajvV.LadEiigF7Yah9CaYZWc0SAOl69Cg_xi6S6xEQKgISLmp4wEq3CLLxIioyyOnKEzzk- Received: from [202.54.176.11] by web56504.mail.re3.yahoo.com via HTTP; Wed, 25 Jul 2007 05:43:44 PDT Date: Wed, 25 Jul 2007 05:43:44 -0700 (PDT) From: sengottuvelan srirangan Subject: RE: [Sip] Doubt about ACK and BYE To: Attila Sipos , sip@ietf.org In-Reply-To: <165288C2C3E29449AFDE022DD10CC47106120971@ExBE03.nasstar-t1.net> MIME-Version: 1.0 Message-ID: <404680.55439.qm@web56504.mail.re3.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2023962049==" Errors-To: sip-bounces@ietf.org --===============2023962049== Content-Type: multipart/alternative; boundary="0-388966037-1185367424=:55439" Content-Transfer-Encoding: 8bit --0-388966037-1185367424=:55439 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Attila, The problem is got fixed after changing the client1(as you suggested). Thanks. Regards Sengottuvelan Attila Sipos wrote: It is some configuration issue (or maybe a bug) in the SIP client 1 I think. Once the call is established and the route has been learnt (using Record-Route), any new requests should only be sent to the proxies on that learnt route. Unfortunately I have heard that some SIP clients break this rule and send EVERY message to the outbound proxy even when the outbound proxy did not add a Record-Route header. >>Could you anyone clarify that how can i send ACK and BYE messages to Registered proxy2 instead outbound proxy1? Of course, it should only get sent to proxy 2 if proxy 2 had added a Record-Route. Like I say, to fix the problem, I think it's either a bug or configuration issue for SIP client 1. Regards, Attila --------------------------------- From: sengottuvelan srirangan [mailto:sengottuvelan_s@yahoo.com] Sent: 25 July 2007 06:15 To: sip@ietf.org Subject: [Sip] Doubt about ACK and BYE Hi SIP-experts, I have doubt in a specific Scenario where SIP client is set to send INVITE messages via outbound proxy. The setup is like below: SIP-client 1---------------------------SIP outbound---------------------SIP proxy2---------------SIP client2 &n! bsp; proxy1 Here SIP client1 is registered with Proxy2 and set outbound proxy as proxy1. Outbound proxy1 is set not to include its ip address in the Record-Route header. After SIP 200 OK message is received in SIP-client1 which is still sending ACK and BYE messages via outbound proxy1 instead proxy2. Could you anyone clarify that how can i send ACK and BYE messages to Registered proxy2 instead outbound proxy1? Regards Sengottuvelan --------------------------------- Shape Yahoo! in your own image. Join our Network Research Panel today! --------------------------------- Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. --0-388966037-1185367424=:55439 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
        Hi Attila,
         
        The problem is got fixed after changing the client1(as you suggested).
         
        Thanks.
         
        Regards
        Sengottuvelan

        Attila Sipos <attila.sipos@vegastream.com> wrote:
         
        It is some configuration issue (or maybe a bug) in the SIP client 1 I think.
         
        Once the call is established and the route has been learnt (using Record-Route), any new
        requests should only be sent to the proxies on that learnt route.
        Unfortunately I have heard that some SIP clients break this rule and send EVERY message to
        the outbound proxy even when the outbound proxy did not add a Record-Route header.
         
        >>Could you anyone clarify that how can i send ACK and BYE messages to Registered proxy2 instead outbound proxy1?
        Of course, it should only get sent to proxy 2 if proxy 2 had added a Record-Route.
        Like I say, to fix the problem, I think it's either a bug or configuration issue for SIP client 1.
         
        Regards,

        Attila
         
         

        From: sengottuvelan srirangan [mailto:sengottuvelan_s@yahoo.com]
        Sent: 25 July 2007 06:15
        To: sip@ietf.org
        Subject: [Sip] Doubt about ACK and BYE

        Hi SIP-experts,
         
        I have doubt in a specific Scenario where SIP client is set to send INVITE messages via outbound proxy. The setup is like below:
        SIP-client 1---------------------------SIP outbound---------------------SIP proxy2---------------SIP client2
                                                   &n! bsp;    proxy1
         
        Here SIP client1 is registered with Proxy2 and set outbound proxy as proxy1. Outbound proxy1 is set not to include its ip address in the Record-Route header. After SIP 200 OK message is received in SIP-client1 which is still sending ACK and BYE messages via outbound proxy1 instead proxy2.
         
        Could you anyone clarify that how can i send ACK and BYE messages to Registered proxy2 instead outbound proxy1?
         
        Regards
        Sengottuvelan
         
         
         
        Shape Yahoo! in your own image. Join our Network Research Panel today!

        Boardwalk for $500? In 2007? Ha!
        Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. --0-388966037-1185367424=:55439-- --===============2023962049== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2023962049==-- From sip-bounces@ietf.org Wed Jul 25 10:09:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDhYN-00077J-44; Wed, 25 Jul 2007 10:09:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDhPc-0001bt-MF for sip-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 10:00:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDhPc-0001bg-9t for sip@ietf.org; Wed, 25 Jul 2007 10:00:24 -0400 Received: from wx-out-0506.google.com ([66.249.82.235]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDhPb-00044K-Fo for sip@ietf.org; Wed, 25 Jul 2007 10:00:24 -0400 Received: by wx-out-0506.google.com with SMTP id h27so176064wxd for ; Wed, 25 Jul 2007 07:00:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Iqig/Yg8X8OXxVqOya+XdIuWz2Z0BAKGnD4/Wx8MVfkKu2/PY5D9hgz7HUt71Vzn8rc5x7+avcXpvQfArHvKkllu457/+Hmc30hhptvlPizzhrNhZFGNejGKwKBgUN1aXdsjjjg34N5hzqF2F97arqjBIR0dXN/6yDYLxuD/lBI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Fp4dilU1tKDa9q6qmwg2ChU4ikal1PxOq+tODSV/d5SIqy1LiNIHYQcKJz0tbzZvhIgr9NqcxCVfFK/qBwO3bKHywjaD6z1kcUsAOixItpAtWwmb/jPr/vaCbTV+zP3PXJIk0MVzv5MPB5zOVY+dOlZ73erwRNoluogIF/P7WhY= Received: by 10.90.116.6 with SMTP id o6mr430269agc.1185372021363; Wed, 25 Jul 2007 07:00:21 -0700 (PDT) Received: by 10.70.38.2 with HTTP; Wed, 25 Jul 2007 07:00:21 -0700 (PDT) Message-ID: Date: Wed, 25 Jul 2007 10:00:21 -0400 From: "Adam Fisk" To: "Henry Sinnreich" Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22B32036@namail5.corp.adobe.com> MIME-Version: 1.0 References: <20070719145334.2EA8B1810C50@mail.iptel.org> <20070719180614.85AB218115BC@mail.iptel.org> <20070721144803.41B4F1810C56@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com> <20070723205140.EC8031811206@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22B32036@namail5.corp.adobe.com> X-Google-Sender-Auth: 3fae490a26934a3b X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 X-Mailman-Approved-At: Wed, 25 Jul 2007 10:09:25 -0400 Cc: mmusic@ietf.org, sip@ietf.org, Juha Heinanen , David Barrett , Jan Janak X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0579111132==" Errors-To: sip-bounces@ietf.org --===============0579111132== Content-Type: multipart/alternative; boundary="----=_Part_93954_1009523.1185372021190" ------=_Part_93954_1009523.1185372021190 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline We do plan on doing that eventually, Henry, but it will be awhile. We're a 2 coder shop, so these things take us forever, but we will definitely do that at some point. It just might not be in 2007, honestly, so it would likely be too late to be useful for the WG. -Adam On 7/24/07, Henry Sinnreich wrote: > > Adam, > > > > I fully agree with your positive assessment of the ICE-17 document. > > > > Do you by any chance plan to also develop a test tool for testing the NAT > environment and the success/failure cases, connection times, etc., to > measure results? > > > > Or maybe you know someone who does? > > > > Thanks, Henry > > > ------------------------------ > > *From:* adamfisk@gmail.com [mailto:adamfisk@gmail.com] *On Behalf Of *Adam > Fisk > *Sent:* Tuesday, July 24, 2007 3:08 PM > *To:* Jiri Kuthan > *Cc:* Henry Sinnreich; David Barrett; Jan Janak; Juha Heinanen; sip@ietf.org; > mmusic@ietf.org > *Subject:* Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE > deploymentdatabefore LC for RFC > > > > I've followed ICE development on the sidelines for years now, and I'm > currently implementing ICE 17. I've implemented what will be open source > implementations of STUN and TURN, both client and server. Here are the key > points I've taken away from that experience: > > 1) The patience of Jonathan and everyone else in meticulously getting to > the current draft is astonishing. > 2) ICE is complex as hell and a pain in the ^#* to implement. I was > surprised at how hard it was, particularly for a draft that's so close to > becoming an RFC. > 3) ICE is solving a very tricky problem. > > I like Phillip's earlier suggestion that the draft stay in the "almost > done" state like used to happen in the Routing group. I realize that's > asking a lot given how much work has gone into it and how eager everyone is > to finalize it. I think the problem is that standardizing NAT traversal is > just hard, and hard problems are difficult to make simpler. In my > implementation of ICE, I do think it could be done more simply, but I don't > have concrete suggestions right now because I'm still pulling my hair out > with the implementation. I'm not talking about drastic changes anywhere, > but all the checklist fiddling sure takes a lot of patience to write. > Simplifications might just be in the description and not necessarily the > algorithm. > > I think it's a hard enough and important enough problem that we owe it to > ourselves to be even more patient with an "almost done" state that adds the > final touches based on real-world feedback. I don't doubt for a second that > ICE works, but it's so complex that I worry no one outside huge companies > will ever implement it. That would be a huge hindrance to ICE's adoption > and power. > > -Adam > ------=_Part_93954_1009523.1185372021190 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline We do plan on doing that eventually, Henry, but it will be awhile.  We're a 2 coder shop, so these things take us forever, but we will definitely do that at some point.  It just might not be in 2007, honestly, so it would likely be too late to be useful for the WG.

        -Adam


        On 7/24/07, Henry Sinnreich <hsinnrei@adobe.com> wrote:

        Adam,

         

        I fully agree with your positive assessment of the ICE-17 document.

         

        Do you by any chance plan to also develop a test tool for testing the NAT environment and the success/failure cases, connection times, etc., to measure results?

         

        Or maybe you know someone who does?

         

        Thanks, Henry

         

        From: adamfisk@gmail.com [mailto: adamfisk@gmail.com] On Behalf Of Adam Fisk
        Sent: Tuesday, July 24, 2007 3:08 PM
        To: Jiri Kuthan
        Cc: Henry Sinnreich; David Barrett; Jan Janak; Juha Heinanen; sip@ietf.org; mmusic@ietf.org
        Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC

         

        I've followed ICE development on the sidelines for years now, and I'm currently implementing ICE 17.  I've implemented what will be open source implementations of STUN and TURN, both client and server.  Here are the key points I've taken away from that experience:

        1) The patience of Jonathan and everyone else in meticulously getting to the current draft is astonishing.
        2) ICE is complex as hell and a pain in the ^#* to implement.  I was surprised at how hard it was, particularly for a draft that's so close to becoming an RFC.
        3) ICE is solving a very tricky problem.

        I like Phillip's earlier suggestion that the draft stay in the "almost done" state like used to happen in the Routing group.  I realize that's asking a lot given how much work has gone into it and how eager everyone is to finalize it.  I think the problem is that standardizing NAT traversal is just hard, and hard problems are difficult to make simpler.  In my implementation of ICE, I do think it could be done more simply, but I don't have concrete suggestions right now because I'm still pulling my hair out with the implementation.  I'm not talking about drastic changes anywhere, but all the checklist fiddling sure takes a lot of patience to write.  Simplifications might just be in the description and not necessarily the algorithm.

        I think it's a hard enough and important enough problem that we owe it to ourselves to be even more patient with an "almost done" state that adds the final touches based on real-world feedback.  I don't doubt for a second that ICE works, but it's so complex that I worry no one outside huge companies will ever implement it.  That would be a huge hindrance to ICE's adoption and power.

        -Adam


        ------=_Part_93954_1009523.1185372021190-- --===============0579111132== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0579111132==-- From sip-bounces@ietf.org Wed Jul 25 14:50:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlw2-00069E-0X; Wed, 25 Jul 2007 14:50:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDlw0-000699-Lh for sip-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 14:50:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlw0-000691-AS for sip@ietf.org; Wed, 25 Jul 2007 14:50:08 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDlvz-0006NF-NA for sip@ietf.org; Wed, 25 Jul 2007 14:50:08 -0400 Received: from dhcp-16b2.ietf69.org ([130.129.22.178]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1IDlvz-0000IW-3w for sip@ietf.org; Wed, 25 Jul 2007 13:50:07 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP List From: Dean Willis Date: Wed, 25 Jul 2007 13:49:53 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: [Sip] Ruminations on the SIP extension model X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There is a deep philosophical divide about how the SIP protocol should be formed and extended. One branch of this debate holds that SIP's role is as a transport protocol with a very few primitives and application logic handled at the data level. In this model, new applications can generally be built without changing the protocol or its syntax. The second branch holds that the SIP protocol itself should be intimately tied to the application, with new functionality represented as new message types. Yet another branch of the debate holds that SIP is only for setting up and tearing down "sessions", and that information outside of that needed to set up or tear down a "session" is rightfully part of the "session" and not in the domain of the SIP protocol itself. Let's consider the user-stimulus over-SIP question (which is all mixed up with the emulating-DTMF-for-telephony question). The "reusable primitive" camp might define a way to use an extensible mechanism (like SIP Events or a new INFO negotiation) and define user- stimulus delivery using a MIME object and use the extensible mechanism's negotiation feature to figure out whether a peer supports the usage (note that this is what we did with KPML). The "extend SIP" camp might define a new SIP non-invite method type (maybe a method called "USERSTIM") that would carry a fixed payload and be negotiated using basic SIP feature negotiation mechanism (the "Allow" and "Supported" header field). One might note that once we have a few hundred SIP method types that these header fields are going to get relatively large. The "it's just a session" camp might define a "user stimulus session", describe it using SDP, and use INVITE to establish a session over which user-stimulus information would be transmitted. There has been a certain lack of clarity about the this extension model in SIP's past, resulting in some extensions that re-use a single SIP method (Event packages, INFO) and others that add new SIP methods (MESSAGE) and others that establish sessions (MSRP chat, Real- time text). It could be argued that this has made for a more complex protocol suite than might have occurred had any single methodology been followed exclusively. It seems to me that we have a quandary -- if we accept the "Add a new method type for each application" model, then we should deprecate RFC 3265, instead adding new SIP methods like SUBSCRIBE-KPML and NOTIFY- KPML. If we accept the "SIP as transport" model, then we have to ask if we need a way to negotiate application context for transported data within an INVITE-bounded dialog (like INFO "packages"). If we accept the "it's just a session" model then everything we've done with event packages, INFO, MESSAGE, and so needs to be replaced with a proper session-based mechanism (presence sessions, ISUP sessions, messaging sessions, and so on). Or we could do nothing, accept that we have a rather muddled protocol, and just try and give guidance on when to use each extension modality. Specifically, as the ongoing body-type-context debate has pointed out, while we can say what body types we support, we don't currently have a good way for a describe what a message containing a body of a specific type is likely to mean in the current context, and the jury is out as to whether we have reliable means of deducing a context. We do have RFC 4485, which seems to me to do a fair job of guiding us on new header fields but doesn't say enough about body types (and doesn't even begin to discuss the body-type-context question beyond a vague mention of Content-Disposition), and which provides little useful guidance on when to use new methods vs. when to use events. What do we want to do here? Is there a way to get a clear position, or are we going to be debating bodies vs. header fields vs. method- types forever? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 25 14:51:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlx5-0007GZ-AQ; Wed, 25 Jul 2007 14:51:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDlx4-0007GU-1M for sip-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 14:51:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlx3-0007GM-Nv for sip@ietf.org; Wed, 25 Jul 2007 14:51:13 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDlx2-0001WT-C5 for sip@ietf.org; Wed, 25 Jul 2007 14:51:13 -0400 Received: from dhcp-16b2.ietf69.org ([130.129.22.178]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1IDlwu-0000IW-AE; Wed, 25 Jul 2007 13:51:04 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Wed, 25 Jul 2007 13:51:00 -0500 To: IETF SIP List X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Cullen Jennings , Keith Drage , "Christer Holmberg \(JO/LMF\)" Subject: [Sip] INFO and what to do about it X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org We have a clear consensus in the WG that "something needs to be done about INFO." In this week's SIP meeting, we discussed a draft by Eric Burger that proposes formally restricting the usage of INFO to the existing RFCs that exercise it. Several people noted that just making this limitation in a void is insufficient -- that we also need to explain the fundamental architectural problem and give guidance on how to more effectively solve the kinds of problems that people have been trying to solve using INFO. We also have a contingent that thinks that we should fix info by adding a negotiation mechanism and registration procedure for INFO usages, much as SIP events have been done. Others think that rather than an extensible mechanism using one message type (INFO), we should instead extend SIP as needed with new message types, further blurring the line between protocol and application (which I'll admit is already pretty blurry in SIP's case). Note that this is a follow-on mechanism to the first step of documenting NOT using INFO. It seems to me that this means we need to clarify the SIP extension model, which I'll come back to later. At this week's meeting, there was a majority (at least a 2 to 1 ratio, and more by some counts) in favor of taking the path of Eric's draft and declaring a formal moratorium on new usages of INFO. This is pretty close to "rough consensus", but not so close that I was willing to declare consensus without taking the question to the list. So here's a proposal: I suggest we accept the model of Eric's draft, but ask him to add more depth to the architectural discussion and ask Christer to contribute some text in this direction, as he has some very definite ideas of what needs to be addressed. This leaves us with clear direction on not extending INFO with new usages or a negotiation mechanism. Please discuss this on-list, especially if you object or have a counter-proposal. This leaves open the question of clarifying the extension model of SIP, which I will raise in another thread to make following the discussion easier. -- Dean Willis SIP co-chair _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 25 14:57:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDm3S-0005MU-16; Wed, 25 Jul 2007 14:57:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDm3Q-0005MK-T4 for sip-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 14:57:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDm3Q-0005M5-JF for sip@ietf.org; Wed, 25 Jul 2007 14:57:48 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDm3Q-0001lA-0Z for sip@ietf.org; Wed, 25 Jul 2007 14:57:48 -0400 Received: from dhcp-32fb.ietf69.org (dhcp-32fb.ietf69.org [130.129.50.251]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6PIvf4I020946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2007 13:57:42 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <46A79D24.90507@nostrum.com> Date: Wed, 25 Jul 2007 13:57:40 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Ruminations on the SIP extension model References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.50.251 is authenticated by a trusted mechanism) X-Spam-Score: -1.4 (-) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 7/25/07 1:49 PM, Dean Willis wrote: > It seems to me that we have a quandary -- if we accept the "Add a new > method type for each application" model, then we should deprecate RFC > 3265, instead adding new SIP methods like SUBSCRIBE-KPML and NOTIFY-KPML. No, not really. In pursuing such a model, you're effectively arguing that INVITE should be split into INVITE-AUDIO, INVITE-VIDEO, INVITE-AUDIO-VIDEO, etc. Why didn't we? Because pretty much all the SIP protocol semantics are identical regardless of what kind of INVITE session you're setting up. Identically, just about all of the SIP protocol semantics are identical for SUBSCRIBE and NOTIFY, _regardless_ of the event package being used. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jul 25 23:04:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDtei-0006Zg-Ks; Wed, 25 Jul 2007 23:04:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDteh-0006ZI-2o for sip-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 23:04:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDteg-0006ZA-O0; Wed, 25 Jul 2007 23:04:46 -0400 Received: from smtpauth01.csee.onr.siteprotect.com ([64.26.60.145]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDteg-0007c9-3o; Wed, 25 Jul 2007 23:04:46 -0400 Received: from cornfed (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth01.csee.onr.siteprotect.com (Postfix) with ESMTP id 868641C802D; Wed, 25 Jul 2007 21:49:26 -0500 (CDT) From: "Frank W. Miller" To: "'Jiri Kuthan'" , "'Henry Sinnreich'" , "'David Barrett'" , "'Jan Janak'" , "'Juha Heinanen'" Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICEdeploymentdatabefore LC for RFC Date: Wed, 25 Jul 2007 21:04:43 -0600 Message-ID: <00d601c7cf31$b81c5480$6901a8c0@cornfed> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <20070723205140.EC8031811206@mail.iptel.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: sip@ietf.org, mmusic@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org For those that may not know, another example of this is IAX2 which is currently under review for publication by the IETF. This protocol clearly competes with SIP at least on some fronts. It may be difficult for new protocols to emerge, particularly with there is such huge momentum behind one, but it can happen. FM -----Original Message----- From: Jiri Kuthan [mailto:jiri@iptel.org] Sent: Monday, July 23, 2007 2:38 PM To: Henry Sinnreich; David Barrett; Jan Janak; Juha Heinanen Cc: sip@ietf.org; mmusic@ietf.org Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICEdeploymentdatabefore LC for RFC At 19:10 21/07/2007, Henry Sinnreich wrote: >I fully agree with Jiri that this is an IETF problem and not an ICE >problem. >ICE-17 is a great document, no doubt about it. > >What happens however of someone finds an innovative approach that may >work better? Will it be rejected because it will not be RFC standards >compliant? I don't think so, IETF is having a history of working on competing standards, jabber and simple being a prominent and recent example thereof. I think that's actually with current IETF's size and dynamics a fairly good strategy to eliminate single points of failure. -jiri >What could an innovator tell customers about a solution that works >better but is not IETF ICE RFC standards compliant? > >Henry > >-----Original Message----- >From: Jiri Kuthan [mailto:jiri@iptel.org] >Sent: Saturday, July 21, 2007 9:48 AM >To: David Barrett; 'Jan Janak'; 'Juha Heinanen' >Cc: sip@ietf.org; mmusic@ietf.org >Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE >deploymentdatabefore LC for RFC > >At 20:05 19/07/2007, David Barrett wrote: >>> -----Original Message----- >>> From: Jiri Kuthan [mailto:jiri@iptel.org] >>> Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment >databefore >>> LC for RFC >>> >>> So I think that the right course of action is that folks doubting ICE >>> reliability >>> make their case (by that I mean specific arguments rather than >emotional >>> debates >>> about red-colored nails and other hardware). >> >>Er, my "specific argument" is "until it's been proven to work, it >hasn't >>been proven to work". It's tautological, but no less true for it. >> >>Indeed, if you're *not* doubting ICE, why aren't you? > >Hi David, > >I'm not entirely sure what is the step you are suggesting? > >I think ICE is architecturally right answer to the right problem. >Notwithstanding that, there are certainly some things I prefer >differently (e.g., the infamous debate about proactive hole punching) >or may turn out to be bugs. I think though that the key problem at >this point is of institutional nature. In the IETF language, "hasn't >been proven to work" is adequate to "lacking running code" and this >appears to be a phenomen which is indeed occuring in the IETF and >is not unique to ICE. > >The question is how to get this fixed? > >Some other standardization bodies enjoying the amount of contributions >and complexity as the IETF is enjoying now (S in SIP does not really >stand for Simple), proceed with 'after-fact filters', in that they >produce the initial specs faster and later produce 'profiles' which >separate what has proved and what less. Plus -bis versions are produced >for whatever appears worth puttting effort in it (i.e., for which there >is running code and field evidence of improvement need).This could be >an approach which may be more feasible in today's IETF's dimension than > >trying to get back to historical roots. > >-jiri > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 26 01:09:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDvbH-0006D1-L9; Thu, 26 Jul 2007 01:09:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDvbE-0006CT-US for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 01:09:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDvbE-0006CH-81 for sip@ietf.org; Thu, 26 Jul 2007 01:09:20 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDvbC-0003rB-GG for sip@ietf.org; Thu, 26 Jul 2007 01:09:19 -0400 Received: by py-out-1112.google.com with SMTP id f31so1450541pyh for ; Wed, 25 Jul 2007 22:09:18 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=VQEEsZBFrfuPfiGERLVwmv0dygUZAktzkKA7gXaV9ib5b6HBPUFLFg/pVQ+l52uSFIgfQBqJbFNCQfYTu3659nQOO3BkB8hm8kTV7x1X3R2wWMXDphW6e4rBMS2jEFZWe0JNEQaVJJ9ZdbX6EsaFhsHvXTHs8IagyoemEuNF0Dg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Cp7Ra+PqpRyUmuG1gBAXMZwFBWjz/e8Gd3/ILRnDKPq3c6F9x4HXFzVnt+kzttkxEi2KGeItZq3OQs5zVyTEtHERoM8vS0K9g1yNWOxjGMSDlp53YV48d+jy0W5Zj5QKg5hlO9FSsdnIR2D1VPPpXCQNvRDKmiVBREpzIUTtkmo= Received: by 10.65.121.9 with SMTP id y9mr2325966qbm.1185426557302; Wed, 25 Jul 2007 22:09:17 -0700 (PDT) Received: by 10.65.254.11 with HTTP; Wed, 25 Jul 2007 22:09:17 -0700 (PDT) Message-ID: <66cd252f0707252209u54028dbfr52cc6da8fdc51794@mail.gmail.com> Date: Thu, 26 Jul 2007 15:09:17 +1000 From: "Hisham Khartabil" To: "vishal jogi" Subject: Re: [Sip] Event - list subscribe In-Reply-To: <66fe674b0707190030n63781e1ao5d2ff69fede430d9@mail.gmail.com> MIME-Version: 1.0 References: <66fe674b0707190030n63781e1ao5d2ff69fede430d9@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0328893192==" Errors-To: sip-bounces@ietf.org --===============0328893192== Content-Type: multipart/alternative; boundary="----=_Part_128485_10279305.1185426557266" ------=_Part_128485_10279305.1185426557266 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline This is incorrect behaviour by the RLS. The list certainly exists. It just happens to be empty. A 2xx response to the SUBSCRIBE followed by a NOTIFY with the appropriate payload is what I would consider to be the correct behaviour. Thanks, Hisham On 19/07/07, vishal jogi wrote: > > Hi, > I have one doubt. > > i m subscribing to RLS uri, > which is refering one Resource-list which doesn't have any > mean it's blank > > server is sending 404 as response for Subscribe, can anyone tell me it's > correct behaviour of server, > as that is existing > > Thanks, > Vishal... > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------=_Part_128485_10279305.1185426557266 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
        This is incorrect behaviour by the RLS. The list certainly exists. It just happens to be empty. A 2xx response to the SUBSCRIBE followed by a NOTIFY with the appropriate payload is what I would consider to be the correct behaviour.
         
        Thanks,
        Hisham

         
        On 19/07/07, vishal jogi <vishaljogi@gmail.com> wrote:
        Hi,
        I have one doubt.
         
        i m subscribing to RLS uri,
        which is refering one Resource-list which doesn't have any <entry>
        mean it's blank <LIST>
         
        server is sending 404 as response for Subscribe, can anyone tell me it's correct behaviour of server,
        as that <LIST> is existing
         
        Thanks,
        Vishal...

        _______________________________________________
        Sip mailing list   https://www1.ietf.org/mailman/listinfo/sip
        This list is for NEW development of the core SIP Protocol
        Use sip-implementors@cs.columbia.edu for questions on current sip
        Use sipping@ietf.org for new developments on the application of sip

        ------=_Part_128485_10279305.1185426557266-- --===============0328893192== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0328893192==-- From sip-bounces@ietf.org Thu Jul 26 02:48:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDx8I-0002gc-PF; Thu, 26 Jul 2007 02:47:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IDx8G-0002gS-Et for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 02:47:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDx8C-0002gE-Fq for sip@ietf.org; Thu, 26 Jul 2007 02:47:28 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDx8B-0005QC-Gr for sip@ietf.org; Thu, 26 Jul 2007 02:47:28 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6Q6lOY24187; Thu, 26 Jul 2007 06:47:25 GMT 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 Subject: RE: [Sip] Ruminations on the SIP extension model Date: Thu, 26 Jul 2007 01:47:20 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437115C58FA7@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ruminations on the SIP extension model Thread-Index: AcfO7KrOtaEE+aSMQhOFiT0nsvyLzQAXVe1A References: From: "Brian Stucker" To: "Dean Willis" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean, I think you're looking at this all wrong. I believe your "camps" below don't reflect what's really going on. Most people who develop using SIP do not have a full understanding of how it really works, nor do they have time to figure it out. They have a stack that gives them some APIs of varying granularity that they must use to create the feature they need to make their deadlines. Some get it right, some get overwhelmed by the complexity of the protocol and make a mistake, others don't care as long as their test plans execute successfully. Generally speaking the philosophy they employ "the path of least (or near-least) resistance". INFO for carrying user-stimulus/DTMF is a great example of this. I can pretty much tell you what happened to get us to where we are today. Designer A: I need to carry some DTMF digits from the client to my voicemail server so I can enter my password. I don't want to mess with RTP because that's harder to do, so I'll do it in SIP since it's easier to code for me. All I need is a quickie in-band message to the gateway to tell it to play some tone and I'll let the gateway guy who has to deal with RTP and codecs anyhow figure it out from there. I'll use INFO since it's handy. Nobody has defined this that I know of (or I have to work with some legacy device) so I'll create my own message body type and just throw it in there. If someone doesn't understand it they'll just drop it. All of the devices I have to test with for this feature (today) have agreed to support this mechanism so I'm golden. Besides, now it's in SIP so I can have my proxy do things with the digits in the future if I want. Designer B: I need to carry some DTMF digits from the client to my voicemail server so I can enter my password. I already have code that handles voice packets, so rather than try to mess with all of that crazy SIP stuff, I'll just jam something into the RTP stream to tell the other end to play DTMF tone X. I'll use RFC-2833. If someone doesn't understand it they'll just drop it. Nobody needs to route off of these digits, so there's no risk in not carrying this in SIP. All of the devices I have to test with for this feature (today) have agreed to support this mechanism so I'm golden. Repeat designer A 2-4 times in semi-parallel, and throw a designer B in there and you have what we have today for DTMF. Contrast this with RFC-3265. Not only did it describe a general mechanism, but it clearly lays out a way forward for new applications that is simple and understandable to the average reader. The mechanism is widely supported in SIP stack APIs. Designer A will use it because it's already there and they can figure it out (although what goes into the message bodies may still vary somewhat). Designer B will use it too because their device probably has an easier to use API these days to make it happen. It's the path of least resistance and it's a good mechanism, so we win. You don't see INVITE-AUDIO or SUBSCRIBE-KPML because it's counter-intuitive and more difficult to implement. INFO is easy to understand, it's sitting there in their stack API, and they don't have to do too much to make it work. You put bits in one end and they pop out the other end, no muss, no fuss. Metaphorically speaking, applications are nouns, not verbs. Protocols only need to contain a very rudimentary set of verbs to facilitate transporting all the rest of the 'parts of speech' so to speak (HTTP is another great example of this at work). The real problem is that if we tell people what not to do (ala INFO) without giving them an easy way of doing it correctly, then they're very likely to ignore the advice given to them. Again, this is where I think 3265 got it right. Regards, Brian > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Wednesday, July 25, 2007 1:50 PM > To: IETF SIP List > Subject: [Sip] Ruminations on the SIP extension model >=20 > There is a deep philosophical divide about how the SIP=20 > protocol should be formed and extended. One branch of this=20 > debate holds that SIP's role is as a transport protocol with=20 > a very few primitives and application logic handled at the=20 > data level. In this model, new applications can generally be=20 > built without changing the protocol or its syntax. The second=20 > branch holds that the SIP protocol itself should be=20 > intimately tied to the application, with new functionality=20 > represented as new message types. Yet another branch of the=20 > debate holds that SIP is only for setting up and tearing down=20 > "sessions", and that information outside of that needed to=20 > set up or tear down a "session" is rightfully part of the=20 > "session" and not in the domain of the SIP protocol itself. >=20 > Let's consider the user-stimulus over-SIP question (which is=20 > all mixed up with the emulating-DTMF-for-telephony question). >=20 > The "reusable primitive" camp might define a way to use an=20 > extensible mechanism (like SIP Events or a new INFO=20 > negotiation) and define user- stimulus delivery using a MIME=20 > object and use the extensible mechanism's negotiation feature=20 > to figure out whether a peer supports the usage (note that=20 > this is what we did with KPML). >=20 > The "extend SIP" camp might define a new SIP non-invite=20 > method type (maybe a method called "USERSTIM") that would=20 > carry a fixed payload and be negotiated using basic SIP=20 > feature negotiation mechanism (the "Allow" and "Supported"=20 > header field). One might note that once we have a few hundred=20 > SIP method types that these header fields are going to get=20 > relatively large. >=20 > The "it's just a session" camp might define a "user stimulus=20 > session", describe it using SDP, and use INVITE to establish=20 > a session over which user-stimulus information would be transmitted. >=20 > There has been a certain lack of clarity about the this=20 > extension model in SIP's past, resulting in some extensions=20 > that re-use a single SIP method (Event packages, INFO) and=20 > others that add new SIP methods (MESSAGE) and others that=20 > establish sessions (MSRP chat, Real- time text). It could be=20 > argued that this has made for a more complex protocol suite=20 > than might have occurred had any single methodology been=20 > followed exclusively. >=20 >=20 > It seems to me that we have a quandary -- if we accept the=20 > "Add a new method type for each application" model, then we=20 > should deprecate RFC 3265, instead adding new SIP methods=20 > like SUBSCRIBE-KPML and NOTIFY- KPML. If we accept the "SIP=20 > as transport" model, then we have to ask if we need a way to=20 > negotiate application context for transported data within an=20 > INVITE-bounded dialog (like INFO "packages"). If we accept=20 > the "it's just a session" model then everything we've done=20 > with event packages, INFO, MESSAGE, and so needs to be=20 > replaced with a proper session-based mechanism (presence=20 > sessions, ISUP sessions, messaging sessions, and so on). >=20 > Or we could do nothing, accept that we have a rather muddled=20 > protocol, and just try and give guidance on when to use each=20 > extension modality. >=20 > Specifically, as the ongoing body-type-context debate has=20 > pointed out, while we can say what body types we support, we=20 > don't currently have a good way for a describe what a message=20 > containing a body of a specific type is likely to mean in the=20 > current context, and the jury is out as to whether we have=20 > reliable means of deducing a context. >=20 > We do have RFC 4485, which seems to me to do a fair job of=20 > guiding us on new header fields but doesn't say enough about=20 > body types (and doesn't even begin to discuss the=20 > body-type-context question beyond a vague mention of=20 > Content-Disposition), and which provides little useful=20 > guidance on when to use new methods vs. when to use events. >=20 > What do we want to do here? Is there a way to get a clear=20 > position, or are we going to be debating bodies vs. header=20 > fields vs. method- types forever? >=20 > -- > Dean >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 26 07:12:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE1GJ-0005DV-Aj; Thu, 26 Jul 2007 07:12:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IE1GH-0005BM-QX for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 07:12:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE1GH-0005As-FN for sip@ietf.org; Thu, 26 Jul 2007 07:12:05 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE1GF-0002XB-Py for sip@ietf.org; Thu, 26 Jul 2007 07:12:05 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP for sip@ietf.org; Thu, 26 Jul 2007 13:12:02 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jul 2007 13:12:02 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: [Sip] comments on draft-munakata-sip-privacy-new Date: Thu, 26 Jul 2007 13:12:01 +0200 Message-Id: <9886E5FCA6D76549A3011068483A4BD411772E@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on draft-munakata-sip-privacy-new Thread-Index: AcfPdcs561G24spWSyCnxkH5slBTCA== From: "Jesske, R" To: X-OriginalArrivalTime: 26 Jul 2007 11:12:02.0230 (UTC) FILETIME=[CAB48560:01C7CF75] X-Spam-Score: -1.0 (-) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dear Mayumi et all, Your draft says: 8. Proxy Behavior When a proxy receives a SIP message containing a privacy flag, the proxy compliant with this specification MUST NOT add any information that may reveal something about the sender that is irrelevant to routing unless the proxy knows that such information will be deleted before it leaves the boundary of the Trust Domain[RFC3324]. A proxy MUST NOT modify the privacy flag, if present. Does this text allows networks that are due to regulation which have to = provide at least within the trusted Domain a Asserted Identity?=20 It looks that it is so. Could we spell out this explicitly? And we should refer to RFC 3325 as already mentioned in an other mail. What we should also to take into consideration is the case of ACR. As you wrote already in Section 7.2 a indication showing that the = economisation of the user identity were done at least by the UAC. If the network provides ACR at least there must be a mechanism to = identity such cases too.=20 I think we should at least mention the relation to this mechanism. And = what could be done to fulfil the requirements of ACR. Best Regards Roland Deutsche Telekom AG=20 T-Com, Zentrum Technik Einf=FChrung=20 Roland Jesske=20 Gateways, Protokolle, Konvergenz, TE33-6=20 Deutsche-Telekom-Allee 1, 64295 Darmstadt, Raum 314(Besucheradresse)=20 Postfach, 64307 Darmstadt (Postanschrift)=20 06151 83-5940 (Tel.)=20 06151 83-4577 (Fax)=20 E-Mail: r.jesske@t-com.net=20 http://www.t-com.de Registerrechtliche Unternehmensangaben:=20 Deutsche Telekom AG Aufsichtsrat: Dr. Klaus Zumwinkel (Vorsitzender) Vorstand: Ren=E9 Obermann (Vorsitzender), Dr. Karl-Gerhard Eick = (stellvertretender Vorsit-zender), Hamid Akhavan, Timotheus H=F6ttges, = Thomas Sattelberger=20 Handelsregister: Amtsgericht Bonn HRB 6794,=20 Sitz der Gesellschaft: Bonn=20 WEEE-Reg.-Nr.: DE50478376=20 ***************************************************************=20 Deutsche Telekom AG=20 Supervisory Board: Dr. Klaus Zumwinkel (Chairman)=20 Board of Management: Ren=E9 Obermann (Chairman),=20 Dr. Karl-Gerhard Eick (Deputy Chairman),=20 Hamid Akhavan, Timotheus H=F6ttges,=20 Lothar Pauly, Thomas Sattelberger=20 Commercial register: Amtsgericht Bonn HRB 6794,=20 corporate seat: Bonn=20 WEEEreg.no: DE50478376=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 26 10:00:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE3t0-00012o-30; Thu, 26 Jul 2007 10:00:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IE3sx-00012i-Sr for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 10:00:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE3sx-00012a-Ib for sip@ietf.org; Thu, 26 Jul 2007 10:00:11 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE3sw-000617-8k for sip@ietf.org; Thu, 26 Jul 2007 10:00:11 -0400 Received: from dhcp-16b2.ietf69.org ([130.129.22.178]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1IE3sv-0001TW-KB; Thu, 26 Jul 2007 09:00:09 -0500 In-Reply-To: <46A79D24.90507@nostrum.com> References: <46A79D24.90507@nostrum.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <770DB056-F390-4D74-84C5-403AE53A1864@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Ruminations on the SIP extension model Date: Thu, 26 Jul 2007 08:59:59 -0500 To: Adam Roach X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 25, 2007, at 1:57 PM, Adam Roach wrote: > On 7/25/07 1:49 PM, Dean Willis wrote: >> It seems to me that we have a quandary -- if we accept the "Add a >> new method type for each application" model, then we should >> deprecate RFC 3265, instead adding new SIP methods like SUBSCRIBE- >> KPML and NOTIFY-KPML. > > No, not really. > > In pursuing such a model, you're effectively arguing that INVITE > should be split into INVITE-AUDIO, INVITE-VIDEO, INVITE-AUDIO- > VIDEO, etc. Why didn't we? Because pretty much all the SIP protocol > semantics are identical regardless of what kind of INVITE session > you're setting up. > > Identically, just about all of the SIP protocol semantics are > identical for SUBSCRIBE and NOTIFY, _regardless_ of the event > package being used. Well, personally I'm in the "reuseable primitives" camp, and I believe you are too (as 3265 is a shining example of this approach). But other people have very different beliefs. Note that at least one person suggested at the mic during the discussion of Eric's draft that each different thing that is likely to be done with INFO should instead be done with a different new method "per thing". Note also that one of the main contributors prior to RFC 2543 broke with the community over the BYE method, as he (IIRC) believed that the way to end a session was to stop sending media. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 26 10:00:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE3tU-0001EQ-6s; Thu, 26 Jul 2007 10:00:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IE3tT-0001BX-2r for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 10:00:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE3tS-00019j-8y for sip@ietf.org; Thu, 26 Jul 2007 10:00:42 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE3tQ-00061n-Li for sip@ietf.org; Thu, 26 Jul 2007 10:00:42 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6QE0bS02795; Thu, 26 Jul 2007 14:00:38 GMT 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 Subject: RE: [Sip] Ruminations on the SIP extension model Date: Thu, 26 Jul 2007 09:00:20 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF11696F30@zrc2hxm0.corp.nortel.com> In-reply-to: <6FC4416DDE56C44DA0AEE67BC7CA437115C58FA7@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ruminations on the SIP extension model Thread-Index: AcfO7KrOtaEE+aSMQhOFiT0nsvyLzQAXVe1AABDJFlA= References: <6FC4416DDE56C44DA0AEE67BC7CA437115C58FA7@zrc2hxm2.corp.nortel.com> From: "Francois Audet" To: "Brian Stucker" , "Dean Willis" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org To top it off, the designers you describe might have actually read RFC 2976 which states the following "example uses" for INFO: - Carrying DTMF digits generated during a SIP session.=20 > -----Original Message----- > From: Stucker, Brian (RICH1:AR00)=20 > Sent: Wednesday, July 25, 2007 23:47 > To: Dean Willis; IETF SIP List > Subject: RE: [Sip] Ruminations on the SIP extension model >=20 > Dean, >=20 > I think you're looking at this all wrong. I believe your=20 > "camps" below don't reflect what's really going on. >=20 > Most people who develop using SIP do not have a full=20 > understanding of how it really works, nor do they have time=20 > to figure it out. They have a stack that gives them some APIs=20 > of varying granularity that they must use to create the=20 > feature they need to make their deadlines. Some get it right,=20 > some get overwhelmed by the complexity of the protocol and=20 > make a mistake, others don't care as long as their test plans=20 > execute successfully. Generally speaking the philosophy they=20 > employ "the path of least (or near-least) resistance". >=20 > INFO for carrying user-stimulus/DTMF is a great example of=20 > this. I can pretty much tell you what happened to get us to=20 > where we are today. >=20 > Designer A: I need to carry some DTMF digits from the client=20 > to my voicemail server so I can enter my password. I don't=20 > want to mess with RTP because that's harder to do, so I'll do=20 > it in SIP since it's easier to code for me. All I need is a=20 > quickie in-band message to the gateway to tell it to play=20 > some tone and I'll let the gateway guy who has to deal with=20 > RTP and codecs anyhow figure it out from there. I'll use INFO=20 > since it's handy. Nobody has defined this that I know of (or=20 > I have to work with some legacy device) so I'll create my own=20 > message body type and just throw it in there. If someone=20 > doesn't understand it they'll just drop it. All of the=20 > devices I have to test with for this feature > (today) have agreed to support this mechanism so I'm golden.=20 > Besides, now it's in SIP so I can have my proxy do things=20 > with the digits in the future if I want. >=20 > Designer B: I need to carry some DTMF digits from the client=20 > to my voicemail server so I can enter my password. I already=20 > have code that handles voice packets, so rather than try to=20 > mess with all of that crazy SIP stuff, I'll just jam=20 > something into the RTP stream to tell the other end to play=20 > DTMF tone X. I'll use RFC-2833. If someone doesn't understand=20 > it they'll just drop it. Nobody needs to route off of these=20 > digits, so there's no risk in not carrying this in SIP. All=20 > of the devices I have to test with for this feature (today)=20 > have agreed to support this mechanism so I'm golden. >=20 > Repeat designer A 2-4 times in semi-parallel, and throw a=20 > designer B in there and you have what we have today for DTMF. >=20 > Contrast this with RFC-3265. Not only did it describe a=20 > general mechanism, but it clearly lays out a way forward for=20 > new applications that is simple and understandable to the=20 > average reader. The mechanism is widely supported in SIP=20 > stack APIs. Designer A will use it because it's already there=20 > and they can figure it out (although what goes into the=20 > message bodies may still vary somewhat). Designer B will use=20 > it too because their device probably has an easier to use API=20 > these days to make it happen. It's the path of least=20 > resistance and it's a good mechanism, so we win. >=20 > You don't see INVITE-AUDIO or SUBSCRIBE-KPML because it's=20 > counter-intuitive and more difficult to implement. INFO is=20 > easy to understand, it's sitting there in their stack API,=20 > and they don't have to do too much to make it work. You put=20 > bits in one end and they pop out the other end, no muss, no fuss. >=20 > Metaphorically speaking, applications are nouns, not verbs.=20 > Protocols only need to contain a very rudimentary set of=20 > verbs to facilitate transporting all the rest of the 'parts=20 > of speech' so to speak (HTTP is another great example of this=20 > at work). >=20 > The real problem is that if we tell people what not to do=20 > (ala INFO) without giving them an easy way of doing it=20 > correctly, then they're very likely to ignore the advice=20 > given to them. Again, this is where I think > 3265 got it right. >=20 > Regards, > Brian >=20 > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Wednesday, July 25, 2007 1:50 PM > > To: IETF SIP List > > Subject: [Sip] Ruminations on the SIP extension model > >=20 > > There is a deep philosophical divide about how the SIP=20 > protocol should=20 > > be formed and extended. One branch of this debate holds that SIP's=20 > > role is as a transport protocol with a very few primitives and=20 > > application logic handled at the data level. In this model, new=20 > > applications can generally be built without changing the=20 > protocol or=20 > > its syntax. The second branch holds that the SIP protocol itself=20 > > should be intimately tied to the application, with new=20 > functionality=20 > > represented as new message types. Yet another branch of the debate=20 > > holds that SIP is only for setting up and tearing down=20 > "sessions", and=20 > > that information outside of that needed to set up or tear down a=20 > > "session" is rightfully part of the "session" and not in=20 > the domain of=20 > > the SIP protocol itself. > >=20 > > Let's consider the user-stimulus over-SIP question (which=20 > is all mixed=20 > > up with the emulating-DTMF-for-telephony question). > >=20 > > The "reusable primitive" camp might define a way to use an=20 > extensible=20 > > mechanism (like SIP Events or a new INFO > > negotiation) and define user- stimulus delivery using a MIME object=20 > > and use the extensible mechanism's negotiation feature to=20 > figure out=20 > > whether a peer supports the usage (note that this is what=20 > we did with=20 > > KPML). > >=20 > > The "extend SIP" camp might define a new SIP non-invite method type=20 > > (maybe a method called "USERSTIM") that would carry a fixed payload=20 > > and be negotiated using basic SIP feature negotiation=20 > mechanism (the=20 > > "Allow" and "Supported" > > header field). One might note that once we have a few hundred SIP=20 > > method types that these header fields are going to get relatively=20 > > large. > >=20 > > The "it's just a session" camp might define a "user=20 > stimulus session",=20 > > describe it using SDP, and use INVITE to establish a session over=20 > > which user-stimulus information would be transmitted. > >=20 > > There has been a certain lack of clarity about the this extension=20 > > model in SIP's past, resulting in some extensions that=20 > re-use a single=20 > > SIP method (Event packages, INFO) and others that add new=20 > SIP methods=20 > > (MESSAGE) and others that establish sessions (MSRP chat, Real- time=20 > > text). It could be argued that this has made for a more complex=20 > > protocol suite than might have occurred had any single methodology=20 > > been followed exclusively. > >=20 > >=20 > > It seems to me that we have a quandary -- if we accept the=20 > > "Add a new method type for each application" model, then we=20 > > should deprecate RFC 3265, instead adding new SIP methods=20 > > like SUBSCRIBE-KPML and NOTIFY- KPML. If we accept the "SIP=20 > > as transport" model, then we have to ask if we need a way to=20 > > negotiate application context for transported data within an=20 > > INVITE-bounded dialog (like INFO "packages"). If we accept=20 > > the "it's just a session" model then everything we've done=20 > > with event packages, INFO, MESSAGE, and so needs to be=20 > > replaced with a proper session-based mechanism (presence=20 > > sessions, ISUP sessions, messaging sessions, and so on). > >=20 > > Or we could do nothing, accept that we have a rather muddled=20 > > protocol, and just try and give guidance on when to use each=20 > > extension modality. > >=20 > > Specifically, as the ongoing body-type-context debate has=20 > > pointed out, while we can say what body types we support, we=20 > > don't currently have a good way for a describe what a message=20 > > containing a body of a specific type is likely to mean in the=20 > > current context, and the jury is out as to whether we have=20 > > reliable means of deducing a context. > >=20 > > We do have RFC 4485, which seems to me to do a fair job of=20 > > guiding us on new header fields but doesn't say enough about=20 > > body types (and doesn't even begin to discuss the=20 > > body-type-context question beyond a vague mention of=20 > > Content-Disposition), and which provides little useful=20 > > guidance on when to use new methods vs. when to use events. > >=20 > > What do we want to do here? Is there a way to get a clear=20 > > position, or are we going to be debating bodies vs. header=20 > > fields vs. method- types forever? > >=20 > > -- > > Dean > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 26 11:18:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE55z-0003E7-Sc; Thu, 26 Jul 2007 11:17:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IE55x-0003DD-VJ for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 11:17:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE55x-0003Cp-J2 for sip@ietf.org; Thu, 26 Jul 2007 11:17:41 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE55v-0000Hn-GL for sip@ietf.org; Thu, 26 Jul 2007 11:17:41 -0400 Received: from hkaplan [130.129.16.205] by acmepacket.com with ESMTP (SMTPD-9.10) id AAF30204; Thu, 26 Jul 2007 11:17:07 -0400 From: "Hadriel Kaplan" To: "'Dean Willis'" , "'Adam Roach'" References: <46A79D24.90507@nostrum.com> <770DB056-F390-4D74-84C5-403AE53A1864@softarmor.com> Subject: RE: [Sip] Ruminations on the SIP extension model Date: Thu, 26 Jul 2007 11:17:05 -0400 Message-ID: <06ce01c7cf98$075ea410$6410a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfPjZDMOBn9vteQQHuqwf3eG3CUEwACBYOA In-Reply-To: <770DB056-F390-4D74-84C5-403AE53A1864@softarmor.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Well, personally I'm in the "reuseable primitives" camp, and I > believe you are too (as 3265 is a shining example of this approach). > But other people have very different beliefs. I think everyone would be for reusable primitives. The concern I have, though, is that the problem with the currently defined primitive for dtmf is it is the wrong type for the dtmf feature. A second concern is that the defined primitive is far too heavy for the problem being addressed. So my marketing gut tells me that market forces will continue to work against it. > Note also that one of the main contributors prior to RFC 2543 broke > with the community over the BYE method, as he (IIRC) believed that > the way to end a session was to stop sending media. Funny. I was thinking it should be a re-Invite with an expires=0 and sdp media ports of 0. ;) -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 26 11:23:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE5BB-0008Uk-EF; Thu, 26 Jul 2007 11:23:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IE5BA-0008US-4K for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 11:23:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE5B9-0008UJ-Q0 for sip@ietf.org; Thu, 26 Jul 2007 11:23:03 -0400 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE5B9-0007eE-Df for sip@ietf.org; Thu, 26 Jul 2007 11:23:03 -0400 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1IE5Bk-0003We-T2; Thu, 26 Jul 2007 08:23:40 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Sip] Ruminations on the SIP extension model Date: Thu, 26 Jul 2007 08:23:00 -0700 Message-ID: <0D4E483A0E6E0A46861409E5D6C2011C71A07E@sea02-mxc01.citel.com> In-Reply-To: <06ce01c7cf98$075ea410$6410a8c0@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ruminations on the SIP extension model Thread-Index: AcfPjZDMOBn9vteQQHuqwf3eG3CUEwACBYOAAACs9rA= References: <46A79D24.90507@nostrum.com><770DB056-F390-4D74-84C5-403AE53A1864@softarmor.com> <06ce01c7cf98$075ea410$6410a8c0@acmepacket.com> From: "Steve Langstaff" To: "Hadriel Kaplan" , "Dean Willis" , "Adam Roach" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: 26 July 2007 16:17 > To: 'Dean Willis'; 'Adam Roach' > Cc: 'IETF SIP List' > Subject: RE: [Sip] Ruminations on the SIP extension model >=20 >=20 > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > >=20 > > Note also that one of the main contributors prior to RFC 2543 broke=20 > > with the community over the BYE method, as he (IIRC)=20 > believed that the=20 > > way to end a session was to stop sending media. >=20 > Funny. I was thinking it should be a re-Invite with an=20 > expires=3D0 and sdp media ports of 0. > ;) >=20 > -hadriel Nonsense. The initial INVITE should cause an implicit subscription for a bye event notification. But I guess we have to use the "legacy" BYE method :) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 26 11:27:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE5FB-0004Vf-93; Thu, 26 Jul 2007 11:27:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IE5F9-0004SS-5T for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 11:27:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE5F8-0004Po-Oj for sip@ietf.org; Thu, 26 Jul 2007 11:27:10 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE5F7-0000aF-AB for sip@ietf.org; Thu, 26 Jul 2007 11:27:10 -0400 Received: from [130.129.22.70] (dhcp-1646.ietf69.org [130.129.22.70]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6QFQ73Z088319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Jul 2007 10:26:08 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <0D4E483A0E6E0A46861409E5D6C2011C71A07E@sea02-mxc01.citel.com> References: <46A79D24.90507@nostrum.com><770DB056-F390-4D74-84C5-403AE53A1864@softarmor.com> <06ce01c7cf98$075ea410$6410a8c0@acmepacket.com> <0D4E483A0E6E0A46861409E5D6C2011C71A07E@sea02-mxc01.citel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Ruminations on the SIP extension model Date: Thu, 26 Jul 2007 10:26:04 -0500 To: "Steve Langstaff" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 130.129.22.70 is authenticated by a trusted mechanism) X-Spam-Score: -1.4 (-) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: IETF SIP List , Adam Roach , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org If any of this shows up at a SIPit, you owe me beer. And asprin. RjS On Jul 26, 2007, at 10:23 AM, Steve Langstaff wrote: >> -----Original Message----- >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >> Sent: 26 July 2007 16:17 >> To: 'Dean Willis'; 'Adam Roach' >> Cc: 'IETF SIP List' >> Subject: RE: [Sip] Ruminations on the SIP extension model >> >> >>> -----Original Message----- >>> From: Dean Willis [mailto:dean.willis@softarmor.com] >>> >>> Note also that one of the main contributors prior to RFC 2543 broke >>> with the community over the BYE method, as he (IIRC) >> believed that the >>> way to end a session was to stop sending media. >> >> Funny. I was thinking it should be a re-Invite with an >> expires=0 and sdp media ports of 0. >> ;) >> >> -hadriel > > Nonsense. The initial INVITE should cause an implicit subscription > for a > bye event notification. But I guess we have to use the "legacy" BYE > method :) > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 26 11:27:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE5FN-0004mN-NS; Thu, 26 Jul 2007 11:27:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IE5FL-0004kk-3C for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 11:27:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE5FK-0004kY-PC for sip@ietf.org; Thu, 26 Jul 2007 11:27:22 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE5FJ-0000by-F7 for sip@ietf.org; Thu, 26 Jul 2007 11:27:22 -0400 Received: from dhcp-11b9.ietf69.org (dhcp-11b9.ietf69.org [130.129.17.185]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6QFRKP4088357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2007 10:27:20 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <46A8BD58.4020904@nostrum.com> Date: Thu, 26 Jul 2007 10:27:20 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Ruminations on the SIP extension model References: <46A79D24.90507@nostrum.com> <770DB056-F390-4D74-84C5-403AE53A1864@softarmor.com> In-Reply-To: <770DB056-F390-4D74-84C5-403AE53A1864@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.17.185 is authenticated by a trusted mechanism) X-Spam-Score: -1.4 (-) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 7/26/07 8:59 AM, Dean Willis wrote: > Well, personally I'm in the "reuseable primitives" camp, and I believe > you are too (as 3265 is a shining example of this approach). But other > people have very different beliefs. Actually, if I knew then what I knew now, I'd probably have proposed doing things completely differently. I have come to believe that a far cleaner approach would have been to use INVITE to set up a stream of state change notifications -- it would have prevented this "multiple usages in a dialog" mess; it would have prevented the bizarre forking SUBSCRIBE problem; it would have made unsolicited NOTIFYs impossible... the whole setup would have been much cleaner. And, as we all know by now, every time you send an unsolicited NOTIFY, the terrorists win. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 26 12:19:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE63f-00078P-TM; Thu, 26 Jul 2007 12:19:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IE63d-000768-Tj for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 12:19:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE63c-000759-H3; Thu, 26 Jul 2007 12:19:20 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE63b-0002lR-B9; Thu, 26 Jul 2007 12:19:20 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 26 Jul 2007 12:19:19 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANxlqEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,584,1175486400"; d="scan'208"; a="127119221:sNHT26802332" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6QGJIaP025436; Thu, 26 Jul 2007 12:19:18 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6QGIsWk003600; Thu, 26 Jul 2007 16:19:18 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); Thu, 26 Jul 2007 12:19:06 -0400 Received: from [10.86.241.65] ([10.86.241.65]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 12:19:06 -0400 Message-ID: <46A8C983.4060302@cisco.com> Date: Thu, 26 Jul 2007 12:19:15 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: IETF SIP List , IETF Sipping List , IETF MMUSIC WG , Behave WG , P2PSIP WG , rai@ietf.org, "'avt@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2007 16:19:06.0078 (UTC) FILETIME=[B02C9FE0:01C7CFA0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=740; t=1185466758; x=1186330758; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20ICE=20tutorial=20in=20Chicago=20=20-=20PLEASE=20PAY=20IF=20YO U=20ATE=20LUNCH |Sender:=20 |To:=20IETF=20SIP=20List=20, =20IETF=20Sipping=20List=20, =0A=20=20=20=20=20=20=20=20IETF=20MMUSIC=20WG=20, =20Behave=20WG=20, =0A=20=20=20=20=20=20=20=20P2PSI P=20WG=20, =20rai@ietf.org, =0A=20=20=20=20=20=20=20=20=22' avt@ietf.org'=22=20; bh=Zrtno2xh1JufqqypXQrJG3eaM0QxnaFVcCRKizkJRlU=; b=EAbRlhLzYaOy4oHUNIotoEwBXwvoS8Zp1gyIR9U0ZLbsLNA0SW2PWFoOvExi7DXio14brEfh Ctw1A+j6KiaWFP+lwWplEuOmXoKwNKI3GCkheAO1e18guOsiXHEOunJT; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Sip] ICE tutorial in Chicago - PLEASE PAY IF YOU ATE LUNCH X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Lunch during the tutorial was paid out of my pocket, and I was expecting to get re-imbursed by everyone that took a sandwich. Though all of the food was taken by the end of the tutorial, I am several hundred dollars short. Please, if you took lunch and did not give me $20, give it to me before you leave, and if you have not, contact me privately and we can arrange for paper mail. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 26 15:10:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8jR-0000zZ-7X; Thu, 26 Jul 2007 15:10:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IE8jO-0000zH-Lq for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 15:10:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8jO-0000z8-8T for sip@ietf.org; Thu, 26 Jul 2007 15:10:38 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE8jN-0005Vi-PA for sip@ietf.org; Thu, 26 Jul 2007 15:10:38 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 26 Jul 2007 15:10:37 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACyOqEZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,584,1175486400"; d="scan'208"; a="66260181:sNHT28136960" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6QJAbWF030407; Thu, 26 Jul 2007 15:10:37 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6QJAKEh014275; Thu, 26 Jul 2007 19:10:37 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 15:10:26 -0400 Received: from [10.86.240.33] ([10.86.240.33]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 15:10:25 -0400 Message-ID: <46A8F1AB.7070503@cisco.com> Date: Thu, 26 Jul 2007 15:10:35 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Ruminations on the SIP extension model References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2007 19:10:25.0853 (UTC) FILETIME=[9F65CED0:01C7CFB8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1910; t=1185477037; x=1186341037; c=relaxed/simple; s=rtpdkim2001; 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[Sip]=20Ruminations=20on=20the=20SIP=20extension=20mo del |Sender:=20 |To:=20Dean=20Willis=20; bh=CRNgyZboqxZNhiwoUsh4IcPri6LvpOG4+M/31CTupXc=; b=EZtCvOCVSD3//G+6B/Iq1MvbVuhhjBZZx874oIJfxaTjAAUO1dixeoVzd2n6jVWbPB8IgTzj uqPL3po1UFQKoC6svDmTn2LR3u+duMKTBhe1oBSI5DmUNbBMxN93R/am; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > There is a deep philosophical divide about how the SIP protocol should > be formed and extended. One branch of this debate holds that SIP's role > is as a transport protocol with a very few primitives and application > logic handled at the data level. In this model, new applications can > generally be built without changing the protocol or its syntax. The > second branch holds that the SIP protocol itself should be intimately > tied to the application, with new functionality represented as new > message types. Yet another branch of the debate holds that SIP is only > for setting up and tearing down "sessions", and that information outside > of that needed to set up or tear down a "session" is rightfully part of > the "session" and not in the domain of the SIP protocol itself. I would argue that SIP *is* an application protocol - supporting 'multimedia communications'. Its implementation takes many forms - softphones, hardphones, gateways, and so on, but still it is all about multimedia communications. Consequently, the notion of an additional layer *above* SIP, something beyond the UI, something that has behaviors that are fundamentally different (and NOT compatible) with other applications that might reside above SIP, is foreign to the design of SIP, and something that is dangerous. It is this thinking that will lead us to highly segmented uses of SIP, none of which are well defined or interoperable. Very reminiscent of the 'service ID' discussions in sipping, in fact. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 26 16:52:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEAJV-0006zc-RH; Thu, 26 Jul 2007 16:52:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IEAJU-0006ro-4B for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 16:52:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEAJT-0006pb-Lp for sip@ietf.org; Thu, 26 Jul 2007 16:51:59 -0400 Received: from wx-out-0506.google.com ([66.249.82.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEAJT-0000Ry-DY for sip@ietf.org; Thu, 26 Jul 2007 16:51:59 -0400 Received: by wx-out-0506.google.com with SMTP id h27so564464wxd for ; Thu, 26 Jul 2007 13:51:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=ehWEk1WoIi2bvg+SqPUOQrCmMvLvV51WRxKnx6E8OTTaACOl5cSDV/dkKGMRwdhmz0F5tY3P34I6ODPTmUVgy/0uNDtQVVQsYTUE7yWBbpcLlD7XkzGY7J/pbXLFPQCD9g81LcCx7eOzDFqmGM2HKQQT+4Q2lUlLLpdZqeJgxDE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=iobURGDsqNFmDca56nOqv4Wnq4kP+CWJv5eB6uVLBgbASMyC8OB3UDiVer6Y5sE/ACvrLDNkPBpm0a+FN+f0TdbIAp1M5W7mgTwlQ32GSFcD/usVZFZo7hmrFKeFvAbKFESCLawmylczWuOHONV1E7jV9pQrS4ss/RU89z15SB0= Received: by 10.70.116.1 with SMTP id o1mr3655821wxc.1185483119038; Thu, 26 Jul 2007 13:51:59 -0700 (PDT) Received: by 10.70.38.2 with HTTP; Thu, 26 Jul 2007 13:51:58 -0700 (PDT) Message-ID: Date: Thu, 26 Jul 2007 16:51:58 -0400 From: "Adam Fisk" To: "Jiri Kuthan" Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC In-Reply-To: <20070724212509.4029E181124D@mail.iptel.org> MIME-Version: 1.0 References: <20070719145334.2EA8B1810C50@mail.iptel.org> <20070719180614.85AB218115BC@mail.iptel.org> <20070721144803.41B4F1810C56@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com> <20070723205140.EC8031811206@mail.iptel.org> <20070724212509.4029E181124D@mail.iptel.org> X-Google-Sender-Auth: 9d143adb8062ffa4 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: mmusic@ietf.org, sip@ietf.org, Juha Heinanen , Henry Sinnreich , David Barrett , Jan Janak X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2103688367==" Errors-To: sip-bounces@ietf.org --===============2103688367== Content-Type: multipart/alternative; boundary="----=_Part_110055_11584226.1185483118369" ------=_Part_110055_11584226.1185483118369 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/24/07, Jiri Kuthan wrote: > > At 22:07 24/07/2007, Adam Fisk wrote: > >I've followed ICE development on the sidelines for years now, and I'm > currently implementing ICE 17. I've implemented what will be open source > implementations of STUN and TURN, both client and server. > > That's marvellous news -- can you send me a pointer to that? We're not quite public yet, Jiri. I'll send a note to the list when we're up, though. -Adam ------=_Part_110055_11584226.1185483118369 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

        On 7/24/07, Jiri Kuthan <jiri@iptel.org> wrote:
        At 22:07 24/07/2007, Adam Fisk wrote:
        >I've followed ICE development on the sidelines for years now, and I'm currently implementing ICE 17.  I've implemented what will be open source implementations of STUN and TURN, both client and server.

        That's marvellous news -- can you send me a pointer to that?

        We're not quite public yet, Jiri.  I'll send a note to the list when we're up, though. 

        -Adam
        ------=_Part_110055_11584226.1185483118369-- --===============2103688367== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2103688367==-- From sip-bounces@ietf.org Thu Jul 26 17:03:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEAUn-0005yE-FJ; Thu, 26 Jul 2007 17:03:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IEAUk-0005y4-Q0 for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 17:03:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEAUk-0005xw-5N for sip@ietf.org; Thu, 26 Jul 2007 17:03:38 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEAUj-00086k-RB for sip@ietf.org; Thu, 26 Jul 2007 17:03:38 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6QL3ZS01168 for ; Thu, 26 Jul 2007 21:03:35 GMT 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, 26 Jul 2007 16:03:19 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfPyGTj9bPZmULKTXqozghHhl1N0Q== From: "Francois Audet" To: "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In the meeting, the issue of the error code to be used when the wrong URI is used in a request-URI (i.e., sip instead of sips, or vice-versa) came up. The status quo is 2 new error codes (418 and 419). Another proposal was to use only one (i.e., 418 with 2 new headers). That proposal did not seem to get much traction. And people were not very with the status quo either.=20 Another proposal was to use 480 (Temporarily Unavailable) and NOT to use an explicit indication of the required/supported URIs (SIP, SIPS, etc.). Of course, one can always put text in the reason phrase to describe the error for displaying to the end-use. After talking to all the individual who seemed to have strong opinions on this topic, it appears that the 480 approach is the preferred approach.=20 Please let the list know if you are strongly opposed to this outcome, along with the=20 reasons behind your opposition. This is the last remaining issue to be closed in the draft, as a result of WGLC. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 26 17:31:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEAvC-0000uR-My; Thu, 26 Jul 2007 17:30:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IEAvB-0000pn-Dv for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 17:30:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEAv9-0000nq-VG for sip@ietf.org; Thu, 26 Jul 2007 17:30:57 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEAv9-00015N-Gx for sip@ietf.org; Thu, 26 Jul 2007 17:30:55 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 26 Jul 2007 14:30:54 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAD+uqEarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,584,1175497200"; d="scan'208"; a="10779344:sNHT13527144" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6QLUsqn024194; Thu, 26 Jul 2007 14:30:55 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6QLUoA2002042; Thu, 26 Jul 2007 21:30:54 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); Thu, 26 Jul 2007 14:30:52 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.66.254]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 14:30:51 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Jul 2007 16:30:50 -0500 To: "Francois Audet" , "IETF SIP List" From: "James M. Polk" Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nor tel.com> References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 26 Jul 2007 21:30:52.0040 (UTC) FILETIME=[3DCBE880:01C7CFCC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1878; t=1185485455; x=1186349455; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20draft-ietf-sip-sips-05=3A=20480=20vs.=20418 |Sender:=20; bh=/Xz+K+7UkXt3v14yy/5os9gLgo7Lc26XyIBUggGBtQ0=; b=AvvZaji/fNvL5WFDiReaBsuK5fYN7EC2ugmqF1mrx76lhFUwE2iCbkGsqBuZvpZbKsWxNwd0 Z6dJO1LSuIQ8+8NxCCD6PQftF/1tR+DfDbAJMHr6sSeRuYcoKTF+qLkj; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 04:03 PM 7/26/2007, Francois Audet wrote: >In the meeting, the issue of the error code to be used when the wrong URI is >used in a request-URI (i.e., sip instead of sips, or vice-versa) came up. > >The status quo is 2 new error codes (418 and 419). (BTW 419 is used by Cullen's hashcash draft) >Another proposal was to use only one (i.e., 418 with 2 new headers). I would advocate this proposal, especially verses a 480, as a (new) Reason code to give the specifics can easily be stripped along the way back to the UAC, leaving it clueless as to what the actual problem was. Also not all implementations support Reason (though they should). A 418 is specific to the point of what was wrong.... and all UACs have to deal with the fact they can become a 400 (thus removing the details) >That proposal did not seem to get much traction. And people were not >very with the status quo either. > >Another proposal was to use 480 (Temporarily Unavailable) and NOT to use >an explicit indication of the required/supported URIs (SIP, SIPS, >etc.). Of course, >one can always put text in the reason phrase to describe the error >for displaying to >the end-use. > >After talking to all the individual who seemed to have strong opinions >on this topic, it appears that the 480 approach is the preferred approach. > >Please let the list know if you are strongly opposed to this outcome, >along with the reasons behind your opposition. > >This is the last remaining issue to be closed in the draft, as a result >of WGLC. > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 26 17:49:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEBDP-0008C0-A9; Thu, 26 Jul 2007 17:49:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IEBDN-0008Bp-Vo for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 17:49:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEBDN-0008Bh-Lk for sip@ietf.org; Thu, 26 Jul 2007 17:49:45 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEBDN-0000Sp-79 for sip@ietf.org; Thu, 26 Jul 2007 17:49:45 -0400 Received: from [130.129.22.70] (dhcp-1646.ietf69.org [130.129.22.70]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6QLnhVt009800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Jul 2007 16:49:44 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Thu, 26 Jul 2007 16:49:35 -0500 To: "Francois Audet" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 130.129.22.70 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think the 480 approach described below is the right thing to do. RjS On Jul 26, 2007, at 4:03 PM, Francois Audet wrote: > In the meeting, the issue of the error code to be used when the wrong > URI is > used in a request-URI (i.e., sip instead of sips, or vice-versa) came > up. > > The status quo is 2 new error codes (418 and 419). Another proposal > was > to use only one > (i.e., 418 with 2 new headers). > > That proposal did not seem to get much traction. And people were not > very with the > status quo either. > > Another proposal was to use 480 (Temporarily Unavailable) and NOT > to use > an explicit > indication of the required/supported URIs (SIP, SIPS, etc.). Of > course, > one can always > put text in the reason phrase to describe the error for displaying to > the end-use. > > After talking to all the individual who seemed to have strong opinions > on this topic, > it appears that the 480 approach is the preferred approach. > > Please let the list know if you are strongly opposed to this outcome, > along with the > reasons behind your opposition. > > This is the last remaining issue to be closed in the draft, as a > result > of WGLC. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 26 18:21:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEBiW-00051I-AY; Thu, 26 Jul 2007 18:21:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IEBiV-000519-62 for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 18:21:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEBiU-000511-Sf for sip@ietf.org; Thu, 26 Jul 2007 18:21:54 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEBiU-0001wa-ES for sip@ietf.org; Thu, 26 Jul 2007 18:21:54 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6QMLlY06108; Thu, 26 Jul 2007 22:21:47 GMT 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 Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Thu, 26 Jul 2007 17:21:39 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF11697876@zrc2hxm0.corp.nortel.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfPzEIJlgBG3J9rR56COAziVQRIYQABnfUg References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "James M. Polk" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi James, The specific reason why many were advocating a 480 instead of a new error code is exactly because they did NOT want the error code=20 to encourage UAC to reattempt the request by downgrading to SIP automatically. This is the point that Eric Rescorla was making in the meeting, and it has been re-iterated in one way or another by both Jon Peterson and by Rohan Mahy. You *could* of course with this approach use a reason phrase in the 480 to provide a message to the user of what the issue is.=20 > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > Sent: Thursday, July 26, 2007 14:31 > To: Audet, Francois (SC100:3055); IETF SIP List > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >=20 > At 04:03 PM 7/26/2007, Francois Audet wrote: > >In the meeting, the issue of the error code to be used when=20 > the wrong=20 > >URI is used in a request-URI (i.e., sip instead of sips, or=20 > vice-versa) came up. > > > >The status quo is 2 new error codes (418 and 419). >=20 > (BTW 419 is used by Cullen's hashcash draft) >=20 > >Another proposal was to use only one (i.e., 418 with 2 new headers). >=20 > I would advocate this proposal, especially verses a 480, as a=20 > (new) Reason code to give the specifics can easily be=20 > stripped along the way back to the UAC, leaving it clueless=20 > as to what the actual problem was. Also not all=20 > implementations support Reason (though they should). >=20 > A 418 is specific to the point of what was wrong.... and all=20 > UACs have to deal with the fact they can become a 400 (thus=20 > removing the details) >=20 >=20 > >That proposal did not seem to get much traction. And people were not > >very with the status quo either. > > > >Another proposal was to use 480 (Temporarily Unavailable)=20 > and NOT to use > >an explicit indication of the required/supported URIs (SIP, SIPS,=20 > >etc.). Of course, > >one can always put text in the reason phrase to describe the error=20 > >for displaying to > >the end-use. > > > >After talking to all the individual who seemed to have=20 > strong opinions > >on this topic, it appears that the 480 approach is the=20 > preferred approach. > > > >Please let the list know if you are strongly opposed to this outcome, > >along with the reasons behind your opposition. > > > >This is the last remaining issue to be closed in the draft,=20 > as a result > >of WGLC. > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 26 18:37:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEBxm-0003xz-EK; Thu, 26 Jul 2007 18:37:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IEBxk-0003xu-D9 for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 18:37:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEBxk-0003xm-22 for sip@ietf.org; Thu, 26 Jul 2007 18:37:40 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEBxj-0001S6-I4 for sip@ietf.org; Thu, 26 Jul 2007 18:37:39 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JLT0047M5IB9T@siemenscomms.co.uk> for sip@ietf.org; Thu, 26 Jul 2007 23:37:23 +0100 (BST) Date: Thu, 26 Jul 2007 23:37:36 +0100 From: "Elwell, John" Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 In-reply-to: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> To: Francois Audet , IETF SIP List Message-id: <0D5F89FAC29E2C41B98A6A762007F5D020610D@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfPyGTj9bPZmULKTXqozghHhl1N0QADLd/Q Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois, I am reasonably happy with this proposal, BUT I must point out the following from RFC 3261: "If the Request-URI indicates a resource at this proxy that does not exist, the proxy MUST return a 404 (Not Found) response. If the target set remains empty after applying all of the above, the proxy MUST return an error response, which SHOULD be the 480 (Temporarily Unavailable) response." Doesn't this fit into the first category, suggesting that 404 would be appropriate? Or do we regard the existence of an AoR as meaning that both SIP and SIPS resources exist, even if one or other has no registered contacts? John > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 26 July 2007 22:03 > To: IETF SIP List > Subject: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > In the meeting, the issue of the error code to be used when the wrong > URI is > used in a request-URI (i.e., sip instead of sips, or vice-versa) came > up. > > The status quo is 2 new error codes (418 and 419). Another > proposal was > to use only one > (i.e., 418 with 2 new headers). > > That proposal did not seem to get much traction. And people were not > very with the > status quo either. > > Another proposal was to use 480 (Temporarily Unavailable) and > NOT to use > an explicit > indication of the required/supported URIs (SIP, SIPS, etc.). > Of course, > one can always > put text in the reason phrase to describe the error for displaying to > the end-use. > > After talking to all the individual who seemed to have strong opinions > on this topic, > it appears that the 480 approach is the preferred approach. > > Please let the list know if you are strongly opposed to this outcome, > along with the > reasons behind your opposition. > > This is the last remaining issue to be closed in the draft, > as a result > of WGLC. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 26 18:42:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEC20-0008Mn-Ql; Thu, 26 Jul 2007 18:42:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IEC1z-0008Mh-UX for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 18:42:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEC1z-0008MY-KL for sip@ietf.org; Thu, 26 Jul 2007 18:42:03 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEC1z-0001Yy-7u for sip@ietf.org; Thu, 26 Jul 2007 18:42:03 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6QMg0Y07782; Thu, 26 Jul 2007 22:42:00 GMT 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 Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Thu, 26 Jul 2007 17:41:59 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF116978B3@zrc2hxm0.corp.nortel.com> In-reply-to: <0D5F89FAC29E2C41B98A6A762007F5D020610D@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfPyGTj9bPZmULKTXqozghHhl1N0QADLd/QAAAk0iA= References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D020610D@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Thursday, July 26, 2007 15:38 > To: Audet, Francois (SC100:3055); IETF SIP List > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >=20 > Francois, >=20 > I am reasonably happy with this proposal, BUT I must point=20 > out the following from RFC 3261: > "If the Request-URI indicates a resource at this proxy that does not > exist, the proxy MUST return a 404 (Not Found) response. >=20 > If the target set remains empty after applying all of the=20 > above, the > proxy MUST return an error response, which SHOULD be the 480 > (Temporarily Unavailable) response." >=20 > Doesn't this fit into the first category, suggesting that 404=20 > would be appropriate? Or do we regard the existence of an AoR=20 > as meaning that both SIP and SIPS resources exist, even if=20 > one or other has no registered contacts? Basically, 480 is the error code that is supposed to be used when the user is known to exist (i.e., the AOR is in the database), but=20 he is not "logged-in" at present. So the presence of the AOR does mean that both the SIP and SIPS AOR exist, but they don't necessarily have a binding assigned to it at the time. Thus the 480. That's the feedback I got from others. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 26 18:59:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IECJ7-0007uW-W5; Thu, 26 Jul 2007 18:59:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IECJ6-0007o4-Ht for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 18:59:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IECJ6-0007lR-5K for sip@ietf.org; Thu, 26 Jul 2007 18:59:44 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IECJ5-0001sg-Co for sip@ietf.org; Thu, 26 Jul 2007 18:59:44 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 26 Jul 2007 15:59:42 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGfDqEarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,584,1175497200"; d="scan'208"; a="507524735:sNHT55696662" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6QMxg2V012407; Thu, 26 Jul 2007 15:59:42 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l6QMxbTl025342; Thu, 26 Jul 2007 22:59:42 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); Thu, 26 Jul 2007 15:59:30 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.65.248]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 15:59:30 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Jul 2007 17:59:32 -0500 To: "Francois Audet" , "IETF SIP List" From: "James M. Polk" Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF11697876@zrc2hxm0.corp.nor tel.com> References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF11697876@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 26 Jul 2007 22:59:30.0337 (UTC) FILETIME=[9FBFA110:01C7CFD8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3463; t=1185490782; x=1186354782; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Sip]=20draft-ietf-sip-sips-05=3A=20480=20vs.=20418 |Sender:=20; bh=Gt0YUaDChwoJ7bTDUkMpZFb03IKJH1l9r/oVmF8ukzc=; b=uIs4nhKm7wPid0YEEO9GMwwmF4zDfSfnEvhGa1gWHHh0ps562bTcfVDhkXuo+MBoGqYNycnW EblC59IGW1jwhJedy+LgB5oO0+Uh5tBTS5M8v0RHsxfrL1gUJKJ4TF3n; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois I just don't see the difference between a 480 and a 400 in this case. Either way, the UAC is left clueless, and hopeless (because it doesn't understand the real reason things went south). I prefer telling the UAC what the error was. This is making a policy decision for the user of the UAC at the protocol level without their ability to make a choice, while blinding them to what actually happened. I can give lots of examples outside of calling where this would be endlessly frustrating, and a few that are within calling... At 05:21 PM 7/26/2007, Francois Audet wrote: >Hi James, > >The specific reason why many were advocating a 480 instead of a new >error code is exactly because they did NOT want the error code >to encourage UAC to reattempt the request by downgrading to >SIP automatically. > >This is the point that Eric Rescorla was making in the meeting, and >it has been re-iterated in one way or another by both Jon Peterson >and by Rohan Mahy. > >You *could* of course with this approach use a reason phrase in the >480 to provide a message to the user of what the issue is. > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Thursday, July 26, 2007 14:31 > > To: Audet, Francois (SC100:3055); IETF SIP List > > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > > > At 04:03 PM 7/26/2007, Francois Audet wrote: > > >In the meeting, the issue of the error code to be used when > > the wrong > > >URI is used in a request-URI (i.e., sip instead of sips, or > > vice-versa) came up. > > > > > >The status quo is 2 new error codes (418 and 419). > > > > (BTW 419 is used by Cullen's hashcash draft) > > > > >Another proposal was to use only one (i.e., 418 with 2 new headers). > > > > I would advocate this proposal, especially verses a 480, as a > > (new) Reason code to give the specifics can easily be > > stripped along the way back to the UAC, leaving it clueless > > as to what the actual problem was. Also not all > > implementations support Reason (though they should). > > > > A 418 is specific to the point of what was wrong.... and all > > UACs have to deal with the fact they can become a 400 (thus > > removing the details) > > > > > > >That proposal did not seem to get much traction. And people were not > > >very with the status quo either. > > > > > >Another proposal was to use 480 (Temporarily Unavailable) > > and NOT to use > > >an explicit indication of the required/supported URIs (SIP, SIPS, > > >etc.). Of course, > > >one can always put text in the reason phrase to describe the error > > >for displaying to > > >the end-use. > > > > > >After talking to all the individual who seemed to have > > strong opinions > > >on this topic, it appears that the 480 approach is the > > preferred approach. > > > > > >Please let the list know if you are strongly opposed to this outcome, > > >along with the reasons behind your opposition. > > > > > >This is the last remaining issue to be closed in the draft, > > as a result > > >of WGLC. > > > > > > > > >_______________________________________________ > > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >This list is for NEW development of the core SIP Protocol > > >Use sip-implementors@cs.columbia.edu for questions on current sip > > >Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jul 26 19:17:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IECaF-0007t1-7t; Thu, 26 Jul 2007 19:17:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IECaE-0007sq-9X for sip-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 19:17:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IECaD-0007si-UT for sip@ietf.org; Thu, 26 Jul 2007 19:17:25 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IECaD-0002Ai-Ew for sip@ietf.org; Thu, 26 Jul 2007 19:17:25 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 26 Jul 2007 19:17:25 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswMAEvIqEZAZnme/2dsb2JhbACIYp1J X-IronPort-AV: i="4.16,585,1175486400"; d="scan'208"; a="127163324:sNHT29635764" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6QNHPDx032106; Thu, 26 Jul 2007 19:17:25 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6QNH2Eh015741; Thu, 26 Jul 2007 23:17:19 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); Thu, 26 Jul 2007 19:17:16 -0400 Received: from [10.86.242.184] ([10.86.242.184]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 19:17:15 -0400 Message-ID: <46A92B7C.7080202@cisco.com> Date: Thu, 26 Jul 2007 19:17:16 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> In-Reply-To: <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2007 23:17:15.0919 (UTC) FILETIME=[1AE289F0:01C7CFDB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3029; t=1185491845; x=1186355845; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20draft-ietf-sip-sips-05=3A=20480=20vs.=20418 |Sender:=20 |To:=20Robert=20Sparks=20; bh=/fChJ1BM09fEnsintvhuTf94mrCkacZtunWEACb9Y8Y=; b=r20iXxj59BnookuOyO3bg2+hnHRt9zL1XkQkzw/TrAP74l4TfnGZhQ7FaVrvyAyfpKAt8Nu+ LG8QRsgAxMoLu72fXz2MZLGMn23Nvl62GmdzHoOHmY9jpC5ZYqRWm7H1; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: IETF SIP List , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Is the 480 intended to be *indistinguishable* from a 480 returned as a result of no registrations at all? Or is it intended to be distinguishable but more obscure than an explicit error response? I think it needs to be distinguishable, one way or another. The reason is that there are UIs where it makes sense to downgrade. For instance: The input to the UI of the UA is just a dial string, not a URI. It is up to the UA to decide what scheme to apply. It can do this based on policy, or perhaps based on a "secure" button on the phone. Typically the user won't know whether a particular number should be sip or sips. (Or even what that means.) The phone may decide to try sips first and downgrade to sip if the sips doesn't work. If sips works then it can display some sort of indication that the call is more secure than if sip is used. If the UA can't tell why the sips request failed then it will have to retry the call in all cases. The bottom line is that whether to downgrade is a valid policy issue, and we shouldn't arbitrarily block it from working. Paul Robert Sparks wrote: > I think the 480 approach described below is the right thing to do. > > RjS > > On Jul 26, 2007, at 4:03 PM, Francois Audet wrote: > >> In the meeting, the issue of the error code to be used when the wrong >> URI is >> used in a request-URI (i.e., sip instead of sips, or vice-versa) came >> up. >> >> The status quo is 2 new error codes (418 and 419). Another proposal was >> to use only one >> (i.e., 418 with 2 new headers). >> >> That proposal did not seem to get much traction. And people were not >> very with the >> status quo either. >> >> Another proposal was to use 480 (Temporarily Unavailable) and NOT to use >> an explicit >> indication of the required/supported URIs (SIP, SIPS, etc.). Of course, >> one can always >> put text in the reason phrase to describe the error for displaying to >> the end-use. >> >> After talking to all the individual who seemed to have strong opinions >> on this topic, >> it appears that the 480 approach is the preferred approach. >> >> Please let the list know if you are strongly opposed to this outcome, >> along with the >> reasons behind your opposition. >> >> This is the last remaining issue to be closed in the draft, as a result >> of WGLC. >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 27 01:34:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEISm-0006Pd-L2; Fri, 27 Jul 2007 01:34:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IEISk-0006Or-Gr for sip-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 01:34:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEISj-0006Mq-Mv for sip@ietf.org; Fri, 27 Jul 2007 01:34:05 -0400 Received: from cluster-f.mailcontrol.com ([85.119.2.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEISi-0001Bf-B5 for sip@ietf.org; Fri, 27 Jul 2007 01:34:05 -0400 Received: from rly35f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly35f.srv.mailcontrol.com (MailControl) with ESMTP id l6R5Y1Ef007091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jul 2007 06:34:02 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly35f.srv.mailcontrol.com (MailControl) id l6R5X6gZ000302 for sip@ietf.org; Fri, 27 Jul 2007 06:33:06 +0100 Received: from exsmtp01.nasstar-t1.net (exsmtp01.nasstar-t1.net [89.28.233.12]) by rly35f-eth0.srv.mailcontrol.com (envelope-sender attila.sipos@vegastream.com) (MIMEDefang) with ESMTP id l6R5X5XT032711; Fri, 27 Jul 2007 06:33:06 +0100 (BST) Received: from ExBE03.nasstar-t1.net ([10.2.10.102]) by exsmtp01.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 06:33:19 +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" Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Fri, 27 Jul 2007 06:33:04 +0100 Message-ID: <165288C2C3E29449AFDE022DD10CC471062D8DCA@ExBE03.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfP2zQCuA3F4hLiSfCYT7wUq9QGiAAM+DuA From: "Attila Sipos" To: "Paul Kyzivat" , "Robert Sparks" X-OriginalArrivalTime: 27 Jul 2007 05:33:19.0772 (UTC) FILETIME=[A3FD45C0:01C7D00F] X-Scanned-By: MailControl A-07-08-00 (www.mailcontrol.com) on 10.70.1.145 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: IETF SIP List , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 >>The bottom line is that whether to downgrade is a valid >>policy issue, and we shouldn't arbitrarily block it from working. I would agree with this. I think a UA user would always like the most secure call possible. If the user only wants secure calls, then it can configure that on the phone and so this would block any automatic downgrade. In an other situation, the user could hear a warning tone or message saying that the security downgrade is about occur. Then if the user doesn't like it they can just hang up. As Paul says, downgrade is valid. Regards, Attila -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: 27 July 2007 00:17 To: Robert Sparks Cc: IETF SIP List; Francois Audet Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Is the 480 intended to be *indistinguishable* from a 480 returned as a result of no registrations at all? Or is it intended to be distinguishable but more obscure than an explicit error response? I think it needs to be distinguishable, one way or another. The reason is that there are UIs where it makes sense to downgrade. For instance: The input to the UI of the UA is just a dial string, not a URI. It is up to the UA to decide what scheme to apply. It can do this based on policy, or perhaps based on a "secure" button on the phone. Typically the user won't know whether a particular number should be sip or sips.=20 (Or even what that means.) The phone may decide to try sips first and downgrade to sip if the sips doesn't work. If sips works then it can display some sort of indication that the call is more secure than if sip is used. If the UA can't tell why the sips request failed then it will have to retry the call in all cases. The bottom line is that whether to downgrade is a valid policy issue, and we shouldn't arbitrarily block it from working. Paul Robert Sparks wrote: > I think the 480 approach described below is the right thing to do. >=20 > RjS >=20 > On Jul 26, 2007, at 4:03 PM, Francois Audet wrote: >=20 >> In the meeting, the issue of the error code to be used when the wrong >> URI is used in a request-URI (i.e., sip instead of sips, or=20 >> vice-versa) came up. >> >> The status quo is 2 new error codes (418 and 419). Another proposal=20 >> was to use only one (i.e., 418 with 2 new headers). >> >> That proposal did not seem to get much traction. And people were not=20 >> very with the status quo either. >> >> Another proposal was to use 480 (Temporarily Unavailable) and NOT to=20 >> use an explicit indication of the required/supported URIs (SIP, SIPS, >> etc.). Of course, one can always put text in the reason phrase to=20 >> describe the error for displaying to the end-use. >> >> After talking to all the individual who seemed to have strong=20 >> opinions on this topic, it appears that the 480 approach is the=20 >> preferred approach. >> >> Please let the list know if you are strongly opposed to this outcome, >> along with the reasons behind your opposition. >> >> This is the last remaining issue to be closed in the draft, as a=20 >> result of WGLC. >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use=20 >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 >> sipping@ietf.org for new developments on the application of sip >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 27 01:59:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEIr3-0005ay-UB; Fri, 27 Jul 2007 01:59:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IEIr1-0005aq-Hp for sip-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 01:59:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEIr1-0005ai-71 for sip@ietf.org; Fri, 27 Jul 2007 01:59:11 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEIqz-00027C-DW for sip@ietf.org; Fri, 27 Jul 2007 01:59:11 -0400 Received: from hkaplan [67.97.210.2] by acmepacket.com with ESMTP (SMTPD-9.10) id A9AB0230; Fri, 27 Jul 2007 01:59:07 -0400 From: "Hadriel Kaplan" To: "'Paul Kyzivat'" , "'Robert Sparks'" References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com><247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Fri, 27 Jul 2007 01:59:07 -0400 Message-ID: <003d01c7d013$3ee7e790$cd108182@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfP2yba8ZT5fiNTSKC+jfK8gJjMcwANV8yA In-Reply-To: <46A92B7C.7080202@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: 'IETF SIP List' , 'Francois Audet' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree with Paul mostly. Especially since I think we would also want the UAC to *upgrade* if it tried sip but the AoR was only registered at sips. (note I mean the UAC upgrading, not the proxy of course) Obfuscating the error seems wrong. (clever though :) -hadriel > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, July 26, 2007 7:17 PM > To: Robert Sparks > Cc: IETF SIP List; Francois Audet > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > Is the 480 intended to be *indistinguishable* from a 480 returned as a > result of no registrations at all? Or is it intended to be > distinguishable but more obscure than an explicit error response? > > I think it needs to be distinguishable, one way or another. > > The reason is that there are UIs where it makes sense to downgrade. For > instance: > > The input to the UI of the UA is just a dial string, not a URI. It is up > to the UA to decide what scheme to apply. It can do this based on > policy, or perhaps based on a "secure" button on the phone. Typically > the user won't know whether a particular number should be sip or sips. > (Or even what that means.) The phone may decide to try sips first and > downgrade to sip if the sips doesn't work. If sips works then it can > display some sort of indication that the call is more secure than if sip > is used. > > If the UA can't tell why the sips request failed then it will have to > retry the call in all cases. > > The bottom line is that whether to downgrade is a valid policy issue, > and we shouldn't arbitrarily block it from working. > > Paul > > Robert Sparks wrote: > > I think the 480 approach described below is the right thing to do. > > > > RjS > > > > On Jul 26, 2007, at 4:03 PM, Francois Audet wrote: > > > >> In the meeting, the issue of the error code to be used when the wrong > >> URI is > >> used in a request-URI (i.e., sip instead of sips, or vice-versa) came > >> up. > >> > >> The status quo is 2 new error codes (418 and 419). Another proposal was > >> to use only one > >> (i.e., 418 with 2 new headers). > >> > >> That proposal did not seem to get much traction. And people were not > >> very with the > >> status quo either. > >> > >> Another proposal was to use 480 (Temporarily Unavailable) and NOT to > use > >> an explicit > >> indication of the required/supported URIs (SIP, SIPS, etc.). Of course, > >> one can always > >> put text in the reason phrase to describe the error for displaying to > >> the end-use. > >> > >> After talking to all the individual who seemed to have strong opinions > >> on this topic, > >> it appears that the 480 approach is the preferred approach. > >> > >> Please let the list know if you are strongly opposed to this outcome, > >> along with the > >> reasons behind your opposition. > >> > >> This is the last remaining issue to be closed in the draft, as a result > >> of WGLC. > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 27 03:08:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEJvu-0004Kt-UQ; Fri, 27 Jul 2007 03:08:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IEJvt-0004Ki-L1 for sip-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 03:08:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEJvt-0004Ka-BS for sip@ietf.org; Fri, 27 Jul 2007 03:08:17 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEJvs-0003AZ-En for sip@ietf.org; Fri, 27 Jul 2007 03:08:17 -0400 Received: by py-out-1112.google.com with SMTP id f31so2593463pyh for ; Fri, 27 Jul 2007 00:08:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ID5jdFkkhHsxskHyy+/o6OEqF6/USMNErcRQN/QXq9tYmfbso8V9sAMf92R9HwTNQccbx7WFBSEyfJi1Q9sH4AB3Qt4+1GMKMl1DodftcexQMBzMHdlttlA3vyMnboNfQ39tRPnbxiRTwr6CFlNuZ78S93xXEcz8zitzFUpWd4c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=gxdVHQShuYvKOpAPSooQZsOEu0YLcidvhYiJWRIEIHyrQWwGKxuMSKnSwIN367tP0ktguIWcbb+pvYkVEIhsOulcuhtBLoqTCOmyqvs2FFNGl3d4UaAlisijoqo9sNRhHUbdGnQbaNCwU8BaHgy33DyJC+yIB2iH2dI/QrnIqN8= Received: by 10.65.196.2 with SMTP id y2mr4471295qbp.1185520095602; Fri, 27 Jul 2007 00:08:15 -0700 (PDT) Received: by 10.65.254.11 with HTTP; Fri, 27 Jul 2007 00:08:15 -0700 (PDT) Message-ID: <66cd252f0707270008k758aa683i833241b8d5fa2f48@mail.gmail.com> Date: Fri, 27 Jul 2007 17:08:15 +1000 From: "Hisham Khartabil" To: "Paul Kyzivat" Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 In-Reply-To: <46A92B7C.7080202@cisco.com> MIME-Version: 1.0 References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: IETF SIP List , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1269492937==" Errors-To: sip-bounces@ietf.org --===============1269492937== Content-Type: multipart/alternative; boundary="----=_Part_1354_7073718.1185520095468" ------=_Part_1354_7073718.1185520095468 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I also agree with Paul's views. Can someone elaborate as to why it is not desirable for a UAC to retry automatically? This could be a check box in the setting menu. Regards, Hisham On 27/07/07, Paul Kyzivat wrote: > > Is the 480 intended to be *indistinguishable* from a 480 returned as a > result of no registrations at all? Or is it intended to be > distinguishable but more obscure than an explicit error response? > > I think it needs to be distinguishable, one way or another. > > The reason is that there are UIs where it makes sense to downgrade. For > instance: > > The input to the UI of the UA is just a dial string, not a URI. It is up > to the UA to decide what scheme to apply. It can do this based on > policy, or perhaps based on a "secure" button on the phone. Typically > the user won't know whether a particular number should be sip or sips. > (Or even what that means.) The phone may decide to try sips first and > downgrade to sip if the sips doesn't work. If sips works then it can > display some sort of indication that the call is more secure than if sip > is used. > > If the UA can't tell why the sips request failed then it will have to > retry the call in all cases. > > The bottom line is that whether to downgrade is a valid policy issue, > and we shouldn't arbitrarily block it from working. > > Paul > > Robert Sparks wrote: > > I think the 480 approach described below is the right thing to do. > > > > RjS > > > > On Jul 26, 2007, at 4:03 PM, Francois Audet wrote: > > > >> In the meeting, the issue of the error code to be used when the wrong > >> URI is > >> used in a request-URI (i.e., sip instead of sips, or vice-versa) came > >> up. > >> > >> The status quo is 2 new error codes (418 and 419). Another proposal was > >> to use only one > >> (i.e., 418 with 2 new headers). > >> > >> That proposal did not seem to get much traction. And people were not > >> very with the > >> status quo either. > >> > >> Another proposal was to use 480 (Temporarily Unavailable) and NOT to > use > >> an explicit > >> indication of the required/supported URIs (SIP, SIPS, etc.). Of course, > >> one can always > >> put text in the reason phrase to describe the error for displaying to > >> the end-use. > >> > >> After talking to all the individual who seemed to have strong opinions > >> on this topic, > >> it appears that the 480 approach is the preferred approach. > >> > >> Please let the list know if you are strongly opposed to this outcome, > >> along with the > >> reasons behind your opposition. > >> > >> This is the last remaining issue to be closed in the draft, as a result > >> of WGLC. > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------=_Part_1354_7073718.1185520095468 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
        I also agree with Paul's views. Can someone elaborate as to why it is not desirable for a UAC to retry automatically? This could be a check box in the setting menu.
         
        Regards,
        Hisham

         
        On 27/07/07, Paul Kyzivat <pkyzivat@cisco.com> wrote:
        Is the 480 intended to be *indistinguishable* from a 480 returned as a
        result of no registrations at all? Or is it intended to be
        distinguishable but more obscure than an explicit error response?

        I think it needs to be distinguishable, one way or another.

        The reason is that there are UIs where it makes sense to downgrade. For
        instance:

        The input to the UI of the UA is just a dial string, not a URI. It is up
        to the UA to decide what scheme to apply. It can do this based on
        policy, or perhaps based on a "secure" button on the phone. Typically
        the user won't know whether a particular number should be sip or sips.
        (Or even what that means.) The phone may decide to try sips first and
        downgrade to sip if the sips doesn't work. If sips works then it can
        display some sort of indication that the call is more secure than if sip
        is used.

        If the UA can't tell why the sips request failed then it will have to
        retry the call in all cases.

        The bottom line is that whether to downgrade is a valid policy issue,
        and we shouldn't arbitrarily block it from working.

               Paul

        Robert Sparks wrote:
        > I think the 480 approach described below is the right thing to do.
        >
        > RjS
        >
        > On Jul 26, 2007, at 4:03 PM, Francois Audet wrote:
        >
        >> In the meeting, the issue of the error code to be used when the wrong
        >> URI is
        >> used in a request-URI (i.e., sip instead of sips, or vice-versa) came
        >> up.
        >>
        >> The status quo is 2 new error codes (418 and 419). Another proposal was
        >> to use only one
        >> (i.e., 418 with 2 new headers).
        >>
        >> That proposal did not seem to get much traction. And people were not
        >> very with the
        >> status quo either.
        >>
        >> Another proposal was to use 480 (Temporarily Unavailable) and NOT to use
        >> an explicit
        >> indication of the required/supported URIs (SIP, SIPS, etc.). Of course,
        >> one can always
        >> put text in the reason phrase to describe the error for displaying to
        >> the end-use.
        >>
        >> After talking to all the individual who seemed to have strong opinions
        >> on this topic,
        >> it appears that the 480 approach is the preferred approach.
        >>
        >> Please let the list know if you are strongly opposed to this outcome,
        >> along with the
        >> reasons behind your opposition.
        >>
        >> This is the last remaining issue to be closed in the draft, as a result
        >> of WGLC.
        >>
        >>
        >> _______________________________________________
        >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
        >> This list is for NEW development of the core SIP Protocol
        >> Use sip-implementors@cs.columbia.edu for questions on current sip
        >> Use sipping@ietf.org for new developments on the application of sip
        >
        >
        >
        > _______________________________________________
        > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
        > This list is for NEW development of the core SIP Protocol
        > Use sip-implementors@cs.columbia.edu for questions on current sip
        > Use sipping@ietf.org for new developments on the application of sip
        >


        _______________________________________________
        Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
        This list is for NEW development of the core SIP Protocol
        Use sip-implementors@cs.columbia.edu for questions on current sip
        Use sipping@ietf.org for new developments on the application of sip

        ------=_Part_1354_7073718.1185520095468-- --===============1269492937== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1269492937==-- From sip-bounces@ietf.org Fri Jul 27 10:35:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEQuj-0002H4-0y; Fri, 27 Jul 2007 10:35:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IEQuh-0002Gx-RV for sip-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 10:35:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEQuh-0002Go-I4 for sip@ietf.org; Fri, 27 Jul 2007 10:35:31 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEQuh-0005eY-02 for sip@ietf.org; Fri, 27 Jul 2007 10:35:31 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6REZHD26044; Fri, 27 Jul 2007 14:35:17 GMT 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 Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Fri, 27 Jul 2007 09:35:12 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> In-reply-to: <46A92B7C.7080202@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfP2ygLiuKMrg1tTAm19cu36EAuqgAfuEZA References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" , , "Rohan Mahy" , "Eric Rescorla" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The intent is to be UNDISTINGUISHABLE. We do NOT want the equipment to automatically downgrade. We want the user to make the decision in a concious way. Furthermore, we want to emphasise that the SIP and SIPS are=20 different addresses and are not interchangeable. Rohan Mahy, Jon Peterson, Eric Rescorla, Since you were the main people advocating this change, can=20 you make clear on the list what the rationale is. Thanks. =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Thursday, July 26, 2007 16:17 > To: Robert Sparks > Cc: Audet, Francois (SC100:3055); IETF SIP List > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >=20 > Is the 480 intended to be *indistinguishable* from a 480=20 > returned as a result of no registrations at all? Or is it=20 > intended to be distinguishable but more obscure than an=20 > explicit error response? >=20 > I think it needs to be distinguishable, one way or another. >=20 > The reason is that there are UIs where it makes sense to=20 > downgrade. For > instance: >=20 > The input to the UI of the UA is just a dial string, not a=20 > URI. It is up to the UA to decide what scheme to apply. It=20 > can do this based on policy, or perhaps based on a "secure"=20 > button on the phone. Typically the user won't know whether a=20 > particular number should be sip or sips.=20 > (Or even what that means.) The phone may decide to try sips=20 > first and downgrade to sip if the sips doesn't work. If sips=20 > works then it can display some sort of indication that the=20 > call is more secure than if sip is used. >=20 > If the UA can't tell why the sips request failed then it will=20 > have to retry the call in all cases. >=20 > The bottom line is that whether to downgrade is a valid=20 > policy issue, and we shouldn't arbitrarily block it from working. >=20 > Paul >=20 > Robert Sparks wrote: > > I think the 480 approach described below is the right thing to do. > >=20 > > RjS > >=20 > > On Jul 26, 2007, at 4:03 PM, Francois Audet wrote: > >=20 > >> In the meeting, the issue of the error code to be used=20 > when the wrong=20 > >> URI is used in a request-URI (i.e., sip instead of sips, or=20 > >> vice-versa) came up. > >> > >> The status quo is 2 new error codes (418 and 419). Another=20 > proposal=20 > >> was to use only one (i.e., 418 with 2 new headers). > >> > >> That proposal did not seem to get much traction. And=20 > people were not=20 > >> very with the status quo either. > >> > >> Another proposal was to use 480 (Temporarily Unavailable)=20 > and NOT to=20 > >> use an explicit indication of the required/supported URIs=20 > (SIP, SIPS,=20 > >> etc.). Of course, one can always put text in the reason phrase to=20 > >> describe the error for displaying to the end-use. > >> > >> After talking to all the individual who seemed to have strong=20 > >> opinions on this topic, it appears that the 480 approach is the=20 > >> preferred approach. > >> > >> Please let the list know if you are strongly opposed to=20 > this outcome,=20 > >> along with the reasons behind your opposition. > >> > >> This is the last remaining issue to be closed in the draft, as a=20 > >> result of WGLC. > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 27 10:40:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEQzL-0007NE-43; Fri, 27 Jul 2007 10:40:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IEQzI-0007Hl-Ur for sip-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 10:40:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEQzI-0007Gv-Iv for sip@ietf.org; Fri, 27 Jul 2007 10:40:16 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEQzH-00061U-Us for sip@ietf.org; Fri, 27 Jul 2007 10:40:16 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6REeCD26847; Fri, 27 Jul 2007 14:40:12 GMT 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 Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Fri, 27 Jul 2007 09:40:11 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF116E20CB@zrc2hxm0.corp.nortel.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfP2Kw9qykbE4ZUQ0OEUnKzLggxMQAgsaAw References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF11697876@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "James M. Polk" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org 400 =3D=3D Bad Request (i.e., there is something wrong with it) 480 =3D=3D Temporarily Unavailable (i.e., there is currently no Contact binding associated with the URI)=20 If I send a request to a SIPS Request-URI and there is no current binding to a SIPS Contact, then I will receive a 480. If I send a where the Request-URI is SIPS, but the Contact is SIP, then I get a 400. > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > Sent: Thursday, July 26, 2007 16:00 > To: Audet, Francois (SC100:3055); IETF SIP List > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >=20 > Francois >=20 > I just don't see the difference between a 480 and a 400 in this case.=20 > Either way, the UAC is left clueless, and hopeless (because=20 > it doesn't understand the real reason things went south). >=20 > I prefer telling the UAC what the error was. This is making a=20 > policy decision for the user of the UAC at the protocol level=20 > without their ability to make a choice, while blinding them=20 > to what actually happened. >=20 > I can give lots of examples outside of calling where this=20 > would be endlessly frustrating, and a few that are within calling... >=20 > At 05:21 PM 7/26/2007, Francois Audet wrote: > >Hi James, > > > >The specific reason why many were advocating a 480 instead of a new=20 > >error code is exactly because they did NOT want the error code to=20 > >encourage UAC to reattempt the request by downgrading to SIP=20 > >automatically. > > > >This is the point that Eric Rescorla was making in the=20 > meeting, and it=20 > >has been re-iterated in one way or another by both Jon=20 > Peterson and by=20 > >Rohan Mahy. > > > >You *could* of course with this approach use a reason phrase=20 > in the 480=20 > >to provide a message to the user of what the issue is. > > > > > -----Original Message----- > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > Sent: Thursday, July 26, 2007 14:31 > > > To: Audet, Francois (SC100:3055); IETF SIP List > > > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > > > > > At 04:03 PM 7/26/2007, Francois Audet wrote: > > > >In the meeting, the issue of the error code to be used when > > > the wrong > > > >URI is used in a request-URI (i.e., sip instead of sips, or > > > vice-versa) came up. > > > > > > > >The status quo is 2 new error codes (418 and 419). > > > > > > (BTW 419 is used by Cullen's hashcash draft) > > > > > > >Another proposal was to use only one (i.e., 418 with 2=20 > new headers). > > > > > > I would advocate this proposal, especially verses a 480, as a > > > (new) Reason code to give the specifics can easily be=20 > stripped along=20 > > > the way back to the UAC, leaving it clueless as to what=20 > the actual=20 > > > problem was. Also not all implementations support Reason (though=20 > > > they should). > > > > > > A 418 is specific to the point of what was wrong.... and all UACs=20 > > > have to deal with the fact they can become a 400 (thus=20 > removing the=20 > > > details) > > > > > > > > > >That proposal did not seem to get much traction. And people were=20 > > > >not very with the status quo either. > > > > > > > >Another proposal was to use 480 (Temporarily Unavailable) > > > and NOT to use > > > >an explicit indication of the required/supported URIs=20 > (SIP, SIPS,=20 > > > >etc.). Of course, one can always put text in the reason=20 > phrase to=20 > > > >describe the error for displaying to the end-use. > > > > > > > >After talking to all the individual who seemed to have > > > strong opinions > > > >on this topic, it appears that the 480 approach is the > > > preferred approach. > > > > > > > >Please let the list know if you are strongly opposed to this=20 > > > >outcome, along with the reasons behind your opposition. > > > > > > > >This is the last remaining issue to be closed in the draft, > > > as a result > > > >of WGLC. > > > > > > > > > > > >_______________________________________________ > > > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > >This list is for NEW development of the core SIP Protocol Use=20 > > > >sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > >sipping@ietf.org for new developments on the application of sip > > > >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 27 10:58:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERGn-0005Bq-C7; Fri, 27 Jul 2007 10:58:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IERGl-0005Bi-O4 for sip-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 10:58:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERGl-0005BX-Cg for sip@ietf.org; Fri, 27 Jul 2007 10:58:19 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IERGk-0006OO-MY for sip@ietf.org; Fri, 27 Jul 2007 10:58:19 -0400 Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-1.cisco.com with ESMTP; 27 Jul 2007 07:58:18 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAJqkqUasE2C2/2dsb2JhbAAN X-IronPort-AV: i="4.16,589,1175497200"; d="scan'208"; a="10896096:sNHT15779988" Received: from [64.142.29.213] ([10.21.80.67]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l6RDcXhJ006405; Fri, 27 Jul 2007 06:38:33 -0700 Message-ID: <46AA080C.2010501@cisco.com> Date: Fri, 27 Jul 2007 07:58:20 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.12) Gecko/20070509 Thunderbird/1.5.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4591; t=1185543514; x=1186407514; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20draft-ietf-sip-sips-05=3A=20480=20vs.=20418 |Sender:=20 |To:=20Francois=20Audet=20; bh=5DWDICPKQp6oQsVHz9hJ4PWMQZd7ElHIwZiSGuMaeqM=; b=ILnPxzeqkVZL1Ia4kvpXuqrRYZgh+3cr5Du/uTPREM/SjlV5HGzowre3EXSi1pvnFJAwZenu +jBLxPhNflQmgRpAVZlhVmiHpNU6504kFxVxpuPvKUpkTGySUsJBTY4A; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: IETF SIP List , Rohan Mahy , Paul Kyzivat , Jon.Peterson@neustar.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org You mean, security through obscurity? I guess it's about par for SIPS course. Mike Francois Audet wrote: > The intent is to be UNDISTINGUISHABLE. > > We do NOT want the equipment to automatically downgrade. We want > the user to make the decision in a concious way. > > Furthermore, we want to emphasise that the SIP and SIPS are > different addresses and are not interchangeable. > > Rohan Mahy, Jon Peterson, Eric Rescorla, > > Since you were the main people advocating this change, can > you make clear on the list what the rationale is. > > Thanks. > > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, July 26, 2007 16:17 >> To: Robert Sparks >> Cc: Audet, Francois (SC100:3055); IETF SIP List >> Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >> >> Is the 480 intended to be *indistinguishable* from a 480 >> returned as a result of no registrations at all? Or is it >> intended to be distinguishable but more obscure than an >> explicit error response? >> >> I think it needs to be distinguishable, one way or another. >> >> The reason is that there are UIs where it makes sense to >> downgrade. For >> instance: >> >> The input to the UI of the UA is just a dial string, not a >> URI. It is up to the UA to decide what scheme to apply. It >> can do this based on policy, or perhaps based on a "secure" >> button on the phone. Typically the user won't know whether a >> particular number should be sip or sips. >> (Or even what that means.) The phone may decide to try sips >> first and downgrade to sip if the sips doesn't work. If sips >> works then it can display some sort of indication that the >> call is more secure than if sip is used. >> >> If the UA can't tell why the sips request failed then it will >> have to retry the call in all cases. >> >> The bottom line is that whether to downgrade is a valid >> policy issue, and we shouldn't arbitrarily block it from working. >> >> Paul >> >> Robert Sparks wrote: >> >>> I think the 480 approach described below is the right thing to do. >>> >>> RjS >>> >>> On Jul 26, 2007, at 4:03 PM, Francois Audet wrote: >>> >>> >>>> In the meeting, the issue of the error code to be used >>>> >> when the wrong >> >>>> URI is used in a request-URI (i.e., sip instead of sips, or >>>> vice-versa) came up. >>>> >>>> The status quo is 2 new error codes (418 and 419). Another >>>> >> proposal >> >>>> was to use only one (i.e., 418 with 2 new headers). >>>> >>>> That proposal did not seem to get much traction. And >>>> >> people were not >> >>>> very with the status quo either. >>>> >>>> Another proposal was to use 480 (Temporarily Unavailable) >>>> >> and NOT to >> >>>> use an explicit indication of the required/supported URIs >>>> >> (SIP, SIPS, >> >>>> etc.). Of course, one can always put text in the reason phrase to >>>> describe the error for displaying to the end-use. >>>> >>>> After talking to all the individual who seemed to have strong >>>> opinions on this topic, it appears that the 480 approach is the >>>> preferred approach. >>>> >>>> Please let the list know if you are strongly opposed to >>>> >> this outcome, >> >>>> along with the reasons behind your opposition. >>>> >>>> This is the last remaining issue to be closed in the draft, as a >>>> result of WGLC. >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sipping@ietf.org for new developments on the application of sip >>>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >>> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 27 11:06:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEROf-0004LK-PT; Fri, 27 Jul 2007 11:06:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IEROd-0004LD-LW for sip-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 11:06:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEROd-0004L5-A3 for sip@ietf.org; Fri, 27 Jul 2007 11:06:27 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEROc-0006ah-KM for sip@ietf.org; Fri, 27 Jul 2007 11:06:27 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l6RF4aX29855; Fri, 27 Jul 2007 15:04:37 GMT 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 Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Fri, 27 Jul 2007 10:06:18 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF116E213B@zrc2hxm0.corp.nortel.com> In-reply-to: <46AA080C.2010501@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfQXpfdgtv0G2YXRKqFuLvGKV0NNQAALf5Q References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <46AA080C.2010501@cisco.com> From: "Francois Audet" To: "Michael Thomas" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Oh, please with the rethoric.=20 Again, the idea is that a sip address is different than a sips address. If you use a sip address when a sips is expected, then you'd get=20 the behavior you'd get for when there is no binging assigned. It's as simple as that. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com]=20 > Sent: Friday, July 27, 2007 07:58 > To: Audet, Francois (SC100:3055) > Cc: Paul Kyzivat; Jon.Peterson@neustar.com; Rohan Mahy; Eric=20 > Rescorla; IETF SIP List > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >=20 > You mean, security through obscurity? I guess it's about par=20 > for SIPS course. >=20 > Mike >=20 > Francois Audet wrote: > > The intent is to be UNDISTINGUISHABLE. > > > > We do NOT want the equipment to automatically downgrade. We=20 > want the=20 > > user to make the decision in a concious way. > > > > Furthermore, we want to emphasise that the SIP and SIPS are=20 > different=20 > > addresses and are not interchangeable. > > > > Rohan Mahy, Jon Peterson, Eric Rescorla, > > > > Since you were the main people advocating this change, can you make=20 > > clear on the list what the rationale is. > > > > Thanks. > > =20 > > > > =20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Thursday, July 26, 2007 16:17 > >> To: Robert Sparks > >> Cc: Audet, Francois (SC100:3055); IETF SIP List > >> Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > >> > >> Is the 480 intended to be *indistinguishable* from a 480=20 > returned as=20 > >> a result of no registrations at all? Or is it intended to be=20 > >> distinguishable but more obscure than an explicit error response? > >> > >> I think it needs to be distinguishable, one way or another. > >> > >> The reason is that there are UIs where it makes sense to=20 > downgrade.=20 > >> For > >> instance: > >> > >> The input to the UI of the UA is just a dial string, not a=20 > URI. It is=20 > >> up to the UA to decide what scheme to apply. It can do=20 > this based on=20 > >> policy, or perhaps based on a "secure" > >> button on the phone. Typically the user won't know whether a=20 > >> particular number should be sip or sips. > >> (Or even what that means.) The phone may decide to try=20 > sips first and=20 > >> downgrade to sip if the sips doesn't work. If sips works=20 > then it can=20 > >> display some sort of indication that the call is more=20 > secure than if=20 > >> sip is used. > >> > >> If the UA can't tell why the sips request failed then it=20 > will have to=20 > >> retry the call in all cases. > >> > >> The bottom line is that whether to downgrade is a valid=20 > policy issue,=20 > >> and we shouldn't arbitrarily block it from working. > >> > >> Paul > >> > >> Robert Sparks wrote: > >> =20 > >>> I think the 480 approach described below is the right thing to do. > >>> > >>> RjS > >>> > >>> On Jul 26, 2007, at 4:03 PM, Francois Audet wrote: > >>> > >>> =20 > >>>> In the meeting, the issue of the error code to be used > >>>> =20 > >> when the wrong > >> =20 > >>>> URI is used in a request-URI (i.e., sip instead of sips, or > >>>> vice-versa) came up. > >>>> > >>>> The status quo is 2 new error codes (418 and 419). Another > >>>> =20 > >> proposal > >> =20 > >>>> was to use only one (i.e., 418 with 2 new headers). > >>>> > >>>> That proposal did not seem to get much traction. And > >>>> =20 > >> people were not > >> =20 > >>>> very with the status quo either. > >>>> > >>>> Another proposal was to use 480 (Temporarily Unavailable) > >>>> =20 > >> and NOT to > >> =20 > >>>> use an explicit indication of the required/supported URIs > >>>> =20 > >> (SIP, SIPS, > >> =20 > >>>> etc.). Of course, one can always put text in the reason=20 > phrase to=20 > >>>> describe the error for displaying to the end-use. > >>>> > >>>> After talking to all the individual who seemed to have strong=20 > >>>> opinions on this topic, it appears that the 480 approach is the=20 > >>>> preferred approach. > >>>> > >>>> Please let the list know if you are strongly opposed to > >>>> =20 > >> this outcome, > >> =20 > >>>> along with the reasons behind your opposition. > >>>> > >>>> This is the last remaining issue to be closed in the draft, as a=20 > >>>> result of WGLC. > >>>> > >>>> > >>>> _______________________________________________ > >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>> This list is for NEW development of the core SIP Protocol Use=20 > >>>> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > >>>> sipping@ietf.org for new developments on the application of sip > >>>> =20 > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol Use=20 > >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>> sipping@ietf.org for new developments on the application of sip > >>> > >>> =20 > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > > =20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 27 11:06:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERP3-0004a0-Qq; Fri, 27 Jul 2007 11:06:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IERP2-0004ZW-70 for sip-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 11:06:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERP1-0004ZN-Rr for sip@ietf.org; Fri, 27 Jul 2007 11:06:51 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IERP1-0006bd-6h for sip@ietf.org; Fri, 27 Jul 2007 11:06:51 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 27 Jul 2007 11:06:50 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswMAHamqUZAZnme/2dsb2JhbACIYp0+ X-IronPort-AV: i="4.16,589,1175486400"; d="scan'208"; a="66341742:sNHT30850480" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6RF6ooP026962; Fri, 27 Jul 2007 11:06:50 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6RF6KWg017982; Fri, 27 Jul 2007 15:06:31 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 11:06:29 -0400 Received: from [10.86.241.172] ([10.86.241.172]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 11:06:28 -0400 Message-ID: <46AA09F1.6010401@cisco.com> Date: Fri, 27 Jul 2007 11:06:25 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2007 15:06:28.0706 (UTC) FILETIME=[B5642C20:01C7D05F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4375; t=1185548810; x=1186412810; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20draft-ietf-sip-sips-05=3A=20480=20vs.=20418 |Sender:=20 |To:=20Francois=20Audet=20; bh=ryp6RUxGOsieNmpZuZ2syRcNxUrHT290tnulpa80XqU=; b=d4D2yHMhKyCntU1u98mGF2lWYDYwPrwfpG3NDpKqU2YIEl/SOwY89lt7JoPnzE9i1k535TsX cbJa8qDpS/iLZf1QcNP7FH9QwEmXPspxUMde5BNtX6RT2ne7M9Jmu/ku; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: IETF SIP List , Rohan Mahy , Jon.Peterson@neustar.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I understand that if the user entered a sips URI then it should be the user that must decide to downgrade. But if the user didn't know whether to use sip or sips in the first place, and the UA decides to try sips first then I see no problem in the UA having a policy that causes it to downgrade. This is highly related to how security is managed in the user interface. Paul Francois Audet wrote: > The intent is to be UNDISTINGUISHABLE. > > We do NOT want the equipment to automatically downgrade. We want > the user to make the decision in a concious way. > > Furthermore, we want to emphasise that the SIP and SIPS are > different addresses and are not interchangeable. > > Rohan Mahy, Jon Peterson, Eric Rescorla, > > Since you were the main people advocating this change, can > you make clear on the list what the rationale is. > > Thanks. > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, July 26, 2007 16:17 >> To: Robert Sparks >> Cc: Audet, Francois (SC100:3055); IETF SIP List >> Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >> >> Is the 480 intended to be *indistinguishable* from a 480 >> returned as a result of no registrations at all? Or is it >> intended to be distinguishable but more obscure than an >> explicit error response? >> >> I think it needs to be distinguishable, one way or another. >> >> The reason is that there are UIs where it makes sense to >> downgrade. For >> instance: >> >> The input to the UI of the UA is just a dial string, not a >> URI. It is up to the UA to decide what scheme to apply. It >> can do this based on policy, or perhaps based on a "secure" >> button on the phone. Typically the user won't know whether a >> particular number should be sip or sips. >> (Or even what that means.) The phone may decide to try sips >> first and downgrade to sip if the sips doesn't work. If sips >> works then it can display some sort of indication that the >> call is more secure than if sip is used. >> >> If the UA can't tell why the sips request failed then it will >> have to retry the call in all cases. >> >> The bottom line is that whether to downgrade is a valid >> policy issue, and we shouldn't arbitrarily block it from working. >> >> Paul >> >> Robert Sparks wrote: >>> I think the 480 approach described below is the right thing to do. >>> >>> RjS >>> >>> On Jul 26, 2007, at 4:03 PM, Francois Audet wrote: >>> >>>> In the meeting, the issue of the error code to be used >> when the wrong >>>> URI is used in a request-URI (i.e., sip instead of sips, or >>>> vice-versa) came up. >>>> >>>> The status quo is 2 new error codes (418 and 419). Another >> proposal >>>> was to use only one (i.e., 418 with 2 new headers). >>>> >>>> That proposal did not seem to get much traction. And >> people were not >>>> very with the status quo either. >>>> >>>> Another proposal was to use 480 (Temporarily Unavailable) >> and NOT to >>>> use an explicit indication of the required/supported URIs >> (SIP, SIPS, >>>> etc.). Of course, one can always put text in the reason phrase to >>>> describe the error for displaying to the end-use. >>>> >>>> After talking to all the individual who seemed to have strong >>>> opinions on this topic, it appears that the 480 approach is the >>>> preferred approach. >>>> >>>> Please let the list know if you are strongly opposed to >> this outcome, >>>> along with the reasons behind your opposition. >>>> >>>> This is the last remaining issue to be closed in the draft, as a >>>> result of WGLC. >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sipping@ietf.org for new developments on the application of sip >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 27 11:20:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERcZ-0007Yb-39; Fri, 27 Jul 2007 11:20:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IERcW-0007V6-NU for sip-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 11:20:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERcW-0007Us-Cb for sip@ietf.org; Fri, 27 Jul 2007 11:20:48 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IERcV-0006wc-J0 for sip@ietf.org; Fri, 27 Jul 2007 11:20:48 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l6RFKWp03114; Fri, 27 Jul 2007 08:20:32 -0700 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4A0CEE16-D704-4C8B-8199-D6A772B09DED@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Fri, 27 Jul 2007 10:20:31 -0500 To: "Francois Audet" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: Rohan Mahy , IETF SIP List , Paul Kyzivat , Jon.Peterson@neustar.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I think 480 has the correct semantics. When an authoritative proxy has no Contacts registered for a resource (in this case it is a "sips" resource), the correct response code is 480. In addition we don't want the UAC to automatically downgrade because it mistakenly thinks that's the right thing to do. My intent however was not to make this indistinguishable, since I proposed adding a Warning: header. I think it is useful to have the reason there where no relevant Contacts. thanks, -rohan On Jul 27, 2007, at 9:35 AM, Francois Audet wrote: > The intent is to be UNDISTINGUISHABLE. > > We do NOT want the equipment to automatically downgrade. We want > the user to make the decision in a concious way. > > Furthermore, we want to emphasise that the SIP and SIPS are > different addresses and are not interchangeable. > > Rohan Mahy, Jon Peterson, Eric Rescorla, > > Since you were the main people advocating this change, can > you make clear on the list what the rationale is. > > Thanks. > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, July 26, 2007 16:17 >> To: Robert Sparks >> Cc: Audet, Francois (SC100:3055); IETF SIP List >> Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >> >> Is the 480 intended to be *indistinguishable* from a 480 >> returned as a result of no registrations at all? Or is it >> intended to be distinguishable but more obscure than an >> explicit error response? >> >> I think it needs to be distinguishable, one way or another. >> >> The reason is that there are UIs where it makes sense to >> downgrade. For >> instance: >> >> The input to the UI of the UA is just a dial string, not a >> URI. It is up to the UA to decide what scheme to apply. It >> can do this based on policy, or perhaps based on a "secure" >> button on the phone. Typically the user won't know whether a >> particular number should be sip or sips. >> (Or even what that means.) The phone may decide to try sips >> first and downgrade to sip if the sips doesn't work. If sips >> works then it can display some sort of indication that the >> call is more secure than if sip is used. >> >> If the UA can't tell why the sips request failed then it will >> have to retry the call in all cases. >> >> The bottom line is that whether to downgrade is a valid >> policy issue, and we shouldn't arbitrarily block it from working. >> >> Paul >> >> Robert Sparks wrote: >>> I think the 480 approach described below is the right thing to do. >>> >>> RjS >>> >>> On Jul 26, 2007, at 4:03 PM, Francois Audet wrote: >>> >>>> In the meeting, the issue of the error code to be used >> when the wrong >>>> URI is used in a request-URI (i.e., sip instead of sips, or >>>> vice-versa) came up. >>>> >>>> The status quo is 2 new error codes (418 and 419). Another >> proposal >>>> was to use only one (i.e., 418 with 2 new headers). >>>> >>>> That proposal did not seem to get much traction. And >> people were not >>>> very with the status quo either. >>>> >>>> Another proposal was to use 480 (Temporarily Unavailable) >> and NOT to >>>> use an explicit indication of the required/supported URIs >> (SIP, SIPS, >>>> etc.). Of course, one can always put text in the reason phrase to >>>> describe the error for displaying to the end-use. >>>> >>>> After talking to all the individual who seemed to have strong >>>> opinions on this topic, it appears that the 480 approach is the >>>> preferred approach. >>>> >>>> Please let the list know if you are strongly opposed to >> this outcome, >>>> along with the reasons behind your opposition. >>>> >>>> This is the last remaining issue to be closed in the draft, as a >>>> result of WGLC. >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sipping@ietf.org for new developments on the application of sip >>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 27 11:24:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERff-0004TF-Vq; Fri, 27 Jul 2007 11:24:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IERfe-0004O7-IK for sip-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 11:24:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERfe-0004MA-7I for sip@ietf.org; Fri, 27 Jul 2007 11:24:02 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IERfd-0006mp-B4 for sip@ietf.org; Fri, 27 Jul 2007 11:24:02 -0400 Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 27 Jul 2007 08:24:00 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADqqqUasE2C2/2dsb2JhbAAN X-IronPort-AV: i="4.16,589,1175497200"; d="scan'208"; a="189778915:sNHT309822894" Received: from [64.142.29.213] ([10.21.80.67]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l6RE4FxX007449; Fri, 27 Jul 2007 07:04:15 -0700 Message-ID: <46AA0E11.2010502@cisco.com> Date: Fri, 27 Jul 2007 08:24:01 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.12) Gecko/20070509 Thunderbird/1.5.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <46AA080C.2010501@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E213B@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF116E213B@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6707; t=1185545055; x=1186409055; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20draft-ietf-sip-sips-05=3A=20480=20vs.=20418 |Sender:=20 |To:=20Francois=20Audet=20; bh=268d8dqHBSvLQPbGETausmj53uQk4Dt29OSgszOcMd8=; b=PWPbMr96Zf+e+mDxkCQZpiEE++jj6w7+kL5AVpoV7suHkN7jgAFU48AkTxMH8rvG3Wr9XCtb 2BGI1jKkdyYx4GsaZN4OlCDsRe2NmqsrjWc/9MdYmBJ1Iqdn9orJZqQQ; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't see the point in parsimony on return codes unless you're trying to obscure something. And I don't find "We don't want [...]" particularly compelling as it implies there's a one-size-fits-all on UI design. Were SIPS an end to end mechanism there _might_ be a case to be made (and I'd be extremely dubious even then), but it's far more broken than that so making proscriptions against this or that is rather pointless. Never try to teach a *pig* to sing; it wastes your time and it *annoys the pig*. *...* Mark *Twain Mike * Francois Audet wrote: > Oh, please with the rethoric. > > Again, the idea is that a sip address is different than a sips address. > > If you use a sip address when a sips is expected, then you'd get > the behavior you'd get for when there is no binging assigned. > > It's as simple as that. > > >> -----Original Message----- >> From: Michael Thomas [mailto:mat@cisco.com] >> Sent: Friday, July 27, 2007 07:58 >> To: Audet, Francois (SC100:3055) >> Cc: Paul Kyzivat; Jon.Peterson@neustar.com; Rohan Mahy; Eric >> Rescorla; IETF SIP List >> Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >> >> You mean, security through obscurity? I guess it's about par >> for SIPS course. >> >> Mike >> >> Francois Audet wrote: >> >>> The intent is to be UNDISTINGUISHABLE. >>> >>> We do NOT want the equipment to automatically downgrade. We >>> >> want the >> >>> user to make the decision in a concious way. >>> >>> Furthermore, we want to emphasise that the SIP and SIPS are >>> >> different >> >>> addresses and are not interchangeable. >>> >>> Rohan Mahy, Jon Peterson, Eric Rescorla, >>> >>> Since you were the main people advocating this change, can you make >>> clear on the list what the rationale is. >>> >>> Thanks. >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Thursday, July 26, 2007 16:17 >>>> To: Robert Sparks >>>> Cc: Audet, Francois (SC100:3055); IETF SIP List >>>> Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >>>> >>>> Is the 480 intended to be *indistinguishable* from a 480 >>>> >> returned as >> >>>> a result of no registrations at all? Or is it intended to be >>>> distinguishable but more obscure than an explicit error response? >>>> >>>> I think it needs to be distinguishable, one way or another. >>>> >>>> The reason is that there are UIs where it makes sense to >>>> >> downgrade. >> >>>> For >>>> instance: >>>> >>>> The input to the UI of the UA is just a dial string, not a >>>> >> URI. It is >> >>>> up to the UA to decide what scheme to apply. It can do >>>> >> this based on >> >>>> policy, or perhaps based on a "secure" >>>> button on the phone. Typically the user won't know whether a >>>> particular number should be sip or sips. >>>> (Or even what that means.) The phone may decide to try >>>> >> sips first and >> >>>> downgrade to sip if the sips doesn't work. If sips works >>>> >> then it can >> >>>> display some sort of indication that the call is more >>>> >> secure than if >> >>>> sip is used. >>>> >>>> If the UA can't tell why the sips request failed then it >>>> >> will have to >> >>>> retry the call in all cases. >>>> >>>> The bottom line is that whether to downgrade is a valid >>>> >> policy issue, >> >>>> and we shouldn't arbitrarily block it from working. >>>> >>>> Paul >>>> >>>> Robert Sparks wrote: >>>> >>>> >>>>> I think the 480 approach described below is the right thing to do. >>>>> >>>>> RjS >>>>> >>>>> On Jul 26, 2007, at 4:03 PM, Francois Audet wrote: >>>>> >>>>> >>>>> >>>>>> In the meeting, the issue of the error code to be used >>>>>> >>>>>> >>>> when the wrong >>>> >>>> >>>>>> URI is used in a request-URI (i.e., sip instead of sips, or >>>>>> vice-versa) came up. >>>>>> >>>>>> The status quo is 2 new error codes (418 and 419). Another >>>>>> >>>>>> >>>> proposal >>>> >>>> >>>>>> was to use only one (i.e., 418 with 2 new headers). >>>>>> >>>>>> That proposal did not seem to get much traction. And >>>>>> >>>>>> >>>> people were not >>>> >>>> >>>>>> very with the status quo either. >>>>>> >>>>>> Another proposal was to use 480 (Temporarily Unavailable) >>>>>> >>>>>> >>>> and NOT to >>>> >>>> >>>>>> use an explicit indication of the required/supported URIs >>>>>> >>>>>> >>>> (SIP, SIPS, >>>> >>>> >>>>>> etc.). Of course, one can always put text in the reason >>>>>> >> phrase to >> >>>>>> describe the error for displaying to the end-use. >>>>>> >>>>>> After talking to all the individual who seemed to have strong >>>>>> opinions on this topic, it appears that the 480 approach is the >>>>>> preferred approach. >>>>>> >>>>>> Please let the list know if you are strongly opposed to >>>>>> >>>>>> >>>> this outcome, >>>> >>>> >>>>>> along with the reasons behind your opposition. >>>>>> >>>>>> This is the last remaining issue to be closed in the draft, as a >>>>>> result of WGLC. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP Protocol Use >>>>>> sip-implementors@cs.columbia.edu for questions on >>>>>> >> current sip Use >> >>>>>> sipping@ietf.org for new developments on the application of sip >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol Use >>>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>>> sipping@ietf.org for new developments on the application of sip >>>>> >>>>> >>>>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >>> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 27 11:33:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERoK-0002nA-4n; Fri, 27 Jul 2007 11:33:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IERoI-0002mr-S4 for sip-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 11:32:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERoI-0002mj-IY for sip@ietf.org; Fri, 27 Jul 2007 11:32:58 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IERoH-0006z5-9V for sip@ietf.org; Fri, 27 Jul 2007 11:32:58 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6RFWnD16666; Fri, 27 Jul 2007 15:32:49 GMT 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 Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Fri, 27 Jul 2007 10:32:48 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF116E21C3@zrc2hxm0.corp.nortel.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfQYpRCPxDSlnXaThq8C0tuYUq8ygAADHWA References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <46AA09F1.6010401@cisco.com> From: "Francois Audet" To: "Alan Hawrylyshen" , "Kyzivat Paul" , "Mahy Rohan" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: IETF SIP List , Jon.Peterson@neustar.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On the Warning header... Values 300-379 are reserved for SDP-related stuff. Values 380-389 are unassiged (but there is no text on it). Values 390-398 are unassigned (but don't fall into the SDP related stuff.=20 399 means Miscellaneous and the text can be provided to the user. It further says that Automata MUST NOT take action based on this. Rohan, are you advocating using 399, or defining a new code from the 390-398 space? > -----Original Message----- > From: Alan Hawrylyshen [mailto:a.hawrylyshen@gmail.com] On=20 > Behalf Of Alan Hawrylyshen > Sent: Friday, July 27, 2007 08:27 > To: Kyzivat Paul; Mahy Rohan > Cc: Audet, Francois (SC100:3055); IETF SIP List;=20 > Jon.Peterson@neustar.com > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >=20 >=20 > On 27-Jul-2007, at 10:06 , Paul Kyzivat wrote: >=20 > > I understand that if the user entered a sips URI then it=20 > should be the=20 > > user that must decide to downgrade. But if the user didn't know=20 > > whether to use sip or sips in the first place, and the UA=20 > decides to=20 > > try sips first then I see no problem in the UA having a policy that=20 > > causes it to downgrade. >=20 > I was under the impression (based on meeting discussion) that : > 1 - the downgrade was undesirable because it reveals=20 > (possibly) information about the targeted party in the clear, and; > 2 - The 480 with a Warning header was an option to provide=20 > automata- friendly indication of the failure reason. >=20 > Alan Hawrylyshen >=20 > a l a n a t p o l y p h a s e d o t c a >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 27 11:39:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERuk-00009R-C5; Fri, 27 Jul 2007 11:39:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IERuj-00009H-LH for sip-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 11:39:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IERuj-000099-B6 for sip@ietf.org; Fri, 27 Jul 2007 11:39:37 -0400 Received: from dhcp-11b6.ietf69.org ([130.129.17.182] helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IERuj-0007P7-18 for sip@ietf.org; Fri, 27 Jul 2007 11:39:37 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id A4BDD33C1A; Fri, 27 Jul 2007 08:37:27 -0700 (PDT) Date: Fri, 27 Jul 2007 08:37:26 -0700 From: Eric Rescorla To: "Francois Audet" Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070727153727.A4BDD33C1A@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Rohan Mahy , IETF SIP List , Paul Kyzivat , Jon.Peterson@neustar.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At Fri, 27 Jul 2007 09:35:12 -0500, Francois Audet wrote: > The intent is to be UNDISTINGUISHABLE. > > We do NOT want the equipment to automatically downgrade. We want > the user to make the decision in a concious way. > > Furthermore, we want to emphasise that the SIP and SIPS are > different addresses and are not interchangeable. > > Rohan Mahy, Jon Peterson, Eric Rescorla, > > Since you were the main people advocating this change, can > you make clear on the list what the rationale is. Right. So, I want to avoid automatic downgrade. I think that at minimum that means that we should avoid using a return code ordinary associated with automatic retry. Better yet would be to use a hard failure return code and then a textual error message... -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 27 11:47:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IES2J-0008Qw-JW; Fri, 27 Jul 2007 11:47:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IES2H-0008Qi-UL for sip-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 11:47:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IES2H-0008Qa-Ko for sip@ietf.org; Fri, 27 Jul 2007 11:47:25 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IES2H-0007Kq-A5 for sip@ietf.org; Fri, 27 Jul 2007 11:47:25 -0400 Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-5.cisco.com with ESMTP; 27 Jul 2007 08:47:24 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAFKwqUasE2C2/2dsb2JhbAAN X-IronPort-AV: i="4.16,589,1175497200"; d="scan'208"; a="168451371:sNHT31462731" Received: from [64.142.29.213] ([10.21.80.67]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l6RERcQQ008415; Fri, 27 Jul 2007 07:27:38 -0700 Message-ID: <46AA138D.6030001@cisco.com> Date: Fri, 27 Jul 2007 08:47:25 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.12) Gecko/20070509 Thunderbird/1.5.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <20070727153727.A4BDD33C1A@delta.rtfm.com> In-Reply-To: <20070727153727.A4BDD33C1A@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1296; t=1185546459; x=1186410459; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20draft-ietf-sip-sips-05=3A=20480=20vs.=20418 |Sender:=20 |To:=20Eric=20Rescorla=20; bh=PSdUwyUCUiGaXQ5H0ZtZUxnySsp3g6ttszZMGNDx68g=; b=NfV/gdfDU5Dp5LcNFWAqknDiPChv1sDEx67fO0qVQlwixg6ZuDR02kG8s6imeaMFnh7wwKjJ tHP3+XXs+70mciLXe90GQ/f1g9jc+Ad3djnaxXI7dHKWLsINS9DgZOHP; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: IETF SIP List , Rohan Mahy , Francois Audet , Paul Kyzivat , Jon.Peterson@neustar.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Eric Rescorla wrote: > At Fri, 27 Jul 2007 09:35:12 -0500, > Francois Audet wrote: > >> The intent is to be UNDISTINGUISHABLE. >> >> We do NOT want the equipment to automatically downgrade. We want >> the user to make the decision in a concious way. >> >> Furthermore, we want to emphasise that the SIP and SIPS are >> different addresses and are not interchangeable. >> >> Rohan Mahy, Jon Peterson, Eric Rescorla, >> >> Since you were the main people advocating this change, can >> you make clear on the list what the rationale is. >> > > Right. So, I want to avoid automatic downgrade. I think that > at minimum that means that we should avoid using a return > code ordinary associated with automatic retry. Better yet > would be to use a hard failure return code and then a textual > error message... > Do people seriously believe that any amount of protestation from the IETF is going to prevent implementors from downgrading? If the receiver(s) really don't want the SIP method, they don't have to accept them. If they do, then no amount of hand wringing MUST NOT's is going to prevent the inevitable. The only thing this kind of hand wringing is likely to produce is more incompatibility between the puritans and the sinners. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 27 12:02:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IESGo-0004cc-70; Fri, 27 Jul 2007 12:02:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IESGm-0004cV-Ou for sip-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 12:02:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IESGm-0004cI-EB for sip@ietf.org; Fri, 27 Jul 2007 12:02:24 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IESGk-0007z5-JR for sip@ietf.org; Fri, 27 Jul 2007 12:02:23 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l6RG2Dp03707; Fri, 27 Jul 2007 09:02:13 -0700 In-Reply-To: <46AA138D.6030001@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <20070727153727.A4BDD33C1A@delta.rtfm.com> <46AA138D.6030001@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Fri, 27 Jul 2007 11:02:12 -0500 To: Michael Thomas X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Rohan Mahy , IETF SIP List , Francois Audet , Jon.Peterson@neustar.com, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Michael, At issue here is what the default implementor is likely to do. With a new 4xx, the misguided but well-meaning implementor is likely to try to "helpfully" "repair" the error without thinking about or understanding the security context. Using a Warning code raises the bar significantly, but still allows automata to at least log what happened. thanks, -rohan On Jul 27, 2007, at 10:47 AM, Michael Thomas wrote: > Eric Rescorla wrote: >> At Fri, 27 Jul 2007 09:35:12 -0500, >> Francois Audet wrote: >> >>> The intent is to be UNDISTINGUISHABLE. >>> >>> We do NOT want the equipment to automatically downgrade. We want >>> the user to make the decision in a concious way. >>> >>> Furthermore, we want to emphasise that the SIP and SIPS are >>> different addresses and are not interchangeable. >>> >>> Rohan Mahy, Jon Peterson, Eric Rescorla, >>> >>> Since you were the main people advocating this change, can you >>> make clear on the list what the rationale is. >>> >> >> Right. So, I want to avoid automatic downgrade. I think that >> at minimum that means that we should avoid using a return >> code ordinary associated with automatic retry. Better yet >> would be to use a hard failure return code and then a textual >> error message... >> > > Do people seriously believe that any amount of protestation from > the IETF > is going to prevent implementors from downgrading? If the receiver > (s) really > don't want the SIP method, they don't have to accept them. If they > do, then no > amount of hand wringing MUST NOT's is going to prevent the inevitable. > > The only thing this kind of hand wringing is likely to produce is more > incompatibility between the puritans and the sinners. > > Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 27 12:06:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IESKK-0001za-HS; Fri, 27 Jul 2007 12:06:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IESKJ-0001sr-9t for sip-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 12:06:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IESKI-0001qc-U4 for sip@ietf.org; Fri, 27 Jul 2007 12:06:02 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IESKI-00089j-JX for sip@ietf.org; Fri, 27 Jul 2007 12:06:02 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6RG5xD05282; Fri, 27 Jul 2007 16:05:59 GMT 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 Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Fri, 27 Jul 2007 11:05:41 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF116E2279@zrc2hxm0.corp.nortel.com> In-reply-to: <46AA138D.6030001@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfQZYjuftDoa5VWQC2eism6CoMJ9wAAjSIA References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <20070727153727.A4BDD33C1A@delta.rtfm.com> <46AA138D.6030001@cisco.com> From: "Francois Audet" To: "Michael Thomas" , "Eric Rescorla" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: IETF SIP List , Rohan Mahy , Paul Kyzivat , Jon.Peterson@neustar.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > Do people seriously believe that any amount of protestation=20 > from the IETF is going to prevent implementors from=20 > downgrading? If the receiver(s) really don't want the SIP=20 > method, they don't have to accept them. If they do, then no=20 > amount of hand wringing MUST NOT's is going to prevent the inevitable. >=20 > The only thing this kind of hand wringing is likely to=20 > produce is more incompatibility between the puritans and the sinners. Doesn't this argue agaist your own previous email? The 480 approach doesn't allow for automatic retry, because you can't figure out from the error code that it might actually work=20 by downgrading. I'm am quite lost at understanding what concrete outcome you want to see. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jul 27 12:39:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IESqJ-0004Hl-8Y; Fri, 27 Jul 2007 12:39:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IESqH-0004Ew-Tg for sip-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 12:39:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IESqH-0004EX-Ib for sip@ietf.org; Fri, 27 Jul 2007 12:39:05 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IESqH-0000Wu-7h for sip@ietf.org; Fri, 27 Jul 2007 12:39:05 -0400 Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 27 Jul 2007 09:39:05 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAI67qUasE2C2/2dsb2JhbAAN X-IronPort-AV: i="4.16,589,1175497200"; d="scan'208"; a="189816358:sNHT30342411" Received: from [64.142.29.213] ([10.21.80.67]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l6RFJJ5b010516; Fri, 27 Jul 2007 08:19:19 -0700 Message-ID: <46AA1FAA.3000204@cisco.com> Date: Fri, 27 Jul 2007 09:39:06 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.12) Gecko/20070509 Thunderbird/1.5.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <20070727153727.A4BDD33C1A@delta.rtfm.com> <46AA138D.6030001@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=980; t=1185549560; x=1186413560; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20draft-ietf-sip-sips-05=3A=20480=20vs.=20418 |Sender:=20 |To:=20Rohan=20Mahy=20; bh=Vo5XDZnTi468Q2EMiVafCPFHD6jQ1iy40q7gaNPQ9W8=; b=F33/PjPLjSoGg2mBj37eVTN42oMRqNtNCp9+fGpA02BfziFzMxzUj0HG0WOMOVafWE569KND mqiUkWzB+RqHxphEyyNS5bqeArYAGAXoFbwVrK4og+RhePkxnKSKJXWS; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: IETF SIP List , Jon.Peterson@neustar.com, Francois Audet , Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rohan Mahy wrote: > Michael, > > At issue here is what the default implementor is likely to do. With a > new 4xx, the misguided but well-meaning implementor is likely to try > to "helpfully" "repair" the error without thinking about or > understanding the security context. > > Using a Warning code raises the bar significantly, but still allows > automata to at least log what happened. As I said, a receiver is completely at liberty to prevent the downgrade by not accepting the downgraded request. Problem solved by those who care. On the other hand I think it's pretty presumptuous that we "know" in all cases whether it's wrong to "repair" the error. Paul brought up several examples. Also: if the receiver allows non-SIPS requests why shouldn't you infer that they want you to "repair" the request? It sure seems like this is a misguided attempt at forcing ineffectual nannyware which is a pointless enterprise for IETF protocols. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jul 28 21:25:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IExX5-00085J-O5; Sat, 28 Jul 2007 21:25:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IExX3-0007yj-Dt for sip-confirm+ok@megatron.ietf.org; Sat, 28 Jul 2007 21:25:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IExX3-0007x8-3f for sip@ietf.org; Sat, 28 Jul 2007 21:25:17 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IExX2-0001vo-HX for sip@ietf.org; Sat, 28 Jul 2007 21:25:17 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 28 Jul 2007 21:25:01 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEuJq0ZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.19,194,1183348800"; d="scan'208"; a="127321154:sNHT28509982" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6T1P0ho012153; Sat, 28 Jul 2007 21:25:00 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6T1OjEZ021158; Sun, 29 Jul 2007 01:24:49 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Jul 2007 21:24:44 -0400 Received: from jmpolk-wxp.cisco.com ([10.82.217.58]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Jul 2007 21:24:44 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 28 Jul 2007 20:24:43 -0500 To: "Francois Audet" , "Alan Hawrylyshen" , "Kyzivat Paul" , "Mahy Rohan" From: "James M. Polk" Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF116E21C3@zrc2hxm0.corp.nor tel.com> References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <46AA09F1.6010401@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E21C3@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 29 Jul 2007 01:24:44.0333 (UTC) FILETIME=[3E8565D0:01C7D17F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2294; t=1185672301; x=1186536301; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Sip]=20draft-ietf-sip-sips-05=3A=20480=20vs.=20418 |Sender:=20 |To:=20=22Francois=20Audet=22=20, =0A=20=20=20=20=20=20= 20=20=22Alan=20Hawrylyshen=22=20, =0A=20=20=20=20=20=20= 20=20=22Kyzivat=20Paul=22=20, =20=22Mahy=20Rohan=22=20< rohan@ekabal.com>; bh=HYqQvlSPkMfQQ6lCj2J3T6ezYT4qDeoZT7AanH1FRnk=; b=UfyzcBtJeGNmADamcgumiGQfDN/KbHwCJSR/HyYaY3qkAHqDSMEscWPTKmpFeShlGJfZ+n3m RhyvYATlOtUcL+iIrLRspiZjmUYBFiI96rndWjldA9UCShHj1OVLGsll; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: IETF SIP List , Jon.Peterson@neustar.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A 399 Miscellaneous? That doesn't make sense... Warning codes are not limited to 3XX, so if a new Warning code is what Rohan wants to convey more information in the response (which I believe should be done one way or another) - it can be almost any value other than 300-379 or 399 IMO. At 10:32 AM 7/27/2007, Francois Audet wrote: >On the Warning header... > >Values 300-379 are reserved for SDP-related stuff. > >Values 380-389 are unassiged (but there is no text on it). > >Values 390-398 are unassigned (but don't fall into the SDP >related stuff. > >399 means Miscellaneous and the text can be provided to the user. >It further says that Automata MUST NOT take action based on this. > >Rohan, are you advocating using 399, or defining a new code from the >390-398 space? > > > -----Original Message----- > > From: Alan Hawrylyshen [mailto:a.hawrylyshen@gmail.com] On > > Behalf Of Alan Hawrylyshen > > Sent: Friday, July 27, 2007 08:27 > > To: Kyzivat Paul; Mahy Rohan > > Cc: Audet, Francois (SC100:3055); IETF SIP List; > > Jon.Peterson@neustar.com > > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > > > > > On 27-Jul-2007, at 10:06 , Paul Kyzivat wrote: > > > > > I understand that if the user entered a sips URI then it > > should be the > > > user that must decide to downgrade. But if the user didn't know > > > whether to use sip or sips in the first place, and the UA > > decides to > > > try sips first then I see no problem in the UA having a policy that > > > causes it to downgrade. > > > > I was under the impression (based on meeting discussion) that : > > 1 - the downgrade was undesirable because it reveals > > (possibly) information about the targeted party in the clear, and; > > 2 - The 480 with a Warning header was an option to provide > > automata- friendly indication of the failure reason. > > > > Alan Hawrylyshen > > > > a l a n a t p o l y p h a s e d o t c a > > > > > > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jul 29 22:04:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFKcb-0000Op-Va; Sun, 29 Jul 2007 22:04:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFKcb-0000Og-9K for sip-confirm+ok@megatron.ietf.org; Sun, 29 Jul 2007 22:04:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFKca-0000OX-Vn for sip@ietf.org; Sun, 29 Jul 2007 22:04:32 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFKca-0003tf-IG for sip@ietf.org; Sun, 29 Jul 2007 22:04:32 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 29 Jul 2007 19:04:32 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswMACjkrEarR7O6/2dsb2JhbACIZZxp X-IronPort-AV: i="4.19,196,1183359600"; d="scan'208"; a="190802651:sNHT37219239" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6U24VtO023202; Sun, 29 Jul 2007 19:04:31 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l6U24UTb027790; Mon, 30 Jul 2007 02:04:31 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); Sun, 29 Jul 2007 19:04:30 -0700 Received: from [10.21.82.32] ([10.21.82.32]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Jul 2007 19:04:30 -0700 Message-ID: <46AD472C.8010009@cisco.com> Date: Sun, 29 Jul 2007 22:04:28 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Alan Hawrylyshen Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <46AA09F1.6010401@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 02:04:30.0192 (UTC) FILETIME=[F7045700:01C7D24D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1208; t=1185761071; x=1186625071; 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[Sip]=20draft-ietf-sip-sips-05=3A=20480=20vs.=20418 |Sender:=20; bh=Q3FWLT5dbZzCrmx2JVDw5LLbCMAQAS3V3Qx0MAATDxk=; b=lhXImZ0Z+PDxdMXZKfW6dYyd2vv0olV5ovj73V0bVg5spdAXepyLc6EIliCcrrMLRxrpFhO1 yKx5HhdRtu8s4navH0EEZ5GSHdcvqQZ47Yyn1q5SV9caD+wte/10xAjC; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: IETF SIP List , Mahy Rohan , Francois Audet , Jon.Peterson@neustar.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Alan Hawrylyshen wrote: > > On 27-Jul-2007, at 10:06 , Paul Kyzivat wrote: > >> I understand that if the user entered a sips URI then it should be the >> user that must decide to downgrade. But if the user didn't know >> whether to use sip or sips in the first place, and the UA decides to >> try sips first then I see no problem in the UA having a policy that >> causes it to downgrade. > > I was under the impression (based on meeting discussion) that : > 1 - the downgrade was undesirable because it reveals (possibly) > information about the targeted party in the clear, and; Its only undesirable if the UAC had any expectation that the information would not be revealed. I repeat that this is largely a function of the UI and contract between the UI and the user. I don't think we can or should make assumptions about that that is. > 2 - The 480 with a Warning header was an option to provide > automata-friendly indication of the failure reason. I don't have strong feelings about what the response is, so long as the particular case is distinguishable in some way. Thanks, Paul > Alan Hawrylyshen > > a l a n a t p o l y p h a s e d o t c a > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 04:28:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFQbo-0008Mv-VA; Mon, 30 Jul 2007 04:28:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFQbn-0008Mp-Uh for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 04:28:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFQbn-0008Mh-JK for sip@ietf.org; Mon, 30 Jul 2007 04:28:07 -0400 Received: from web15310.mail.cnb.yahoo.com ([203.209.230.40]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IFQbl-0003eR-IW for sip@ietf.org; Mon, 30 Jul 2007 04:28:07 -0400 Received: (qmail 68434 invoked by uid 60001); 30 Jul 2007 08:28:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=akX9WDg1RvqIIvzwbaBrYlURDnd7VzhZc7/YkhpO8LHsFd2C+tha0JdYpaV/7zAYU0ocnhRcVGemxItqdd01XhHFpts6ki0H23MtZXgh5R28DD8DCNTvyxqlmNFfKKVgM7wJVTscnz0et2PFk/EFX+iFv2qegMPYh8Nv5hdsWxU=; X-YMail-OSG: E8aH2FIVM1mAcK7u1MgaFYxbeY7HT4_WL8tCOJnQlDq_wvH.zG3ZmRjod_C30u.RkcLnDPhxzPgyRpsvEuoEcJReBtIp7NAHgzYUWFgUONrbMNyaYWs- Received: from [123.112.4.102] by web15310.mail.cnb.yahoo.com via HTTP; Mon, 30 Jul 2007 16:28:01 CST Date: Mon, 30 Jul 2007 16:28:01 +0800 (CST) From: ji ma Subject: [Sip]RFC4916:the usage of connected identity in interdomain To: sip@ietf.org MIME-Version: 1.0 Message-ID: <471431.66845.qm@web15310.mail.cnb.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0374296465==" Errors-To: sip-bounces@ietf.org --===============0374296465== Content-Type: multipart/alternative; boundary="0-451529467-1185784081=:66845" Content-Transfer-Encoding: 8bit --0-451529467-1185784081=:66845 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Hi folks: I have some questions after reading RFC4916, which descibes a solution of ensuring the identity of the UA that sends backward request after a dialog has formed. As far as I'm concerned, this specification is a supplement of RFC4474, which can only provide the validaty of the UA sending the request. However, RFC4916's 2 examples regarding to the its desciption only illustrate how to convey connected identity in an assumption that the caller and callee are in the same domain (example.com in particular), by using UPDATE messages which renew the From field of the sender. So my question is, can this specification resolve the authentication of the connected identity regarding to the scenories where the caller and callee are in different domains? [Considering RFC4474, the authenticator will not be the responsible proxy for the request that contains a From field (bob@biloxi.example.com) that is different from its real identity (bob@chicago.example.com) ] Another doubt I'm concerning about, is the content of last two paragraphs in page 3 of RFC4916, which is said as below: The provision of the identity of the responder in a response (commonly called "response identity") is outside the scope of this document. Note that even if identity were to be conveyed somehow in a response, there would in general be difficulty authenticating the UAS. Providing identity in a separate request allows normal authentication techniques to be used. I can't understand why it's difficult to authenticate response messages as I thought it could be authenticated in a way like the request it responses to(I don't know how much different in the process it should be regarding request and response) .So what's special for response? Regards, Ma Ji --------------------------------- ÇÀ×¢ÑÅ»¢Ãâ·ÑÓÊÏä3.5GÈÝÁ¿£¬20M¸½¼þ£¡ --0-451529467-1185784081=:66845 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit
        Hi folks:
         
            I have some questions after reading RFC4916, which descibes a solution of ensuring the identity of the UA that sends backward request after a dialog has formed. As far as I'm concerned, this specification is a supplement of RFC4474, which can only provide the validaty of the UA sending the request. However, RFC4916's 2 examples regarding to the its desciption only illustrate how to convey connected identity in an assumption that the caller and callee are in the same domain (example.com in particular), by using UPDATE messages which renew the From field of the sender. So my question is, can this specification resolve the authentication of the connected identity regarding to the scenories where the caller and callee are in different domains?
        [Considering RFC4474, the authenticator will not be the responsible proxy for the request that contains a From field (bob@biloxi.example.com) that is different from its real identity (bob@chicago.example.com) ]
         
            Another doubt I'm concerning about, is the content of last two paragraphs in page 3 of RFC4916, which is said as below:
         
           The provision of the identity of the responder in a response
           (commonly called "response identity") is outside the scope of this
           document.
         
              Note that even if identity were to be conveyed somehow in a
              response, there would in general be difficulty authenticating the
              UAS.  Providing identity in a separate request allows normal
              authentication techniques to be used.
         
         
        I can't understand why it's difficult to authenticate response messages as I thought it could be authenticated in a way like the request it responses to(I don't know how much different in the process it should be regarding request and response) .So what's special for response?
         
        Regards,
        Ma Ji
           

        ÇÀ×¢ÑÅ»¢Ãâ·ÑÓÊÏä3.5GÈÝÁ¿£¬20M¸½¼þ£¡ --0-451529467-1185784081=:66845-- --===============0374296465== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0374296465==-- From sip-bounces@ietf.org Mon Jul 30 04:44:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFQr6-0007L9-G7; Mon, 30 Jul 2007 04:43:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFQr4-0007L2-B7 for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 04:43:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFQr4-0007Ku-0J for sip@ietf.org; Mon, 30 Jul 2007 04:43:54 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFQr3-0004Cc-Fr for sip@ietf.org; Mon, 30 Jul 2007 04:43:53 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JLZ00J9GHKQRW@siemenscomms.co.uk> for sip@ietf.org; Mon, 30 Jul 2007 09:43:38 +0100 (BST) Date: Mon, 30 Jul 2007 09:43:51 +0100 From: "Elwell, John" Subject: RE: [Sip]RFC4916:the usage of connected identity in interdomain In-reply-to: <471431.66845.qm@web15310.mail.cnb.yahoo.com> To: ji ma , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D020620B@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-Topic: [Sip]RFC4916:the usage of connected identity in interdomain Thread-Index: AcfSg6DRVTqQkqsWROiF0fjD+PEIewAAaK0Q Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <471431.66845.qm@web15310.mail.cnb.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ma Ji, See below. John > -----Original Message----- > From: ji ma [mailto:mjhorse1984@yahoo.com.cn]=20 > Sent: 30 July 2007 09:28 > To: sip@ietf.org > Subject: [Sip]RFC4916:the usage of connected identity in interdomain >=20 > Hi folks: > =20 > I have some questions after reading RFC4916, which=20 > descibes a solution of ensuring the identity of the UA that=20 > sends backward request after a dialog has formed. As far as=20 > I'm concerned, this specification is a supplement of RFC4474,=20 > which can only provide the validaty of the UA sending the=20 > request. However, RFC4916's 2 examples regarding to the its=20 > desciption only illustrate how to convey connected identity=20 > in an assumption that the caller and callee are in the same=20 > domain (example.com in particular), by using UPDATE messages=20 > which renew the From field of the sender. So my question is,=20 > can this specification resolve the authentication of the=20 > connected identity regarding to the scenories where the=20 > caller and callee are in different domains? > [Considering RFC4474, the authenticator will not be the=20 > responsible proxy for the request that contains a From field=20 > (bob@biloxi.example.com) that is different from its real=20 > identity (bob@chicago.example.com) ] [JRE] Although the examples show only a single domain, the RFC is = equally applicable when caller and callee are in different domains. Each = domain will provide its own authentication service. > =20 > Another doubt I'm concerning about, is the content of=20 > last two paragraphs in page 3 of RFC4916, which is said as below: > =20 > The provision of the identity of the responder in a response > (commonly called "response identity") is outside the scope of this > document. > =20 > Note that even if identity were to be conveyed somehow in a > response, there would in general be difficulty=20 > authenticating the > UAS. Providing identity in a separate request allows normal > authentication techniques to be used. > =20 > =20 > I can't understand why it's difficult to authenticate=20 > response messages as I thought it could be authenticated in a=20 > way like the request it responses to(I don't know how much=20 > different in the process it should be regarding request and=20 > response) .So what's special for response? [JRE] SIP digest authentication is only specified for requests. In = particular, there is no mechanism for challenging a response. > =20 > Regards, > Ma Ji > =20 >=20 > ________________________________ >=20 > = =C7=C0=D7=A2=D1=C5=BB=A2=C3=E2=B7=D1=D3=CA=CF=E43.5G=C8=DD=C1=BF=A3=AC20M= =B8=BD=BC=FE=A3=A1 =20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 07:15:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFTDq-0001kL-Hs; Mon, 30 Jul 2007 07:15:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFTDo-0001kG-K1 for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 07:15:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFTDo-0001k8-AY for sip@ietf.org; Mon, 30 Jul 2007 07:15:32 -0400 Received: from web15313.mail.cnb.yahoo.com ([203.209.230.43]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IFTDm-00037q-CN for sip@ietf.org; Mon, 30 Jul 2007 07:15:32 -0400 Received: (qmail 37772 invoked by uid 60001); 30 Jul 2007 11:15:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=A3O/7+EGzzwWM+0Ph9rGzvyUmBXwTHFqoNGooKYrYpkVlUGy6OoOQ4ookM1oBxtvKbvKLGj3TfR1RtM0RjQw6kus4Z0M5Air2Rq6CNW411JFhkHywhTdZfnT3CorgTgwEt1/p01CEU6RfdEjQXYQ3uKlcjB+Y3dxhqq1TP9i6SA=; X-YMail-OSG: rDnNjaEVM1niO4JaR9dPQgRVIWYL6j1zUUQu_.mLISUeS15bWBCpthGNReDEiXb8sEXTXlumKDNhPVwxCDHyFNj4EWnBkW_VCsVQFUUJnOz7TIS8OkY- Received: from [123.112.4.102] by web15313.mail.cnb.yahoo.com via HTTP; Mon, 30 Jul 2007 19:15:27 CST Date: Mon, 30 Jul 2007 19:15:27 +0800 (CST) From: ji ma Subject: RE: [Sip]RFC4916:the usage of connected identity in interdomain To: "Elwell, John" , sip@ietf.org In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D020620B@GBNTHT12009MSX.gb002.siemens.net> MIME-Version: 1.0 Message-ID: <521911.36809.qm@web15313.mail.cnb.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1594783799==" Errors-To: sip-bounces@ietf.org --===============1594783799== Content-Type: multipart/alternative; boundary="0-1893849076-1185794127=:36809" Content-Transfer-Encoding: 8bit --0-1893849076-1185794127=:36809 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit "Elwell, John" дµÀ£º Ma Ji, See below. John > -----Original Message----- > From: ji ma [mailto:mjhorse1984@yahoo.com.cn] > Sent: 30 July 2007 09:28 > To: sip@ietf.org > Subject: [Sip]RFC4916:the usage of connected identity in interdomain > > Hi folks: > > I have some questions after reading RFC4916, which > descibes a solution of ensuring the identity of the UA that > sends backward request after a dialog has formed. As far as > I'm concerned, this specification is a supplement of RFC4474, > which can only provide the validaty of the UA sending the > request. However, RFC4916's 2 examples regarding to the its > desciption only illustrate how to convey connected identity > in an assumption that the caller and callee are in the same > domain (example.com in particular), by using UPDATE messages > which renew the From field of the sender. So my question is, > can this specification resolve the authentication of the > connected identity regarding to the scenories where the > caller and callee are in different domains? > [Considering RFC4474, the authenticator will not be the > responsible proxy for the request that contains a From field > (bob@biloxi.example.com) that is different from its real > identity (bob@chicago.example.com) ] [JRE] Although the examples show only a single domain, the RFC is equally applicable when caller and callee are in different domains. Each domain will provide its own authentication service. > > Another doubt I'm concerning about, is the content of > last two paragraphs in page 3 of RFC4916, which is said as below: > > The provision of the identity of the responder in a response > (commonly called "response identity") is outside the scope of this > document. > > Note that even if identity were to be conveyed somehow in a > response, there would in general be difficulty > authenticating the > UAS. Providing identity in a separate request allows normal > authentication techniques to be used. > > > I can't understand why it's difficult to authenticate > response messages as I thought it could be authenticated in a > way like the request it responses to(I don't know how much > different in the process it should be regarding request and > response) .So what's special for response? [JRE] SIP digest authentication is only specified for requests. In particular, there is no mechanism for challenging a response. > > Regards, > Ma Ji Thanks for reminding. When using connected identity,the sender has no reason to use the previous identity the same as the From URI of the request, who sends UPDATE which contains the new identity of the sender. More, I deliberate that authenticating the validaty of the receiver in a response(that means the To header) is also required, and so far I has not see any draft nor maillist discussing it(maybe I missed), considering the current mechanism is not enough for such issue, I thing there should be some effort to be put to take this aspect into account. Regards, Ma Ji --------------------------------- ÇÀ×¢ÑÅ»¢Ãâ·ÑÓÊÏä3.5GÈÝÁ¿£¬20M¸½¼þ£¡ --0-1893849076-1185794127=:36809 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit

        "Elwell, John" <john.elwell@siemens.com> дµÀ£º
        Ma Ji,

        See below.

        John

        > -----Original Message-----
        > From: ji ma [mailto:mjhorse1984@yahoo.com.cn]
        > Sent: 30 July 2007 09:28
        > To: sip@ietf.org
        > Subject: [Sip]RFC4916:the usage of connected identity in interdomain
        >
        > Hi folks:
        >
        > I have some questions after reading RFC4916, which
        > descibes a solution of ensuring the identity of the UA that
        > sends backward request after a dialog has formed. As far as
        > I'm concerned, this specification is a supplement of RFC4474,
        > which can only provide the validaty of the UA sending the
        > request. However, RFC4916's 2 examples regarding to the its
        > desciption only illustrate how to convey connected identity
        > in an assumption that the caller and callee are in the same
        > domain (example.com in particular), by using UPDATE messages
        > which renew the From field of the sender. So my question is,
        > can this specification resolve the authentication of the
        > connected identity regarding to the scenories where the
        > caller and callee are in different domains?
        > [Considering RFC4474, the authenticator will not be the
        > responsible proxy for the request that contains a From field
        > (bob@biloxi.example.com) that is different from its real
        > identity (bob@chicago.example.com) ]
        [JRE] Although the examples show only a single domain, the RFC is equally applicable when caller and callee are in different domains. Each domain will provide its own authentication service.

        >
        > Another doubt I'm concerning about, is the content of
        > last two paragraphs in page 3 of RFC4916, which is said as below:
        >
        > The provision of the identity of the responder in a response
        > (commonly called "response identity") is outside the scope of this
        > document.
        >
        > Note that even if identity were to be conveyed somehow in a
        > response, there would in general be difficulty
        > authenticating the
        > UAS. Providing identity in a separate request allows normal
        > authentication techniques to be used.
        >
        >
        > I can't understand why it's difficult to authenticate
        > response messages as I thought it could be authenticated in a
        > way like the request it responses to(I don't know how much
        > different in the process it should be regarding request and
        > response) .So what's special for response?
        [JRE] SIP digest authentication is only specified for requests. In particular, there is no mechanism for challenging a response.

        >
        > Regards,
        > Ma Ji
        Thanks for reminding. When using connected identity,the sender has no reason to use the previous identity the same as the From URI of the request, who sends UPDATE which contains the new identity of the sender.
         
         More, I deliberate that authenticating the validaty of the receiver in a response(that means the To header) is also required, and so far I has not see any draft nor maillist discussing it(maybe I missed), considering the current mechanism is not enough for such issue, I thing there should be some effort to be put to take this aspect into account.
         
        Regards,
        Ma Ji

        ÇÀ×¢ÑÅ»¢Ãâ·ÑÓÊÏä3.5GÈÝÁ¿£¬20M¸½¼þ£¡ --0-1893849076-1185794127=:36809-- --===============1594783799== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1594783799==-- From sip-bounces@ietf.org Mon Jul 30 09:10:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFV0d-0002Ff-Bz; Mon, 30 Jul 2007 09:10:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFV0b-0002FA-RV for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 09:10:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFV0b-0002F2-HQ for sip@ietf.org; Mon, 30 Jul 2007 09:10:01 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFV0b-0004j8-3y for sip@ietf.org; Mon, 30 Jul 2007 09:10:01 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JLZ00H65TI5WW@siemenscomms.co.uk> for sip@ietf.org; Mon, 30 Jul 2007 14:01:17 +0100 (BST) Date: Mon, 30 Jul 2007 14:01:30 +0100 From: "Elwell, John" Subject: RE: [Sip]RFC4916:the usage of connected identity in interdomain In-reply-to: <521911.36809.qm@web15313.mail.cnb.yahoo.com> To: ji ma , sip@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D020625C@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-Topic: [Sip]RFC4916:the usage of connected identity in interdomain Thread-Index: AcfSmxf+pJ4Z4GJ4SOakvsJ64sHtNgADXmHg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D020620B@GBNTHT12009MSX.gb002.siemens.net> <521911.36809.qm@web15313.mail.cnb.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > More, I deliberate that authenticating the validaty of the=20 > receiver in a response(that means the To header) is also=20 > required, and so far I has not see any draft nor maillist=20 > discussing it(maybe I missed), considering the current=20 > mechanism is not enough for such issue, I thing there should=20 > be some effort to be put to take this aspect into account. [JRE] There have been a number of proposals in the past for response = identity, but the problems encountered have proved to be insurmountable. = I would suggest you look in the SIP and SIPPING mail archives and = minutes from late 2005 / early 2006. Note also that, because of request = retargeting, the identity of the responder will not necessarily equate = to the identity in the To header field. In the absence of any solution = to the response identity problem, RFC 4916 fills the gap by allowing = authenticated identity to occur in a request in the reverse direction. John > =20 > Regards, > Ma Ji >=20 > ________________________________ >=20 > = =C7=C0=D7=A2=D1=C5=BB=A2=C3=E2=B7=D1=D3=CA=CF=E43.5G=C8=DD=C1=BF=A3=AC20M= =B8=BD=BC=FE=A3=A1 =20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 11:55:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFXaV-00043q-C1; Mon, 30 Jul 2007 11:55:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFXaT-00043i-Ly for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 11:55:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFXaT-00043a-CN for sip@ietf.org; Mon, 30 Jul 2007 11:55:13 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFXaS-0001Ds-5U for sip@ietf.org; Mon, 30 Jul 2007 11:55:13 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6UFt3a22983; Mon, 30 Jul 2007 15:55:04 GMT 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 Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Mon, 30 Jul 2007 10:54:57 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF11747126@zrc2hxm0.corp.nortel.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfRf02hY8pG9ZT1SWK7DJ/7JIj+oABQn4Bg References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <46AA09F1.6010401@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E21C3@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "James M. Polk" , "Alan Hawrylyshen" , "Kyzivat Paul" , "Mahy Rohan" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: IETF SIP List , Jon.Peterson@neustar.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org RFC 3261, p. 181: "The first digit of warning codes beginning with "3" indicates warnings specific to SIP." Then it explains within the 3XX space, how they are used. > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > Sent: Saturday, July 28, 2007 18:25 > To: Audet, Francois (SC100:3055); Alan Hawrylyshen; Kyzivat=20 > Paul; Mahy Rohan > Cc: IETF SIP List; Jon.Peterson@neustar.com > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >=20 > A 399 Miscellaneous? That doesn't make sense... >=20 > Warning codes are not limited to 3XX, so if a new Warning=20 > code is what Rohan wants to convey more information in the=20 > response (which I believe should be done one way or another)=20 > - it can be almost any value other than 300-379 or 399 IMO. >=20 > At 10:32 AM 7/27/2007, Francois Audet wrote: > >On the Warning header... > > > >Values 300-379 are reserved for SDP-related stuff. > > > >Values 380-389 are unassiged (but there is no text on it). > > > >Values 390-398 are unassigned (but don't fall into the SDP related=20 > >stuff. > > > >399 means Miscellaneous and the text can be provided to the user. > >It further says that Automata MUST NOT take action based on this. > > > >Rohan, are you advocating using 399, or defining a new code from the > >390-398 space? > > > > > -----Original Message----- > > > From: Alan Hawrylyshen [mailto:a.hawrylyshen@gmail.com]=20 > On Behalf Of=20 > > > Alan Hawrylyshen > > > Sent: Friday, July 27, 2007 08:27 > > > To: Kyzivat Paul; Mahy Rohan > > > Cc: Audet, Francois (SC100:3055); IETF SIP List;=20 > > > Jon.Peterson@neustar.com > > > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > > > > > > > > On 27-Jul-2007, at 10:06 , Paul Kyzivat wrote: > > > > > > > I understand that if the user entered a sips URI then it > > > should be the > > > > user that must decide to downgrade. But if the user didn't know=20 > > > > whether to use sip or sips in the first place, and the UA > > > decides to > > > > try sips first then I see no problem in the UA having a policy=20 > > > > that causes it to downgrade. > > > > > > I was under the impression (based on meeting discussion) that : > > > 1 - the downgrade was undesirable because it reveals > > > (possibly) information about the targeted party in the clear, and; > > > 2 - The 480 with a Warning header was an option to provide > > > automata- friendly indication of the failure reason. > > > > > > Alan Hawrylyshen > > > > > > a l a n a t p o l y p h a s e d o t c a > > > > > > > > > > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol Use=20 > >sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 11:55:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFXad-00046g-OG; Mon, 30 Jul 2007 11:55:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFXac-00044o-Qw for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 11:55:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFXab-00044V-Ul for sip@ietf.org; Mon, 30 Jul 2007 11:55:21 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFXaa-0001E7-NI for sip@ietf.org; Mon, 30 Jul 2007 11:55:21 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l6UFrPq27035; Mon, 30 Jul 2007 15:53:25 GMT 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 Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Mon, 30 Jul 2007 10:55:09 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1174712B@zrc2hxm0.corp.nortel.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfQYpRCPxDSlnXaThq8C0tuYUq8ygCX2s/g References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <46AA09F1.6010401@cisco.com> From: "Francois Audet" To: "Alan Hawrylyshen" , "Kyzivat Paul" , "Mahy Rohan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: IETF SIP List , Jon.Peterson@neustar.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Correct.=20 > -----Original Message----- > From: Alan Hawrylyshen [mailto:a.hawrylyshen@gmail.com] On=20 > Behalf Of Alan Hawrylyshen > Sent: Friday, July 27, 2007 08:27 > To: Kyzivat Paul; Mahy Rohan > Cc: Audet, Francois (SC100:3055); IETF SIP List;=20 > Jon.Peterson@neustar.com > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >=20 >=20 > On 27-Jul-2007, at 10:06 , Paul Kyzivat wrote: >=20 > > I understand that if the user entered a sips URI then it=20 > should be the=20 > > user that must decide to downgrade. But if the user didn't know=20 > > whether to use sip or sips in the first place, and the UA=20 > decides to=20 > > try sips first then I see no problem in the UA having a policy that=20 > > causes it to downgrade. >=20 > I was under the impression (based on meeting discussion) that : > 1 - the downgrade was undesirable because it reveals=20 > (possibly) information about the targeted party in the clear, and; > 2 - The 480 with a Warning header was an option to provide=20 > automata- friendly indication of the failure reason. >=20 > Alan Hawrylyshen >=20 > a l a n a t p o l y p h a s e d o t c a >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 11:55:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFXaV-00043q-C1; Mon, 30 Jul 2007 11:55:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFXaT-00043i-Ly for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 11:55:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFXaT-00043a-CN for sip@ietf.org; Mon, 30 Jul 2007 11:55:13 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFXaS-0001Ds-5U for sip@ietf.org; Mon, 30 Jul 2007 11:55:13 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6UFt3a22983; Mon, 30 Jul 2007 15:55:04 GMT 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 Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Mon, 30 Jul 2007 10:54:57 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF11747126@zrc2hxm0.corp.nortel.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfRf02hY8pG9ZT1SWK7DJ/7JIj+oABQn4Bg References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <46AA09F1.6010401@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E21C3@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "James M. Polk" , "Alan Hawrylyshen" , "Kyzivat Paul" , "Mahy Rohan" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: IETF SIP List , Jon.Peterson@neustar.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org RFC 3261, p. 181: "The first digit of warning codes beginning with "3" indicates warnings specific to SIP." Then it explains within the 3XX space, how they are used. > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > Sent: Saturday, July 28, 2007 18:25 > To: Audet, Francois (SC100:3055); Alan Hawrylyshen; Kyzivat=20 > Paul; Mahy Rohan > Cc: IETF SIP List; Jon.Peterson@neustar.com > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >=20 > A 399 Miscellaneous? That doesn't make sense... >=20 > Warning codes are not limited to 3XX, so if a new Warning=20 > code is what Rohan wants to convey more information in the=20 > response (which I believe should be done one way or another)=20 > - it can be almost any value other than 300-379 or 399 IMO. >=20 > At 10:32 AM 7/27/2007, Francois Audet wrote: > >On the Warning header... > > > >Values 300-379 are reserved for SDP-related stuff. > > > >Values 380-389 are unassiged (but there is no text on it). > > > >Values 390-398 are unassigned (but don't fall into the SDP related=20 > >stuff. > > > >399 means Miscellaneous and the text can be provided to the user. > >It further says that Automata MUST NOT take action based on this. > > > >Rohan, are you advocating using 399, or defining a new code from the > >390-398 space? > > > > > -----Original Message----- > > > From: Alan Hawrylyshen [mailto:a.hawrylyshen@gmail.com]=20 > On Behalf Of=20 > > > Alan Hawrylyshen > > > Sent: Friday, July 27, 2007 08:27 > > > To: Kyzivat Paul; Mahy Rohan > > > Cc: Audet, Francois (SC100:3055); IETF SIP List;=20 > > > Jon.Peterson@neustar.com > > > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > > > > > > > > On 27-Jul-2007, at 10:06 , Paul Kyzivat wrote: > > > > > > > I understand that if the user entered a sips URI then it > > > should be the > > > > user that must decide to downgrade. But if the user didn't know=20 > > > > whether to use sip or sips in the first place, and the UA > > > decides to > > > > try sips first then I see no problem in the UA having a policy=20 > > > > that causes it to downgrade. > > > > > > I was under the impression (based on meeting discussion) that : > > > 1 - the downgrade was undesirable because it reveals > > > (possibly) information about the targeted party in the clear, and; > > > 2 - The 480 with a Warning header was an option to provide > > > automata- friendly indication of the failure reason. > > > > > > Alan Hawrylyshen > > > > > > a l a n a t p o l y p h a s e d o t c a > > > > > > > > > > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol Use=20 > >sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 11:55:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFXad-00046g-OG; Mon, 30 Jul 2007 11:55:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFXac-00044o-Qw for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 11:55:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFXab-00044V-Ul for sip@ietf.org; Mon, 30 Jul 2007 11:55:21 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFXaa-0001E7-NI for sip@ietf.org; Mon, 30 Jul 2007 11:55:21 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l6UFrPq27035; Mon, 30 Jul 2007 15:53:25 GMT 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 Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Mon, 30 Jul 2007 10:55:09 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1174712B@zrc2hxm0.corp.nortel.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfQYpRCPxDSlnXaThq8C0tuYUq8ygCX2s/g References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <46AA09F1.6010401@cisco.com> From: "Francois Audet" To: "Alan Hawrylyshen" , "Kyzivat Paul" , "Mahy Rohan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: IETF SIP List , Jon.Peterson@neustar.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Correct.=20 > -----Original Message----- > From: Alan Hawrylyshen [mailto:a.hawrylyshen@gmail.com] On=20 > Behalf Of Alan Hawrylyshen > Sent: Friday, July 27, 2007 08:27 > To: Kyzivat Paul; Mahy Rohan > Cc: Audet, Francois (SC100:3055); IETF SIP List;=20 > Jon.Peterson@neustar.com > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >=20 >=20 > On 27-Jul-2007, at 10:06 , Paul Kyzivat wrote: >=20 > > I understand that if the user entered a sips URI then it=20 > should be the=20 > > user that must decide to downgrade. But if the user didn't know=20 > > whether to use sip or sips in the first place, and the UA=20 > decides to=20 > > try sips first then I see no problem in the UA having a policy that=20 > > causes it to downgrade. >=20 > I was under the impression (based on meeting discussion) that : > 1 - the downgrade was undesirable because it reveals=20 > (possibly) information about the targeted party in the clear, and; > 2 - The 480 with a Warning header was an option to provide=20 > automata- friendly indication of the failure reason. >=20 > Alan Hawrylyshen >=20 > a l a n a t p o l y p h a s e d o t c a >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 12:11:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFXph-0005QE-Hj; Mon, 30 Jul 2007 12:10:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFXpg-0005Q7-MS for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 12:10:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFXpg-0005Pz-Cy for sip@ietf.org; Mon, 30 Jul 2007 12:10:56 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFXpf-0001ZB-4E for sip@ietf.org; Mon, 30 Jul 2007 12:10:56 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 178A833C1A; Mon, 30 Jul 2007 09:08:45 -0700 (PDT) Date: Mon, 30 Jul 2007 09:08:44 -0700 From: Eric Rescorla To: Michael Thomas Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 In-Reply-To: <46AA1FAA.3000204@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <20070727153727.A4BDD33C1A@delta.rtfm.com> <46AA138D.6030001@cisco.com> <46AA1FAA.3000204@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070730160846.178A833C1A@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Rohan Mahy , IETF SIP List , Francois Audet , Jon.Peterson@neustar.com, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At Fri, 27 Jul 2007 09:39:06 -0700, Michael Thomas wrote: > > Rohan Mahy wrote: > > Michael, > > > > At issue here is what the default implementor is likely to do. With a > > new 4xx, the misguided but well-meaning implementor is likely to try > > to "helpfully" "repair" the error without thinking about or > > understanding the security context. > > > > Using a Warning code raises the bar significantly, but still allows > > automata to at least log what happened. > As I said, a receiver is completely at liberty to prevent the downgrade > by not > accepting the downgraded request. Unless, of course, someone is impersonating the receiver. > Problem solved by those who care. Regrettably no. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 12:19:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFXxW-0008FL-E3; Mon, 30 Jul 2007 12:19:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFXxU-0008FD-Va for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 12:19:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFXxU-0008F5-M6 for sip@ietf.org; Mon, 30 Jul 2007 12:19:00 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFXxT-0001mW-G4 for sip@ietf.org; Mon, 30 Jul 2007 12:19:00 -0400 Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-2.cisco.com with ESMTP; 30 Jul 2007 09:18:59 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAJ6rrUasE2C2/2dsb2JhbAAN X-IronPort-AV: i="4.19,199,1183359600"; d="scan'208"; a="389043978:sNHT33993086" Received: from [64.142.29.214] ([10.21.89.117]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l6UEx3MG023581; Mon, 30 Jul 2007 07:59:03 -0700 Message-ID: <46AE0F78.1070303@cisco.com> Date: Mon, 30 Jul 2007 09:19:04 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.12) Gecko/20070509 Thunderbird/1.5.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <20070727153727.A4BDD33C1A@delta.rtfm.com> <46AA138D.6030001@cisco.com> <46AA1FAA.3000204@cisco.com> <20070730160846.178A833C1A@delta.rtfm.com> In-Reply-To: <20070730160846.178A833C1A@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1089; t=1185807543; x=1186671543; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20draft-ietf-sip-sips-05=3A=20480=20vs.=20418 |Sender:=20 |To:=20Eric=20Rescorla=20; bh=jH3H1vsX69xX4yeAWMWwnt9YCrk4YSr/J4Xjs4r18Xo=; b=ngKyVUthFjYQYpzlJpA4edYrQFEQ0BGrAxr04lTyEOPQGv3Qixj1tdZpfIXYbPhaanqjk1T2 pMeSRzVERqgiNQ6fxb2no6Lccn8u9X4mwpvtAq2rLdAsaK66ZSTuSkRH; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: IETF SIP List , Rohan Mahy , Francois Audet , Paul Kyzivat , Jon.Peterson@neustar.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Eric Rescorla wrote: > At Fri, 27 Jul 2007 09:39:06 -0700, > Michael Thomas wrote: > >> Rohan Mahy wrote: >> >>> Michael, >>> >>> At issue here is what the default implementor is likely to do. With a >>> new 4xx, the misguided but well-meaning implementor is likely to try >>> to "helpfully" "repair" the error without thinking about or >>> understanding the security context. >>> >>> Using a Warning code raises the bar significantly, but still allows >>> automata to at least log what happened. >>> >> As I said, a receiver is completely at liberty to prevent the downgrade >> by not >> accepting the downgraded request. >> > > Unless, of course, someone is impersonating the receiver. > Given how tangled up SIPS is, I really no idea what you're talking about, or whether it's even responsive to my suggestion. Last I heard, the entire raison d'etre of SIPS was that the next hop is cryptographically identified via TLS. I'm guessing that you're not suggesting that TLS is useless against impersonation attacks. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 12:38:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYGj-0003fU-Ib; Mon, 30 Jul 2007 12:38:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFYGi-0003fM-3d for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 12:38:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYGh-0003fD-QG for sip@ietf.org; Mon, 30 Jul 2007 12:38:51 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFYGg-0002By-Ik for sip@ietf.org; Mon, 30 Jul 2007 12:38:51 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6UGcme08825 for ; Mon, 30 Jul 2007 16:38:48 GMT 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 Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Mon, 30 Jul 2007 11:38:45 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF11747253@zrc2hxm0.corp.nortel.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfRf02hY8pG9ZT1SWK7DJ/7JIj+oABRHE5w References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <46AA09F1.6010401@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E21C3@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In the interest of moving forward on this arcane issue of marginal interest, I am making the following concrete proposal. Here are 2 alternatives. I'd like to have a virtual show of hands on which option is=20 preferred by people. OPTION 1 Use Response code 480, with new Warning header field 390 (URI Scheme Not Supported) for both cases when SIP or SIPS is rejected. The proxy or UAS may use the warning text field to provide more indications, e.g.: Warning: 390 isi.edu "SIPS Not Allowed" Warning: 390 isi.edu "SIPS Required" OPTION 2 Use Response code 480, with 2 new Warning headera field 390 (SIPS Not Allowed) and 391 (SIPS Required). The proxy or UAS may use the warning text field to provide user, e.g.: Warning: 390 isi.edu "Please use a SIP URI" Warning: 391 isi.edu "A secure SIPS URI is required" OPTION 1 has the characteristic of being "opaque" to Automatas, but it is generic enough to support other URI schemes. The precise reasons is described in human-readable format. OPTON 2 has the characteristic of precisely describing the reason for the rejection. It is NOT opaque to Automatas. If new warnings are necessary for other URI shemes, new warning headers can be defined. In both cases, existing UACs (or UACs that do not wish to have any special behavior based on this) will exhibit the desired behavior, i.e., it will look like "temporarily unavailable". _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 13:13:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYoX-0003WA-7f; Mon, 30 Jul 2007 13:13:49 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFYoV-0003TB-RS for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 13:13:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYoV-0003Qb-GF for sip@ietf.org; Mon, 30 Jul 2007 13:13:47 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFYoV-0001wH-4R for sip@ietf.org; Mon, 30 Jul 2007 13:13:47 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.100]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IFYoU-0007Bd-4K; Mon, 30 Jul 2007 12:13:46 -0500 Message-ID: <46AE1D2C.3050200@softarmor.com> Date: Mon, 30 Jul 2007 12:17:32 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <46AA09F1.6010401@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E21C3@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF11747253@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF11747253@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet wrote: > In the interest of moving forward on this arcane issue of marginal > interest, I am making the > following concrete proposal. . . . > OPTION 2 > > Use Response code 480, with 2 new Warning headera field 390 > (SIPS Not Allowed) > and 391 (SIPS Required). > > The proxy or UAS may use the warning text field to provide user, > e.g.: > > Warning: 390 isi.edu "Please use a SIP URI" > Warning: 391 isi.edu "A secure SIPS URI is required" > > In the interest of coming to a conclusion, please sign me up for option 2, but I'm willing to accept option 1 nearly as readily. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 13:47:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFZKy-0006l1-6f; Mon, 30 Jul 2007 13:47:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFZKw-0006kq-Hx for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 13:47:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFZKw-0006ki-8K for sip@ietf.org; Mon, 30 Jul 2007 13:47:18 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFZKu-0004QN-WC for sip@ietf.org; Mon, 30 Jul 2007 13:47:18 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 30 Jul 2007 10:47:16 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswMALbArUarR7PE/2dsb2JhbACIZpx1 X-IronPort-AV: i="4.19,199,1183359600"; d="scan'208"; a="508438676:sNHT35343272" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6UHlGoY008735; Mon, 30 Jul 2007 10:47:16 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6UHl8AC007342; Mon, 30 Jul 2007 17:47:16 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); Mon, 30 Jul 2007 13:47:11 -0400 Received: from [161.44.174.190] ([161.44.174.190]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 13:47:11 -0400 Message-ID: <46AE241B.4070208@cisco.com> Date: Mon, 30 Jul 2007 13:47:07 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <46AA09F1.6010401@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E21C3@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF11747253@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF11747253@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 17:47:11.0216 (UTC) FILETIME=[A803AF00:01C7D2D1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2163; t=1185817636; x=1186681636; c=relaxed/simple; s=sjdkim4002; 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[Sip]=20draft-ietf-sip-sips-05=3A=20480=20vs.=20418 |Sender:=20; bh=2/4KXU5/5XMI8eUDhCTPu2TpORXxA4MrFxA4W8wGyOQ=; b=g57mzip/2tZDGQyaZdhDvFxeTkksgnoPU+hvtTuXhtDkpdstbI5f4ZYmlxq95uYgTNy+nMPD wcF/Kdsx8gypJnShsCmwWkYZeahnK39uXgLp5nMZDHukGLcwExLUlPrD; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I am ok with either of these, though I somewhat prefer Option 2. I don't know what you mean about Option 1 being opaque to automata. It seems to me it provides comparable info to Option 2, giving that the UAC knows what it used in the request. Paul Francois Audet wrote: > In the interest of moving forward on this arcane issue of marginal > interest, I am making the > following concrete proposal. > > Here are 2 alternatives. I'd like to have a virtual show of hands on > which option is > preferred by people. > > > OPTION 1 > > Use Response code 480, with new Warning header field 390 (URI > Scheme Not Supported) > for both cases when SIP or SIPS is rejected. > > The proxy or UAS may use the warning text field to provide more > indications, e.g.: > > Warning: 390 isi.edu "SIPS Not Allowed" > Warning: 390 isi.edu "SIPS Required" > > OPTION 2 > > Use Response code 480, with 2 new Warning headera field 390 > (SIPS Not Allowed) > and 391 (SIPS Required). > > The proxy or UAS may use the warning text field to provide user, > e.g.: > > Warning: 390 isi.edu "Please use a SIP URI" > Warning: 391 isi.edu "A secure SIPS URI is required" > > > OPTION 1 has the characteristic of being "opaque" to Automatas, but it > is generic > enough to support other URI schemes. The precise reasons is described in > human-readable > format. > > OPTON 2 has the characteristic of precisely describing the reason for > the rejection. It > is NOT opaque to Automatas. If new warnings are necessary for other URI > shemes, new warning > headers can be defined. > > In both cases, existing UACs (or UACs that do not wish to have any > special behavior based > on this) will exhibit the desired behavior, i.e., it will look like > "temporarily unavailable". > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 13:59:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFZWj-0004T1-Iu; Mon, 30 Jul 2007 13:59:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFZWi-0004Sk-8v for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 13:59:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFZWh-0004Sb-UJ for sip@ietf.org; Mon, 30 Jul 2007 13:59:27 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFZWh-0004fW-7b for sip@ietf.org; Mon, 30 Jul 2007 13:59:27 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6UHxNB27320; Mon, 30 Jul 2007 17:59:23 GMT 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 Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Mon, 30 Jul 2007 12:59:02 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF11747414@zrc2hxm0.corp.nortel.com> In-reply-to: <46AE241B.4070208@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfS0bAqFnu36HGlR+KTuJsPLQfBYQAASs6Q References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <46AA09F1.6010401@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E21C3@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF11747253@zrc2hxm0.corp.nortel.com> <46AE241B.4070208@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Monday, July 30, 2007 10:47 > To: Audet, Francois (SC100:3055) > Cc: IETF SIP List > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > I don't know what you mean about Option 1 being opaque to=20 > automata. It seems to me it provides comparable info to=20 > Option 2, giving that the UAC knows what it used in the request. It means an Automata can not "upgrade" or "downgrade" automatically with OPTION 1, as the indication is not a "hard" indication. It is a Warning text that is not standardized, and will vary by language, operators, region, etc. Best it can do is "record" the Warning text. That can be done automatically of course. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 16:11:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFbai-0003i0-AS; Mon, 30 Jul 2007 16:11:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFbae-0003gu-MF for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 16:11:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFbae-0003gb-71 for sip@ietf.org; Mon, 30 Jul 2007 16:11:40 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFbac-00082o-Ul for sip@ietf.org; Mon, 30 Jul 2007 16:11:40 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 30 Jul 2007 13:11:37 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALLirUarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.19,200,1183359600"; d="scan'208"; a="389097433:sNHT4459349094" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6UKBaEC018625; Mon, 30 Jul 2007 13:11:36 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6UKBMSt002094; Mon, 30 Jul 2007 20:11:36 GMT Received: from xmb-sjc-231.amer.cisco.com ([128.107.191.73]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 13:11:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Mon, 30 Jul 2007 13:11:34 -0700 Message-ID: <49DFEF82990374449378AD1198F39F8B039FE2CD@xmb-sjc-231.amer.cisco.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF11747414@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfS0bAqFnu36HGlR+KTuJsPLQfBYQAASs6QAASVjOA= From: "Charles Eckel \(eckelcu\)" To: "Francois Audet" , "Paul Kyzivat \(pkyzivat\)" X-OriginalArrivalTime: 30 Jul 2007 20:11:34.0741 (UTC) FILETIME=[D3E0B050:01C7D2E5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1690; t=1185826296; x=1186690296; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=eckelcu@cisco.com; z=From:=20=22Charles=20Eckel=20\(eckelcu\)=22=20 |Subject:=20RE=3A=20[Sip]=20draft-ietf-sip-sips-05=3A=20480=20vs.=20418 |Sender:=20; bh=+lWuXd40KmCqqwc5jdnFnvXK4UsANCyN/nc5GtoKae4=; b=dwHTFP6IBBPRnbfqyKrMq8gSBGt57y1xOBG7ASYycEfCqnHA0spglifJzAnwKHr6OUv+GcFY Dum5v5JHvtXO3hHX+CfWwB0EnfbudqdwV356+zdSqsm5HRLfvZKsMjCZ; Authentication-Results: sj-dkim-3; header.From=eckelcu@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I do not have a real preference, but provided the reason for using 480 = vs. 418 is to minimize na=EFve downgrading from SIPS to SIP, I do not = see how option 2, resulting in: 480=20 Warning: 390 isi.edu "Please use a SIP URI"=20 helps matters. Cheers, Charles > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: Monday, July 30, 2007 10:59 AM > To: Paul Kyzivat (pkyzivat) > Cc: IETF SIP List > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >=20 > =20 >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > > Sent: Monday, July 30, 2007 10:47 > > To: Audet, Francois (SC100:3055) > > Cc: IETF SIP List > > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > > > I don't know what you mean about Option 1 being opaque to=20 > > automata. It seems to me it provides comparable info to=20 > > Option 2, giving that the UAC knows what it used in the request. >=20 > It means an Automata can not "upgrade" or "downgrade"=20 > automatically with > OPTION 1, as the indication is not a "hard" indication. It is=20 > a Warning > text > that is not standardized, and will vary by language,=20 > operators, region, > etc. >=20 > Best it can do is "record" the Warning text. That can be done > automatically > of course. >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 16:22:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFbkd-0001oe-AD; Mon, 30 Jul 2007 16:21:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFbkb-0001oZ-PS for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 16:21:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFbkb-0001oQ-ER for sip@ietf.org; Mon, 30 Jul 2007 16:21:57 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFbka-0000Ad-SQ for sip@ietf.org; Mon, 30 Jul 2007 16:21:57 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6UKLpa28549; Mon, 30 Jul 2007 20:21:52 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Mon, 30 Jul 2007 15:21:34 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF117476F5@zrc2hxm0.corp.nortel.com> In-reply-to: <49DFEF82990374449378AD1198F39F8B039FE2CD@xmb-sjc-231.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfS0bAqFnu36HGlR+KTuJsPLQfBYQAASs6QAASVjOAAAGFo8A== References: <1ECE0EB50388174790F9694F77522CCF11747414@zrc2hxm0.corp.nortel.com> <49DFEF82990374449378AD1198F39F8B039FE2CD@xmb-sjc-231.amer.cisco.com> From: "Francois Audet" To: "Charles Eckel (eckelcu)" , "Paul Kyzivat (pkyzivat)" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Existing implementations would ignore the Warning, and normal treatment = for 480 would occur. I.e., it would be the same treatment as if the user is = recognized as beeing a valid user, but he's currently not logged in. With 418, existing implementations would treat it as 400. I.e., it would = be as if the message itself had an error. This may need to different UI for the user (e.g., different tone played, = different message displayed, etc.) > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 > Sent: Monday, July 30, 2007 13:12 > To: Audet, Francois (SC100:3055); Paul Kyzivat (pkyzivat) > Cc: IETF SIP List > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >=20 > I do not have a real preference, but provided the reason for=20 > using 480 vs. 418 is to minimize na=EFve downgrading from SIPS=20 > to SIP, I do not see how option 2, resulting in: >=20 > 480 > Warning: 390 isi.edu "Please use a SIP URI"=20 >=20 > helps matters. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Monday, July 30, 2007 10:59 AM > > To: Paul Kyzivat (pkyzivat) > > Cc: IETF SIP List > > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Monday, July 30, 2007 10:47 > > > To: Audet, Francois (SC100:3055) > > > Cc: IETF SIP List > > > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > > > > > I don't know what you mean about Option 1 being opaque to=20 > automata.=20 > > > It seems to me it provides comparable info to Option 2,=20 > giving that=20 > > > the UAC knows what it used in the request. > >=20 > > It means an Automata can not "upgrade" or "downgrade"=20 > > automatically with > > OPTION 1, as the indication is not a "hard" indication. It is a=20 > > Warning text that is not standardized, and will vary by language,=20 > > operators, region, etc. > >=20 > > Best it can do is "record" the Warning text. That can be done=20 > > automatically of course. > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 16:40:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFc2n-00036v-3M; Mon, 30 Jul 2007 16:40:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFc2m-00036l-3G for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 16:40:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFc2l-00036Y-N3 for sip@ietf.org; Mon, 30 Jul 2007 16:40:43 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFc2l-0000ed-8d for sip@ietf.org; Mon, 30 Jul 2007 16:40:43 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 87F9133C1A; Mon, 30 Jul 2007 13:38:34 -0700 (PDT) Date: Mon, 30 Jul 2007 13:38:34 -0700 From: Eric Rescorla To: Michael Thomas Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 In-Reply-To: <46AE0F78.1070303@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <20070727153727.A4BDD33C1A@delta.rtfm.com> <46AA138D.6030001@cisco.com> <46AA1FAA.3000204@cisco.com> <20070730160846.178A833C1A@delta.rtfm.com> <46AE0F78.1070303@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070730203834.87F9133C1A@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Rohan Mahy , IETF SIP List , Francois Audet , Jon.Peterson@neustar.com, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At Mon, 30 Jul 2007 09:19:04 -0700, Michael Thomas wrote: > > Eric Rescorla wrote: > > At Fri, 27 Jul 2007 09:39:06 -0700, > > Michael Thomas wrote: > > > >> Rohan Mahy wrote: > >> > >>> Michael, > >>> > >>> At issue here is what the default implementor is likely to do. With a > >>> new 4xx, the misguided but well-meaning implementor is likely to try > >>> to "helpfully" "repair" the error without thinking about or > >>> understanding the security context. > >>> > >>> Using a Warning code raises the bar significantly, but still allows > >>> automata to at least log what happened. > >>> > >> As I said, a receiver is completely at liberty to prevent the downgrade > >> by not > >> accepting the downgraded request. > >> > > > > Unless, of course, someone is impersonating the receiver. > > > Given how tangled up SIPS is, I really no idea what you're talking > about, or whether it's even responsive to my suggestion. Last I heard, > the entire raison d'etre of SIPS was that the next hop is cryptographically > identified via TLS. I'm guessing that you're not suggesting that TLS > is useless against impersonation attacks. Of course not. The point here is that if a caller automatically downgrades to SIP, an active attacker can then intercept the request and accept it, regardless of the receiver's preferences. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 16:54:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFcGI-0002zh-4C; Mon, 30 Jul 2007 16:54:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFcGF-0002zZ-Kn for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 16:54:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFcGF-0002zQ-BG for sip@ietf.org; Mon, 30 Jul 2007 16:54:39 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFcGE-0000hf-52 for sip@ietf.org; Mon, 30 Jul 2007 16:54:39 -0400 Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 30 Jul 2007 13:54:37 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAHrtrUasE2C2/2dsb2JhbAAN X-IronPort-AV: i="4.19,200,1183359600"; d="scan'208"; a="191306358:sNHT29669724" Received: from [64.142.29.214] ([10.21.89.117]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l6UJYeaw002372; Mon, 30 Jul 2007 12:34:40 -0700 Message-ID: <46AE5011.6010702@cisco.com> Date: Mon, 30 Jul 2007 13:54:41 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.12) Gecko/20070509 Thunderbird/1.5.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <20070727153727.A4BDD33C1A@delta.rtfm.com> <46AA138D.6030001@cisco.com> <46AA1FAA.3000204@cisco.com> <20070730160846.178A833C1A@delta.rtfm.com> <46AE0F78.1070303@cisco.com> <20070730203834.87F9133C1A@delta.rtfm.com> In-Reply-To: <20070730203834.87F9133C1A@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1986; t=1185824080; x=1186688080; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20draft-ietf-sip-sips-05=3A=20480=20vs.=20418 |Sender:=20 |To:=20Eric=20Rescorla=20; bh=Wksa+22Cu5O0LIo91bM9djsBsabh/wUdKizpohhCdR8=; b=rh2OIIyPvgEPSgpr+pxqvlzlnjMI6Q+p7iYp1Dmv2d6U8wKBXFcdQQmVwi7gXgpiTV2+ucmD Qiwd0wFlr9kjZ4lqwo6EnuYAuzOI3fZTgoEfctC+pyE54uUZaBXa+M2l; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: IETF SIP List , Rohan Mahy , Francois Audet , Paul Kyzivat , Jon.Peterson@neustar.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Eric Rescorla wrote: > At Mon, 30 Jul 2007 09:19:04 -0700, > Michael Thomas wrote: > >> Eric Rescorla wrote: >> >>> At Fri, 27 Jul 2007 09:39:06 -0700, >>> Michael Thomas wrote: >>> >>> >>>> Rohan Mahy wrote: >>>> >>>> >>>>> Michael, >>>>> >>>>> At issue here is what the default implementor is likely to do. With a >>>>> new 4xx, the misguided but well-meaning implementor is likely to try >>>>> to "helpfully" "repair" the error without thinking about or >>>>> understanding the security context. >>>>> >>>>> Using a Warning code raises the bar significantly, but still allows >>>>> automata to at least log what happened. >>>>> >>>>> >>>> As I said, a receiver is completely at liberty to prevent the downgrade >>>> by not >>>> accepting the downgraded request. >>>> >>>> >>> Unless, of course, someone is impersonating the receiver. >>> >>> >> Given how tangled up SIPS is, I really no idea what you're talking >> about, or whether it's even responsive to my suggestion. Last I heard, >> the entire raison d'etre of SIPS was that the next hop is cryptographically >> identified via TLS. I'm guessing that you're not suggesting that TLS >> is useless against impersonation attacks. >> > > Of course not. > > The point here is that if a caller automatically downgrades to SIP, > an active attacker can then intercept the request and accept it, > regardless of the receiver's preferences. > Um, so? That's the risk that the sender takes by sending stuff in the clear. And where's the problem here anyway? The steps are: try SIPS, then try SIP. If the first succeeds, there's no attack. So it's only in some slim window of when the receiver was down, or something like that. Doesn't seem to me to be something to get all exercised about, especially when you factor in all of the other insecurities associated with SIPS. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 17:33:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFcrp-0007iW-Vm; Mon, 30 Jul 2007 17:33:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFcro-0007iM-J9 for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 17:33:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFcro-0007iE-6v for sip@ietf.org; Mon, 30 Jul 2007 17:33:28 -0400 Received: from rwcrmhc15.comcast.net ([204.127.192.85]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFcrn-0002Gi-Ip for sip@ietf.org; Mon, 30 Jul 2007 17:33:27 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc15) with ESMTP id <20070730213326m1500a6e6be>; Mon, 30 Jul 2007 21:33:26 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l6ULXP8t005055 for ; Mon, 30 Jul 2007 17:33:25 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l6ULXPXV005051; Mon, 30 Jul 2007 17:33:25 -0400 Date: Mon, 30 Jul 2007 17:33:25 -0400 Message-Id: <200707302133.l6ULXPXV005051@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <5D1A7985295922448D5550C94DE29180014B69AB@DEEXC1U01.de.lucent.com> (drage@alcatel-lucent.com) Subject: Re: [Sip] Two minor Max-Breadth comments References: <46A6113A.9000500@nostrum.com> <200707241500.l6OF0bML016019@dragon.ariadne.com> <5D1A7985295922448D5550C94DE29180014B69AB@DEEXC1U01.de.lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "DRAGE, Keith \(Keith\)" How does the UAC cancelling the request help. Surely all we end up with is the CANCEL request desperatly trying to catch up with all the propagated INVITE requests. I see nothing in the transaction model that helps it catch up, and I suspect (based on experience in non-SIP systems) that it never will in most people's implementations. It will always be pretty much the same number of steps behind. By design, the total number of transactions active at any moment will be limited to Max-Forwards times Max-Breadth. In the canonical example, that's 20 times 64 equals 1280. There are 64 active "fingers" that are depth-first-searching the tree of possible forks, and each finger is limited to being 20 forwards long. Of course, there's a lot of activity at the ends of the fingers, but each finger's actions are serial. In the worse case, all 1280 transactions are happening on the same SIP agent, so its work-queue can have 1280 items in it at any moment. But at the same time, the work-queue can have no more than 1280 items in it. Injecting a CANCEL at the top of the tree, the cancel may have to wait for 1280 actions to be processed before it gets processed. The CANCEL stops the (unique) depth = 1 transaction from generating any more requests, and also generates CANCELs that go to all of the depth = 2 transactions. Each of those second-generation CANCELs may have to wait for 1280 work-items ahead of it before they are processed. (Actually, 19 times 64 equals 1216 work-items.) But that won't take horribly long, and you can work out the time-bound by which time all the second-generation CANCELs have been processed, terminated the generation of depth = 3 requests, and caused the sending of the third-generation CANCELs. Etc., for depth = 3 to 20. What saves the day is that Max-Breadth prevents any single SIP agent from becoming totally jammed, so that any CANCEL will be processed within a bounded amount of time. And that Max-Forwards prevents the fork fingers from extending beyond the limit at their tips while their roots are being torn down by CANCELs. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 17:53:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFdBR-0002Ox-93; Mon, 30 Jul 2007 17:53:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFdBQ-0002L3-EJ for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 17:53:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFdBQ-0002JI-41 for sip@ietf.org; Mon, 30 Jul 2007 17:53:44 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFdBO-0003D1-Ey for sip@ietf.org; Mon, 30 Jul 2007 17:53:44 -0400 Received: from unknown (HELO 306181ANEX3.global.avaya.com) ([135.9.6.101]) by co300216-co-outbound.avaya.com with ESMTP; 30 Jul 2007 17:53:41 -0400 X-IronPort-AV: i="4.19,200,1183348800"; d="scan'208"; a="48232690:sNHT8650794" 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 Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Mon, 30 Jul 2007 15:52:58 -0600 Message-ID: <166476A2803C3B4994D744DFD57A942F230DA5@306181ANEX3.global.avaya.com> In-Reply-To: <46AE5011.6010702@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfS697+Mqir1LT8RLGRYPm7vdHT1QAB2OVQ References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <20070727153727.A4BDD33C1A@delta.rtfm.com> <46AA138D.6030001@cisco.com> <46AA1FAA.3000204@cisco.com> <20070730160846.178A833C1A@delta.rtfm.com> <46AE0F78.1070303@cisco.com><20070730203834.87F9133C1A@delta.rtfm.com> <46AE5011.6010702@cisco.com> From: "Rai, Anupam (Anupam)" To: "Michael Thomas" , "Eric Rescorla" X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: IETF SIP List , Rohan Mahy , Francois Audet , Paul Kyzivat , Jon.Peterson@neustar.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org An active attacker could very well DoS the SIPS attempt making it look like "reciever was down". Hence downgrade must never bet attempted under such condition. There must be some explict indication, like the one discussed here, to indicate that contact does not accept SIPS. -Anupam > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com]=20 > Sent: Monday, July 30, 2007 1:55 PM > To: Eric Rescorla > Cc: IETF SIP List; Rohan Mahy; Francois Audet; Paul Kyzivat;=20 > Jon.Peterson@neustar.com > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >=20 > Eric Rescorla wrote: > > At Mon, 30 Jul 2007 09:19:04 -0700, > > Michael Thomas wrote: > > =20 > >> Eric Rescorla wrote: > >> =20 > >>> At Fri, 27 Jul 2007 09:39:06 -0700, > >>> Michael Thomas wrote: > >>> =20 > >>> =20 > >>>> Rohan Mahy wrote: > >>>> =20 > >>>> =20 > >>>>> Michael, > >>>>> > >>>>> At issue here is what the default implementor is likely to do. =20 > >>>>> With a new 4xx, the misguided but well-meaning implementor is=20 > >>>>> likely to try to "helpfully" "repair" the error without=20 > thinking=20 > >>>>> about or understanding the security context. > >>>>> > >>>>> Using a Warning code raises the bar significantly, but still=20 > >>>>> allows automata to at least log what happened. > >>>>> =20 > >>>>> =20 > >>>> As I said, a receiver is completely at liberty to prevent the=20 > >>>> downgrade by not accepting the downgraded request. > >>>> =20 > >>>> =20 > >>> Unless, of course, someone is impersonating the receiver. > >>> =20 > >>> =20 > >> Given how tangled up SIPS is, I really no idea what you're talking=20 > >> about, or whether it's even responsive to my suggestion. Last I=20 > >> heard, the entire raison d'etre of SIPS was that the next hop is=20 > >> cryptographically identified via TLS. I'm guessing that you're not=20 > >> suggesting that TLS is useless against impersonation attacks. > >> =20 > > > > Of course not. > > > > The point here is that if a caller automatically downgrades=20 > to SIP, an=20 > > active attacker can then intercept the request and accept it,=20 > > regardless of the receiver's preferences. > > =20 >=20 > Um, so? That's the risk that the sender takes by sending=20 > stuff in the clear. And where's the problem here anyway? The=20 > steps are: try SIPS, then try SIP.=20 > If the > first succeeds, there's no attack. So it's only in some slim=20 > window of when the receiver was down, or something like that.=20 > Doesn't seem to me to be something to get all exercised=20 > about, especially when you factor in all of the other=20 > insecurities associated with SIPS. >=20 > Mike >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 18:02:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFdJm-0006LC-9P; Mon, 30 Jul 2007 18:02:22 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFdJk-0006L0-GV for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 18:02:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFdJk-0006Ks-3A for sip@ietf.org; Mon, 30 Jul 2007 18:02:20 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFdJj-0003yj-D2 for sip@ietf.org; Mon, 30 Jul 2007 18:02:19 -0400 Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 30 Jul 2007 15:02:18 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAHr8rUasE2C2/2dsb2JhbAAN X-IronPort-AV: i="4.19,200,1183359600"; d="scan'208"; a="191340598:sNHT37989414" Received: from [64.142.29.214] ([10.21.89.117]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l6UKgLm9005164; Mon, 30 Jul 2007 13:42:22 -0700 Message-ID: <46AE5FF0.4090403@cisco.com> Date: Mon, 30 Jul 2007 15:02:24 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.12) Gecko/20070509 Thunderbird/1.5.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: "Rai, Anupam (Anupam)" Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <20070727153727.A4BDD33C1A@delta.rtfm.com> <46AA138D.6030001@cisco.com> <46AA1FAA.3000204@cisco.com> <20070730160846.178A833C1A@delta.rtfm.com> <46AE0F78.1070303@cisco.com><20070730203834.87F9133C1A@delta.rtfm.com> <46AE5011.6010702@cisco.com> <166476A2803C3B4994D744DFD57A942F230DA5@306181ANEX3.global.avaya.com> In-Reply-To: <166476A2803C3B4994D744DFD57A942F230DA5@306181ANEX3.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3857; t=1185828142; x=1186692142; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Sip]=20draft-ietf-sip-sips-05=3A=20480=20vs.=20418 |Sender:=20 |To:=20=22Rai,=20Anupam=20(Anupam)=22=20; bh=TKRkVrBDujKpRDzzEvlQpQLkwHe0HNfHUjkQZV9ZWBE=; b=m50+kNmjsEeC7EJhjmEO63tYGsl60hlOEzdgER0fPzIbKFdlFpNRkeZckHtDDXAmUx6AKsxD AT+djbqsAlFClAl+OLa9Oa8sZsquVMARNCYHzdpFLvfe85XRdoxm5418; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: Rohan Mahy , IETF SIP List , Francois Audet , Jon.Peterson@neustar.com, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org And the way to deal with this is some obscure ietf nanny text in some document that may or may not be read by developers? I'm sorry, but I don't find this a very compelling way to go about fixing this kind of problem. But if you're going to do this at all, at least instruct them that they should only try the SIP downgrade at first contact, so that you don't have to keep exposing yourself on subsequent invitations. Telling them to not do it at all is about the worst advise because it will be ignored. Mike Rai, Anupam (Anupam) wrote: > An active attacker could very well DoS the SIPS attempt making it look > like "reciever was down". Hence downgrade must never bet attempted under > such condition. There must be some explict indication, like the one > discussed here, to indicate that contact does not accept SIPS. > > -Anupam > > >> -----Original Message----- >> From: Michael Thomas [mailto:mat@cisco.com] >> Sent: Monday, July 30, 2007 1:55 PM >> To: Eric Rescorla >> Cc: IETF SIP List; Rohan Mahy; Francois Audet; Paul Kyzivat; >> Jon.Peterson@neustar.com >> Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >> >> Eric Rescorla wrote: >> >>> At Mon, 30 Jul 2007 09:19:04 -0700, >>> Michael Thomas wrote: >>> >>> >>>> Eric Rescorla wrote: >>>> >>>> >>>>> At Fri, 27 Jul 2007 09:39:06 -0700, >>>>> Michael Thomas wrote: >>>>> >>>>> >>>>> >>>>>> Rohan Mahy wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Michael, >>>>>>> >>>>>>> At issue here is what the default implementor is likely to do. >>>>>>> With a new 4xx, the misguided but well-meaning implementor is >>>>>>> likely to try to "helpfully" "repair" the error without >>>>>>> >> thinking >> >>>>>>> about or understanding the security context. >>>>>>> >>>>>>> Using a Warning code raises the bar significantly, but still >>>>>>> allows automata to at least log what happened. >>>>>>> >>>>>>> >>>>>>> >>>>>> As I said, a receiver is completely at liberty to prevent the >>>>>> downgrade by not accepting the downgraded request. >>>>>> >>>>>> >>>>>> >>>>> Unless, of course, someone is impersonating the receiver. >>>>> >>>>> >>>>> >>>> Given how tangled up SIPS is, I really no idea what you're talking >>>> about, or whether it's even responsive to my suggestion. Last I >>>> heard, the entire raison d'etre of SIPS was that the next hop is >>>> cryptographically identified via TLS. I'm guessing that you're not >>>> suggesting that TLS is useless against impersonation attacks. >>>> >>>> >>> Of course not. >>> >>> The point here is that if a caller automatically downgrades >>> >> to SIP, an >> >>> active attacker can then intercept the request and accept it, >>> regardless of the receiver's preferences. >>> >>> >> Um, so? That's the risk that the sender takes by sending >> stuff in the clear. And where's the problem here anyway? The >> steps are: try SIPS, then try SIP. >> If the >> first succeeds, there's no attack. So it's only in some slim >> window of when the receiver was down, or something like that. >> Doesn't seem to me to be something to get all exercised >> about, especially when you factor in all of the other >> insecurities associated with SIPS. >> >> Mike >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 18:10:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFdRw-0003Ey-GQ; Mon, 30 Jul 2007 18:10:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFdRv-0003Es-2o for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 18:10:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFdRu-0003Ek-N2 for sip@ietf.org; Mon, 30 Jul 2007 18:10:46 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFdRu-00048n-6o for sip@ietf.org; Mon, 30 Jul 2007 18:10:46 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 17EE333C1A; Mon, 30 Jul 2007 15:08:34 -0700 (PDT) Date: Mon, 30 Jul 2007 15:08:34 -0700 From: Eric Rescorla To: Michael Thomas Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 In-Reply-To: <46AE5011.6010702@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <20070727153727.A4BDD33C1A@delta.rtfm.com> <46AA138D.6030001@cisco.com> <46AA1FAA.3000204@cisco.com> <20070730160846.178A833C1A@delta.rtfm.com> <46AE0F78.1070303@cisco.com> <20070730203834.87F9133C1A@delta.rtfm.com> <46AE5011.6010702@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070730220835.17EE333C1A@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Rohan Mahy , IETF SIP List , Francois Audet , Jon.Peterson@neustar.com, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At Mon, 30 Jul 2007 13:54:41 -0700, Michael Thomas wrote: > > Eric Rescorla wrote: > > At Mon, 30 Jul 2007 09:19:04 -0700, > > Michael Thomas wrote: > > > >> Eric Rescorla wrote: > >> > >>> At Fri, 27 Jul 2007 09:39:06 -0700, > >>> Michael Thomas wrote: > >>> > >>> > >>>> Rohan Mahy wrote: > >>>> > >>>> > >>>>> Michael, > >>>>> > >>>>> At issue here is what the default implementor is likely to do. With a > >>>>> new 4xx, the misguided but well-meaning implementor is likely to try > >>>>> to "helpfully" "repair" the error without thinking about or > >>>>> understanding the security context. > >>>>> > >>>>> Using a Warning code raises the bar significantly, but still allows > >>>>> automata to at least log what happened. > >>>>> > >>>>> > >>>> As I said, a receiver is completely at liberty to prevent the downgrade > >>>> by not > >>>> accepting the downgraded request. > >>>> > >>>> > >>> Unless, of course, someone is impersonating the receiver. > >>> > >>> > >> Given how tangled up SIPS is, I really no idea what you're talking > >> about, or whether it's even responsive to my suggestion. Last I heard, > >> the entire raison d'etre of SIPS was that the next hop is cryptographically > >> identified via TLS. I'm guessing that you're not suggesting that TLS > >> is useless against impersonation attacks. > >> > > > > Of course not. > > > > The point here is that if a caller automatically downgrades to SIP, > > an active attacker can then intercept the request and accept it, > > regardless of the receiver's preferences. > > > > Um, so? That's the risk that the sender takes by sending stuff in the > clear. And > where's the problem here anyway? The steps are: try SIPS, then try SIP. > If the > first succeeds, there's no attack. So it's only in some slim window of > when the > receiver was down, or something like that. Doesn't seem to me to be > something > to get all exercised about, especially when you factor in all of the > other insecurities > associated with SIPS. I'm not saying it's something huge to get exercised about. However, since the question is what behavior to define here, we might as well get it right. -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 18:23:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFdeH-0000nV-DC; Mon, 30 Jul 2007 18:23:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFdeF-0000nN-Vb for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 18:23:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFdeF-0000nF-M3 for sip@ietf.org; Mon, 30 Jul 2007 18:23:31 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFdeE-0003ub-G4 for sip@ietf.org; Mon, 30 Jul 2007 18:23:31 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l6UMLSq29686; Mon, 30 Jul 2007 22:21:28 GMT 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, 30 Jul 2007 17:23:14 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1174794F@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Warn-Codes and draft-ietf-sip-sips Thread-Index: AcfS+Dh3GW4cRtZzQDyKjx11x+8T6w== From: "Francois Audet" To: "IETF SIP List" , "Jonathan Rosenberg" , "Dean Willis" , , , "Mahy Rohan" , "Cullen Jennings" , "Robert Sparks" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Sip] Warn-Codes and draft-ietf-sip-sips X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Now that we have everybody exited about the prospect of using a Warn-Code for "SIPS Not Allowed" and "SIP Required" with Response 480, instead of using new response codes, here is a quote from 27.2/RFC 3261. Warning codes provide information supplemental to the status code in SIP response messages when the failure of the transaction results from a Session Description Protocol (SDP) (RFC 2327 [1]) problem. My reading of this is that Warn-Codes are ONLY usable for SDP errors. Doesn't this disqualify the idea of using a Warn-Code for SIP/SIPS URI problems?????? If so, aren't we back to 418/419, or 418+New header (Allow/Require), or=20 480+Response text? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 20:52:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFfxn-0002C7-QR; Mon, 30 Jul 2007 20:51:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFfxl-0002C0-G9 for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 20:51:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFfxl-0002Br-6V for sip@ietf.org; Mon, 30 Jul 2007 20:51:49 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFfxk-0007Z4-8r for sip@ietf.org; Mon, 30 Jul 2007 20:51:49 -0400 Received: by py-out-1112.google.com with SMTP id f31so5452904pyh for ; Mon, 30 Jul 2007 17:51:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=uFn0gJ7HkaGCQDKjSbizShDyF4/oWQD3NqfUbrxDkm89DDmzhZXbpB2MkGuoq9+kIpuNRKte+EEzMsjBl6mAJokr9BhFAYNcF8GhuNjR3imbKP2k+JC4Q6prPo7qfRSvcN/UaMymoKvBG+5hWZtfIFWaE8tD0rflSKEJ+3idETM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Dw3M3h76C90vSSE+Yv8zlWPbzYpEqgR6wdypZswNLxA2LijUcWZje+3Ix39SdXbGpiqlTvM6+ZK53U6bDQgFVLySjo4FeabRZZlNLSCumSnKf3fuNaiiNflYkvHmx/kbz4DUb7OOO2VRczER//SHrYJml75S1xGn9kslshZ0hgc= Received: by 10.65.135.19 with SMTP id m19mr9659180qbn.1185843106124; Mon, 30 Jul 2007 17:51:46 -0700 (PDT) Received: by 10.65.213.1 with HTTP; Mon, 30 Jul 2007 17:51:46 -0700 (PDT) Message-ID: <66cd252f0707301751y11671db6xf5e70855093ceb51@mail.gmail.com> Date: Tue, 31 Jul 2007 10:51:46 +1000 From: "Hisham Khartabil" To: "Francois Audet" Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF117476F5@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 References: <1ECE0EB50388174790F9694F77522CCF11747414@zrc2hxm0.corp.nortel.com> <49DFEF82990374449378AD1198F39F8B039FE2CD@xmb-sjc-231.amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF117476F5@zrc2hxm0.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: IETF SIP List , "Paul Kyzivat \(pkyzivat\)" , "Charles Eckel \(eckelcu\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1300011482==" Errors-To: sip-bounces@ietf.org --===============1300011482== Content-Type: multipart/alternative; boundary="----=_Part_33216_15644429.1185843106028" ------=_Part_33216_15644429.1185843106028 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline With a new 4xx response, existing implementations would treat it as 400 anyway. In any case, option 1 is good enough, but I am not a fan of using reason phrases as indicators to humans. I call someone is Japan and get a Japanese string telling me 'SIPS required'. I would have no clue what its saying. Hisham On 31/07/07, Francois Audet wrote: > > Existing implementations would ignore the Warning, and normal treatment > for 480 > would occur. I.e., it would be the same treatment as if the user is > recognized as > beeing a valid user, but he's currently not logged in. > > With 418, existing implementations would treat it as 400. I.e., it would > be > as if the message itself had an error. > > This may need to different UI for the user (e.g., different tone played, > different > message displayed, etc.) > > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: Monday, July 30, 2007 13:12 > > To: Audet, Francois (SC100:3055); Paul Kyzivat (pkyzivat) > > Cc: IETF SIP List > > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > > > I do not have a real preference, but provided the reason for > > using 480 vs. 418 is to minimize na=EFve downgrading from SIPS > > to SIP, I do not see how option 2, resulting in: > > > > 480 > > Warning: 390 isi.edu "Please use a SIP URI" > > > > helps matters. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: Monday, July 30, 2007 10:59 AM > > > To: Paul Kyzivat (pkyzivat) > > > Cc: IETF SIP List > > > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > > > > > > > > > > > > -----Original Message----- > > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > Sent: Monday, July 30, 2007 10:47 > > > > To: Audet, Francois (SC100:3055) > > > > Cc: IETF SIP List > > > > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > > > > > > > I don't know what you mean about Option 1 being opaque to > > automata. > > > > It seems to me it provides comparable info to Option 2, > > giving that > > > > the UAC knows what it used in the request. > > > > > > It means an Automata can not "upgrade" or "downgrade" > > > automatically with > > > OPTION 1, as the indication is not a "hard" indication. It is a > > > Warning text that is not standardized, and will vary by language, > > > operators, region, etc. > > > > > > Best it can do is "record" the Warning text. That can be done > > > automatically of course. > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------=_Part_33216_15644429.1185843106028 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
        With a new 4xx response, existing implementations would treat it as 40= 0 anyway.
         
        In any case, option 1 is good enough, but I am not a fan of using reas= on phrases as indicators to humans. I call someone is Japan and get a Japan= ese string telling me 'SIPS required'. I would have no clue what it= s saying.
         
        Hisham

         
        On 31/07/07, Francois Audet <audet@nortel.co= m> wrote:
        Existing implementations would i= gnore the Warning, and normal treatment for 480
        would occur. I.e., it wo= uld be the same treatment as if the user is recognized as
        beeing a valid user, but he's currently not logged in.

        With = 418, existing implementations would treat it as 400. I.e., it would be
        a= s if the message itself had an error.

        This may need to different UI = for the user ( e.g., different tone played, different
        message displayed, etc.)

        &= gt; -----Original Message-----
        > From: Charles Eckel (eckelcu) [mailt= o:eckelcu@cisco.com]
        > Sent:= Monday, July 30, 2007 13:12
        > To: Audet, Francois (SC100:3055); Paul Kyzivat (pkyzivat)
        > = Cc: IETF SIP List
        > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs= . 418
        >
        > I do not have a real preference, but provided the rea= son for
        > using 480 vs. 418 is to minimize na=EFve downgrading from SIPS
        = > to SIP, I do not see how option 2, resulting in:
        >
        > 480> Warning: 390 isi.edu "Please use= a SIP URI"
        >
        > helps matters.
        >
        > Cheers,
        > Charles
        = >
        > > -----Original Message-----
        > > From: Francois Au= det [mailto:audet@nortel.com]
        > > Sent: Monday, July 30, 2007 10:59 AM
        > > To: Paul Kyziva= t (pkyzivat)
        > > Cc: IETF SIP List
        > > Subject: RE: [Sip]= draft-ietf-sip-sips-05: 480 vs. 418
        > >
        > >
        > >
        > > > -----Original Message-----
        > > > From: Paul = Kyzivat [mailto:pkyzivat@cisco.com]
        > > > Sent: Monday, July 30, 2007 10:47
        > > > To= : Audet, Francois (SC100:3055)
        > > > Cc: IETF SIP List
        > > > Subject: Re: [Sip] d= raft-ietf-sip-sips-05: 480 vs. 418
        > > >
        > > > I do= n't know what you mean about Option 1 being opaque to
        > automata.
        > > > It seems to me it provides comparable info to Option 2,<= br>> giving that
        > > > the UAC knows what it used in the req= uest.
        > >
        > > It means an Automata can not "upgrade&= quot; or "downgrade"
        > > automatically with
        > > OPTION 1, as the indication i= s not a "hard" indication. It is a
        > > Warning text that= is not standardized, and will vary by language,
        > > operators, re= gion, etc.
        > >
        > > Best it can do is "record" the Warning= text. That can be done
        > > automatically of course.
        > ><= br>> >
        > >
        > > ____________________________________= ___________
        > > Sip mailing list          https://www1.ietf.org/mailman/listinfo/sip
        >= ; > This list is for NEW development of the core SIP Protocol Use
        >= ; > sip-implementors@cs.columbia.edu for questions on current sip Use
        &g= t; > sipping@ietf.org for new de= velopments on the application of sip
        > >
        >


        ______= _________________________________________
        Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
        This list is = for NEW development of the core SIP Protocol
        Use sip-implementors@cs.columbia.edu for questions on current sip
        Use sipping@ietf.org for new developments= on the application of sip

        ------=_Part_33216_15644429.1185843106028-- --===============1300011482== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1300011482==-- From sip-bounces@ietf.org Mon Jul 30 20:54:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFg0g-0003wd-8Q; Mon, 30 Jul 2007 20:54:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFg0e-0003wP-H8 for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 20:54:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFg0e-0003wH-7c for sip@ietf.org; Mon, 30 Jul 2007 20:54:48 -0400 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFg0d-0007cZ-Nc for sip@ietf.org; Mon, 30 Jul 2007 20:54:48 -0400 Received: by py-out-1112.google.com with SMTP id f31so5454816pyh for ; Mon, 30 Jul 2007 17:54:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=IUxtK933d3ltlZI0GM6/30Yzet9bocIRTfVjgAVCkMxs677qsaNsQkb7wNsGn/uqO/QE7iiNhKZ4qzQOjF5JEkts8YV5MyT0d0NlJO7y2UPODHrufnOR/vmg3cLXyySjLstKutxP1pjLinjUgv2g5sueW31i2gN56Sloq/YJqNk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Cz/Vqd4degN+9MhpqdRSbHcdbudexmLCVcOTCaX/EizN2hk2hI6/9puOE1Sau5GY2cinczDtB9/Zgdy9Z0Hi0pxjzCoAKr3YIqM5XBoZ0m1huSElaf/t7xTiV/bXKzd50/LsYQA8bClGMCSkMNw1+8OrkP7TPikEw9TEMhre8Ms= Received: by 10.65.147.1 with SMTP id z1mr9669368qbn.1185843286343; Mon, 30 Jul 2007 17:54:46 -0700 (PDT) Received: by 10.65.213.1 with HTTP; Mon, 30 Jul 2007 17:54:46 -0700 (PDT) Message-ID: <66cd252f0707301754l69ffe964hd732e75cecd63ba7@mail.gmail.com> Date: Tue, 31 Jul 2007 10:54:46 +1000 From: "Hisham Khartabil" To: "Francois Audet" Subject: Re: [Sip] Warn-Codes and draft-ietf-sip-sips In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1174794F@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 References: <1ECE0EB50388174790F9694F77522CCF1174794F@zrc2hxm0.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1653496290==" Errors-To: sip-bounces@ietf.org --===============1653496290== Content-Type: multipart/alternative; boundary="----=_Part_33232_3955756.1185843286295" ------=_Part_33232_3955756.1185843286295 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Like I said in an earlier email, Reason phrases are not good enough for me, unless my phone has a translation for every language on Earth. It is much preferred that my phone looks at the error code and presents me with a localised reason phrase. Hisham On 31/07/07, Francois Audet wrote: > > Now that we have everybody exited about the prospect of using a > Warn-Code > for "SIPS Not Allowed" and "SIP Required" with Response 480, instead of > using > new response codes, here is a quote from 27.2/RFC 3261. > > Warning codes provide information supplemental to the status code in > SIP response messages when the failure of the transaction results > from a Session Description Protocol (SDP) (RFC 2327 [1]) problem. > > My reading of this is that Warn-Codes are ONLY usable for SDP errors. > > Doesn't this disqualify the idea of using a Warn-Code for SIP/SIPS URI > problems?????? > > If so, aren't we back to 418/419, or 418+New header (Allow/Require), or > 480+Response text? > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------=_Part_33232_3955756.1185843286295 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
        Like I said in an earlier email, Reason phrases are not good enough for me, unless my phone has a translation for every language on Earth.
         
        It is much preferred that my phone looks at the error code and presents me with a localised reason phrase.
         
        Hisham

         
        On 31/07/07, Francois Audet <audet@nortel.com> wrote:
        Now that we have everybody exited about the prospect of using a
        Warn-Code
        for "SIPS Not Allowed" and "SIP Required" with Response 480, instead of
        using
        new response codes, here is a quote from 27.2/RFC 3261.

          Warning codes provide information supplemental to the status code in
          SIP response messages when the failure of the transaction results
          from a Session Description Protocol (SDP) (RFC 2327 [1]) problem.

        My reading of this is that Warn-Codes are ONLY usable for SDP errors.

        Doesn't this disqualify the idea of using a Warn-Code for SIP/SIPS URI
        problems??????

        If so, aren't we back to 418/419, or 418+New header (Allow/Require), or
        480+Response text?


        _______________________________________________
        Sip mailing list   https://www1.ietf.org/mailman/listinfo/sip
        This list is for NEW development of the core SIP Protocol
        Use sip-implementors@cs.columbia.edu for questions on current sip
        Use sipping@ietf.org for new developments on the application of sip

        ------=_Part_33232_3955756.1185843286295-- --===============1653496290== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1653496290==-- From sip-bounces@ietf.org Mon Jul 30 21:37:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFgfh-0005I4-FN; Mon, 30 Jul 2007 21:37:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFgff-0005Hw-77 for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 21:37:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFgfe-0005Ho-Sd for sip@ietf.org; Mon, 30 Jul 2007 21:37:10 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFgfd-0001Ng-Ve for sip@ietf.org; Mon, 30 Jul 2007 21:37:10 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM000H4USGS6Q@szxga01-in.huawei.com> for sip@ietf.org; Tue, 31 Jul 2007 09:36:28 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM000253SGRG3@szxga01-in.huawei.com> for sip@ietf.org; Tue, 31 Jul 2007 09:36:28 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JM000KFZSGOO9@szxml04-in.huawei.com> for sip@ietf.org; Tue, 31 Jul 2007 09:36:27 +0800 (CST) Date: Tue, 31 Jul 2007 09:36:24 +0800 From: Qian Sun Subject: RE: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides forbody (MIME) handling) In-reply-to: <46A09239.6010908@softarmor.com> To: 'Dean Willis' Message-id: <024301c7d313$348e5150$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Thread-index: AcfKupB62GZKRId9SlOVj2wAEWz7JgIUvGQA X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 'sip' , 'Paul Kyzivat' , 'Gonzalo Camarillo' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Dean Sorry for late response. Do you mean "advertisement" content always is needed to 'render'? So a single content disposition "advertisement" is enough. In addition, some content body (e.g. Geolocation or advertisement) may be inserted or modified by intermediary. Could we specify a common way for indicating the source of inserted content body? For example, define a new MIME header: Content-Insertedby. A B2BUA may insert a content body including AD like this: Content-Type: text/plain Content-Disposition: advertisement Content-Insertedby: AD-Agent McDonald, i'm lovin' it! Opinion? Cheers, Qian -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, July 20, 2007 6:45 PM To: Qian Sun Cc: 'Paul Kyzivat'; 'Gonzalo Camarillo'; 'sip' Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides forbody (MIME) handling) Qian Sun wrote: > If we define a new Content Disposition type "advertisement" so that > the operator or service provider may insert advertisement in the all > kinds of message body. And we want the advertisement content 'render' > to the users. Could we use multiple content dispositions > ("advertisement" and 'render') for a single content part? Or only > define a new Content Disposition Parameters "advertisement" instead? So is there a need to ever use "advertisement" in conjunction with something besides "render"? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jul 30 22:30:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFhUo-00006i-OC; Mon, 30 Jul 2007 22:30:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFhUn-000065-BK for sip-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 22:30:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFhUn-00005u-07 for sip@ietf.org; Mon, 30 Jul 2007 22:30:01 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFhUm-0003O9-Jw for sip@ietf.org; Mon, 30 Jul 2007 22:30:00 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 Jul 2007 22:29:59 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwPAEs7rkZAZnme/2dsb2JhbACIBJwj X-IronPort-AV: i="4.19,201,1183348800"; d="scan'208"; a="66585957:sNHT28084670" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6V2U0Zo023185; Mon, 30 Jul 2007 22:30:00 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6V2TvEZ000866; Tue, 31 Jul 2007 02:29:57 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 22:29:57 -0400 Received: from [10.82.218.240] ([10.82.218.240]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 22:29:57 -0400 Message-ID: <46AE9EA5.8070908@cisco.com> Date: Mon, 30 Jul 2007 22:29:57 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Qian Sun Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides forbody (MIME) handling) References: <024301c7d313$348e5150$7c6c460a@china.huawei.com> In-Reply-To: <024301c7d313$348e5150$7c6c460a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2007 02:29:57.0115 (UTC) FILETIME=[AF8C0CB0:01C7D31A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1792; t=1185849000; x=1186713000; c=relaxed/simple; s=rtpdkim1001; 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=20Content-Disposition=20in=20multiparts=20WAS=20(Re=3A= 20[Sip]=20Draft=20slides=0A=20forbody=20(MIME)=20handling) |Sender:=20 |To:=20Qian=20Sun=20; bh=B+b0Qn5Rq/TQwlVvkc8c4SV40qEMffR9BY+Ek99zN1g=; b=ktV8TaI9hn9HwqZ+nt2fPxXTk6b0gaXv7XrpqgHLRDSWV1hs91pn5zptsCsVt+n3+Itie4p+ t09VoblKSlN9SWWm48ve0SPKUE3LCipBp8oUzgavOjdLT5iVT4oEK71z; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: 'sip' , 'Gonzalo Camarillo' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'd rather not institutionalize advertising in ietf standards. BUT, if we can get an agreement that all advertisements, of any sort, MUST be labeled with the "advertisement" content-disposition. Paul Qian Sun wrote: > Hi, Dean > > Sorry for late response. Do you mean "advertisement" content always is needed to 'render'? So a single content disposition "advertisement" is enough. > > In addition, some content body (e.g. Geolocation or advertisement) may be inserted or modified by intermediary. Could we specify a common way for indicating the source of inserted content body? For example, define a new MIME header: Content-Insertedby. A B2BUA may insert a content body including AD like this: > > Content-Type: text/plain > Content-Disposition: advertisement > Content-Insertedby: AD-Agent > > McDonald, i'm lovin' it! > > Opinion? > > Cheers, > Qian > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, July 20, 2007 6:45 PM > To: Qian Sun > Cc: 'Paul Kyzivat'; 'Gonzalo Camarillo'; 'sip' > Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides forbody (MIME) handling) > > Qian Sun wrote: >> If we define a new Content Disposition type "advertisement" so that >> the operator or service provider may insert advertisement in the all >> kinds of message body. And we want the advertisement content 'render' >> to the users. Could we use multiple content dispositions >> ("advertisement" and 'render') for a single content part? Or only >> define a new Content Disposition Parameters "advertisement" instead? > > So is there a need to ever use "advertisement" in conjunction with > something besides "render"? > > -- > Dean > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 00:45:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFjaS-0003hv-I1; Tue, 31 Jul 2007 00:44:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFjaR-0003hp-Ky for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 00:43:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFjaR-0003hh-BG for sip@ietf.org; Tue, 31 Jul 2007 00:43:59 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFjaQ-0007KM-Id for sip@ietf.org; Tue, 31 Jul 2007 00:43:59 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 30 Jul 2007 21:43:58 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHZarkarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.19,201,1183359600"; d="scan'208"; a="191488980:sNHT28489680" 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 l6V4hvdr004629; Mon, 30 Jul 2007 21:43:57 -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.12.10/8.12.6) with ESMTP id l6V4hh6C014416; Tue, 31 Jul 2007 04:43:47 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 21:43:43 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.145.35]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 21:43:42 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 30 Jul 2007 23:43:40 -0500 To: "Francois Audet" , "Alan Hawrylyshen" , "Kyzivat Paul" , "Mahy Rohan" From: "James M. Polk" Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF11747126@zrc2hxm0.corp.nor tel.com> References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <46AA09F1.6010401@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E21C3@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF11747126@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 31 Jul 2007 04:43:42.0413 (UTC) FILETIME=[5EFF57D0:01C7D32D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3778; t=1185857037; x=1186721037; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Sip]=20draft-ietf-sip-sips-05=3A=20480=20vs.=20418 |Sender:=20; bh=yAsS6YzW6oIEJZGmQ8Dn0KBDXZ1j5CmG1+SJlWD4Css=; b=LMKh23N6NB3F8dvI5YFAWYtrNLjMAihwH+uUYPbC2I+L0yori+Y6OuflvBs+/yYxN8qrkwfD vLoJcH18iX0AoK2bGlh7g9wEU9a1+XIi6DfKZ5I2MiO9kH1cpN2l6mEQ; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: IETF SIP List , Jon.Peterson@neustar.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 10:54 AM 7/30/2007, Francois Audet wrote: >RFC 3261, p. 181: > > "The first digit of warning codes beginning with "3" indicates >warnings > specific to SIP." > >Then it explains within the 3XX space, how they are used. btw -- for location-conveyance-07, I created 15 new Warning codes (#s 701 through 712, then 720, 721, and 722). All this at the suggestion of Henning (who knows something about 3261 text... ;-) btw II - I have since replaced the Warning header indication with a new Geolocation-Error header, but this was so I could stuff more into the new header than the Warning header would allow. In all this, I did not get one person claiming Warning codes were limited to 3XX. Henning merely said the "first batch of codes were in the 300s, and that there was nothing limiting a new ID from defining new codes in any other number range"... > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Saturday, July 28, 2007 18:25 > > To: Audet, Francois (SC100:3055); Alan Hawrylyshen; Kyzivat > > Paul; Mahy Rohan > > Cc: IETF SIP List; Jon.Peterson@neustar.com > > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > > > A 399 Miscellaneous? That doesn't make sense... > > > > Warning codes are not limited to 3XX, so if a new Warning > > code is what Rohan wants to convey more information in the > > response (which I believe should be done one way or another) > > - it can be almost any value other than 300-379 or 399 IMO. > > > > At 10:32 AM 7/27/2007, Francois Audet wrote: > > >On the Warning header... > > > > > >Values 300-379 are reserved for SDP-related stuff. > > > > > >Values 380-389 are unassiged (but there is no text on it). > > > > > >Values 390-398 are unassigned (but don't fall into the SDP related > > >stuff. > > > > > >399 means Miscellaneous and the text can be provided to the user. > > >It further says that Automata MUST NOT take action based on this. > > > > > >Rohan, are you advocating using 399, or defining a new code from the > > >390-398 space? > > > > > > > -----Original Message----- > > > > From: Alan Hawrylyshen [mailto:a.hawrylyshen@gmail.com] > > On Behalf Of > > > > Alan Hawrylyshen > > > > Sent: Friday, July 27, 2007 08:27 > > > > To: Kyzivat Paul; Mahy Rohan > > > > Cc: Audet, Francois (SC100:3055); IETF SIP List; > > > > Jon.Peterson@neustar.com > > > > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > > > > > > > > > > > On 27-Jul-2007, at 10:06 , Paul Kyzivat wrote: > > > > > > > > > I understand that if the user entered a sips URI then it > > > > should be the > > > > > user that must decide to downgrade. But if the user didn't know > > > > > whether to use sip or sips in the first place, and the UA > > > > decides to > > > > > try sips first then I see no problem in the UA having a policy > > > > > that causes it to downgrade. > > > > > > > > I was under the impression (based on meeting discussion) that : > > > > 1 - the downgrade was undesirable because it reveals > > > > (possibly) information about the targeted party in the clear, and; > > > > 2 - The 480 with a Warning header was an option to provide > > > > automata- friendly indication of the failure reason. > > > > > > > > Alan Hawrylyshen > > > > > > > > a l a n a t p o l y p h a s e d o t c a > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >This list is for NEW development of the core SIP Protocol Use > > >sip-implementors@cs.columbia.edu for questions on current sip Use > > >sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 01:43:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFkVY-0008Gj-GW; Tue, 31 Jul 2007 01:43:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFkVX-0008GV-Pe for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 01:42:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFkVX-0008FZ-Cx for sip@ietf.org; Tue, 31 Jul 2007 01:42:59 -0400 Received: from mailipao.vtcif.telstra.com.au ([202.12.144.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFkVW-0001RS-G3 for sip@ietf.org; Tue, 31 Jul 2007 01:42:59 -0400 Received: from webi.vtcif.telstra.com.au (HELO mailbi.vtcif.telstra.com.au) ([202.12.142.19]) by mailipai.vtcif.telstra.com.au with ESMTP; 31 Jul 2007 15:42:53 +1000 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id 62AAF1DA96; Tue, 31 Jul 2007 15:42:52 +1000 (EST) Received: from wsmsg2902.srv.dir.telstra.com (wsmsg2902.srv.dir.telstra.com [172.49.40.51]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id F220243424; Tue, 31 Jul 2007 15:42:29 +1000 (EST) Received: from WSMSG2103V.srv.dir.telstra.com ([172.49.40.20]) by wsmsg2902.srv.dir.telstra.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 15:42:22 +1000 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 Jul 2007 15:42:22 +1000 Message-ID: <903E4F74808D4F4B93635C9D9183EBAC02199973@WSMSG2103V.srv.dir.telstra.com> In-Reply-To: <7374777208BDC7449D5620EF942325670743BB0B@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bandwidth parameter in SIP/SDP Thread-Index: Ace82p2yNu6lfaNzQcq8BXk5gCIEoQAHC+iwAAFo/cADO9lZkAAH6/iAAAiwSbACQYkrwA== References: <7374777208BDC7449D5620EF94232567073F7740@esealmw113.eemea.ericsson.se><0c1a01c7ca2d$c7fb9040$7d646b80@amer.cisco.com> <7374777208BDC7449D5620EF942325670743BB0B@esealmw113.eemea.ericsson.se> From: "Robins, Ellen" To: X-OriginalArrivalTime: 31 Jul 2007 05:42:22.0751 (UTC) FILETIME=[91484AF0:01C7D335] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ietf-rtpsec@imc.org Subject: [Sip] Bandwidth parameter in SIP/SDP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dear all, Please help to confirm which bandwidth parameter shall be used by Video Terminal Client for a SIP Client to SIP Client call case, i.e. between 2 parties not a three-way conference. Bandwidth b=3D: o This specifies the proposed bandwidth to be used by the session or media, and is optional. o is in kilobits per second o is a single alphanumeric word giving the meaning of the bandwidth figure. o Two modifiers are initially defined: CT Conference Total: An implicit maximum bandwidth is associated with each TTL on the Mbone or within a particular multicast administrative scope region (the Mbone bandwidth vs. TTL limits are given in the MBone FAQ). If the bandwidth of a session or media in a session is different from the bandwidth implicit from the scope, a `b=3DCT:...' line should be supplied for the session giving the proposed upper limit to the bandwidth used. The primary purpose of this is to give an approximate idea as to whether two or more conferences can co-exist simultaneously. AS Application-Specific Maximum: The bandwidth is interpreted to be application-specific, i.e., will be the application's concept of maximum bandwidth. Normally this will coincide with what is set on the application's "maximum bandwidth" control if applicable. Note that CT gives a total bandwidth figure for all the media at all sites. AS gives a bandwidth figure for a single media at a single site, although there may be many sites sending simultaneously. Thanks and kind regards / Ellen Robins ViG Technology Manager Services Enablers Wireless Engineering & Operations Telstra Operations Telstra Corporation Limited =20 Ph 03 8627 8981 Mob 0428 309 250 Fax 03 9620 7864 Mail ellen.robins@team.telstra.com=20 The information contained in this email message may be confidential. If you are not the intended recipient, any use of, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this message in error, please notify me by reply email and then delete the message. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 03:09:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFlqj-0005Jk-Rm; Tue, 31 Jul 2007 03:08:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFlqh-0005Jc-IA for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 03:08:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFlqd-00057u-Ev for sip@ietf.org; Tue, 31 Jul 2007 03:08:51 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFlqb-0002vv-VA for sip@ietf.org; Tue, 31 Jul 2007 03:08:51 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6V78MX7007954 for ; Tue, 31 Jul 2007 10:08:48 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 10:08:31 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 10:08:31 +0300 Received: from [172.21.40.97] (esdhcp04097.research.nokia.com [172.21.40.97]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6V78UCL014000 for ; Tue, 31 Jul 2007 10:08:30 +0300 Message-ID: <46AEDFED.6000302@nokia.com> Date: Tue, 31 Jul 2007 10:08:29 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2007 07:08:31.0619 (UTC) FILETIME=[9A2AF530:01C7D341] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Sip] subnot-etags: suppressing NOTIFY interactions with SBCs and other middleboxes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi all, This is a potential show-stopper issue that Rohan brought up in the SIP WG session last week. Currently, subnot-etags offers two modes of operation. In the first, the body of the SUBSCRIBE-generated NOTIFY is suppressed, and in the other, the entire NOTIFY is suppressed, and a new response 204 (No Notification) is generated instead. The latter is a considerable change to how SIP events works, and might cause a middlebox that tracks the SIP dialog to basically barf, thinking the dialog expires when it in fact gets refreshed. Do folks think this is a problem? It would be great if some SBC vendors could check what their implementation does with SUBSCRIBE dialogs. Personally, I'd hate to hack around boxes that people claim are doing something fishy. But if this is a real problem, then subnot-etags would basically need to be reduced to just suppressing bodies of NOTIFYs. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 03:53:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFmXZ-0002Qg-9G; Tue, 31 Jul 2007 03:53:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFmXY-0002Qa-B3 for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 03:53:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFmXX-0002QS-W1 for sip@ietf.org; Tue, 31 Jul 2007 03:53:12 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFmXX-0005AZ-4Y for sip@ietf.org; Tue, 31 Jul 2007 03:53:11 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6V7qlj4014878 for ; Tue, 31 Jul 2007 10:53:09 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 10:52:46 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 10:52:47 +0300 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 Subject: [Sip] Some comments for location-conveyance-08 Date: Tue, 31 Jul 2007 10:50:38 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F03EC92AC@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Some comments for location-conveyance-08 Thread-Index: AcfTR3wldwdkBh7rQPONg/MhEgG4SA== From: To: X-OriginalArrivalTime: 31 Jul 2007 07:52:47.0034 (UTC) FILETIME=[C8EB21A0:01C7D347] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I had a review of draft-ietf-sip-location-conveyance-08 and have the following comments to it. I have not followed up the email discussions for this draft so please apologize if any of my comments have already been raised. 1. Possible values within the inserted-by parameter What kind of value should the UAC enter into the "inserted-by" parameter if it does not have a hostname ? Is e.g. the local IP=20 address of the UAC OK ? The BNF syntax refers to "host-id" when describing the contents of the "inserted-by" parameter. However I did not find anywhere any formal BNF definition to the "host-id" (either in this draft or RFC 3261), thus it is not clear if it only refers to a hostname or could it also refer to e.g. an IP address or some other=20 cryptographically constructed random ID allocated by the UAC. 2. Handling of 424 responses In my opinion the handling the 424 responses is not well specified: UAC:=20 The Geolocation-Error has a header parameter indicating which entity inserted the location pertaining to this error. This is in the form of a host-id. A UAC receiving this 424 should review this=20 "inserter=3D" locationErrorValue parameter to see if it indicates = this UAC. If it does not, the 424 should be ignored.=20 First of all the Geolocation-Error header might contain multiple=20 locationErrorValue entries. It is not clear in the normative text for UAC that the UAC is expected to search through all of those to check if it can find any entries targetted to itself. Further on if there is no entries for the UAC, shall the UAC really ignore the 424 and continue retransmitting the request or handle it as 4xx response and stop retransmissions ? What if it was the proxy to insert Geolocation header into the request and the UAS would return 424 response ? There is no=20 normative text for the proxy to take this response into account even if the Geolocation-Error header would refer to the proxy. 3. Usage of geolocation tag in the Supported header Usage of the geolocation tag in the Supported header is not specified according to the guidelines of RFC 3261. There were=20 similar issues raised for SIP Outbound recently and the agreement was to fix them: http://www1.ietf.org/mail-archive/web/sip/current/msg20045.html RFC 3261: If the UAC supports extensions to SIP that can be applied by the server to the response, the UAC SHOULD include a Supported header field in the request listing the option tags (Section 19.2) for those extensions. draft-ietf-sip-location-conveyance-08: Whenever a UA wants to=20 indicate support for this SIP extension, the geolocation option tag=20 is included in a Supported header of the SIP message. =20 The UAC supporting this=20 extension MUST include a Supported header with the geolocation=20 option tag. The geolocation option-tag is inserted in a Supported header by a=20 UAC to provide an indication of support for this extension. The=20 presence of the geolocation option tag in a Supported header without a Geolocation header field in the same message informs a receiving=20 SIP element the UAC understands this extension, but it does not know or wish to convey its location at this time. Certain scenarios=20 exist (location-based retargeting) in which location is required in a SIP request in order to retarget the message properly. This=20 affects how a UAS or SIP server processes to such a request. The semantics of the geolocation tag within the Supported header seems to be vaguely defined. The presence of this tag does not indicate the UAS (or proxy) any extensions that the server could apply to its response. According to RFC 3261 that would however be the reason why to include an option tag into the Supported header of a request. All the use cases given in the draft for the geolocation tag justify its usage within the Require header but there seems to be no clear reason why the UAC would add it into the Supported header of a request. Support for the extension can also be inferred from the presence of Geolocation header. If it is not present but the a proxy would require it for retargeting,=20 the correct behaviour would be the proxy to send 421 Extension Required response. A UAS MAY include a geolocation option-tag in the Supported header=20 of a response, indicating if does understand this extension. Similarily for the UAS no clear reasons exist why to include the=20 Supported header into its response. =20 Nit: 4.1 Location-by-value Geolocation: =20 --boundary1 Content-Type: application/pidf+xml Content-ID: alice123@atlanta.example.com In Geolocation header the Content ID begins with "target123" even if within the MIME entity the ID begins with "alice123". Regards, Erkki Koivusalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 07:37:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFq2C-0006ne-Tb; Tue, 31 Jul 2007 07:37:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFq2A-0006nU-Ow for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 07:37:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFq2A-0006nM-FN for sip@ietf.org; Tue, 31 Jul 2007 07:37:02 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFq29-00048P-8k for sip@ietf.org; Tue, 31 Jul 2007 07:37:02 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 31 Jul 2007 07:37:01 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0KAH67rkZAZnmf/2dsb2JhbACIA50I X-IronPort-AV: i="4.19,203,1183348800"; d="scan'208"; a="127497305:sNHT28038620" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6VBb0n3026274; Tue, 31 Jul 2007 07:37:00 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6VBb0WI005236; Tue, 31 Jul 2007 11:37:00 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 07:37:00 -0400 Received: from [10.82.218.240] ([10.82.218.240]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 07:37:00 -0400 Message-ID: <46AF1EDB.3020102@cisco.com> Date: Tue, 31 Jul 2007 07:36:59 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] subnot-etags: suppressing NOTIFY interactions with SBCs and other middleboxes References: <46AEDFED.6000302@nokia.com> In-Reply-To: <46AEDFED.6000302@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2007 11:37:00.0163 (UTC) FILETIME=[1B9BB530:01C7D367] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1605; t=1185881820; x=1186745820; c=relaxed/simple; s=rtpdkim2001; 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[Sip]=20subnot-etags=3A=20suppressing=20NOTIFY=20inte ractions=20with=20SBCs=0A=20and=20other=20middleboxes |Sender:=20 |To:=20Aki=20Niemi=20; bh=cgxUB+S2yFSfeCZEB5nlhRPTTS7r/UsKQj89Xdf4rII=; b=RIOz+jvg1245XnyGeVcEPBGHI20hzW0GHPGbg00ezMzafIKRkUALhj6a1pDbuPLy9rTTS8SP oFoGIaZKP1Z6htWNM0oCximJ3JDdAc1bTQR6iDmMDGGMH/GYcOE0AXTT; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't think this is a real problem. It is a *change*, no worse than other changes we make from time to time. It won't bother the sorts of middleboxes (proxies) that we have clear standards for. If it bothers B2BUAs then they will need to learn how to deal with it. Paul Aki Niemi wrote: > Hi all, > > This is a potential show-stopper issue that Rohan brought up in the SIP > WG session last week. > > Currently, subnot-etags offers two modes of operation. In the first, the > body of the SUBSCRIBE-generated NOTIFY is suppressed, and in the other, > the entire NOTIFY is suppressed, and a new response 204 (No > Notification) is generated instead. > > The latter is a considerable change to how SIP events works, and might > cause a middlebox that tracks the SIP dialog to basically barf, thinking > the dialog expires when it in fact gets refreshed. > > Do folks think this is a problem? It would be great if some SBC vendors > could check what their implementation does with SUBSCRIBE dialogs. > > Personally, I'd hate to hack around boxes that people claim are doing > something fishy. But if this is a real problem, then subnot-etags would > basically need to be reduced to just suppressing bodies of NOTIFYs. > > Cheers, > Aki > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 09:22:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFrfb-0005Ao-KL; Tue, 31 Jul 2007 09:21:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFrfZ-000596-RU for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 09:21:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFrfZ-00058y-I0 for sip@ietf.org; Tue, 31 Jul 2007 09:21:49 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFrfY-0008Bq-V3 for sip@ietf.org; Tue, 31 Jul 2007 09:21:49 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 31 Jul 2007 06:21:48 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAN7TrkarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.19,204,1183359600"; d="scan'208"; a="508779335:sNHT30728468" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6VDLmYf009488; Tue, 31 Jul 2007 06:21:48 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6VDLmA0018468; Tue, 31 Jul 2007 13:21:48 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); Tue, 31 Jul 2007 06:21:47 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 06:21:47 -0700 Message-ID: <46AF3776.8020501@cisco.com> Date: Tue, 31 Jul 2007 09:21:58 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] subnot-etags: suppressing NOTIFY interactions with SBCs and other middleboxes References: <46AEDFED.6000302@nokia.com> In-Reply-To: <46AEDFED.6000302@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2007 13:21:47.0747 (UTC) FILETIME=[BF4CE330:01C7D375] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1848; t=1185888108; x=1186752108; 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[Sip]=20subnot-etags=3A=20suppressing=20NOTIFY=20inte ractions=20with=20SBCs=0A=20and=20other=20middleboxes |Sender:=20; bh=gYwYIRc8DKEm91dBsKEt2aHzLF+rcmvjfeQ5+QmgWts=; b=aOqeT1NvlmyiZkRVXfAQ9Skdf3T2mYkF+AA03s0COnyXh6bjJToGJnZpFj6HJ+erm12HvPHS UK8t16+My/HhjPCftp1zx9HRS7X10iCi3QaA5i8i6wc0ETBsYW2ipqJ1ywn238qRlSC6gq1va3 ryHn+FmO+ZUxdBERn0kyQjii8=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm worried that, if you eliminate suppression of NOTIFY itself, the primary value of this draft (reduction of message traffic) is lost. I'd like to keep this capability if we can. -Jonathan R. Aki Niemi wrote: > Hi all, > > This is a potential show-stopper issue that Rohan brought up in the SIP > WG session last week. > > Currently, subnot-etags offers two modes of operation. In the first, the > body of the SUBSCRIBE-generated NOTIFY is suppressed, and in the other, > the entire NOTIFY is suppressed, and a new response 204 (No > Notification) is generated instead. > > The latter is a considerable change to how SIP events works, and might > cause a middlebox that tracks the SIP dialog to basically barf, thinking > the dialog expires when it in fact gets refreshed. > > Do folks think this is a problem? It would be great if some SBC vendors > could check what their implementation does with SUBSCRIBE dialogs. > > Personally, I'd hate to hack around boxes that people claim are doing > something fishy. But if this is a real problem, then subnot-etags would > basically need to be reduced to just suppressing bodies of NOTIFYs. > > Cheers, > Aki > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 09:49:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFs6e-0003rQ-Pa; Tue, 31 Jul 2007 09:49:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFs6c-0003qU-R6 for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 09:49:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFs6c-0003q4-G4 for sip@ietf.org; Tue, 31 Jul 2007 09:49:46 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFs6b-0000fo-Pw for sip@ietf.org; Tue, 31 Jul 2007 09:49:46 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6VDnbO11857; Tue, 31 Jul 2007 13:49:37 GMT 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 Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Tue, 31 Jul 2007 08:49:24 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF11747CDA@zrc2hxm0.corp.nortel.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfTLX4HepJFETTURfmz+XkoLdOiIQAS7rYg References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <46AA09F1.6010401@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E21C3@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF11747126@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "James M. Polk" , "Alan Hawrylyshen" , "Kyzivat Paul" , "Mahy Rohan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: IETF SIP List , Jon.Peterson@neustar.com, Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ok, that's fine with me. It's just a glitch in 3261 then. I'd rather we stick with the Warn-Codes approach. Did you assign a purpose for 7XX-series warn-codes yet? I'm wondering what range should be used for this purpose. James, I didn't see your codes on IANA's web site. What values are you using? I don't want to overlap. > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > Sent: Monday, July 30, 2007 21:44 > To: Audet, Francois (SC100:3055); Alan Hawrylyshen; Kyzivat=20 > Paul; Mahy Rohan > Cc: IETF SIP List; Jon.Peterson@neustar.com > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >=20 > At 10:54 AM 7/30/2007, Francois Audet wrote: > >RFC 3261, p. 181: > > > > "The first digit of warning codes beginning with "3"=20 > >indicates warnings > > specific to SIP." > > > >Then it explains within the 3XX space, how they are used. >=20 > btw -- for location-conveyance-07, I created 15 new Warning codes (#s > 701 through 712, then 720, 721, and 722). All this at the=20 > suggestion of Henning (who knows something about 3261 text... ;-) >=20 > btw II - I have since replaced the Warning header indication=20 > with a new Geolocation-Error header, but this was so I could=20 > stuff more into the new header than the Warning header would allow. >=20 > In all this, I did not get one person claiming Warning codes=20 > were limited to 3XX. Henning merely said the "first batch of=20 > codes were in the 300s, and that there was nothing limiting a=20 > new ID from defining new codes in any other number range"... >=20 >=20 > > > -----Original Message----- > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > Sent: Saturday, July 28, 2007 18:25 > > > To: Audet, Francois (SC100:3055); Alan Hawrylyshen; Kyzivat Paul;=20 > > > Mahy Rohan > > > Cc: IETF SIP List; Jon.Peterson@neustar.com > > > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > > > > > A 399 Miscellaneous? That doesn't make sense... > > > > > > Warning codes are not limited to 3XX, so if a new Warning code is=20 > > > what Rohan wants to convey more information in the=20 > response (which I=20 > > > believe should be done one way or another) > > > - it can be almost any value other than 300-379 or 399 IMO. > > > > > > At 10:32 AM 7/27/2007, Francois Audet wrote: > > > >On the Warning header... > > > > > > > >Values 300-379 are reserved for SDP-related stuff. > > > > > > > >Values 380-389 are unassiged (but there is no text on it). > > > > > > > >Values 390-398 are unassigned (but don't fall into the=20 > SDP related=20 > > > >stuff. > > > > > > > >399 means Miscellaneous and the text can be provided to the user. > > > >It further says that Automata MUST NOT take action based on this. > > > > > > > >Rohan, are you advocating using 399, or defining a new code from=20 > > > >the > > > >390-398 space? > > > > > > > > > -----Original Message----- > > > > > From: Alan Hawrylyshen [mailto:a.hawrylyshen@gmail.com] > > > On Behalf Of > > > > > Alan Hawrylyshen > > > > > Sent: Friday, July 27, 2007 08:27 > > > > > To: Kyzivat Paul; Mahy Rohan > > > > > Cc: Audet, Francois (SC100:3055); IETF SIP List;=20 > > > > > Jon.Peterson@neustar.com > > > > > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > > > > > > > > > > > > > > On 27-Jul-2007, at 10:06 , Paul Kyzivat wrote: > > > > > > > > > > > I understand that if the user entered a sips URI then it > > > > > should be the > > > > > > user that must decide to downgrade. But if the user didn't=20 > > > > > > know whether to use sip or sips in the first place,=20 > and the UA > > > > > decides to > > > > > > try sips first then I see no problem in the UA=20 > having a policy=20 > > > > > > that causes it to downgrade. > > > > > > > > > > I was under the impression (based on meeting=20 > discussion) that : > > > > > 1 - the downgrade was undesirable because it reveals > > > > > (possibly) information about the targeted party in the clear,=20 > > > > > and; > > > > > 2 - The 480 with a Warning header was an option to provide > > > > > automata- friendly indication of the failure reason. > > > > > > > > > > Alan Hawrylyshen > > > > > > > > > > a l a n a t p o l y p h a s e d o t c a > > > > > > > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > >This list is for NEW development of the core SIP Protocol Use=20 > > > >sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > >sipping@ietf.org for new developments on the application of sip > > > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 11:12:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFtO7-00010T-Ub; Tue, 31 Jul 2007 11:11:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFtO6-0000wy-W8 for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 11:11:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFtO6-0000wn-Az for sip@ietf.org; Tue, 31 Jul 2007 11:11:54 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFtO5-0004ox-LN for sip@ietf.org; Tue, 31 Jul 2007 11:11:54 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l6VFBmp11403; Tue, 31 Jul 2007 08:11:48 -0700 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1174794F@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF1174794F@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Rohan Mahy Date: Tue, 31 Jul 2007 08:11:47 -0700 To: "Francois Audet" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Cullen Jennings , Rohan Mahy , IETF SIP List , drage@alcatel-lucent.com, Robert Sparks , Jon.Peterson@neustar.com, Dean Willis Subject: [Sip] Re: Warn-Codes and draft-ietf-sip-sips X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Fran=E7ois, I think the IANA paragraph you described is too restrictive. The =20 text in RFC3261 section 20.43 seems perfectly fine with registering =20 non-SDP errors. I would allocate warn-code 380 "No SIPS contacts =20 registered". thanks, -rohan On Jul 30, 2007, at 3:23 PM, Francois Audet wrote: > Now that we have everybody exited about the prospect of using a > Warn-Code > for "SIPS Not Allowed" and "SIP Required" with Response 480, =20 > instead of > using > new response codes, here is a quote from 27.2/RFC 3261. > > Warning codes provide information supplemental to the status =20 > code in > SIP response messages when the failure of the transaction results > from a Session Description Protocol (SDP) (RFC 2327 [1]) problem. > > My reading of this is that Warn-Codes are ONLY usable for SDP errors. > > Doesn't this disqualify the idea of using a Warn-Code for SIP/SIPS URI > problems?????? > > If so, aren't we back to 418/419, or 418+New header (Allow/=20 > Require), or > 480+Response text? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 11:21:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFtXL-0001kP-Mh; Tue, 31 Jul 2007 11:21:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFtXI-0001hL-R6 for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 11:21:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFtXH-0001gk-Sk; Tue, 31 Jul 2007 11:21:23 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFtXG-0003rm-8U; Tue, 31 Jul 2007 11:21:23 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A5EBB548021; Tue, 31 Jul 2007 17:21:21 +0200 (CEST) X-AuditID: c1b4fb3c-afe7ebb0000007e1-a7-46af53713e29 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4277920474; Tue, 31 Jul 2007 17:21:21 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 17:21:20 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 17:21:20 +0200 Message-ID: <46AF5370.9020304@ericsson.com> Date: Tue, 31 Jul 2007 17:21:20 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: tsvwg , NSIS , IETF SIPPING WG , sip@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed X-OriginalArrivalTime: 31 Jul 2007 15:21:20.0301 (UTC) FILETIME=[7279C5D0:01C7D386] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Cc: Subject: [Sip] Draft Liaision response to SG13 on Emergency Telecommunications X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi This is the draft for a liaison response to be sent to SG 13 of the=20 ITU-T from the TSVWG, NSIS, SIP and SIPPING WGs. Please provide any=20 comments at the latest by the 14th of August. After that we will address=20 any raised comments and send the liaison to ITU-T before the end of Augus= t. Submission Date: , 2007 From: IETF Working groups TSVWG, NSIS, SIP and SIPPING To: Georges Sebek , Keith Knightson Cc: Magnus Westerlund , Lars Eggert , James Polk , Martin Stiemerling , John Loughney Dean Willis , Keith Drage , Mary Barnes , Gonzalo Camarillo , Scott Bradner , Kimberly King , Scott Brim Response Contact: TSV WG (tsv-chairs@tools.ietf.org) NSIS (nsis-chairs@tools.ietf.org) SIPPING (sipping-chairs@tools.ietf.org) SIP (sip-chairs@tools.ietf.org) =09 Purpose: Response to Liaison Request Deadline: None Title: Response to liaison request from ITU-T Study Group 13 work on=20 emergency telecommunications This is a response to the liaison request made by Q3/13 regarding=20 emergency telecommunications (REF: NGN-GSI/DOC =E2=80=93 60 Rev.2). We wo= uld=20 first like to apologize for failing to meet the deadline in responding.=20 We do hope that the late answer still can be of some use. The liaison request was made to the following working groups (WG):=20 IEPREP, TSVWG, and NSIS. Since the request was sent the IEPREP WG has=20 concluded. In addition to the WGs from which information was requested,=20 we also think that work performed by the SIP and SIPPING WG may be of=20 relevance. Pursuant to ITU-T Study Group 13 request for information on relevant and=20 related work in the IETF regarding emergency communications, we list=20 below RFCs and works in progress that we feel may be of interest to your=20 group. Some of the completed work is Informational, and others are in=20 the category of Standards Track. Q.3/13 also requested that we keep you informed of any developments in=20 regards to emergency telecommunications. In those regards we would like=20 to make you aware that IETF mailing list participation and document=20 information is free and open for anyone. Allowing participants in Q.3/13=20 to keep them selves informed of any developments. If Q.3/13 desire to=20 get further information about specific ongoing work, then please send a=20 liaison request to the responsible WG for those specific documents. The following list is divided under the associated working groups from=20 which the work has been done within the IETF. SIP Working Group RFC 4411 Title: Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events Abstract: This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to be included in a BYE Method Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS). This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred. RFC 4412 Title: Communications Resource Priority for the Session Initiation Protocol (SIP) Abstract: This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely, "Resource-Priority" and "Accept-Resource-Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior of IP routers. SIPPING Working Group The below two documents are proposed work items not yet accepted as IETF WG items but are likely of interest as they update RFC 4412. Work In Progress: draft-polk-sip-rph-in-responses-00 Title: Allowing SIP Resource Priority Header in SIP Responses Abstract: The Session Initiation Protocol (SIP) Resource Priority Header (RPH), in its current form, is ignored in SIP responses. This was a design choice during RFC 4412's development. This is now considered a bad design choice in certain scenarios. This document corrects RFC 4412's communications model by optionally allowing a SIP server or user agent client to process the Resource-Priority Header in a response. Work In Progress: draft-polk-sip-rph-new-namespaces--00 Title: New Session Initiation Protocol Resource-Priority Header Namespaces for the Defense Information Systems Agency Abstract: This document creates additional Session Initiation Protocol Resource-Priority header namespaces, to be IANA registered. This document intends to update RFC 4412, as a Proposed Standard document if published by the RFC-Editor. IEPREP Working Group RFC 3487 Title: Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP) Abstract: This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). RFC 3689 Title: General Requirements for Emergency Telecommunication Service (ETS) Abstract: This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). RFC 3690 Title: IP Telephony Requirements for Emergency Telecommunication Service (ETS) Abstract: This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in RFC 3689. Solutions to these requirements are not presented in this document. RFC 4190 Title: Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony Abstract: This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space. RFC 4375 Title: Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain Abstract: This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single administrative domain. This document focuses on a specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document. TSV Working Group RFC 4542 Title: Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite Abstract: RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis. This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations. Work In Progress: draft-ietf-tsvwg-emergency-rsvp-03.txt Title: Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services Abstract: An Emergency Telecommunications Service (ETS) requires the ability to provide an elevated probability of session establishment to an authorized user in times of network congestion (typically, during a crisis). When supported over the Internet Protocol suite, this may be facilitated through a network layer admission control solution, which supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for emergency services, or they may be shared with other sessions. This document specifies RSVP extensions that can be used to support such an admission priority capability at the network layer. Note that these extensions represent one possible solution component in satisfying ETS requirements. Other solution components, or other solutions, are outside the scope of this document. NSIS Working Group Work In Progress: draft-ietf-nsis-qos-nslp-14.txt Title: NSLP for Quality-of-Service Signaling Abstract: This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling QoS reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with GIST, it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This specification explains the overall protocol approach, design decisions made and provides examples. It specifies object, message formats and processing rules. --=20 Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 11:34:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFtk3-0005ZG-WF; Tue, 31 Jul 2007 11:34:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFtk1-0005S6-99 for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 11:34:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFtk0-0005Rk-HX; Tue, 31 Jul 2007 11:34:32 -0400 Received: from mail171.messagelabs.com ([216.82.253.243]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IFtjx-00062P-RG; Tue, 31 Jul 2007 11:34:32 -0400 X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-12.tower-171.messagelabs.com!1185896061!8098786!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [20.137.52.151] Received: (qmail 14991 invoked from network); 31 Jul 2007 15:34:22 -0000 Received: from amer-mta07.csc.com (HELO amer-mta07.csc.com) (20.137.52.151) by server-12.tower-171.messagelabs.com with AES256-SHA encrypted SMTP; 31 Jul 2007 15:34:22 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id l6VFYaYJ009979; Tue, 31 Jul 2007 11:34:37 -0400 (EDT) In-Reply-To: <46AF5370.9020304@ericsson.com> To: Magnus Westerlund MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Tue, 31 Jul 2007 11:34:17 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1 HF180|March 29, 2007) at 07/31/2007 11:32:58 AM, Serialize complete at 07/31/2007 11:32:58 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: ee8eaa76ea6a4fb3ccc9059a3f656ffc Cc: sip@ietf.org, IETF SIPPING WG , tsvwg , NSIS Subject: [Sip] Re: [Tsvwg] Draft Liaision response to SG13 on Emergency Telecommunications X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0715605749==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0715605749== Content-Type: multipart/alternative; boundary="=_alternative 0055890785257329_=" This is a multipart message in MIME format. --=_alternative 0055890785257329_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 TWFnbnVzLA0KDQpZb3UgbWlnaHQgd2FudCB0byBhZGQtDQoNCmRyYWZ0LXBvbGstdHN2d2ctc2ln bmFsZWQtZG9tYWluLWlkLTAwLnR4dA0KYW5kIA0KZHJhZnQtcG9say1lY3JpdC1sb2NhbC1lbWVy Z2VuY3ktcnBoLW5hbWVzcGFjZS0wMS50eHQNCg0KKEJvdGggd2VyZSBvbiB0aGUgYWdlbmRhIGFu ZCBkaXNjdXNzZWQuKQ0KDQpBbmQgbWF5YmUNCmRyYWZ0LWNhcmxiZXJnLXRyaXAtYXR0cmlidXRl LXJwLTAyIA0KDQoodGhvdWdoIEkgZGlkIG5vdCBzZWUgaXQgb24gdGhlIGFnZW5kYSkNCg0KSmFu ZXQNCg0KUFMsDQoNCk15IHNwZWxsaW5nIGNoZWNrZXIgc2F5cyAiTGlhaXNpb24iIHNob3VsZCBi ZSAiTGlhaXNvbiIsIGJ1dCBpdCBtYXkgYmUgYSANClVTIGNlbnRyaWMgZGljdGlvbmFyeS4NCkoN Ck1hZ251cyBXZXN0ZXJsdW5kIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+IHdyb3Rl IG9uIDA3LzMxLzIwMDcgDQoxMToyMToyMCBBTToNCg0KPiBIaQ0KPiANCj4gVGhpcyBpcyB0aGUg ZHJhZnQgZm9yIGEgbGlhaXNvbiByZXNwb25zZSB0byBiZSBzZW50IHRvIFNHIDEzIG9mIHRoZSAN Cj4gSVRVLVQgZnJvbSB0aGUgVFNWV0csIE5TSVMsIFNJUCBhbmQgU0lQUElORyBXR3MuIFBsZWFz ZSBwcm92aWRlIGFueSANCj4gY29tbWVudHMgYXQgdGhlIGxhdGVzdCBieSB0aGUgMTR0aCBvZiBB dWd1c3QuIEFmdGVyIHRoYXQgd2Ugd2lsbCBhZGRyZXNzIA0KDQo+IGFueSByYWlzZWQgY29tbWVu dHMgYW5kIHNlbmQgdGhlIGxpYWlzb24gdG8gSVRVLVQgYmVmb3JlIHRoZSBlbmQgb2YgDQpBdWd1 c3QuDQo+IA0KPiBTdWJtaXNzaW9uDQo+IERhdGU6ICAgICAgPHRiZD4sIDIwMDcNCj4gDQo+IEZy b206ICAgICAgIElFVEYgV29ya2luZyBncm91cHMgVFNWV0csIE5TSVMsIFNJUCBhbmQgU0lQUElO Rw0KPiANCj4gVG86ICAgICAgR2VvcmdlcyBTZWJlayAgPHRzYnNnMTNAaXR1LmludD4gLA0KPiAg ICAgICBLZWl0aCBLbmlnaHRzb24gPGtna0BpZ3MubmV0Pg0KPiANCj4gQ2M6ICAgICAgTWFnbnVz IFdlc3Rlcmx1bmQgPG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4sDQo+ICAgICAgICAg ICAgICAgICAgTGFycyBFZ2dlcnQgPGxhcnMuZWdnZXJ0QG5va2lhLmNvbT4sDQo+ICAgICAgICAg ICAgICAgICAgSmFtZXMgUG9sayA8am1wb2xrQGNpc2NvLmNvbT4sDQo+ICAgICAgICAgICAgICAg ICAgTWFydGluIFN0aWVtZXJsaW5nIDxzdGllbWVybGluZ0BuZXRsYWIubmVjLmRlPiwNCj4gICAg ICAgICAgICAgICAgICBKb2huIExvdWdobmV5IDxqb2huLmxvdWdobmV5QG5va2lhLmNvbT4NCj4g ICAgICAgICAgICAgICAgICBEZWFuIFdpbGxpcyA8ZGVhbi53aWxsaXNAc29mdGFybW9yLmNvbT4s DQo+ICAgICAgICAgICAgICAgICAgS2VpdGggRHJhZ2UgPGRyYWdlQGFsY2F0ZWwtbHVjZW50LmNv bT4sDQo+ICAgICAgICAgICAgICAgICAgTWFyeSBCYXJuZXMgPG1hcnkuYmFybmVzQG5vcnRlbC5j b20+LA0KPiAgICAgICAgICAgICAgICAgIEdvbnphbG8gQ2FtYXJpbGxvIDxnb256YWxvLmNhbWFy aWxsb0Blcmljc3Nvbi5jb20+LA0KPiAgICAgICAgICAgICAgICAgIFNjb3R0IEJyYWRuZXIgPHNv YkBoYXJ2YXJkLmVkdT4sDQo+ICAgICAgICAgICAgICAgICAgS2ltYmVybHkgS2luZyA8a3NraW5n QG1pdHJlLm9yZz4sDQo+ICAgICAgICAgICAgICAgICAgU2NvdHQgQnJpbSA8c3diQGVtcGxveWVl cy5vcmc+DQo+IA0KPiBSZXNwb25zZQ0KPiBDb250YWN0OiAgIFRTViBXRyAodHN2LWNoYWlyc0B0 b29scy5pZXRmLm9yZykNCj4gICAgICAgTlNJUyAobnNpcy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcp DQo+ICAgICAgIFNJUFBJTkcgKHNpcHBpbmctY2hhaXJzQHRvb2xzLmlldGYub3JnKQ0KPiAgICAg ICBTSVAgKHNpcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcpDQo+IA0KPiBQdXJwb3NlOiAgICBSZXNw b25zZSB0byBMaWFpc29uIFJlcXVlc3QNCj4gDQo+IERlYWRsaW5lOiAgIE5vbmUNCj4gDQo+IFRp dGxlOiBSZXNwb25zZSB0byBsaWFpc29uIHJlcXVlc3QgZnJvbSBJVFUtVCBTdHVkeSBHcm91cCAx MyB3b3JrIG9uIA0KPiBlbWVyZ2VuY3kgdGVsZWNvbW11bmljYXRpb25zDQo+IA0KPiBUaGlzIGlz IGEgcmVzcG9uc2UgdG8gdGhlIGxpYWlzb24gcmVxdWVzdCBtYWRlIGJ5IFEzLzEzIHJlZ2FyZGlu ZyANCj4gZW1lcmdlbmN5IHRlbGVjb21tdW5pY2F0aW9ucyAoUkVGOiBOR04tR1NJL0RPQyDigJMg NjAgUmV2LjIpLiBXZSB3b3VsZCANCj4gZmlyc3QgbGlrZSB0byBhcG9sb2dpemUgZm9yIGZhaWxp bmcgdG8gbWVldCB0aGUgZGVhZGxpbmUgaW4gcmVzcG9uZGluZy4gDQo+IFdlIGRvIGhvcGUgdGhh dCB0aGUgbGF0ZSBhbnN3ZXIgc3RpbGwgY2FuIGJlIG9mIHNvbWUgdXNlLg0KPiANCj4gVGhlIGxp YWlzb24gcmVxdWVzdCB3YXMgbWFkZSB0byB0aGUgZm9sbG93aW5nIHdvcmtpbmcgZ3JvdXBzIChX Ryk6IA0KPiBJRVBSRVAsIFRTVldHLCBhbmQgTlNJUy4gU2luY2UgdGhlIHJlcXVlc3Qgd2FzIHNl bnQgdGhlIElFUFJFUCBXRyBoYXMgDQo+IGNvbmNsdWRlZC4gSW4gYWRkaXRpb24gdG8gdGhlIFdH cyBmcm9tIHdoaWNoIGluZm9ybWF0aW9uIHdhcyByZXF1ZXN0ZWQsIA0KPiB3ZSBhbHNvIHRoaW5r IHRoYXQgd29yayBwZXJmb3JtZWQgYnkgdGhlIFNJUCBhbmQgU0lQUElORyBXRyBtYXkgYmUgb2Yg DQo+IHJlbGV2YW5jZS4NCj4gDQo+IFB1cnN1YW50IHRvIElUVS1UIFN0dWR5IEdyb3VwIDEzIHJl cXVlc3QgZm9yIGluZm9ybWF0aW9uIG9uIHJlbGV2YW50IGFuZCANCg0KPiByZWxhdGVkIHdvcmsg aW4gdGhlIElFVEYgcmVnYXJkaW5nIGVtZXJnZW5jeSBjb21tdW5pY2F0aW9ucywgd2UgbGlzdCAN Cj4gYmVsb3cgUkZDcyBhbmQgd29ya3MgaW4gcHJvZ3Jlc3MgdGhhdCB3ZSBmZWVsIG1heSBiZSBv ZiBpbnRlcmVzdCB0byB5b3VyIA0KDQo+IGdyb3VwLiAgU29tZSBvZiB0aGUgY29tcGxldGVkIHdv cmsgaXMgSW5mb3JtYXRpb25hbCwgYW5kIG90aGVycyBhcmUgaW4gDQo+IHRoZSBjYXRlZ29yeSBv ZiBTdGFuZGFyZHMgVHJhY2suDQo+IA0KPiBRLjMvMTMgYWxzbyByZXF1ZXN0ZWQgdGhhdCB3ZSBr ZWVwIHlvdSBpbmZvcm1lZCBvZiBhbnkgZGV2ZWxvcG1lbnRzIGluIA0KPiByZWdhcmRzIHRvIGVt ZXJnZW5jeSB0ZWxlY29tbXVuaWNhdGlvbnMuIEluIHRob3NlIHJlZ2FyZHMgd2Ugd291bGQgbGlr ZSANCj4gdG8gbWFrZSB5b3UgYXdhcmUgdGhhdCBJRVRGIG1haWxpbmcgbGlzdCBwYXJ0aWNpcGF0 aW9uIGFuZCBkb2N1bWVudCANCj4gaW5mb3JtYXRpb24gaXMgZnJlZSBhbmQgb3BlbiBmb3IgYW55 b25lLiBBbGxvd2luZyBwYXJ0aWNpcGFudHMgaW4gUS4zLzEzIA0KDQo+IHRvIGtlZXAgdGhlbSBz ZWx2ZXMgaW5mb3JtZWQgb2YgYW55IGRldmVsb3BtZW50cy4gSWYgUS4zLzEzIGRlc2lyZSB0byAN Cj4gZ2V0IGZ1cnRoZXIgaW5mb3JtYXRpb24gYWJvdXQgc3BlY2lmaWMgb25nb2luZyB3b3JrLCB0 aGVuIHBsZWFzZSBzZW5kIGEgDQo+IGxpYWlzb24gcmVxdWVzdCB0byB0aGUgcmVzcG9uc2libGUg V0cgZm9yIHRob3NlIHNwZWNpZmljIGRvY3VtZW50cy4NCj4gDQo+IFRoZSBmb2xsb3dpbmcgbGlz dCBpcyBkaXZpZGVkIHVuZGVyIHRoZSBhc3NvY2lhdGVkIHdvcmtpbmcgZ3JvdXBzIGZyb20gDQo+ IHdoaWNoIHRoZSB3b3JrIGhhcyBiZWVuIGRvbmUgd2l0aGluIHRoZSBJRVRGLg0KPiANCj4gDQo+ IFNJUCBXb3JraW5nIEdyb3VwDQo+IA0KPiBSRkMgNDQxMQ0KPiANCj4gVGl0bGU6DQo+ICAgICBF eHRlbmRpbmcgdGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKQ0KPiAgICAgUmVh c29uIEhlYWRlciBmb3IgUHJlZW1wdGlvbiBFdmVudHMNCj4gDQo+IEFic3RyYWN0Og0KPiAgICBU aGlzIGRvY3VtZW50IHByb3Bvc2VzIGFuIElBTkEgUmVnaXN0cmF0aW9uIGV4dGVuc2lvbiB0byB0 aGUgU2Vzc2lvbg0KPiAgICAgSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBSZWFzb24gSGVhZGVy IHRvIGJlIGluY2x1ZGVkIGluIGEgQllFDQo+ICAgICBNZXRob2QgUmVxdWVzdCBhcyBhIHJlc3Vs dCBvZiBhIHNlc3Npb24gcHJlZW1wdGlvbiBldmVudCwgZWl0aGVyIGF0IA0KYQ0KPiAgICAgdXNl ciBhZ2VudCAoVUEpLCBvciBzb21ld2hlcmUgaW4gdGhlIG5ldHdvcmsgaW52b2x2aW5nIGENCj4g ICAgIHJlc2VydmF0aW9uLWJhc2VkIHByb3RvY29sIHN1Y2ggYXMgdGhlIFJlc291cmNlIFJlU2Vy VmF0aW9uIFByb3RvY29sDQo+ICAgICAoUlNWUCkgb3IgTmV4dCBTdGVwcyBpbiBTaWduYWxpbmcg KE5TSVMpLiAgVGhpcyBkb2N1bWVudCBkb2VzIG5vdA0KPiAgICAgYXR0ZW1wdCB0byBhZGRyZXNz IHJvdXRlcnMgZmFpbGluZyBpbiB0aGUgcGFja2V0IHBhdGg7IGluc3RlYWQsIGl0DQo+ICAgICBh ZGRyZXNzZXMgYSBkZWxpYmVyYXRlIHRlYXIgZG93biBvZiBhIGZsb3cgYmV0d2VlbiBVQXMsIGFu ZCBpbmZvcm1zDQo+ICAgICB0aGUgdGVybWluYXRlZCBVQShzKSB3aXRoIGFuIGluZGljYXRpb24g b2Ygd2hhdCBvY2N1cnJlZC4NCj4gDQo+IFJGQyA0NDEyDQo+IA0KPiBUaXRsZToNCj4gICAgIENv bW11bmljYXRpb25zIFJlc291cmNlIFByaW9yaXR5IGZvciB0aGUgU2Vzc2lvbiBJbml0aWF0aW9u DQo+ICAgICBQcm90b2NvbCAoU0lQKQ0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgICBUaGlzIGRvY3Vt ZW50IGRlZmluZXMgdHdvIG5ldyBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkNCj4g ICAgIGhlYWRlciBmaWVsZHMgZm9yIGNvbW11bmljYXRpbmcgcmVzb3VyY2UgcHJpb3JpdHksIG5h bWVseSwNCj4gICAgICJSZXNvdXJjZS1Qcmlvcml0eSIgYW5kICJBY2NlcHQtUmVzb3VyY2UtUHJp b3JpdHkiLiAgVGhlDQo+ICAgICAiUmVzb3VyY2UtUHJpb3JpdHkiIGhlYWRlciBmaWVsZCBjYW4g aW5mbHVlbmNlIHRoZSBiZWhhdmlvciBvZiBTSVANCj4gICAgIHVzZXIgYWdlbnRzIChzdWNoIGFz IHRlbGVwaG9uZSBnYXRld2F5cyBhbmQgSVAgdGVsZXBob25lcykgYW5kIFNJUA0KPiAgICAgcHJv eGllcy4gIEl0IGRvZXMgbm90IGRpcmVjdGx5IGluZmx1ZW5jZSB0aGUgZm9yd2FyZGluZyBiZWhh dmlvciBvZg0KPiAgICAgSVAgcm91dGVycy4NCj4gDQo+IA0KPiANCj4gU0lQUElORyBXb3JraW5n IEdyb3VwDQo+IA0KPiAgICAgVGhlIGJlbG93IHR3byBkb2N1bWVudHMgYXJlIHByb3Bvc2VkIHdv cmsgaXRlbXMgbm90IHlldCBhY2NlcHRlZCBhcw0KPiAgICAgSUVURiBXRyBpdGVtcyBidXQgYXJl IGxpa2VseSBvZiBpbnRlcmVzdCBhcyB0aGV5IHVwZGF0ZSBSRkMgNDQxMi4NCj4gDQo+IFdvcmsg SW4gUHJvZ3Jlc3M6ICAgZHJhZnQtcG9say1zaXAtcnBoLWluLXJlc3BvbnNlcy0wMA0KPiANCj4g VGl0bGU6DQo+ICAgICBBbGxvd2luZyBTSVAgUmVzb3VyY2UgUHJpb3JpdHkgSGVhZGVyIGluIFNJ UCBSZXNwb25zZXMNCj4gDQo+IEFic3RyYWN0Og0KPiAgICAgVGhlIFNlc3Npb24gSW5pdGlhdGlv biBQcm90b2NvbCAoU0lQKSBSZXNvdXJjZSBQcmlvcml0eSBIZWFkZXINCj4gICAgIChSUEgpLCBp biBpdHMgY3VycmVudCBmb3JtLCBpcyBpZ25vcmVkIGluIFNJUCByZXNwb25zZXMuICBUaGlzIHdh cyBhDQo+ICAgICBkZXNpZ24gY2hvaWNlIGR1cmluZyBSRkMgNDQxMidzIGRldmVsb3BtZW50LiBU aGlzIGlzIG5vdyBjb25zaWRlcmVkDQo+ICAgICBhIGJhZCBkZXNpZ24gY2hvaWNlIGluIGNlcnRh aW4gc2NlbmFyaW9zLiAgVGhpcyBkb2N1bWVudCBjb3JyZWN0cw0KPiAgICAgUkZDIDQ0MTIncyBj b21tdW5pY2F0aW9ucyBtb2RlbCBieSBvcHRpb25hbGx5IGFsbG93aW5nIGEgU0lQIHNlcnZlcg0K PiAgICAgb3IgdXNlciBhZ2VudCBjbGllbnQgdG8gcHJvY2VzcyB0aGUgUmVzb3VyY2UtUHJpb3Jp dHkgSGVhZGVyIGluIGENCj4gICAgIHJlc3BvbnNlLg0KPiANCj4gV29yayBJbiBQcm9ncmVzczog ICBkcmFmdC1wb2xrLXNpcC1ycGgtbmV3LW5hbWVzcGFjZXMtLTAwDQo+IA0KPiBUaXRsZToNCj4g ICAgIE5ldyBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgUmVzb3VyY2UtUHJpb3JpdHkgSGVh ZGVyIE5hbWVzcGFjZXMNCj4gICAgIGZvciB0aGUgRGVmZW5zZSBJbmZvcm1hdGlvbiBTeXN0ZW1z IEFnZW5jeQ0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgICBUaGlzIGRvY3VtZW50IGNyZWF0ZXMgYWRk aXRpb25hbCBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wNCj4gICAgIFJlc291cmNlLVByaW9y aXR5IGhlYWRlciBuYW1lc3BhY2VzLCB0byBiZSBJQU5BIHJlZ2lzdGVyZWQuICBUaGlzDQo+ICAg ICBkb2N1bWVudCBpbnRlbmRzIHRvIHVwZGF0ZSBSRkMgNDQxMiwgYXMgYSBQcm9wb3NlZCBTdGFu ZGFyZCBkb2N1bWVudA0KPiAgICAgaWYgcHVibGlzaGVkIGJ5IHRoZSBSRkMtRWRpdG9yLg0KPiAN Cj4gSUVQUkVQIFdvcmtpbmcgR3JvdXANCj4gDQo+IFJGQyAzNDg3DQo+IA0KPiBUaXRsZToNCj4g ICAgIFJlcXVpcmVtZW50cyBmb3IgUmVzb3VyY2UgUHJpb3JpdHkgTWVjaGFuaXNtcyBmb3IgdGhl DQo+ICAgICBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkNCj4gDQo+IEFic3RyYWN0 Og0KPiAgICAgVGhpcyBkb2N1bWVudCBzdW1tYXJpemVzIHJlcXVpcmVtZW50cyBmb3IgcHJpb3Jp dGl6aW5nIGFjY2VzcyB0bw0KPiAgICAgY2lyY3VpdC1zd2l0Y2hlZCBuZXR3b3JrLCBlbmQgc3lz dGVtIGFuZCBwcm94eSByZXNvdXJjZXMgZm9yDQo+ICAgICBlbWVyZ2VuY3kgcHJlcGFyZWRuZXNz IGNvbW11bmljYXRpb25zIHVzaW5nIHRoZSBTZXNzaW9uIEluaXRpYXRpb24NCj4gICAgIFByb3Rv Y29sIChTSVApLg0KPiANCj4gUkZDIDM2ODkNCj4gDQo+IFRpdGxlOg0KPiAgICAgR2VuZXJhbCBS ZXF1aXJlbWVudHMgZm9yDQo+ICAgICBFbWVyZ2VuY3kgVGVsZWNvbW11bmljYXRpb24gU2Vydmlj ZSAoRVRTKQ0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgICBUaGlzIGRvY3VtZW50IHByZXNlbnRzIGEg bGlzdCBvZiBnZW5lcmFsIHJlcXVpcmVtZW50cyBpbiBzdXBwb3J0IG9mDQo+ICAgICBFbWVyZ2Vu Y3kgVGVsZWNvbW11bmljYXRpb25zIFNlcnZpY2UgKEVUUykuICBTb2x1dGlvbnMgdG8gdGhlc2UN Cj4gICAgIHJlcXVpcmVtZW50cyBhcmUgbm90IHByZXNlbnRlZCBpbiB0aGlzIGRvY3VtZW50LiAg QWRkaXRpb25hbA0KPiAgICAgcmVxdWlyZW1lbnRzIHBlcnRhaW5pbmcgdG8gc3BlY2lmaWMgYXBw bGljYXRpb25zLCBvciB0eXBlcyBvZg0KPiAgICAgYXBwbGljYXRpb25zLCBhcmUgdG8gYmUgc3Bl Y2lmaWVkIGluIHNlcGFyYXRlIGRvY3VtZW50KHMpLg0KPiANCj4gUkZDIDM2OTANCj4gDQo+IFRp dGxlOg0KPiAgICAgSVAgVGVsZXBob255IFJlcXVpcmVtZW50cyBmb3INCj4gICAgIEVtZXJnZW5j eSBUZWxlY29tbXVuaWNhdGlvbiBTZXJ2aWNlIChFVFMpDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAg IFRoaXMgZG9jdW1lbnQgcHJlc2VudHMgYSBsaXN0IG9mIHJlcXVpcmVtZW50cyBpbiBzdXBwb3J0 IG9mIA0KRW1lcmdlbmN5DQo+ICAgICBUZWxlY29tbXVuaWNhdGlvbnMgU2VydmljZSAoRVRTKSB3 aXRoaW4gdGhlIGNvbnRleHQgb2YgSVAgdGVsZXBob255Lg0KPiAgICAgSXQgaXMgYW4gZXh0ZW5z aW9uIHRvIHRoZSBnZW5lcmFsIHJlcXVpcmVtZW50cyBwcmVzZW50ZWQgaW4gUkZDIA0KMzY4OS4N Cj4gICAgIFNvbHV0aW9ucyB0byB0aGVzZSByZXF1aXJlbWVudHMgYXJlIG5vdCBwcmVzZW50ZWQg aW4gdGhpcyBkb2N1bWVudC4NCj4gDQo+IFJGQyA0MTkwDQo+IA0KPiBUaXRsZToNCj4gICAgIEZy YW1ld29yayBmb3IgU3VwcG9ydGluZyBFbWVyZ2VuY3kgVGVsZWNvbW11bmljYXRpb25zDQo+ICAg ICBTZXJ2aWNlIChFVFMpIGluIElQIFRlbGVwaG9ueQ0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgICBU aGlzIGRvY3VtZW50IHByZXNlbnRzIGEgZnJhbWV3b3JrIGZvciBzdXBwb3J0aW5nIGF1dGhvcml6 ZWQsDQo+ICAgICBlbWVyZ2VuY3ktcmVsYXRlZCBjb21tdW5pY2F0aW9uIHdpdGhpbiB0aGUgY29u dGV4dCBvZiBJUCB0ZWxlcGhvbnkuDQo+ICAgICBXZSBwcmVzZW50IGEgc2VyaWVzIG9mIG9iamVj dGl2ZXMgdGhhdCByZWZsZWN0IGEgZ2VuZXJhbCB2aWV3IG9mIGhvdw0KPiAgICAgYXV0aG9yaXpl ZCBlbWVyZ2VuY3kgc2VydmljZSwgaW4gbGluZSB3aXRoIHRoZSBFbWVyZ2VuY3kNCj4gICAgIFRl bGVjb21tdW5pY2F0aW9ucyBTZXJ2aWNlIChFVFMpLCBzaG91bGQgYmUgcmVhbGl6ZWQgd2l0aGlu IHRvZGF5J3MNCj4gICAgIElQIGFyY2hpdGVjdHVyZSBhbmQgc2VydmljZSBtb2RlbHMuICBGcm9t IHRoZXNlIG9iamVjdGl2ZXMsIHdlDQo+ICAgICBwcmVzZW50IGEgY29ycmVzcG9uZGluZyBzZXQg b2YgcHJvdG9jb2xzIGFuZCBjYXBhYmlsaXRpZXMsIHdoaWNoDQo+ICAgICBwcm92aWRlIGEgbW9y ZSBzcGVjaWZpYyBzZXQgb2YgcmVjb21tZW5kYXRpb25zIHJlZ2FyZGluZyBleGlzdGluZw0KPiAg ICAgSUVURiBwcm90b2NvbHMuICBGaW5hbGx5LCB3ZSBwcmVzZW50IHR3byBzY2VuYXJpb3MgdGhh dCBhY3QgYXMNCj4gICAgIGd1aWRpbmcgbW9kZWxzIGZvciB0aGUgb2JqZWN0aXZlcyBhbmQgZnVu Y3Rpb25zIGxpc3RlZCBpbiB0aGlzDQo+ICAgICBkb2N1bWVudC4gIFRoZXNlIG1vZGVscywgY291 cGxlZCB3aXRoIGFuIGV4YW1wbGUgb2YgYW4gZXhpc3RpbmcNCj4gICAgIHNlcnZpY2UgaW4gdGhl IFB1YmxpYyBTd2l0Y2hlZCBUZWxlcGhvbmUgTmV0d29yayAoUFNUTiksIGNvbnRyaWJ1dGUNCj4g ICAgIHRvIGEgY29uc3RyYWluZWQgc29sdXRpb24gc3BhY2UuDQo+IA0KPiBSRkMgNDM3NQ0KPiAN Cj4gVGl0bGU6DQo+ICAgICBFbWVyZ2VuY3kgVGVsZWNvbW11bmljYXRpb25zIFNlcnZpY2VzIChF VFMpIFJlcXVpcmVtZW50cw0KPiAgICAgZm9yIGEgU2luZ2xlIEFkbWluaXN0cmF0aXZlIERvbWFp bg0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgICBUaGlzIGRvY3VtZW50IHByZXNlbnRzIGEgbGlzdCBv ZiByZXF1aXJlbWVudHMgaW4gc3VwcG9ydCBvZiANCkVtZXJnZW5jeQ0KPiAgICAgVGVsZWNvbW11 bmljYXRpb25zIFNlcnZpY2UgKEVUUykgd2l0aGluIGEgc2luZ2xlIGFkbWluaXN0cmF0aXZlDQo+ ICAgICBkb21haW4uICBUaGlzIGRvY3VtZW50IGZvY3VzZXMgb24gYSBzcGVjaWZpYyBzZXQgb2Yg YWRtaW5pc3RyYXRpdmUNCj4gICAgIGNvbnN0cmFpbnRzIGFuZCBzY29wZS4gIFNvbHV0aW9ucyB0 byB0aGVzZSByZXF1aXJlbWVudHMgYXJlIG5vdA0KPiAgICAgcHJlc2VudGVkIGluIHRoaXMgZG9j dW1lbnQuDQo+IA0KPiANCj4gVFNWIFdvcmtpbmcgR3JvdXANCj4gDQo+IFJGQyA0NTQyDQo+IA0K PiBUaXRsZToNCj4gICAgIEltcGxlbWVudGluZyBhbiBFbWVyZ2VuY3kgVGVsZWNvbW11bmljYXRp b25zIFNlcnZpY2UgKEVUUykNCj4gICAgIGZvciBSZWFsLVRpbWUgU2VydmljZXMgaW4gdGhlIElu dGVybmV0IFByb3RvY29sIFN1aXRlDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgIFJGQ3MgMzY4OSBh bmQgMzY5MCBkZXRhaWwgcmVxdWlyZW1lbnRzIGZvciBhbiBFbWVyZ2VuY3kNCj4gICAgIFRlbGVj b21tdW5pY2F0aW9ucyBTZXJ2aWNlIChFVFMpLCBvZiB3aGljaCBhbiBJbnRlcm5ldCBFbWVyZ2Vu Y3kNCj4gICAgIFByZXBhcmVkbmVzcyBTZXJ2aWNlIChJRVBTKSB3b3VsZCBiZSBhIHBhcnQuICBT b21lIG9mIHRoZXNlIHR5cGVzIG9mDQo+ICAgICBzZXJ2aWNlcyByZXF1aXJlIGNhbGwgcHJlZW1w dGlvbjsgb3RoZXJzIHJlcXVpcmUgY2FsbCBxdWV1aW5nIG9yDQo+ICAgICBvdGhlciBtZWNoYW5p c21zLiAgSUVQUyByZXF1aXJlcyBhIENhbGwgQWRtaXNzaW9uIENvbnRyb2wgKENBQykNCj4gICAg IHByb2NlZHVyZSBhbmQgYSBQZXIgSG9wIEJlaGF2aW9yIChQSEIpIGZvciB0aGUgZGF0YSB0aGF0 IG1lZXQgdGhlDQo+ICAgICBuZWVkcyBvZiB0aGlzIGFyY2hpdGVjdHVyZS4gIFN1Y2ggYSBDQUMg cHJvY2VkdXJlIGFuZCBQSEIgaXMNCj4gICAgIGFwcHJvcHJpYXRlIHRvIGFueSBzZXJ2aWNlIHRo YXQgbWlnaHQgdXNlIEguMzIzIG9yIFNJUCB0byBzZXQgdXANCj4gICAgIHJlYWwtdGltZSBzZXNz aW9ucy4gIFRoZSBrZXkgcmVxdWlyZW1lbnQgaXMgdG8gZ3VhcmFudGVlIGFuIGVsZXZhdGVkDQo+ ICAgICBwcm9iYWJpbGl0eSBvZiBjYWxsIGNvbXBsZXRpb24gdG8gYW4gYXV0aG9yaXplZCB1c2Vy IGluIHRpbWUgb2YNCj4gICAgIGNyaXNpcy4NCj4gDQo+ICAgICBUaGlzIGRvY3VtZW50IHByaW1h cmlseSBkaXNjdXNzZXMgc3VwcG9ydGluZyBFVFMgaW4gdGhlIGNvbnRleHQgb2YNCj4gICAgIHRo ZSBVUyBHb3Zlcm5tZW50IGFuZCBOQVRPLCBiZWNhdXNlIGl0IGZvY3VzZXMgb24gdGhlIE11bHRp LUxldmVsDQo+ICAgICBQcmVjZWRlbmNlIGFuZCBQcmVlbXB0aW9uIChNTFBQKSBhbmQgR292ZXJu bWVudCBFbWVyZ2VuY3kNCj4gICAgIFRlbGVjb21tdW5pY2F0aW9uIFNlcnZpY2UgKEdFVFMpIHN0 YW5kYXJkcy4gIFRoZSBhcmNoaXRlY3R1cmVzDQo+ICAgICBkZXNjcmliZWQgaGVyZSBhcmUgYXBw bGljYWJsZSBiZXlvbmQgdGhlc2Ugb3JnYW5pemF0aW9ucy4NCj4gDQo+IFdvcmsgSW4gUHJvZ3Jl c3M6ICAgZHJhZnQtaWV0Zi10c3Z3Zy1lbWVyZ2VuY3ktcnN2cC0wMy50eHQNCj4gDQo+IFRpdGxl Og0KPiAgICAgUmVzb3VyY2UgUmVTZXJWYXRpb24gUHJvdG92b2wgKFJTVlApIEV4dGVuc2lvbnMg Zm9yDQo+ICAgICBFbWVyZ2VuY3kgU2VydmljZXMNCj4gDQo+IEFic3RyYWN0Og0KPiAgICAgQW4g RW1lcmdlbmN5IFRlbGVjb21tdW5pY2F0aW9ucyBTZXJ2aWNlIChFVFMpIHJlcXVpcmVzIHRoZSBh YmlsaXR5IA0KdG8NCj4gICAgIHByb3ZpZGUgYW4gZWxldmF0ZWQgcHJvYmFiaWxpdHkgb2Ygc2Vz c2lvbiBlc3RhYmxpc2htZW50IHRvIGFuDQo+ICAgICBhdXRob3JpemVkIHVzZXIgaW4gdGltZXMg b2YgbmV0d29yayBjb25nZXN0aW9uICh0eXBpY2FsbHksIGR1cmluZyBhDQo+ICAgICBjcmlzaXMp LiBXaGVuIHN1cHBvcnRlZCBvdmVyIHRoZSBJbnRlcm5ldCBQcm90b2NvbCBzdWl0ZSwgdGhpcyBt YXkgDQpiZQ0KPiAgICAgZmFjaWxpdGF0ZWQgdGhyb3VnaCBhIG5ldHdvcmsgbGF5ZXIgYWRtaXNz aW9uIGNvbnRyb2wgc29sdXRpb24sIA0Kd2hpY2gNCj4gICAgIHN1cHBvcnRzIHByaW9yaXRpemVk IGFjY2VzcyB0byByZXNvdXJjZXMgKGUuZy4sIGJhbmR3aWR0aCkuIFRoZXNlDQo+ICAgICByZXNv dXJjZXMgbWF5IGJlIGV4cGxpY2l0bHkgc2V0IGFzaWRlIGZvciBlbWVyZ2VuY3kgc2VydmljZXMs IG9yIA0KdGhleQ0KPiAgICAgbWF5IGJlIHNoYXJlZCB3aXRoIG90aGVyIHNlc3Npb25zLg0KPiAN Cj4gICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgUlNWUCBleHRlbnNpb25zIHRoYXQgY2FuIGJl IHVzZWQgdG8gc3VwcG9ydA0KPiAgICAgc3VjaCBhbiBhZG1pc3Npb24gcHJpb3JpdHkgY2FwYWJp bGl0eSBhdCB0aGUgbmV0d29yayBsYXllci4gTm90ZSANCnRoYXQNCj4gICAgIHRoZXNlIGV4dGVu c2lvbnMgcmVwcmVzZW50IG9uZSBwb3NzaWJsZSBzb2x1dGlvbiBjb21wb25lbnQgaW4NCj4gICAg IHNhdGlzZnlpbmcgRVRTIHJlcXVpcmVtZW50cy4gT3RoZXIgc29sdXRpb24gY29tcG9uZW50cywg b3Igb3RoZXINCj4gICAgIHNvbHV0aW9ucywgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMg ZG9jdW1lbnQuDQo+IA0KPiBOU0lTIFdvcmtpbmcgR3JvdXANCj4gDQo+IFdvcmsgSW4gUHJvZ3Jl c3M6IGRyYWZ0LWlldGYtbnNpcy1xb3MtbnNscC0xNC50eHQNCj4gDQo+IFRpdGxlOg0KPiAgICAg TlNMUCBmb3IgUXVhbGl0eS1vZi1TZXJ2aWNlIFNpZ25hbGluZw0KPiANCj4gQWJzdHJhY3Q6DQo+ ICAgICBUaGlzIHNwZWNpZmljYXRpb24gZGVzY3JpYmVzIHRoZSBOU0lTIFNpZ25hbGluZyBMYXll ciBQcm90b2NvbA0KPiAgICAgKE5TTFApIGZvciBzaWduYWxpbmcgUW9TIHJlc2VydmF0aW9ucyBp biB0aGUgSW50ZXJuZXQuICBJdCBpcyBpbg0KPiAgICAgYWNjb3JkYW5jZSB3aXRoIHRoZSBmcmFt ZXdvcmsgYW5kIHJlcXVpcmVtZW50cyBkZXZlbG9wZWQgaW4gTlNJUy4NCj4gICAgIFRvZ2V0aGVy IHdpdGggR0lTVCwgaXQgcHJvdmlkZXMgZnVuY3Rpb25hbGl0eSBzaW1pbGFyIHRvIFJTVlAgYW5k DQo+ICAgICBleHRlbmRzIGl0LiAgVGhlIFFvUyBOU0xQIGlzIGluZGVwZW5kZW50IG9mIHRoZSB1 bmRlcmx5aW5nIFFvUw0KPiAgICAgc3BlY2lmaWNhdGlvbiBvciBhcmNoaXRlY3R1cmUgYW5kIHBy b3ZpZGVzIHN1cHBvcnQgZm9yIGRpZmZlcmVudA0KPiAgICAgcmVzZXJ2YXRpb24gbW9kZWxzLiBJ dCBpcyBzaW1wbGlmaWVkIGJ5IHRoZSBlbGltaW5hdGlvbiBvZiBzdXBwb3J0DQo+ICAgICBmb3Ig bXVsdGljYXN0IGZsb3dzLiBUaGlzIHNwZWNpZmljYXRpb24gZXhwbGFpbnMgdGhlIG92ZXJhbGwN Cj4gICAgIHByb3RvY29sIGFwcHJvYWNoLCBkZXNpZ24gZGVjaXNpb25zIG1hZGUgYW5kIHByb3Zp ZGVzIGV4YW1wbGVzLiAgSXQNCj4gICAgIHNwZWNpZmllcyBvYmplY3QsIG1lc3NhZ2UgIGZvcm1h dHMgYW5kIHByb2Nlc3NpbmcgcnVsZXMuDQo+IA0KPiAtLSANCj4gDQo+IE1hZ251cyBXZXN0ZXJs dW5kDQo+IA0KPiBJRVRGIFRyYW5zcG9ydCBBcmVhIERpcmVjdG9yICYgVFNWV0cgQ2hhaXINCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiBNdWx0aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFy Y2ggRUFCL1RWTS9NDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRXJpY3Nzb24gQUIgICAgICAgICAgICAg ICAgfCBQaG9uZSArNDYgOCA0MDQ4Mjg3DQo+IFRvcnNoYW1zZ2F0YW4gMjMgICAgICAgICAgIHwg RmF4ICAgKzQ2IDggNzU3NTU1MA0KPiBTLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbiB8IG1haWx0 bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+ IA0KDQo= --=_alternative 0055890785257329_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk1hZ251cyw8YnI+DQo8YnI+DQpZ b3UgbWlnaHQgd2FudCB0byBhZGQtPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5kcmFmdC1wb2xrLXRzdndnLXNpZ25hbGVkLWRvbWFpbi1pZC0wMC50eHQ8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmFuZCA8YnI+DQpkcmFm dC1wb2xrLWVjcml0LWxvY2FsLWVtZXJnZW5jeS1ycGgtbmFtZXNwYWNlLTAxLnR4dDwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+KEJvdGggd2VyZSBvbiB0 aGUgYWdlbmRhIGFuZCBkaXNjdXNzZWQuKTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+QW5kIG1heWJlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5kcmFmdC1jYXJsYmVyZy10cmlwLWF0dHJpYnV0ZS1ycC0wMg0KPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4odGhvdWdoIEkgZGlk IG5vdCBzZWUgaXQgb24gdGhlIGFnZW5kYSk8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPkphbmV0PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5QUyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPk15IHNwZWxsaW5nIGNoZWNrZXIgc2F5cyAmcXVvdDtMaWFpc2lvbiZxdW90 Ow0Kc2hvdWxkIGJlICZxdW90O0xpYWlzb24mcXVvdDssIGJ1dCBpdCBtYXkgYmUgYSBVUyBjZW50 cmljIGRpY3Rpb25hcnkuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5KPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+TWFnbnVzIFdlc3Rlcmx1bmQgJmx0O21h Z251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbSZndDsNCndyb3RlIG9uIDA3LzMxLzIwMDcgMTE6 MjE6MjAgQU06PGJyPg0KPGJyPg0KJmd0OyBIaTxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGlzIGlz IHRoZSBkcmFmdCBmb3IgYSBsaWFpc29uIHJlc3BvbnNlIHRvIGJlIHNlbnQgdG8gU0cgMTMgb2Yg dGhlDQo8YnI+DQomZ3Q7IElUVS1UIGZyb20gdGhlIFRTVldHLCBOU0lTLCBTSVAgYW5kIFNJUFBJ TkcgV0dzLiBQbGVhc2UgcHJvdmlkZSBhbnkNCjxicj4NCiZndDsgY29tbWVudHMgYXQgdGhlIGxh dGVzdCBieSB0aGUgMTR0aCBvZiBBdWd1c3QuIEFmdGVyIHRoYXQgd2Ugd2lsbCBhZGRyZXNzDQo8 YnI+DQomZ3Q7IGFueSByYWlzZWQgY29tbWVudHMgYW5kIHNlbmQgdGhlIGxpYWlzb24gdG8gSVRV LVQgYmVmb3JlIHRoZSBlbmQgb2YNCkF1Z3VzdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgU3VibWlz c2lvbjxicj4NCiZndDsgRGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7dGJkJmd0OywgMjAw Nzxicj4NCiZndDsgPGJyPg0KJmd0OyBGcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJRVRGIFdv cmtpbmcgZ3JvdXBzIFRTVldHLCBOU0lTLCBTSVAgYW5kDQpTSVBQSU5HPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IFRvOiAmbmJzcDsgJm5ic3A7ICZuYnNwO0dlb3JnZXMgU2ViZWsgJm5ic3A7Jmx0O3Rz YnNnMTNAaXR1LmludCZndDsNCiw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEtlaXRo IEtuaWdodHNvbiAmbHQ7a2drQGlncy5uZXQmZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IENjOiAm bmJzcDsgJm5ic3A7ICZuYnNwO01hZ251cyBXZXN0ZXJsdW5kICZsdDttYWdudXMud2VzdGVybHVu ZEBlcmljc3Nvbi5jb20mZ3Q7LDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtMYXJzDQpFZ2dlcnQgJmx0O2xhcnMu ZWdnZXJ0QG5va2lhLmNvbSZndDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0phbWVzDQpQb2xrICZsdDtqbXBv bGtAY2lzY28uY29tJmd0Oyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TWFydGluDQpTdGllbWVybGluZyAmbHQ7 c3RpZW1lcmxpbmdAbmV0bGFiLm5lYy5kZSZndDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0pvaG4NCkxvdWdo bmV5ICZsdDtqb2huLmxvdWdobmV5QG5va2lhLmNvbSZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RGVhbg0K V2lsbGlzICZsdDtkZWFuLndpbGxpc0Bzb2Z0YXJtb3IuY29tJmd0Oyw8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 S2VpdGgNCkRyYWdlICZsdDtkcmFnZUBhbGNhdGVsLWx1Y2VudC5jb20mZ3Q7LDxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtNYXJ5DQpCYXJuZXMgJmx0O21hcnkuYmFybmVzQG5vcnRlbC5jb20mZ3Q7LDxicj4NCiZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtHb256YWxvDQpDYW1hcmlsbG8gJmx0O2dvbnphbG8uY2FtYXJpbGxvQGVyaWNzc29u LmNvbSZndDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1Njb3R0DQpCcmFkbmVyICZsdDtzb2JAaGFydmFyZC5l ZHUmZ3Q7LDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtLaW1iZXJseQ0KS2luZyAmbHQ7a3NraW5nQG1pdHJlLm9y ZyZndDssPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1Njb3R0DQpCcmltICZsdDtzd2JAZW1wbG95ZWVzLm9yZyZn dDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgUmVzcG9uc2U8YnI+DQomZ3Q7IENvbnRhY3Q6ICZuYnNw OyBUU1YgV0cgKHRzdi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcpPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBOU0lTIChuc2lzLWNoYWlyc0B0b29scy5pZXRmLm9yZyk8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IFNJUFBJTkcgKHNpcHBpbmctY2hhaXJzQHRvb2xzLmlldGYub3Jn KTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU0lQIChzaXAtY2hhaXJzQHRvb2xzLmll dGYub3JnKTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsgUHVycG9zZTogJm5ic3A7 ICZuYnNwO1Jlc3BvbnNlIHRvIExpYWlzb24gUmVxdWVzdDxicj4NCiZndDsgPGJyPg0KJmd0OyBE ZWFkbGluZTogJm5ic3A7IE5vbmU8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGl0bGU6IFJlc3BvbnNl IHRvIGxpYWlzb24gcmVxdWVzdCBmcm9tIElUVS1UIFN0dWR5IEdyb3VwIDEzIHdvcmsNCm9uIDxi cj4NCiZndDsgZW1lcmdlbmN5IHRlbGVjb21tdW5pY2F0aW9uczxicj4NCiZndDsgPGJyPg0KJmd0 OyBUaGlzIGlzIGEgcmVzcG9uc2UgdG8gdGhlIGxpYWlzb24gcmVxdWVzdCBtYWRlIGJ5IFEzLzEz IHJlZ2FyZGluZw0KPGJyPg0KJmd0OyBlbWVyZ2VuY3kgdGVsZWNvbW11bmljYXRpb25zIChSRUY6 IE5HTi1HU0kvRE9DIOKAkyA2MCBSZXYuMikuIFdlIHdvdWxkDQo8YnI+DQomZ3Q7IGZpcnN0IGxp a2UgdG8gYXBvbG9naXplIGZvciBmYWlsaW5nIHRvIG1lZXQgdGhlIGRlYWRsaW5lIGluIHJlc3Bv bmRpbmcuDQo8YnI+DQomZ3Q7IFdlIGRvIGhvcGUgdGhhdCB0aGUgbGF0ZSBhbnN3ZXIgc3RpbGwg Y2FuIGJlIG9mIHNvbWUgdXNlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgbGlhaXNvbiByZXF1 ZXN0IHdhcyBtYWRlIHRvIHRoZSBmb2xsb3dpbmcgd29ya2luZyBncm91cHMgKFdHKToNCjxicj4N CiZndDsgSUVQUkVQLCBUU1ZXRywgYW5kIE5TSVMuIFNpbmNlIHRoZSByZXF1ZXN0IHdhcyBzZW50 IHRoZSBJRVBSRVAgV0cNCmhhcyA8YnI+DQomZ3Q7IGNvbmNsdWRlZC4gSW4gYWRkaXRpb24gdG8g dGhlIFdHcyBmcm9tIHdoaWNoIGluZm9ybWF0aW9uIHdhcyByZXF1ZXN0ZWQsDQo8YnI+DQomZ3Q7 IHdlIGFsc28gdGhpbmsgdGhhdCB3b3JrIHBlcmZvcm1lZCBieSB0aGUgU0lQIGFuZCBTSVBQSU5H IFdHIG1heSBiZQ0Kb2YgPGJyPg0KJmd0OyByZWxldmFuY2UuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFB1cnN1YW50IHRvIElUVS1UIFN0dWR5IEdyb3VwIDEzIHJlcXVlc3QgZm9yIGluZm9ybWF0aW9u IG9uIHJlbGV2YW50DQphbmQgPGJyPg0KJmd0OyByZWxhdGVkIHdvcmsgaW4gdGhlIElFVEYgcmVn YXJkaW5nIGVtZXJnZW5jeSBjb21tdW5pY2F0aW9ucywgd2UgbGlzdA0KPGJyPg0KJmd0OyBiZWxv dyBSRkNzIGFuZCB3b3JrcyBpbiBwcm9ncmVzcyB0aGF0IHdlIGZlZWwgbWF5IGJlIG9mIGludGVy ZXN0IHRvDQp5b3VyIDxicj4NCiZndDsgZ3JvdXAuICZuYnNwO1NvbWUgb2YgdGhlIGNvbXBsZXRl ZCB3b3JrIGlzIEluZm9ybWF0aW9uYWwsIGFuZCBvdGhlcnMNCmFyZSBpbiA8YnI+DQomZ3Q7IHRo ZSBjYXRlZ29yeSBvZiBTdGFuZGFyZHMgVHJhY2suPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFEuMy8x MyBhbHNvIHJlcXVlc3RlZCB0aGF0IHdlIGtlZXAgeW91IGluZm9ybWVkIG9mIGFueSBkZXZlbG9w bWVudHMNCmluIDxicj4NCiZndDsgcmVnYXJkcyB0byBlbWVyZ2VuY3kgdGVsZWNvbW11bmljYXRp b25zLiBJbiB0aG9zZSByZWdhcmRzIHdlIHdvdWxkDQpsaWtlIDxicj4NCiZndDsgdG8gbWFrZSB5 b3UgYXdhcmUgdGhhdCBJRVRGIG1haWxpbmcgbGlzdCBwYXJ0aWNpcGF0aW9uIGFuZCBkb2N1bWVu dA0KPGJyPg0KJmd0OyBpbmZvcm1hdGlvbiBpcyBmcmVlIGFuZCBvcGVuIGZvciBhbnlvbmUuIEFs bG93aW5nIHBhcnRpY2lwYW50cyBpbg0KUS4zLzEzIDxicj4NCiZndDsgdG8ga2VlcCB0aGVtIHNl bHZlcyBpbmZvcm1lZCBvZiBhbnkgZGV2ZWxvcG1lbnRzLiBJZiBRLjMvMTMgZGVzaXJlDQp0byA8 YnI+DQomZ3Q7IGdldCBmdXJ0aGVyIGluZm9ybWF0aW9uIGFib3V0IHNwZWNpZmljIG9uZ29pbmcg d29yaywgdGhlbiBwbGVhc2Ugc2VuZA0KYSA8YnI+DQomZ3Q7IGxpYWlzb24gcmVxdWVzdCB0byB0 aGUgcmVzcG9uc2libGUgV0cgZm9yIHRob3NlIHNwZWNpZmljIGRvY3VtZW50cy48YnI+DQomZ3Q7 IDxicj4NCiZndDsgVGhlIGZvbGxvd2luZyBsaXN0IGlzIGRpdmlkZWQgdW5kZXIgdGhlIGFzc29j aWF0ZWQgd29ya2luZyBncm91cHMNCmZyb20gPGJyPg0KJmd0OyB3aGljaCB0aGUgd29yayBoYXMg YmVlbiBkb25lIHdpdGhpbiB0aGUgSUVURi48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0 OyBTSVAgV29ya2luZyBHcm91cDxicj4NCiZndDsgPGJyPg0KJmd0OyBSRkMgNDQxMTxicj4NCiZn dDsgPGJyPg0KJmd0OyBUaXRsZTo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgRXh0ZW5kaW5nIHRo ZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCk8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgUmVhc29uIEhlYWRlciBmb3IgUHJlZW1wdGlvbiBFdmVudHM8YnI+DQomZ3Q7IDxicj4NCiZn dDsgQWJzdHJhY3Q6PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBwcm9wb3Nl cyBhbiBJQU5BIFJlZ2lzdHJhdGlvbiBleHRlbnNpb24NCnRvIHRoZSBTZXNzaW9uPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7IEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkgUmVhc29uIEhlYWRlciB0 byBiZSBpbmNsdWRlZA0KaW4gYSBCWUU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgTWV0aG9kIFJl cXVlc3QgYXMgYSByZXN1bHQgb2YgYSBzZXNzaW9uIHByZWVtcHRpb24gZXZlbnQsDQplaXRoZXIg YXQgYTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB1c2VyIGFnZW50IChVQSksIG9yIHNvbWV3aGVy ZSBpbiB0aGUgbmV0d29yayBpbnZvbHZpbmcNCmE8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgcmVz ZXJ2YXRpb24tYmFzZWQgcHJvdG9jb2wgc3VjaCBhcyB0aGUgUmVzb3VyY2UgUmVTZXJWYXRpb24N ClByb3RvY29sPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IChSU1ZQKSBvciBOZXh0IFN0ZXBzIGlu IFNpZ25hbGluZyAoTlNJUykuICZuYnNwO1RoaXMNCmRvY3VtZW50IGRvZXMgbm90PGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7IGF0dGVtcHQgdG8gYWRkcmVzcyByb3V0ZXJzIGZhaWxpbmcgaW4gdGhl IHBhY2tldCBwYXRoOw0KaW5zdGVhZCwgaXQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgYWRkcmVz c2VzIGEgZGVsaWJlcmF0ZSB0ZWFyIGRvd24gb2YgYSBmbG93IGJldHdlZW4gVUFzLA0KYW5kIGlu Zm9ybXM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgdGhlIHRlcm1pbmF0ZWQgVUEocykgd2l0aCBh biBpbmRpY2F0aW9uIG9mIHdoYXQgb2NjdXJyZWQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJGQyA0 NDEyPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRpdGxlOjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBD b21tdW5pY2F0aW9ucyBSZXNvdXJjZSBQcmlvcml0eSBmb3IgdGhlIFNlc3Npb24gSW5pdGlhdGlv bjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBQcm90b2NvbCAoU0lQKTxicj4NCiZndDsgPGJyPg0K Jmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgVGhpcyBkb2N1bWVudCBkZWZp bmVzIHR3byBuZXcgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sDQooU0lQKTxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyBoZWFkZXIgZmllbGRzIGZvciBjb21tdW5pY2F0aW5nIHJlc291cmNlIHBy aW9yaXR5LCBuYW1lbHksPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZxdW90O1Jlc291cmNlLVBy aW9yaXR5JnF1b3Q7IGFuZCAmcXVvdDtBY2NlcHQtUmVzb3VyY2UtUHJpb3JpdHkmcXVvdDsuDQom bmJzcDtUaGU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7UmVzb3VyY2UtUHJpb3JpdHkm cXVvdDsgaGVhZGVyIGZpZWxkIGNhbiBpbmZsdWVuY2UNCnRoZSBiZWhhdmlvciBvZiBTSVA8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgdXNlciBhZ2VudHMgKHN1Y2ggYXMgdGVsZXBob25lIGdhdGV3 YXlzIGFuZCBJUCB0ZWxlcGhvbmVzKQ0KYW5kIFNJUDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBw cm94aWVzLiAmbmJzcDtJdCBkb2VzIG5vdCBkaXJlY3RseSBpbmZsdWVuY2UgdGhlIGZvcndhcmRp bmcNCmJlaGF2aW9yIG9mPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IElQIHJvdXRlcnMuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBTSVBQSU5HIFdvcmtpbmcgR3Jv dXA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBUaGUgYmVsb3cgdHdvIGRvY3Vt ZW50cyBhcmUgcHJvcG9zZWQgd29yayBpdGVtcyBub3QNCnlldCBhY2NlcHRlZCBhczxicj4NCiZn dDsgJm5ic3A7ICZuYnNwOyBJRVRGIFdHIGl0ZW1zIGJ1dCBhcmUgbGlrZWx5IG9mIGludGVyZXN0 IGFzIHRoZXkgdXBkYXRlDQpSRkMgNDQxMi48YnI+DQomZ3Q7IDxicj4NCiZndDsgV29yayBJbiBQ cm9ncmVzczogJm5ic3A7IGRyYWZ0LXBvbGstc2lwLXJwaC1pbi1yZXNwb25zZXMtMDA8YnI+DQom Z3Q7IDxicj4NCiZndDsgVGl0bGU6PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IEFsbG93aW5nIFNJ UCBSZXNvdXJjZSBQcmlvcml0eSBIZWFkZXIgaW4gU0lQIFJlc3BvbnNlczxicj4NCiZndDsgPGJy Pg0KJmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgVGhlIFNlc3Npb24gSW5p dGlhdGlvbiBQcm90b2NvbCAoU0lQKSBSZXNvdXJjZSBQcmlvcml0eQ0KSGVhZGVyPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7IChSUEgpLCBpbiBpdHMgY3VycmVudCBmb3JtLCBpcyBpZ25vcmVkIGlu IFNJUCByZXNwb25zZXMuDQombmJzcDtUaGlzIHdhcyBhPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 IGRlc2lnbiBjaG9pY2UgZHVyaW5nIFJGQyA0NDEyJ3MgZGV2ZWxvcG1lbnQuIFRoaXMgaXMNCm5v dyBjb25zaWRlcmVkPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IGEgYmFkIGRlc2lnbiBjaG9pY2Ug aW4gY2VydGFpbiBzY2VuYXJpb3MuICZuYnNwO1RoaXMNCmRvY3VtZW50IGNvcnJlY3RzPGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7IFJGQyA0NDEyJ3MgY29tbXVuaWNhdGlvbnMgbW9kZWwgYnkgb3B0 aW9uYWxseSBhbGxvd2luZw0KYSBTSVAgc2VydmVyPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IG9y IHVzZXIgYWdlbnQgY2xpZW50IHRvIHByb2Nlc3MgdGhlIFJlc291cmNlLVByaW9yaXR5DQpIZWFk ZXIgaW4gYTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyByZXNwb25zZS48YnI+DQomZ3Q7IDxicj4N CiZndDsgV29yayBJbiBQcm9ncmVzczogJm5ic3A7IGRyYWZ0LXBvbGstc2lwLXJwaC1uZXctbmFt ZXNwYWNlcy0tMDA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGl0bGU6PGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7IE5ldyBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgUmVzb3VyY2UtUHJpb3JpdHkg SGVhZGVyDQpOYW1lc3BhY2VzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IGZvciB0aGUgRGVmZW5z ZSBJbmZvcm1hdGlvbiBTeXN0ZW1zIEFnZW5jeTxicj4NCiZndDsgPGJyPg0KJmd0OyBBYnN0cmFj dDo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgVGhpcyBkb2N1bWVudCBjcmVhdGVzIGFkZGl0aW9u YWwgU2Vzc2lvbiBJbml0aWF0aW9uDQpQcm90b2NvbDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBS ZXNvdXJjZS1Qcmlvcml0eSBoZWFkZXIgbmFtZXNwYWNlcywgdG8gYmUgSUFOQSByZWdpc3RlcmVk Lg0KJm5ic3A7VGhpczxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBkb2N1bWVudCBpbnRlbmRzIHRv IHVwZGF0ZSBSRkMgNDQxMiwgYXMgYSBQcm9wb3NlZCBTdGFuZGFyZA0KZG9jdW1lbnQ8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsgaWYgcHVibGlzaGVkIGJ5IHRoZSBSRkMtRWRpdG9yLjxicj4NCiZn dDsgPGJyPg0KJmd0OyBJRVBSRVAgV29ya2luZyBHcm91cDxicj4NCiZndDsgPGJyPg0KJmd0OyBS RkMgMzQ4Nzxicj4NCiZndDsgPGJyPg0KJmd0OyBUaXRsZTo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgUmVxdWlyZW1lbnRzIGZvciBSZXNvdXJjZSBQcmlvcml0eSBNZWNoYW5pc21zIGZvciB0aGU8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVAp PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFic3RyYWN0Ojxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBU aGlzIGRvY3VtZW50IHN1bW1hcml6ZXMgcmVxdWlyZW1lbnRzIGZvciBwcmlvcml0aXppbmcNCmFj Y2VzcyB0bzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBjaXJjdWl0LXN3aXRjaGVkIG5ldHdvcmss IGVuZCBzeXN0ZW0gYW5kIHByb3h5IHJlc291cmNlcw0KZm9yPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7IGVtZXJnZW5jeSBwcmVwYXJlZG5lc3MgY29tbXVuaWNhdGlvbnMgdXNpbmcgdGhlIFNlc3Np b24NCkluaXRpYXRpb248YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgUHJvdG9jb2wgKFNJUCkuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IFJGQyAzNjg5PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRpdGxlOjxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyBHZW5lcmFsIFJlcXVpcmVtZW50cyBmb3I8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsgRW1lcmdlbmN5IFRlbGVjb21tdW5pY2F0aW9uIFNlcnZpY2UgKEVUUyk8 YnI+DQomZ3Q7IDxicj4NCiZndDsgQWJzdHJhY3Q6PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IFRo aXMgZG9jdW1lbnQgcHJlc2VudHMgYSBsaXN0IG9mIGdlbmVyYWwgcmVxdWlyZW1lbnRzDQppbiBz dXBwb3J0IG9mPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IEVtZXJnZW5jeSBUZWxlY29tbXVuaWNh dGlvbnMgU2VydmljZSAoRVRTKS4gJm5ic3A7U29sdXRpb25zDQp0byB0aGVzZTxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyByZXF1aXJlbWVudHMgYXJlIG5vdCBwcmVzZW50ZWQgaW4gdGhpcyBkb2N1 bWVudC4gJm5ic3A7QWRkaXRpb25hbDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyByZXF1aXJlbWVu dHMgcGVydGFpbmluZyB0byBzcGVjaWZpYyBhcHBsaWNhdGlvbnMsIG9yDQp0eXBlcyBvZjxicj4N CiZndDsgJm5ic3A7ICZuYnNwOyBhcHBsaWNhdGlvbnMsIGFyZSB0byBiZSBzcGVjaWZpZWQgaW4g c2VwYXJhdGUgZG9jdW1lbnQocykuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJGQyAzNjkwPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IFRpdGxlOjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBJUCBUZWxlcGhv bnkgUmVxdWlyZW1lbnRzIGZvcjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBFbWVyZ2VuY3kgVGVs ZWNvbW11bmljYXRpb24gU2VydmljZSAoRVRTKTxicj4NCiZndDsgPGJyPg0KJmd0OyBBYnN0cmFj dDo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgVGhpcyBkb2N1bWVudCBwcmVzZW50cyBhIGxpc3Qg b2YgcmVxdWlyZW1lbnRzIGluIHN1cHBvcnQNCm9mIEVtZXJnZW5jeTxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyBUZWxlY29tbXVuaWNhdGlvbnMgU2VydmljZSAoRVRTKSB3aXRoaW4gdGhlIGNvbnRl eHQNCm9mIElQIHRlbGVwaG9ueS48YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgSXQgaXMgYW4gZXh0 ZW5zaW9uIHRvIHRoZSBnZW5lcmFsIHJlcXVpcmVtZW50cyBwcmVzZW50ZWQNCmluIFJGQyAzNjg5 Ljxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBTb2x1dGlvbnMgdG8gdGhlc2UgcmVxdWlyZW1lbnRz IGFyZSBub3QgcHJlc2VudGVkIGluDQp0aGlzIGRvY3VtZW50Ljxicj4NCiZndDsgPGJyPg0KJmd0 OyBSRkMgNDE5MDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaXRsZTo8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgRnJhbWV3b3JrIGZvciBTdXBwb3J0aW5nIEVtZXJnZW5jeSBUZWxlY29tbXVuaWNhdGlv bnM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgU2VydmljZSAoRVRTKSBpbiBJUCBUZWxlcGhvbnk8 YnI+DQomZ3Q7IDxicj4NCiZndDsgQWJzdHJhY3Q6PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IFRo aXMgZG9jdW1lbnQgcHJlc2VudHMgYSBmcmFtZXdvcmsgZm9yIHN1cHBvcnRpbmcgYXV0aG9yaXpl ZCw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgZW1lcmdlbmN5LXJlbGF0ZWQgY29tbXVuaWNhdGlv biB3aXRoaW4gdGhlIGNvbnRleHQgb2YNCklQIHRlbGVwaG9ueS48YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgV2UgcHJlc2VudCBhIHNlcmllcyBvZiBvYmplY3RpdmVzIHRoYXQgcmVmbGVjdCBhIGdl bmVyYWwNCnZpZXcgb2YgaG93PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IGF1dGhvcml6ZWQgZW1l cmdlbmN5IHNlcnZpY2UsIGluIGxpbmUgd2l0aCB0aGUgRW1lcmdlbmN5PGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7IFRlbGVjb21tdW5pY2F0aW9ucyBTZXJ2aWNlIChFVFMpLCBzaG91bGQgYmUgcmVh bGl6ZWQNCndpdGhpbiB0b2RheSdzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IElQIGFyY2hpdGVj dHVyZSBhbmQgc2VydmljZSBtb2RlbHMuICZuYnNwO0Zyb20gdGhlc2UNCm9iamVjdGl2ZXMsIHdl PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHByZXNlbnQgYSBjb3JyZXNwb25kaW5nIHNldCBvZiBw cm90b2NvbHMgYW5kIGNhcGFiaWxpdGllcywNCndoaWNoPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 IHByb3ZpZGUgYSBtb3JlIHNwZWNpZmljIHNldCBvZiByZWNvbW1lbmRhdGlvbnMgcmVnYXJkaW5n DQpleGlzdGluZzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBJRVRGIHByb3RvY29scy4gJm5ic3A7 RmluYWxseSwgd2UgcHJlc2VudCB0d28gc2NlbmFyaW9zDQp0aGF0IGFjdCBhczxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyBndWlkaW5nIG1vZGVscyBmb3IgdGhlIG9iamVjdGl2ZXMgYW5kIGZ1bmN0 aW9ucyBsaXN0ZWQNCmluIHRoaXM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgZG9jdW1lbnQuICZu YnNwO1RoZXNlIG1vZGVscywgY291cGxlZCB3aXRoIGFuIGV4YW1wbGUNCm9mIGFuIGV4aXN0aW5n PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHNlcnZpY2UgaW4gdGhlIFB1YmxpYyBTd2l0Y2hlZCBU ZWxlcGhvbmUgTmV0d29yayAoUFNUTiksDQpjb250cmlidXRlPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7IHRvIGEgY29uc3RyYWluZWQgc29sdXRpb24gc3BhY2UuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFJGQyA0Mzc1PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRpdGxlOjxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyBFbWVyZ2VuY3kgVGVsZWNvbW11bmljYXRpb25zIFNlcnZpY2VzIChFVFMpIFJlcXVpcmVt ZW50czxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBmb3IgYSBTaW5nbGUgQWRtaW5pc3RyYXRpdmUg RG9tYWluPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFic3RyYWN0Ojxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyBUaGlzIGRvY3VtZW50IHByZXNlbnRzIGEgbGlzdCBvZiByZXF1aXJlbWVudHMgaW4gc3Vw cG9ydA0Kb2YgRW1lcmdlbmN5PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IFRlbGVjb21tdW5pY2F0 aW9ucyBTZXJ2aWNlIChFVFMpIHdpdGhpbiBhIHNpbmdsZSBhZG1pbmlzdHJhdGl2ZTxicj4NCiZn dDsgJm5ic3A7ICZuYnNwOyBkb21haW4uICZuYnNwO1RoaXMgZG9jdW1lbnQgZm9jdXNlcyBvbiBh IHNwZWNpZmljIHNldA0Kb2YgYWRtaW5pc3RyYXRpdmU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg Y29uc3RyYWludHMgYW5kIHNjb3BlLiAmbmJzcDtTb2x1dGlvbnMgdG8gdGhlc2UgcmVxdWlyZW1l bnRzDQphcmUgbm90PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHByZXNlbnRlZCBpbiB0aGlzIGRv Y3VtZW50Ljxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRTViBXb3JraW5nIEdyb3Vw PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJGQyA0NTQyPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRpdGxl Ojxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBJbXBsZW1lbnRpbmcgYW4gRW1lcmdlbmN5IFRlbGVj b21tdW5pY2F0aW9ucyBTZXJ2aWNlDQooRVRTKTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBmb3Ig UmVhbC1UaW1lIFNlcnZpY2VzIGluIHRoZSBJbnRlcm5ldCBQcm90b2NvbCBTdWl0ZTxicj4NCiZn dDsgPGJyPg0KJmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgUkZDcyAzNjg5 IGFuZCAzNjkwIGRldGFpbCByZXF1aXJlbWVudHMgZm9yIGFuIEVtZXJnZW5jeTxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyBUZWxlY29tbXVuaWNhdGlvbnMgU2VydmljZSAoRVRTKSwgb2Ygd2hpY2gg YW4gSW50ZXJuZXQNCkVtZXJnZW5jeTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBQcmVwYXJlZG5l c3MgU2VydmljZSAoSUVQUykgd291bGQgYmUgYSBwYXJ0LiAmbmJzcDtTb21lDQpvZiB0aGVzZSB0 eXBlcyBvZjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBzZXJ2aWNlcyByZXF1aXJlIGNhbGwgcHJl ZW1wdGlvbjsgb3RoZXJzIHJlcXVpcmUgY2FsbA0KcXVldWluZyBvcjxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyBvdGhlciBtZWNoYW5pc21zLiAmbmJzcDtJRVBTIHJlcXVpcmVzIGEgQ2FsbCBBZG1p c3Npb24NCkNvbnRyb2wgKENBQyk8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgcHJvY2VkdXJlIGFu ZCBhIFBlciBIb3AgQmVoYXZpb3IgKFBIQikgZm9yIHRoZSBkYXRhDQp0aGF0IG1lZXQgdGhlPGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7IG5lZWRzIG9mIHRoaXMgYXJjaGl0ZWN0dXJlLiAmbmJzcDtT dWNoIGEgQ0FDIHByb2NlZHVyZQ0KYW5kIFBIQiBpczxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBh cHByb3ByaWF0ZSB0byBhbnkgc2VydmljZSB0aGF0IG1pZ2h0IHVzZSBILjMyMyBvciBTSVANCnRv IHNldCB1cDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyByZWFsLXRpbWUgc2Vzc2lvbnMuICZuYnNw O1RoZSBrZXkgcmVxdWlyZW1lbnQgaXMgdG8NCmd1YXJhbnRlZSBhbiBlbGV2YXRlZDxicj4NCiZn dDsgJm5ic3A7ICZuYnNwOyBwcm9iYWJpbGl0eSBvZiBjYWxsIGNvbXBsZXRpb24gdG8gYW4gYXV0 aG9yaXplZCB1c2VyDQppbiB0aW1lIG9mPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IGNyaXNpcy48 YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBUaGlzIGRvY3VtZW50IHByaW1hcmls eSBkaXNjdXNzZXMgc3VwcG9ydGluZyBFVFMgaW4NCnRoZSBjb250ZXh0IG9mPGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7IHRoZSBVUyBHb3Zlcm5tZW50IGFuZCBOQVRPLCBiZWNhdXNlIGl0IGZvY3Vz ZXMgb24gdGhlDQpNdWx0aS1MZXZlbDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBQcmVjZWRlbmNl IGFuZCBQcmVlbXB0aW9uIChNTFBQKSBhbmQgR292ZXJubWVudCBFbWVyZ2VuY3k8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsgVGVsZWNvbW11bmljYXRpb24gU2VydmljZSAoR0VUUykgc3RhbmRhcmRz LiAmbmJzcDtUaGUNCmFyY2hpdGVjdHVyZXM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgZGVzY3Jp YmVkIGhlcmUgYXJlIGFwcGxpY2FibGUgYmV5b25kIHRoZXNlIG9yZ2FuaXphdGlvbnMuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IFdvcmsgSW4gUHJvZ3Jlc3M6ICZuYnNwOyBkcmFmdC1pZXRmLXRzdndn LWVtZXJnZW5jeS1yc3ZwLTAzLnR4dDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaXRsZTo8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsgUmVzb3VyY2UgUmVTZXJWYXRpb24gUHJvdG92b2wgKFJTVlApIEV4 dGVuc2lvbnMgZm9yPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IEVtZXJnZW5jeSBTZXJ2aWNlczxi cj4NCiZndDsgPGJyPg0KJmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgQW4g RW1lcmdlbmN5IFRlbGVjb21tdW5pY2F0aW9ucyBTZXJ2aWNlIChFVFMpIHJlcXVpcmVzDQp0aGUg YWJpbGl0eSB0bzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBwcm92aWRlIGFuIGVsZXZhdGVkIHBy b2JhYmlsaXR5IG9mIHNlc3Npb24gZXN0YWJsaXNobWVudA0KdG8gYW48YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgYXV0aG9yaXplZCB1c2VyIGluIHRpbWVzIG9mIG5ldHdvcmsgY29uZ2VzdGlvbiAo dHlwaWNhbGx5LA0KZHVyaW5nIGE8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgY3Jpc2lzKS4gV2hl biBzdXBwb3J0ZWQgb3ZlciB0aGUgSW50ZXJuZXQgUHJvdG9jb2wgc3VpdGUsDQp0aGlzIG1heSBi ZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBmYWNpbGl0YXRlZCB0aHJvdWdoIGEgbmV0d29yayBs YXllciBhZG1pc3Npb24gY29udHJvbA0Kc29sdXRpb24sIHdoaWNoPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7IHN1cHBvcnRzIHByaW9yaXRpemVkIGFjY2VzcyB0byByZXNvdXJjZXMgKGUuZy4sIGJh bmR3aWR0aCkuDQpUaGVzZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyByZXNvdXJjZXMgbWF5IGJl IGV4cGxpY2l0bHkgc2V0IGFzaWRlIGZvciBlbWVyZ2VuY3kNCnNlcnZpY2VzLCBvciB0aGV5PGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7IG1heSBiZSBzaGFyZWQgd2l0aCBvdGhlciBzZXNzaW9ucy48 YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgc3BlY2lmaWVz IFJTVlAgZXh0ZW5zaW9ucyB0aGF0IGNhbiBiZSB1c2VkDQp0byBzdXBwb3J0PGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7IHN1Y2ggYW4gYWRtaXNzaW9uIHByaW9yaXR5IGNhcGFiaWxpdHkgYXQgdGhl IG5ldHdvcmsNCmxheWVyLiBOb3RlIHRoYXQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgdGhlc2Ug ZXh0ZW5zaW9ucyByZXByZXNlbnQgb25lIHBvc3NpYmxlIHNvbHV0aW9uIGNvbXBvbmVudA0KaW48 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgc2F0aXNmeWluZyBFVFMgcmVxdWlyZW1lbnRzLiBPdGhl ciBzb2x1dGlvbiBjb21wb25lbnRzLA0Kb3Igb3RoZXI8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg c29sdXRpb25zLCBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC48YnI+DQom Z3Q7IDxicj4NCiZndDsgTlNJUyBXb3JraW5nIEdyb3VwPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdv cmsgSW4gUHJvZ3Jlc3M6IGRyYWZ0LWlldGYtbnNpcy1xb3MtbnNscC0xNC50eHQ8YnI+DQomZ3Q7 IDxicj4NCiZndDsgVGl0bGU6PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IE5TTFAgZm9yIFF1YWxp dHktb2YtU2VydmljZSBTaWduYWxpbmc8YnI+DQomZ3Q7IDxicj4NCiZndDsgQWJzdHJhY3Q6PGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7IFRoaXMgc3BlY2lmaWNhdGlvbiBkZXNjcmliZXMgdGhlIE5T SVMgU2lnbmFsaW5nIExheWVyDQpQcm90b2NvbDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAoTlNM UCkgZm9yIHNpZ25hbGluZyBRb1MgcmVzZXJ2YXRpb25zIGluIHRoZSBJbnRlcm5ldC4NCiZuYnNw O0l0IGlzIGluPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IGFjY29yZGFuY2Ugd2l0aCB0aGUgZnJh bWV3b3JrIGFuZCByZXF1aXJlbWVudHMgZGV2ZWxvcGVkDQppbiBOU0lTLjxicj4NCiZndDsgJm5i c3A7ICZuYnNwOyBUb2dldGhlciB3aXRoIEdJU1QsIGl0IHByb3ZpZGVzIGZ1bmN0aW9uYWxpdHkg c2ltaWxhcg0KdG8gUlNWUCBhbmQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgZXh0ZW5kcyBpdC4g Jm5ic3A7VGhlIFFvUyBOU0xQIGlzIGluZGVwZW5kZW50IG9mIHRoZQ0KdW5kZXJseWluZyBRb1M8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgc3BlY2lmaWNhdGlvbiBvciBhcmNoaXRlY3R1cmUgYW5k IHByb3ZpZGVzIHN1cHBvcnQgZm9yDQpkaWZmZXJlbnQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg cmVzZXJ2YXRpb24gbW9kZWxzLiBJdCBpcyBzaW1wbGlmaWVkIGJ5IHRoZSBlbGltaW5hdGlvbg0K b2Ygc3VwcG9ydDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBmb3IgbXVsdGljYXN0IGZsb3dzLiBU aGlzIHNwZWNpZmljYXRpb24gZXhwbGFpbnMgdGhlDQpvdmVyYWxsPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7IHByb3RvY29sIGFwcHJvYWNoLCBkZXNpZ24gZGVjaXNpb25zIG1hZGUgYW5kIHByb3Zp ZGVzDQpleGFtcGxlcy4gJm5ic3A7SXQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgc3BlY2lmaWVz IG9iamVjdCwgbWVzc2FnZSAmbmJzcDtmb3JtYXRzIGFuZCBwcm9jZXNzaW5nDQpydWxlcy48YnI+ DQomZ3Q7IDxicj4NCiZndDsgLS0gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE1hZ251cyBXZXN0ZXJs dW5kPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElFVEYgVHJhbnNwb3J0IEFyZWEgRGlyZWN0b3IgJmFt cDsgVFNWV0cgQ2hhaXI8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IE11bHRpbWVk aWEgVGVjaG5vbG9naWVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFZNL008YnI+DQomZ3Q7IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08YnI+DQomZ3Q7IEVyaWNzc29uIEFCICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8DQpQaG9uZSArNDYgOCA0MDQ4Mjg3PGJy Pg0KJmd0OyBUb3JzaGFtc2dhdGFuIDIzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgfCBGYXggJm5ic3A7ICs0Ng0KOCA3NTc1NTUwPGJyPg0KJmd0OyBTLTE2NCA4MCBTdG9ja2hv bG0sIFN3ZWRlbiB8IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPGJyPg0K Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCjwvdHQ+PC9mb250 Pg0K --=_alternative 0055890785257329_=-- --===============0715605749== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0715605749==-- From sip-bounces@ietf.org Tue Jul 31 11:38:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFtnf-0008BG-5k; Tue, 31 Jul 2007 11:38:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFtnd-0008Ar-JB for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 11:38:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFtnd-0008Aj-8y for sip@ietf.org; Tue, 31 Jul 2007 11:38:17 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFtnc-0006CN-Ty for sip@ietf.org; Tue, 31 Jul 2007 11:38:17 -0400 Received: from 206-176-144-212.waymark.net ([206.176.144.212]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1IFtnX-0000fm-1D; Tue, 31 Jul 2007 10:38:11 -0500 In-Reply-To: <024301c7d313$348e5150$7c6c460a@china.huawei.com> References: <024301c7d313$348e5150$7c6c460a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3F408003-7BD5-455E-9633-54D2914DD9F8@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: Content-Disposition in multiparts WAS (Re: [Sip] Draft slides forbody (MIME) handling) Date: Tue, 31 Jul 2007 10:37:50 -0500 To: Qian Sun X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 'sip' , 'Paul Kyzivat' , 'Gonzalo Camarillo' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jul 30, 2007, at 8:36 PM, Qian Sun wrote: > Hi, Dean > > Sorry for late response. Do you mean "advertisement" content always > is needed to 'render'? So a single content disposition > "advertisement" is enough. Well, I'm wondering if advertisements have any other need than "render". If not, why not just use "render"? If we define an "advertisement" content disposition, we might as well call it "ignore", in which case there's hardly any point in sending it to start with, right? Although I must admit I'm intrigued by the prospect of getting advertisers to self-label stuff so that it can be discarded as efficiently as possible. > In addition, some content body (e.g. Geolocation or advertisement) > may be inserted or modified by intermediary. Could we specify a > common way for indicating the source of inserted content body? For > example, define a new MIME header: Content-Insertedby. A B2BUA may > insert a content body including AD like this: > > Content-Type: text/plain > Content-Disposition: advertisement > Content-Insertedby: AD-Agent I'm sure there has been discussion of this in geopriv, but I don't recall the details. I suspect there have been concerns about mismatches between the "source" and the "information". -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 12:04:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFuD7-0002Wt-IL; Tue, 31 Jul 2007 12:04:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFuD5-0002TP-QM for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 12:04:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFuD5-0002Q5-BL for sip@ietf.org; Tue, 31 Jul 2007 12:04:35 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFuD4-00079S-NG for sip@ietf.org; Tue, 31 Jul 2007 12:04:35 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l6VG4Pp12273; Tue, 31 Jul 2007 09:04:25 -0700 In-Reply-To: <46AA1FAA.3000204@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <20070727153727.A4BDD33C1A@delta.rtfm.com> <46AA138D.6030001@cisco.com> <46AA1FAA.3000204@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <325E76F4-3A53-4101-BBDB-D2131FA4BB1D@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Tue, 31 Jul 2007 09:04:24 -0700 To: Michael Thomas X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Rohan Mahy , IETF SIP List , Francois Audet , Jon.Peterson@neustar.com, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Michael, The semantics of a request to a sip: resource are different from a request to a sips: resource. If there are no Contacts registered against a sips: resource, then the correct thing for the proxy to do is to send a 480. This is the same thing the proxy would do if there were no Contacts registered against a sip: resource. We are not talking about a ciphersuite downgrade here. Providing an error response code that encourages a client to downgrade is just plain irresponsible. thanks, -rohan On Jul 27, 2007, at 9:39 AM, Michael Thomas wrote: > Rohan Mahy wrote: >> Michael, >> >> At issue here is what the default implementor is likely to do. >> With a new 4xx, the misguided but well-meaning implementor is >> likely to try to "helpfully" "repair" the error without thinking >> about or understanding the security context. >> >> Using a Warning code raises the bar significantly, but still >> allows automata to at least log what happened. > As I said, a receiver is completely at liberty to prevent the > downgrade by not > accepting the downgraded request. Problem solved by those who > care. On > the other hand I think it's pretty presumptuous that we "know" in > all cases > whether it's wrong to "repair" the error. Paul brought up several > examples. > Also: if the receiver allows non-SIPS requests why shouldn't you > infer that > they want you to "repair" the request? It sure seems like this is a > misguided > attempt at forcing ineffectual nannyware which is a pointless > enterprise for > IETF protocols. > > Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 12:15:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFuNz-000077-AC; Tue, 31 Jul 2007 12:15:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFuNw-0008Tf-Te for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 12:15:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFuNv-0008Pn-GB for sip@ietf.org; Tue, 31 Jul 2007 12:15:47 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFuNu-0005hT-3g for sip@ietf.org; Tue, 31 Jul 2007 12:15:47 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6VGFVO17609; Tue, 31 Jul 2007 16:15:31 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: Warn-Codes and draft-ietf-sip-sips Date: Tue, 31 Jul 2007 11:15:26 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1174803F@zrc2hxm0.corp.nortel.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: Warn-Codes and draft-ietf-sip-sips Thread-Index: AcfThSrG35+HRubRQ7GWG1ad9RdWxAACMErg References: <1ECE0EB50388174790F9694F77522CCF1174794F@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Rohan Mahy" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Cullen Jennings , IETF SIP List , drage@alcatel-lucent.com, Robert Sparks , Jon.Peterson@neustar.com, Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks. I'm OK with this. =20 > -----Original Message----- > From: Rohan Mahy [mailto:rohan@ekabal.com]=20 > Sent: Tuesday, July 31, 2007 08:12 > To: Audet, Francois (SC100:3055) > Cc: Cullen Jennings; Rohan Mahy; IETF SIP List;=20 > drage@alcatel-lucent.com; Robert Sparks;=20 > Jon.Peterson@neustar.com; Dean Willis > Subject: [Sip] Re: Warn-Codes and draft-ietf-sip-sips >=20 > Fran=E7ois, >=20 > I think the IANA paragraph you described is too restrictive. =20 > The text in RFC3261 section 20.43 seems perfectly fine with=20 > registering non-SDP errors. I would allocate warn-code 380=20 > "No SIPS contacts registered". >=20 > thanks, > -rohan >=20 > On Jul 30, 2007, at 3:23 PM, Francois Audet wrote: >=20 > > Now that we have everybody exited about the prospect of using a=20 > > Warn-Code for "SIPS Not Allowed" and "SIP Required" with=20 > Response 480,=20 > > instead of using new response codes, here is a quote from 27.2/RFC=20 > > 3261. > > > > Warning codes provide information supplemental to the=20 > status code=20 > > in > > SIP response messages when the failure of the transaction results > > from a Session Description Protocol (SDP) (RFC 2327 [1]) problem. > > > > My reading of this is that Warn-Codes are ONLY usable for=20 > SDP errors. > > > > Doesn't this disqualify the idea of using a Warn-Code for=20 > SIP/SIPS URI=20 > > problems?????? > > > > If so, aren't we back to 418/419, or 418+New header (Allow/=20 > Require),=20 > > or > > 480+Response text? >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 12:20:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFuSd-0000pM-NZ; Tue, 31 Jul 2007 12:20:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFuSb-0000n7-TD for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 12:20:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFuSb-0000mY-GV for sip@ietf.org; Tue, 31 Jul 2007 12:20:37 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFuSa-0006Iu-2h for sip@ietf.org; Tue, 31 Jul 2007 12:20:37 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l6VGKCNW018638; Tue, 31 Jul 2007 11:20:17 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 11:20:14 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 18:20:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: Warn-Codes and draft-ietf-sip-sips Date: Tue, 31 Jul 2007 18:20:11 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180014EE53B@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: Warn-Codes and draft-ietf-sip-sips Thread-Index: AcfThTbcz8uah26eTuWrRwUMqlOVqgACJ6kg References: <1ECE0EB50388174790F9694F77522CCF1174794F@zrc2hxm0.corp.nortel.com> From: "DRAGE, Keith \(Keith\)" To: "Rohan Mahy" , "Francois Audet" X-OriginalArrivalTime: 31 Jul 2007 16:20:12.0669 (UTC) FILETIME=[ABEE5AD0:01C7D38E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Cullen Jennings , IETF SIP List , Jon.Peterson@neustar.com, Robert Sparks , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org As Jame's has already remarked, we did discuss this in the context of = location-conveyance. I believe the SIP list conclusion at that point was that the RFC 3261 = text was not preventing usage, but the IANA registry text did. The Warning header registry was created by RFC 3261 in the days before = formal IANA considerations sections in RFCs. As draft-ietf-sip-sips = updates RFC 3261, it would seem to me that it is entirely appropriate = for that document to update the IANA registry for Warning headers. By = this I mean you need to update the registry definition itself, as well = as add new values to it. This is of course assuming that we decide that Warning headers are the = way to go. Regards Keith > -----Original Message----- > From: Rohan Mahy [mailto:rohan@ekabal.com]=20 > Sent: Tuesday, July 31, 2007 4:12 PM > To: Francois Audet > Cc: Cullen Jennings; Rohan Mahy; IETF SIP List; DRAGE, Keith=20 > (Keith); Robert Sparks; Jon.Peterson@neustar.com; Dean Willis > Subject: [Sip] Re: Warn-Codes and draft-ietf-sip-sips >=20 > Fran=E7ois, >=20 > I think the IANA paragraph you described is too restrictive. =20 > The text in RFC3261 section 20.43 seems perfectly fine with=20 > registering non-SDP errors. I would allocate warn-code 380=20 > "No SIPS contacts registered". >=20 > thanks, > -rohan >=20 > On Jul 30, 2007, at 3:23 PM, Francois Audet wrote: >=20 > > Now that we have everybody exited about the prospect of using a=20 > > Warn-Code for "SIPS Not Allowed" and "SIP Required" with=20 > Response 480,=20 > > instead of using new response codes, here is a quote from 27.2/RFC=20 > > 3261. > > > > Warning codes provide information supplemental to the=20 > status code=20 > > in > > SIP response messages when the failure of the transaction results > > from a Session Description Protocol (SDP) (RFC 2327 [1]) problem. > > > > My reading of this is that Warn-Codes are ONLY usable for=20 > SDP errors. > > > > Doesn't this disqualify the idea of using a Warn-Code for=20 > SIP/SIPS URI=20 > > problems?????? > > > > If so, aren't we back to 418/419, or 418+New header (Allow/=20 > Require),=20 > > or > > 480+Response text? >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 12:56:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFv1f-00040S-25; Tue, 31 Jul 2007 12:56:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFv1d-000401-PA for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 12:56:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFv1d-0003yE-DK for sip@ietf.org; Tue, 31 Jul 2007 12:56:49 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFv1c-0007Qf-3c for sip@ietf.org; Tue, 31 Jul 2007 12:56:49 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6VGui121595; Tue, 31 Jul 2007 16:56:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: Warn-Codes and draft-ietf-sip-sips Date: Tue, 31 Jul 2007 11:56:28 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF117942BB@zrc2hxm0.corp.nortel.com> In-reply-to: <5D1A7985295922448D5550C94DE29180014EE53B@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: Warn-Codes and draft-ietf-sip-sips Thread-Index: AcfThTbcz8uah26eTuWrRwUMqlOVqgACJ6kgAAB+NVA= References: <1ECE0EB50388174790F9694F77522CCF1174794F@zrc2hxm0.corp.nortel.com> <5D1A7985295922448D5550C94DE29180014EE53B@DEEXC1U01.de.lucent.com> From: "Francois Audet" To: "DRAGE, Keith (Keith)" , "Rohan Mahy" , "James M. Polk" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Looks like the Warning Codes approach is preferred. I'm glad I'm now reading = http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-08= .txt. I almost fell off my chair when I saw the following two Error codes = defined in James' draft: 3.4.12 Warning code 720 Unsupported Schema - sip desired A Warning header with the code 720 "Unsupported Schema - sip desired" means the location dereferencer cannot dereference using the location-by-reference URI schema supplied because it does not support the necessary protocol to do this. This Warning code means the location recipient can dereference the target's location using a sip-URI schema. There can be more than one Warning code in a Warning header, indicated in this context the recipient can dereference using each schema protocol included in the Warning header. A typical reaction to receiving this warning code would be for the location sender to send a URI with the sip schema. Recommended warn-text: unsupported schema An example usage in a SIP 424 response: Warning: 720 alice.example.com "unsupported schema - sip desired" 3.4.12 Warning code 721 Unsupported Schema - sips desired A Warning header with the code 721 "Unsupported Schema - sips desired" means the location dereferencer cannot dereference using the location-by-reference URI schema supplied because it does not support the necessary protocol to do this. This Warning code means the location recipient can dereference the target's location using a sips-URI schema. There can be more than one Warning code in a Warning header, indicated in this context the recipient can dereference using each schema protocol included in the Warning header. Recommended warn-text: unsupported schema An example usage in a SIP 424 response: Warning: 721 alice.example.com "unsupported schema - sips desired" As James pointed out, in -07, those were Warning headers, now they are Geoprive headers. If we are going to use 2 new Warning Headers in draft-ietf-sip-sips (say 380 and 381), wouldn't it make more sense if = draft-ietf-sip-location-conveyance-09 use those values (with 424) instead of 720/721? It seems to me that error 720-723 would be potentially applicable to = more than just Location. 700-711 however are specific to location, and should = remain as defined. Any toughts? > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: Tuesday, July 31, 2007 09:20 > To: Rohan Mahy; Audet, Francois (SC100:3055) > Cc: Cullen Jennings; IETF SIP List; Jon.Peterson@neustar.com;=20 > Robert Sparks; Dean Willis > Subject: RE: [Sip] Re: Warn-Codes and draft-ietf-sip-sips >=20 > As Jame's has already remarked, we did discuss this in the=20 > context of location-conveyance. >=20 > I believe the SIP list conclusion at that point was that the=20 > RFC 3261 text was not preventing usage, but the IANA registry=20 > text did. >=20 > The Warning header registry was created by RFC 3261 in the=20 > days before formal IANA considerations sections in RFCs. As=20 > draft-ietf-sip-sips updates RFC 3261, it would seem to me=20 > that it is entirely appropriate for that document to update=20 > the IANA registry for Warning headers. By this I mean you=20 > need to update the registry definition itself, as well as add=20 > new values to it. >=20 > This is of course assuming that we decide that Warning=20 > headers are the way to go. >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: Rohan Mahy [mailto:rohan@ekabal.com] > > Sent: Tuesday, July 31, 2007 4:12 PM > > To: Francois Audet > > Cc: Cullen Jennings; Rohan Mahy; IETF SIP List; DRAGE,=20 > Keith (Keith);=20 > > Robert Sparks; Jon.Peterson@neustar.com; Dean Willis > > Subject: [Sip] Re: Warn-Codes and draft-ietf-sip-sips > >=20 > > Fran=E7ois, > >=20 > > I think the IANA paragraph you described is too restrictive. =20 > > The text in RFC3261 section 20.43 seems perfectly fine with=20 > > registering non-SDP errors. I would allocate warn-code 380=20 > "No SIPS=20 > > contacts registered". > >=20 > > thanks, > > -rohan > >=20 > > On Jul 30, 2007, at 3:23 PM, Francois Audet wrote: > >=20 > > > Now that we have everybody exited about the prospect of using a=20 > > > Warn-Code for "SIPS Not Allowed" and "SIP Required" with > > Response 480, > > > instead of using new response codes, here is a quote from=20 > 27.2/RFC=20 > > > 3261. > > > > > > Warning codes provide information supplemental to the > > status code > > > in > > > SIP response messages when the failure of the=20 > transaction results > > > from a Session Description Protocol (SDP) (RFC 2327=20 > [1]) problem. > > > > > > My reading of this is that Warn-Codes are ONLY usable for > > SDP errors. > > > > > > Doesn't this disqualify the idea of using a Warn-Code for > > SIP/SIPS URI > > > problems?????? > > > > > > If so, aren't we back to 418/419, or 418+New header (Allow/ > > Require), > > > or > > > 480+Response text? > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 13:44:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFvl5-00021Z-Ji; Tue, 31 Jul 2007 13:43:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFvl3-00021O-PS for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 13:43:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFvl3-00021G-CF for sip@ietf.org; Tue, 31 Jul 2007 13:43:45 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFvl2-00027C-BO for sip@ietf.org; Tue, 31 Jul 2007 13:43:45 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 31 Jul 2007 10:43:44 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAAsRr0arR7PE/2dsb2JhbAA X-IronPort-AV: i="4.19,204,1183359600"; d="scan'208"; a="508888698:sNHT57005112" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6VHhhKV022807; Tue, 31 Jul 2007 10:43:43 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6VHhXSv027787; Tue, 31 Jul 2007 17:43:38 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 10:43:38 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.90.33]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 10:43:37 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 31 Jul 2007 12:43:36 -0500 To: "Francois Audet" , "Alan Hawrylyshen" , "Kyzivat Paul" , "Mahy Rohan" From: "James M. Polk" Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF11747CDA@zrc2hxm0.corp.nor tel.com> References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <46AA09F1.6010401@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E21C3@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF11747126@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF11747CDA@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 31 Jul 2007 17:43:37.0816 (UTC) FILETIME=[533B2D80:01C7D39A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6329; t=1185903823; x=1186767823; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Sip]=20draft-ietf-sip-sips-05=3A=20480=20vs.=20418 |Sender:=20; bh=dXQCNoW2UT7uyVAIE5o47KAhCBh9djiJhInFmIthpjE=; b=eUBJDfAizzdZlk1Q108bfbNBpP6lXNFQtY8qV29XEiWzqoXJV7zW6+2zVKrUI1mO66D3niCC /mywhick8cV/EAsif5WP9aDAFJSKpEIN1P1d/z2MPUeulm8Y5qqzKNA3; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: IETF SIP List , Jon.Peterson@neustar.com, Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois I don't believe it is a glitch so much as it is an initial range, which can be expanded with a PS RFC, especially one with an update to 3261 (which you are doing). I was using 7XX (assigning 701 through 739) - though I pulled the Warning codes from the conveyance draft, therefore I am no longer using these codes (since I created a new SIP header (Geolocation-Error) to accomplish the same task as the Warning codes plus add new information with header parameters for the new header). My point was that it is possible to go outside the 3XX range for SIP... you just have to define it. BTW - I am ok with the 480+Warning Code, but am cautious about the Warning header (with its 'why' information) being stripped along the way back to the UAC. Ultimately, do we want zero communications between this UAC and UAS (because the UAC can always get a 480 without additional information letting it know what was really wrong with the request), or do we want to send the UAC something it can understand about this scenario? At 08:49 AM 7/31/2007, Francois Audet wrote: >Ok, that's fine with me. It's just a glitch in 3261 then. I'd rather we >stick with the Warn-Codes approach. > >Did you assign a purpose for 7XX-series warn-codes yet? I'm wondering >what >range should be used for this purpose. > >James, I didn't see your codes on IANA's web site. What values are you >using? >I don't want to overlap. > > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Monday, July 30, 2007 21:44 > > To: Audet, Francois (SC100:3055); Alan Hawrylyshen; Kyzivat > > Paul; Mahy Rohan > > Cc: IETF SIP List; Jon.Peterson@neustar.com > > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > > > At 10:54 AM 7/30/2007, Francois Audet wrote: > > >RFC 3261, p. 181: > > > > > > "The first digit of warning codes beginning with "3" > > >indicates warnings > > > specific to SIP." > > > > > >Then it explains within the 3XX space, how they are used. > > > > btw -- for location-conveyance-07, I created 15 new Warning codes (#s > > 701 through 712, then 720, 721, and 722). All this at the > > suggestion of Henning (who knows something about 3261 text... ;-) > > > > btw II - I have since replaced the Warning header indication > > with a new Geolocation-Error header, but this was so I could > > stuff more into the new header than the Warning header would allow. > > > > In all this, I did not get one person claiming Warning codes > > were limited to 3XX. Henning merely said the "first batch of > > codes were in the 300s, and that there was nothing limiting a > > new ID from defining new codes in any other number range"... > > > > > > > > -----Original Message----- > > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > > Sent: Saturday, July 28, 2007 18:25 > > > > To: Audet, Francois (SC100:3055); Alan Hawrylyshen; Kyzivat Paul; > > > > Mahy Rohan > > > > Cc: IETF SIP List; Jon.Peterson@neustar.com > > > > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > > > > > > > A 399 Miscellaneous? That doesn't make sense... > > > > > > > > Warning codes are not limited to 3XX, so if a new Warning code is > > > > what Rohan wants to convey more information in the > > response (which I > > > > believe should be done one way or another) > > > > - it can be almost any value other than 300-379 or 399 IMO. > > > > > > > > At 10:32 AM 7/27/2007, Francois Audet wrote: > > > > >On the Warning header... > > > > > > > > > >Values 300-379 are reserved for SDP-related stuff. > > > > > > > > > >Values 380-389 are unassiged (but there is no text on it). > > > > > > > > > >Values 390-398 are unassigned (but don't fall into the > > SDP related > > > > >stuff. > > > > > > > > > >399 means Miscellaneous and the text can be provided to the user. > > > > >It further says that Automata MUST NOT take action based on this. > > > > > > > > > >Rohan, are you advocating using 399, or defining a new code from > > > > >the > > > > >390-398 space? > > > > > > > > > > > -----Original Message----- > > > > > > From: Alan Hawrylyshen [mailto:a.hawrylyshen@gmail.com] > > > > On Behalf Of > > > > > > Alan Hawrylyshen > > > > > > Sent: Friday, July 27, 2007 08:27 > > > > > > To: Kyzivat Paul; Mahy Rohan > > > > > > Cc: Audet, Francois (SC100:3055); IETF SIP List; > > > > > > Jon.Peterson@neustar.com > > > > > > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > > > > > > > > > > > > > > > > > On 27-Jul-2007, at 10:06 , Paul Kyzivat wrote: > > > > > > > > > > > > > I understand that if the user entered a sips URI then it > > > > > > should be the > > > > > > > user that must decide to downgrade. But if the user didn't > > > > > > > know whether to use sip or sips in the first place, > > and the UA > > > > > > decides to > > > > > > > try sips first then I see no problem in the UA > > having a policy > > > > > > > that causes it to downgrade. > > > > > > > > > > > > I was under the impression (based on meeting > > discussion) that : > > > > > > 1 - the downgrade was undesirable because it reveals > > > > > > (possibly) information about the targeted party in the clear, > > > > > > and; > > > > > > 2 - The 480 with a Warning header was an option to provide > > > > > > automata- friendly indication of the failure reason. > > > > > > > > > > > > Alan Hawrylyshen > > > > > > > > > > > > a l a n a t p o l y p h a s e d o t c a > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > >This list is for NEW development of the core SIP Protocol Use > > > > >sip-implementors@cs.columbia.edu for questions on > > current sip Use > > > > >sipping@ietf.org for new developments on the application of sip > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 13:51:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFvsm-0000Zc-J3; Tue, 31 Jul 2007 13:51:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFvsk-0000ZI-IZ for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 13:51:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFvsk-0000ZA-8t for sip@ietf.org; Tue, 31 Jul 2007 13:51:42 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFvsi-0000Uo-Sr for sip@ietf.org; Tue, 31 Jul 2007 13:51:42 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6VHpX112250; Tue, 31 Jul 2007 17:51:33 GMT 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 Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Tue, 31 Jul 2007 12:51:17 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF117943F5@zrc2hxm0.corp.nortel.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfTmlpj9+c57XElTlqPhgTWyYH8awAAOZwA References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <46AA09F1.6010401@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E21C3@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF11747126@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF11747CDA@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "James M. Polk" X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > Ultimately, do we want zero communications between this UAC=20 > and UAS (because the UAC can always get a 480 without=20 > additional information letting it know what was really wrong=20 > with the request), or do we want to send the UAC something it=20 > can understand about this scenario? Yes, we want the default to be a "hard failure" that looks like if the target was not corrently registered. That's the reasoning behind the 480. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 17:25:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFzDP-0006Dy-Rq; Tue, 31 Jul 2007 17:25:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFzDO-0006DF-Du for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 17:25:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFzDO-0006Cw-46 for sip@ietf.org; Tue, 31 Jul 2007 17:25:14 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFzDM-0005zq-Tw for sip@ietf.org; Tue, 31 Jul 2007 17:25:14 -0400 Received: from hkaplan [65.14.229.26] by acmepacket.com with ESMTP (SMTPD-9.10) id A8B40518; Tue, 31 Jul 2007 17:25:08 -0400 From: "Hadriel Kaplan" To: "'Rohan Mahy'" , "'Michael Thomas'" References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com><20070727153727.A4BDD33C1A@delta.rtfm.com><46AA138D.6030001@cisco.com><46AA1FAA.3000204@cisco.com> <325E76F4-3A53-4101-BBDB-D2131FA4BB1D@ekabal.com> Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Tue, 31 Jul 2007 17:25:08 -0400 Message-ID: <030401c7d3b9$457a9360$800101df@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcfTjJOvyvyREiMrQ9+74ysSMh8lpQAKWj6A In-Reply-To: <325E76F4-3A53-4101-BBDB-D2131FA4BB1D@ekabal.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 1.1 (+) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: 'IETF SIP List' , 'Francois Audet' , Jon.Peterson@neustar.com, 'Paul Kyzivat' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yeah but a 480 implies the resource is not available, whereas in reality the resource *is* available using a different scheme. I guess one question is if the sips scheme literally means the UAS is a different "resource". If so, then registering a sips contact only should not implicitly make the UAS available for routing plain sip. The draft currently says they represent the *same* resource. I'm not convinced by the downgrade argument. The far-end can just as easily send a 3xx redirecting the UAC to the sip contact. Per this new draft the proxies must not recurse on that, and the UAC should inform the user before doing so. But I think a new 4xx response code would be much more likely to make that a reality, as any vendor implementing support for recursing on a 418 would have read the draft and seen where it says "inform the user". If they didn't read the draft, they'd fail the request since they got an unknown 4xx response. (compare that to a 3xx, which is known/usable without reading this draft) Am I missing the gist of the concern? -hadriel > -----Original Message----- > From: Rohan Mahy [mailto:rohan@ekabal.com] > Sent: Tuesday, July 31, 2007 12:04 PM > To: Michael Thomas > Cc: Rohan Mahy; IETF SIP List; Francois Audet; Jon.Peterson@neustar.com; > Paul Kyzivat > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > > Michael, > > The semantics of a request to a sip: resource are different from a > request to a sips: resource. If there are no Contacts registered > against a sips: resource, then the correct thing for the proxy to do > is to send a 480. This is the same thing the proxy would do if there > were no Contacts registered against a sip: resource. > > We are not talking about a ciphersuite downgrade here. Providing an > error response code that encourages a client to downgrade is just > plain irresponsible. > > thanks, > -rohan > > > On Jul 27, 2007, at 9:39 AM, Michael Thomas wrote: > > Rohan Mahy wrote: > >> Michael, > >> > >> At issue here is what the default implementor is likely to do. > >> With a new 4xx, the misguided but well-meaning implementor is > >> likely to try to "helpfully" "repair" the error without thinking > >> about or understanding the security context. > >> > >> Using a Warning code raises the bar significantly, but still > >> allows automata to at least log what happened. > > As I said, a receiver is completely at liberty to prevent the > > downgrade by not > > accepting the downgraded request. Problem solved by those who > > care. On > > the other hand I think it's pretty presumptuous that we "know" in > > all cases > > whether it's wrong to "repair" the error. Paul brought up several > > examples. > > Also: if the receiver allows non-SIPS requests why shouldn't you > > infer that > > they want you to "repair" the request? It sure seems like this is a > > misguided > > attempt at forcing ineffectual nannyware which is a pointless > > enterprise for > > IETF protocols. > > > > Mike > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 17:51:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFzcP-0007Si-5J; Tue, 31 Jul 2007 17:51:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFzcN-0007PD-L4 for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 17:51:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFzcN-0007O1-99 for sip@ietf.org; Tue, 31 Jul 2007 17:51:03 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFzcM-0008AB-Lh for sip@ietf.org; Tue, 31 Jul 2007 17:51:03 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6VLox106852; Tue, 31 Jul 2007 21:50:59 GMT 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 Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Tue, 31 Jul 2007 16:50:39 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1179493C@zrc2hxm0.corp.nortel.com> In-reply-to: <030401c7d3b9$457a9360$800101df@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfTjJOvyvyREiMrQ9+74ysSMh8lpQAKWj6AAAF/ZaA= References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com><20070727153727.A4BDD33C1A@delta.rtfm.com><46AA138D.6030001@cisco.com><46AA1FAA.3000204@cisco.com> <325E76F4-3A53-4101-BBDB-D2131FA4BB1D@ekabal.com> <030401c7d3b9$457a9360$800101df@acmepacket.com> From: "Francois Audet" To: "Hadriel Kaplan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org 480 means that the user identified by the Request-URI is recognized, but there is currently no valid forwarding location for that user. In this case, no SIPS contacts. What many people are missing in the 480 vs. 418 argument is the following: - Existing implementations will treat new 4XX error codes as 400, which basically means "the protocol message is broken". - Existing implements will treat 480 with new Warning just like 480 witn no warning, i.e., as "Temporarily unavailable". There is a huge difference between the 2. 400 will lead you to believe that there is something wrong with the equipment (i.e., you may file a complaint with the manufacturer). Very bad. 480 just means the other end is not available at that address. Good.=20 Everybody is happy. > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Tuesday, July 31, 2007 14:25 > To: 'Rohan Mahy'; 'Michael Thomas' > Cc: 'IETF SIP List'; Audet, Francois (SC100:3055);=20 > Jon.Peterson@neustar.com; 'Paul Kyzivat' > Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >=20 > Yeah but a 480 implies the resource is not available, whereas=20 > in reality the resource *is* available using a different=20 > scheme. I guess one question is if the sips scheme literally=20 > means the UAS is a different "resource". If so, then=20 > registering a sips contact only should not implicitly make=20 > the UAS available for routing plain sip. The draft currently=20 > says they represent the *same* resource. >=20 > I'm not convinced by the downgrade argument. The far-end can=20 > just as easily send a 3xx redirecting the UAC to the sip=20 > contact. Per this new draft the proxies must not recurse on=20 > that, and the UAC should inform the user before doing so. =20 > But I think a new 4xx response code would be much more likely=20 > to make that a reality, as any vendor implementing support=20 > for recursing on a > 418 would have read the draft and seen where it says "inform=20 > the user". If they didn't read the draft, they'd fail the=20 > request since they got an unknown 4xx response. (compare that=20 > to a 3xx, which is known/usable without reading this draft) =20 > Am I missing the gist of the concern? >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: Rohan Mahy [mailto:rohan@ekabal.com] > > Sent: Tuesday, July 31, 2007 12:04 PM > > To: Michael Thomas > > Cc: Rohan Mahy; IETF SIP List; Francois Audet;=20 > > Jon.Peterson@neustar.com; Paul Kyzivat > > Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 > >=20 > > Michael, > >=20 > > The semantics of a request to a sip: resource are different from a=20 > > request to a sips: resource. If there are no Contacts registered=20 > > against a sips: resource, then the correct thing for the=20 > proxy to do=20 > > is to send a 480. This is the same thing the proxy would=20 > do if there=20 > > were no Contacts registered against a sip: resource. > >=20 > > We are not talking about a ciphersuite downgrade here. Providing an=20 > > error response code that encourages a client to downgrade is just=20 > > plain irresponsible. > >=20 > > thanks, > > -rohan > >=20 > >=20 > > On Jul 27, 2007, at 9:39 AM, Michael Thomas wrote: > > > Rohan Mahy wrote: > > >> Michael, > > >> > > >> At issue here is what the default implementor is likely to do. > > >> With a new 4xx, the misguided but well-meaning implementor is=20 > > >> likely to try to "helpfully" "repair" the error without thinking=20 > > >> about or understanding the security context. > > >> > > >> Using a Warning code raises the bar significantly, but=20 > still allows=20 > > >> automata to at least log what happened. > > > As I said, a receiver is completely at liberty to prevent the=20 > > > downgrade by not accepting the downgraded request. =20 > Problem solved=20 > > > by those who care. On the other hand I think it's pretty=20 > > > presumptuous that we "know" in all cases whether it's wrong to=20 > > > "repair" the error. Paul brought up several examples. > > > Also: if the receiver allows non-SIPS requests why shouldn't you=20 > > > infer that they want you to "repair" the request? It sure=20 > seems like=20 > > > this is a misguided attempt at forcing ineffectual=20 > nannyware which=20 > > > is a pointless enterprise for IETF protocols. > > > > > > Mike > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 17:58:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFzjN-0004I2-0e; Tue, 31 Jul 2007 17:58:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IFzjK-0004D5-IH for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 17:58:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFzjK-0004Be-7g for sip@ietf.org; Tue, 31 Jul 2007 17:58:14 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFzjJ-0008JH-Uj for sip@ietf.org; Tue, 31 Jul 2007 17:58:14 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6VLwBO00077 for ; Tue, 31 Jul 2007 21:58:11 GMT 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 Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Tue, 31 Jul 2007 16:58:10 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1179495F@zrc2hxm0.corp.nortel.com> In-reply-to: <030401c7d3b9$457a9360$800101df@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Thread-Index: AcfTjJOvyvyREiMrQ9+74ysSMh8lpQAKWj6AAAG4/1A= References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com><20070727153727.A4BDD33C1A@delta.rtfm.com><46AA138D.6030001@cisco.com><46AA1FAA.3000204@cisco.com> <325E76F4-3A53-4101-BBDB-D2131FA4BB1D@ekabal.com> <030401c7d3b9$457a9360$800101df@acmepacket.com> From: "Francois Audet" To: "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi all, It seems from the mailing list discussion that the preferred approach is to use the 480 (Temporarily Unavailable) response code, with a Warning header field. The Warning header could use one of the following 2 newly defined warn-codes: 380 SIPS Not Allowed: The UAS or proxy can process the request because the SIPS scheme is not allowed (e.g., because there are currently no registered SIPS Contacts). 381 SIPS Required: The UAS or proxy cannot process the request because the SIPS scheme is required. If you cannot live with this approach, please voice your opinion. Thanks. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 19:36:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG1Fq-0006Hs-Ms; Tue, 31 Jul 2007 19:35:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IG1Fp-0006G6-N4 for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 19:35:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG1Fp-0006FW-CB for sip@ietf.org; Tue, 31 Jul 2007 19:35:53 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IG1Fo-0002DX-HM for sip@ietf.org; Tue, 31 Jul 2007 19:35:52 -0400 Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l6VNZpBD003822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jul 2007 18:35:51 -0500 (CDT) Received: from [127.0.0.1] (volkerh.lra.lucent.com [135.244.2.6]) by umail.lucent.com (8.13.8/TPES) with ESMTP id l6VNZlG9016043; Tue, 31 Jul 2007 18:35:50 -0500 (CDT) Message-ID: <46AFC74F.40703@bell-labs.com> Date: Tue, 31 Jul 2007 19:35:43 -0400 From: Volker Hilt User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: IETF SIP List , draft-ietf-sip-session-policy-framework@tools.ietf.org Subject: [Sip] Re: WGLC Review: draft-ietf-sip-session-policy-framework-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Mary, thanks much for reviewing this document. I've fixed all the nits you have identified. Thanks much! Volker Mary Barnes wrote: > Draft: draft-ietf-sip-session-policy-framework-01 > Reviewer: Mary Barnes > Review Date: 8 June 2007 > Review Deadline: 11 June 2007 > Status: WGLC > > Summary: This draft is basically ready for publication, but has nits > that should be fixed before publication. > > Comments: > ---------- > I reviewed the diff for this document as compared to the version > I previously reviewed: > http://www.softarmor.com/sipping/process/wg-review/reviews/draft-ietf-si > pping-session-policy-framework-01-barnes.txt > > And, I believe all my previous concerns have been addressed. There are > a > few nits that I noticed that should be fixed. > > > Nits: > ------ > - Header: Need to add "Intended Status:" (i.e., category="std" in the > field) > > - Section 4.4.1: > - 2nd paragraph, 5th sentence: insert "the" between "using" and > "mechanism" in the following sentence: > "If the UAC decides to continue, it MUST use the policy server > URI to contact the policy server using the mechanism defined in > Section 4.5." > > - 2nd paragraph, 8th sentence: "resend" -> "resent" in the following > sentence: > "If no changes are required by policies or no policies have > been received, the request can be resend without any policy-induced > changes." -- Volker Hilt Bell Labs / Alcatel-Lucent phone: +1 732 888 7206 791 Holmdel-Keyport Rd email: volkerh@bell-labs.com Holmdel, NJ 07733 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 19:36:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG1G5-000708-GY; Tue, 31 Jul 2007 19:36:09 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IG1G3-0006m9-H6 for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 19:36:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG1G3-0006kL-64 for sip@ietf.org; Tue, 31 Jul 2007 19:36:07 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IG1G1-0000cc-MS for sip@ietf.org; Tue, 31 Jul 2007 19:36:07 -0400 Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l6VNa2IR003891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jul 2007 18:36:02 -0500 (CDT) Received: from [127.0.0.1] (volkerh.lra.lucent.com [135.244.2.6]) by umail.lucent.com (8.13.8/TPES) with ESMTP id l6VNZxqu016070; Tue, 31 Jul 2007 18:36:02 -0500 (CDT) Message-ID: <46AFC75C.9090503@bell-labs.com> Date: Tue, 31 Jul 2007 19:35:56 -0400 From: Volker Hilt User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Even, Roni" References: <144ED8561CE90C41A3E5908EDECE315C0495C0AD@IsrExch01.israel.polycom.com> In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C0495C0AD@IsrExch01.israel.polycom.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.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: sip@ietf.org, sip-chairs@tools.ietf.org Subject: [Sip] Re: Review of draft-ietf-sip-session-policy-framework-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Roni, thanks much for reviewing this document. Comments inline. > 1. The draft explains describes two mechanisms the session > independent and the session dependent policies. I did not see what > the relationship between them if any is. I think that at least the > draft should say that they can be implemented independently if there > are no other recommendations. > I've added two sentences to the end of the introduction clarifying this. If also added a sentence to the end of the Session-independent policy section clarifying what to do when both mechanisms are used. > 2. Section 3.2 describes how a UA discovers the policy servers for > session independent policies based on the configuration framework > ua-profile. > > "ua-profile" event package [4] provides a mechanism to discover > policy servers in the local network and the home domain. The "local- > network" profile-type enables a UA to discover a policy server in the > local domain. The "user" profile type enables the discovery of a > policy server in the home domain. A UA compliant to this > specification SHOULD attempt to discover and subscribe to the policy > servers in these two domains" > > The configuration framework does not specify the profile data which > is out of scope. The profile type is not the profile data itself. The profile type effectively defines how the UA subscribes to the policy server in a given domain (e.g. in the local or home domain). > So what is the meaning of this section - is this one way to find the > policy server Yes. > or do you suggest that if you want to have session > independent policies you should have the policy servers defined in > the profile data but then how does a UA identify it in the profile > data, is it by name? > No. The idea is that the UA uses the procedures defined in the config framework to construct the URI of these servers. > I think this needs more clarification. > I've revised the above paragraph to make this more clear. > 3. In section 4.2 > " Endpoints set up a separate policy channel to each policy > server and can specifically decide which information they want to > disclose to which policy server" > How does this work with the trust model between the UA and the proxy. > The UA claimed that it got the policy from the proxy but from this > sentence you can assume that the UA got the policy only to what it > asked. I think that the UA need to include in document sent to the > proxy all the information it can map from SDP. > True. The UA can disclose what is requested by a specific policy server (e.g. offer only or offer/answer). I'll change this sentence accordingly. > 4. In section 4.4.2 what will be the proxy behavior if it sends the > Invite with the policy server URI to an endpoint who do not support > session policy. The EP can ignore the request and respond 200 that will > not include the support for the session policy. What will the proxy do > or is it left to local implementation. > The task of the proxy is to convey the policy server URI to the UAS. The enforcement that the UAS actually uses the URI is outside the scope here and could happen in the proxy or on the network level (i.e. it is left to local implementation). Nevertheless, I think a proxy should be able to know whether the policy server URI was understood by the UAS (e.g. because it may want to do SDP modification if it was not understood). To enable this, the UAS now includes a Supported header into responses that contained a Policy-Contact header. > 5. In section 4.4.6 in the note > > " If, however, a policy server cannot respond with > a policy right away, it may return a policy that temporarily > denies the session and update this policy as the actual policy > decision becomes available" > > I am not sure how does that work, what will the UA do in this case. > Will it continue with the call without any media sessions? > No, I don't think that would be terribly useful. If the policy server does not return the admittance decision right away, a UA can decide to wait, maybe informing the user with something like "All resources are current busy - Retrying". Alternatively, it could terminate the call attempt (maybe after a short time). > > In section 4.4.3 third line should be field and not filed > Fixed. Thanks much! Volker _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 20:01:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG1eV-0005pM-CB; Tue, 31 Jul 2007 20:01:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IG1eS-0005on-W5 for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 20:01:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG1eS-0005of-K6 for sip@ietf.org; Tue, 31 Jul 2007 20:01:20 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IG1eS-0002hv-68 for sip@ietf.org; Tue, 31 Jul 2007 20:01:20 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 31 Jul 2007 17:01:19 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABpqr0arR7PD/2dsb2JhbAA X-IronPort-AV: i="4.19,205,1183359600"; d="scan'208"; a="7606689:sNHT12842898" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7101Jbf013619; Tue, 31 Jul 2007 17:01:19 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l7101E50028820; Wed, 1 Aug 2007 00:01:19 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); Tue, 31 Jul 2007 17:01:17 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.90.33]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 17:01:17 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 31 Jul 2007 19:01:16 -0500 To: "Francois Audet" , "IETF SIP List" From: "James M. Polk" Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1179495F@zrc2hxm0.corp.nor tel.com> References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com> <20070727153727.A4BDD33C1A@delta.rtfm.com> <46AA138D.6030001@cisco.com> <46AA1FAA.3000204@cisco.com> <325E76F4-3A53-4101-BBDB-D2131FA4BB1D@ekabal.com> <030401c7d3b9$457a9360$800101df@acmepacket.com> <1ECE0EB50388174790F9694F77522CCF1179495F@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 01 Aug 2007 00:01:17.0676 (UTC) FILETIME=[158F6AC0:01C7D3CF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1051; t=1185926479; x=1186790479; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Sip]=20draft-ietf-sip-sips-05=3A=20480=20vs.=20418 |Sender:=20; bh=UtY0J1PZbSZDfhD4QJ2tup+Zan2eIzoPvKDCBXqoeZo=; b=gZwK0hq7CrW0brYq/E0uKERRD8DYaNv8I0SyLkkde5aK44Er7vCt4dYeXNDcVVDUCxavhP3c pWNCiSwGNkT8CO3UaeRWTBlsd65PRcI7zpf4ZpIcLEspEF5hUar94aqD; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 04:58 PM 7/31/2007, Francois Audet wrote: >Hi all, > >It seems from the mailing list discussion that the preferred approach is >to >use the 480 (Temporarily Unavailable) response code, with a Warning >header field. > >The Warning header could use one of the following 2 newly defined >warn-codes: > > 380 SIPS Not Allowed: The UAS or proxy can s/can/cannot >process the request > because the SIPS scheme is not allowed (e.g., because there are > currently no registered SIPS Contacts). > > 381 SIPS Required: The UAS or proxy cannot process the request > because the SIPS scheme is required. > >If you cannot live with this approach, please voice your opinion. > >Thanks. > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jul 31 20:49:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG2P5-0001PZ-Bo; Tue, 31 Jul 2007 20:49:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IG2P4-0001PU-14 for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 20:49:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG2P3-0001PL-Nd for sip@ietf.org; Tue, 31 Jul 2007 20:49:29 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IG2P2-000279-AD for sip@ietf.org; Tue, 31 Jul 2007 20:49:29 -0400 Received: by py-out-1112.google.com with SMTP id f31so180204pyh for ; Tue, 31 Jul 2007 17:49:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=XWlP/9PRLnnbY6dj15eBuVL/uIVA9x5OB+rT/UMt9W9gBDgoKpaA2G9ZvxOZYOP30Qq05xsPvc8rJt3mqzX19qG9/Z8Dvr6E4tv5O2ITprO/zGBc8+2s/ePf7j7zuXZIUyg6bR6EF8DVCiAyZD55X3tG6jv9HSHClGORRqwJpjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=IRzBIT1qsVsJzVWogPrh96kaJn5/4yRuVJrDc44doxB6QCVaeQNJnvzGopAYfb+R6sI0fNweYzmYmN/IXQz0j76t/YalAoQ2hHurBYn4exyU1kcHg17RkMfvFP81rgJdUBprsopEpl4F5xa7Jpdgec5DpFVhO46b2Sd9zqfeI+s= Received: by 10.65.183.7 with SMTP id k7mr207083qbp.1185929367507; Tue, 31 Jul 2007 17:49:27 -0700 (PDT) Received: by 10.65.213.1 with HTTP; Tue, 31 Jul 2007 17:49:27 -0700 (PDT) Message-ID: <66cd252f0707311749m611a4c80t32f3d5b3399f077d@mail.gmail.com> Date: Wed, 1 Aug 2007 10:49:27 +1000 From: "Hisham Khartabil" To: "Francois Audet" Subject: Re: [Sip] Re: Warn-Codes and draft-ietf-sip-sips In-Reply-To: <1ECE0EB50388174790F9694F77522CCF117942BB@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 References: <1ECE0EB50388174790F9694F77522CCF1174794F@zrc2hxm0.corp.nortel.com> <5D1A7985295922448D5550C94DE29180014EE53B@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF117942BB@zrc2hxm0.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 Cc: IETF SIP List , Rohan Mahy , "James M. Polk" , "DRAGE, Keith \(Keith\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0377178305==" Errors-To: sip-bounces@ietf.org --===============0377178305== Content-Type: multipart/alternative; boundary="----=_Part_44238_32125043.1185929367443" ------=_Part_44238_32125043.1185929367443 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Yes, it makes more sense if draft-ietf-sip-location-conveyance-09 use 380 and 381 values (with 424) instead of 720/721. Hisham On 01/08/07, Francois Audet wrote: > > Looks like the Warning Codes approach is preferred. > > I'm glad I'm now reading > http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-08= .txt > . > > I almost fell off my chair when I saw the following two Error codes > defined in > James' draft: > > 3.4.12 Warning code 720 Unsupported Schema - sip desired > > > A Warning header with the code 720 "Unsupported Schema - sip > desired" means the location dereferencer cannot dereference using > the location-by-reference URI schema supplied because it does not > support the necessary protocol to do this. This Warning code means > the location recipient can dereference the target's location using a > sip-URI schema. There can be more than one Warning code in a > Warning header, indicated in this context the recipient can > dereference using each schema protocol included in the Warning > header. > > A typical reaction to receiving this warning code would be for the > location sender to send a URI with the sip schema. > > Recommended warn-text: unsupported schema > > An example usage in a SIP 424 response: > > Warning: 720 alice.example.com "unsupported schema - sip desired" > > > 3.4.12 Warning code 721 Unsupported Schema - sips desired > > > A Warning header with the code 721 "Unsupported Schema - sips > desired" means the location dereferencer cannot dereference using > the location-by-reference URI schema supplied because it does not > support the necessary protocol to do this. This Warning code means > the location recipient can dereference the target's location using a > sips-URI schema. There can be more than one Warning code in a > Warning header, indicated in this context the recipient can > dereference using each schema protocol included in the Warning > header. > > Recommended warn-text: unsupported schema > > An example usage in a SIP 424 response: > > Warning: 721 alice.example.com "unsupported schema - sips desired" > > As James pointed out, in -07, those were Warning headers, now they > are Geoprive headers. > > If we are going to use 2 new Warning Headers in draft-ietf-sip-sips (say > 380 and 381), wouldn't it make more sense if > draft-ietf-sip-location-conveyance-09 > use those values (with 424) instead of 720/721? > > It seems to me that error 720-723 would be potentially applicable to more > than just Location. 700-711 however are specific to location, and should > remain > as defined. > > Any toughts? > > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > Sent: Tuesday, July 31, 2007 09:20 > > To: Rohan Mahy; Audet, Francois (SC100:3055) > > Cc: Cullen Jennings; IETF SIP List; Jon.Peterson@neustar.com; > > Robert Sparks; Dean Willis > > Subject: RE: [Sip] Re: Warn-Codes and draft-ietf-sip-sips > > > > As Jame's has already remarked, we did discuss this in the > > context of location-conveyance. > > > > I believe the SIP list conclusion at that point was that the > > RFC 3261 text was not preventing usage, but the IANA registry > > text did. > > > > The Warning header registry was created by RFC 3261 in the > > days before formal IANA considerations sections in RFCs. As > > draft-ietf-sip-sips updates RFC 3261, it would seem to me > > that it is entirely appropriate for that document to update > > the IANA registry for Warning headers. By this I mean you > > need to update the registry definition itself, as well as add > > new values to it. > > > > This is of course assuming that we decide that Warning > > headers are the way to go. > > > > Regards > > > > Keith > > > > > -----Original Message----- > > > From: Rohan Mahy [mailto:rohan@ekabal.com] > > > Sent: Tuesday, July 31, 2007 4:12 PM > > > To: Francois Audet > > > Cc: Cullen Jennings; Rohan Mahy; IETF SIP List; DRAGE, > > Keith (Keith); > > > Robert Sparks; Jon.Peterson@neustar.com; Dean Willis > > > Subject: [Sip] Re: Warn-Codes and draft-ietf-sip-sips > > > > > > Fran=E7ois, > > > > > > I think the IANA paragraph you described is too restrictive. > > > The text in RFC3261 section 20.43 seems perfectly fine with > > > registering non-SDP errors. I would allocate warn-code 380 > > "No SIPS > > > contacts registered". > > > > > > thanks, > > > -rohan > > > > > > On Jul 30, 2007, at 3:23 PM, Francois Audet wrote: > > > > > > > Now that we have everybody exited about the prospect of using a > > > > Warn-Code for "SIPS Not Allowed" and "SIP Required" with > > > Response 480, > > > > instead of using new response codes, here is a quote from > > 27.2/RFC > > > > 3261. > > > > > > > > Warning codes provide information supplemental to the > > > status code > > > > in > > > > SIP response messages when the failure of the > > transaction results > > > > from a Session Description Protocol (SDP) (RFC 2327 > > [1]) problem. > > > > > > > > My reading of this is that Warn-Codes are ONLY usable for > > > SDP errors. > > > > > > > > Doesn't this disqualify the idea of using a Warn-Code for > > > SIP/SIPS URI > > > > problems?????? > > > > > > > > If so, aren't we back to 418/419, or 418+New header (Allow/ > > > Require), > > > > or > > > > 480+Response text? > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------=_Part_44238_32125043.1185929367443 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
        Yes, it makes more sense if draft-ietf-sip-location-conveyance-09 use = 380 and 381 values (with 424) instead of 720/721.
         
        Hisham

         
        On 01/08/07, Francois Audet <audet@nortel.co= m> wrote:
        Looks like the Warning Codes app= roach is preferred.

        I'm glad I'm now reading   http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-08.t= xt.

        I almost fell off my chair when I saw the following two Erro= r codes defined in
        James' draft:

        3.4.12 Warning code 720 Unsu= pported Schema - sip desired


          A Warning header with the code 720 "Unsupporte= d Schema - sip
          desired" means the location dereferencer= cannot dereference using
          the location-by-reference URI sche= ma supplied because it does not
          support the necessary protocol to do this.  This = Warning code means
          the location recipient can dereference th= e target's location using a
          sip-URI schema.  T= here can be more than one Warning code in a
          Warning header, indicated in this context the recipient can
        =   dereference using each schema protocol included in the Warning<= br>  header.

          A typical reaction to receiving t= his warning code would be for the
          location sender to send a URI with the sip schema.

         = ; Recommended warn-text: unsupported schema

          An exam= ple usage in a SIP 424 response:

          Warning: 720 alice.example.com "unsupported schema - sip desired"


        3.4.12 Warning= code 721 Unsupported Schema - sips desired


          A Warnin= g header with the code 721 "Unsupported Schema - sips
          d= esired" means the location dereferencer cannot dereference using
          the location-by-reference URI schema supplied because it do= es not
          support the necessary protocol to do this.  = ;This Warning code means
          the location recipient can derefere= nce the target's location using a
          sips-URI schema.  There can be more than one Warn= ing code in a
          Warning header, indicated in this context the = recipient can
          dereference using each schema protocol include= d in the Warning
          header.

          Recommended warn-text: unsupported schema

          An= example usage in a SIP 424 response:

          Warning: 721 alice.example.com "unsupported sch= ema - sips desired"

        As James pointed out, in -07, those were Warning headers, now they
        a= re Geoprive headers.

        If we are going to use 2 new Warning Headers in= draft-ietf-sip-sips (say
        380 and 381), wouldn't it make more sense = if draft-ietf-sip-location-conveyance-09
        use those values (with 424) instead of 720/721?

        It seems to me t= hat error 720-723 would be potentially applicable to more
        than just Loca= tion. 700-711 however are specific to location, and should remain
        as def= ined.

        Any toughts?

        > -----Original Message-----
        > From: D= RAGE, Keith (Keith) [mailto:dra= ge@alcatel-lucent.com]
        > Sent: Tuesday, July 31, 2007 09:20
        > To: Rohan Mahy; Audet, Francois (SC100:3055)
        > Cc: Cullen Jennin= gs; IETF SIP List; Jon.Peterson= @neustar.com;
        > Robert Sparks; Dean Willis
        > Subject: RE: [= Sip] Re: Warn-Codes and draft-ietf-sip-sips
        >
        > As Jame's has already remarked, we did discuss this in= the
        > context of location-conveyance.
        >
        > I believe the = SIP list conclusion at that point was that the
        > RFC 3261 text was no= t preventing usage, but the IANA registry
        > text did.
        >
        > The Warning header registry was created = by RFC 3261 in the
        > days before formal IANA considerations sections = in RFCs. As
        > draft-ietf-sip-sips updates RFC 3261, it would seem to = me
        > that it is entirely appropriate for that document to update
        >= ; the IANA registry for Warning headers. By this I mean you
        > need to= update the registry definition itself, as well as add
        > new values t= o it.
        >
        > This is of course assuming that we decide that Warning
        = > headers are the way to go.
        >
        > Regards
        >
        > Kei= th
        >
        > > -----Original Message-----
        > > From: Rohan= Mahy [mailto: rohan@ekabal.com]
        > > Sent= : Tuesday, July 31, 2007 4:12 PM
        > > To: Francois Audet
        > &g= t; Cc: Cullen Jennings; Rohan Mahy; IETF SIP List; DRAGE,
        > Keith (Ke= ith);
        > > Robert Sparks; Jo= n.Peterson@neustar.com; Dean Willis
        > > Subject: [Sip] Re: War= n-Codes and draft-ietf-sip-sips
        > >
        > > Fran=E7ois,
        &g= t; >
        > > I think the IANA paragraph you described is too restrictive.<= br>> > The text in RFC3261 section 20.43 seems perfectly fine with> > registering non-SDP errors.  I would allocate warn-cod= e 380
        > "No SIPS
        > > contacts registered".
        > >
        = > > thanks,
        > > -rohan
        > >
        > > On Jul 30, = 2007, at 3:23 PM, Francois Audet wrote:
        > >
        > > > Now = that we have everybody exited about the prospect of using a
        > > > Warn-Code for "SIPS Not Allowed" and "SIP= Required" with
        > > Response 480,
        > > > instead o= f using new response codes, here is a quote from
        > 27.2/RFC
        > &= gt; > 3261.
        > > >
        > > >    Warning codes p= rovide information supplemental to the
        > > status code
        > >= ; > in
        > > >    SIP response messages wh= en the failure of the
        > transaction results
        > > >    from a Session Description Protoc= ol (SDP) (RFC 2327
        > [1]) problem.
        > > >
        > > >= ; My reading of this is that Warn-Codes are ONLY usable for
        > > SD= P errors.
        > > >
        > > > Doesn't this disqualify the idea of using a Warn-Cod= e for
        > > SIP/SIPS URI
        > > > problems??????
        > &g= t; >
        > > > If so, aren't we back to 418/419, or 418+New = header (Allow/
        > > Require),
        > > > or
        > > > 480+Response= text?
        > >
        > >
        > >
        > > ________________= _______________________________
        > > Sip mailing list   https://www1.ietf.org/mailman/listinfo/sip
        > > This list is fo= r NEW development of the core SIP Protocol Use
        > > sip-implementors@cs.columbia.edu for questions on current sip Use
        > > sipping@ietf.org for new developments on the application of sip=
        > >
        >
        >
        > _____________________________________= __________
        > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
        > Thi= s list is for NEW development of the core SIP Protocol Use
        > sip-implementors@cs.columbia.edu for questions on current sip
        > U= se sipping@ietf.org for new develop= ments on the application of sip
        >


        ________________________= _______________________
        Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
        This list is = for NEW development of the core SIP Protocol
        Use sip-implementors@cs.columbia.edu for questions on current sip
        Use sipping@ietf.org for new developments= on the application of sip

        ------=_Part_44238_32125043.1185929367443-- --===============0377178305== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0377178305==-- From sip-bounces@ietf.org Tue Jul 31 23:17:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG4g5-0003jb-3t; Tue, 31 Jul 2007 23:15:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IG4g4-0003jW-A5 for sip-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 23:15:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG4g3-0003jN-Va for sip@ietf.org; Tue, 31 Jul 2007 23:15:12 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IG4g3-0007Py-7g for sip@ietf.org; Tue, 31 Jul 2007 23:15:11 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l713Ewp23560; Tue, 31 Jul 2007 20:14:58 -0700 In-Reply-To: <030401c7d3b9$457a9360$800101df@acmepacket.com> References: <1ECE0EB50388174790F9694F77522CCF11697776@zrc2hxm0.corp.nortel.com> <247B95AF-63F6-432D-9D6E-AF083AF9C525@nostrum.com> <46A92B7C.7080202@cisco.com> <1ECE0EB50388174790F9694F77522CCF116E20B5@zrc2hxm0.corp.nortel.com><20070727153727.A4BDD33C1A@delta.rtfm.com><46AA138D.6030001@cisco.com><46AA1FAA.3000204@cisco.com> <325E76F4-3A53-4101-BBDB-D2131FA4BB1D@ekabal.com> <030401c7d3b9$457a9360$800101df@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3B61AA00-CC03-4607-9606-CA5B8C2EC5CB@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 Date: Tue, 31 Jul 2007 20:14:59 -0700 To: "Hadriel Kaplan" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Rohan Mahy , 'Michael Thomas' , 'IETF SIP List' , 'Francois Audet' , Jon.Peterson@neustar.com, 'Paul Kyzivat' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The resource that was requested (sips:foo@example.com) is NOT available. There may be a related but different resource available, so it is nice as a courtesy to provide this information, but the basic semantics should still be a 480. thanks, -rohan On Jul 31, 2007, at 2:25 PM, Hadriel Kaplan wrote: > Yeah but a 480 implies the resource is not available, whereas in > reality the > resource *is* available using a different scheme. I guess one > question is > if the sips scheme literally means the UAS is a different > "resource". If > so, then registering a sips contact only should not implicitly make > the UAS > available for routing plain sip. The draft currently says they > represent > the *same* resource. > > I'm not convinced by the downgrade argument. The far-end can just > as easily > send a 3xx redirecting the UAC to the sip contact. Per this new > draft the > proxies must not recurse on that, and the UAC should inform the > user before > doing so. But I think a new 4xx response code would be much more > likely to > make that a reality, as any vendor implementing support for > recursing on a > 418 would have read the draft and seen where it says "inform the > user". If > they didn't read the draft, they'd fail the request since they got an > unknown 4xx response. (compare that to a 3xx, which is known/usable > without > reading this draft) Am I missing the gist of the concern? > > -hadriel > > >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan@ekabal.com] >> Sent: Tuesday, July 31, 2007 12:04 PM >> To: Michael Thomas >> Cc: Rohan Mahy; IETF SIP List; Francois Audet; >> Jon.Peterson@neustar.com; >> Paul Kyzivat >> Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 >> >> Michael, >> >> The semantics of a request to a sip: resource are different from a >> request to a sips: resource. If there are no Contacts registered >> against a sips: resource, then the correct thing for the proxy to do >> is to send a 480. This is the same thing the proxy would do if there >> were no Contacts registered against a sip: resource. >> >> We are not talking about a ciphersuite downgrade here. Providing an >> error response code that encourages a client to downgrade is just >> plain irresponsible. >> >> thanks, >> -rohan >> >> >> On Jul 27, 2007, at 9:39 AM, Michael Thomas wrote: >>> Rohan Mahy wrote: >>>> Michael, >>>> >>>> At issue here is what the default implementor is likely to do. >>>> With a new 4xx, the misguided but well-meaning implementor is >>>> likely to try to "helpfully" "repair" the error without thinking >>>> about or understanding the security context. >>>> >>>> Using a Warning code raises the bar significantly, but still >>>> allows automata to at least log what happened. >>> As I said, a receiver is completely at liberty to prevent the >>> downgrade by not >>> accepting the downgraded request. Problem solved by those who >>> care. On >>> the other hand I think it's pretty presumptuous that we "know" in >>> all cases >>> whether it's wrong to "repair" the error. Paul brought up several >>> examples. >>> Also: if the receiver allows non-SIPS requests why shouldn't you >>> infer that >>> they want you to "repair" the request? It sure seems like this is a >>> misguided >>> attempt at forcing ineffectual nannyware which is a pointless >>> enterprise for >>> IETF protocols. >>> >>> Mike >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip