From courettabt@gmail.com Thu Feb 2 22:15:04 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C9D21F8527 for ; Thu, 2 Feb 2012 22:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdAP3ebTfsjH for ; Thu, 2 Feb 2012 22:15:04 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C00321F8525 for ; Thu, 2 Feb 2012 22:15:03 -0800 (PST) Received: by obbwd15 with SMTP id wd15so4615391obb.31 for ; Thu, 02 Feb 2012 22:14:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=NDl5keHqr2xsXvz4Xpr8JrKCOe7D4U9q/DYEOrg5V/s=; b=xA64XjIsunG0j+m8FRNPfak4rwhVoMLTV9dSb1XYLTQIns8M9/5F8gjrkIi7/OLPNH ppikRnV7uaaDO2ehChsSFGzgjfnsOLl5Dxwmu8a7NkzOc1PtJug023gC4RXrIfovLOCx PzNOn2l3O2q/kZYw60Z7M6ZJXwdu6BKq1l0DM= MIME-Version: 1.0 Received: by 10.182.119.73 with SMTP id ks9mr5434763obb.45.1328249698648; Thu, 02 Feb 2012 22:14:58 -0800 (PST) Received: by 10.182.69.138 with HTTP; Thu, 2 Feb 2012 22:14:58 -0800 (PST) Date: Fri, 3 Feb 2012 15:14:58 +0900 Message-ID: From: Couret Tabt To: sipcore@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sipcore] How does SIP verify whether or not Proxy is legimate? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 06:15:04 -0000 Dear folks, In SIP, if a UA received INVITE request, though a Proxy, maybe that is from another domain ,then how does the UA check whether or not it is the right proxy in that domain? If UA CANNOT check it, spoofing of proxy is possible. If you know that, please let me know. Thanks in advance, Tabt From brett@broadsoft.com Fri Feb 3 04:05:38 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F15421F852D for ; Fri, 3 Feb 2012 04:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA9YOopQqErM for ; Fri, 3 Feb 2012 04:05:37 -0800 (PST) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id 9B90721F8546 for ; Fri, 3 Feb 2012 04:05:37 -0800 (PST) Received: from CASUMHUB02.citservers.local (172.16.98.161) by Xedge01.citservers.local (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 3 Feb 2012 04:06:25 -0800 Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Fri, 3 Feb 2012 04:06:24 -0800 From: Brett Tate To: Couret Tabt , "sipcore@ietf.org" Date: Fri, 3 Feb 2012 04:05:27 -0800 Thread-Topic: [sipcore] How does SIP verify whether or not Proxy is legimate? Thread-Index: AcziO1CbTEUtOY1qSBeMqjXE0hBDdAAKljIA Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C18DC7DF3@EXMBXCLUS01.citservers.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] How does SIP verify whether or not Proxy is legimate? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 12:05:38 -0000 The basic answer is that SIP currently relies upon transitive trust relatio= nships when middle boxes are involved. Some of the security mechanisms and= limitations are discussed within RFC 3261 section 26. RFC 5630 updates RF= C 3261 and provides some details concerning SIPS and TLS. RFC 4474 may als= o be insightful. And since you mentioned inter-domain SIP, you might find the following work= ing groups useful. http://tools.ietf.org/wg/drinks/ http://tools.ietf.org/wg/speermint/ > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Couret Tabt > Sent: Friday, February 03, 2012 1:15 AM > To: sipcore@ietf.org > Subject: [sipcore] How does SIP verify whether or not Proxy is > legimate? >=20 > Dear folks, >=20 > In SIP, if a UA received INVITE request, though a Proxy, maybe that is > from another domain > ,then how does the UA check whether or not it is the right proxy in > that domain? >=20 > If UA CANNOT check it, spoofing of proxy is possible. >=20 > If you know that, please let me know. >=20 > Thanks in advance, > Tabt From vkg@bell-labs.com Fri Feb 3 06:20:45 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CC921F85FC for ; Fri, 3 Feb 2012 06:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.752 X-Spam-Level: X-Spam-Status: No, score=-108.752 tagged_above=-999 required=5 tests=[AWL=1.847, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9T5rXbf2zMVd for ; Fri, 3 Feb 2012 06:20:44 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id A293121F855A for ; Fri, 3 Feb 2012 06:20:44 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q13EKh79005533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 3 Feb 2012 08:20:43 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q13EKhZD011922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 3 Feb 2012 08:20:43 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q13EKgZX009949 for ; Fri, 3 Feb 2012 08:20:43 -0600 (CST) Message-ID: <4F2BEE37.8080102@bell-labs.com> Date: Fri, 03 Feb 2012 08:24:55 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: sipcore@ietf.org 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.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [sipcore] How does SIP verify whether or not Proxy is legimate? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 14:20:45 -0000 On 02/03/2012 12:14 AM, Couret Tabt wrote: > In SIP, if a UA received INVITE request, though a Proxy, maybe that > is from another domain ,then how does the UA check whether or not it > is the right proxy in that domain? > > If UA CANNOT check it, spoofing of proxy is possible. > > If you know that, please let me know. In addition to the resources that Brett mentioned, you may also want to eyeball rfc5922. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From dworley@avaya.com Fri Feb 3 08:02:44 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F58221F8460 for ; Fri, 3 Feb 2012 08:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.336 X-Spam-Level: X-Spam-Status: No, score=-103.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulTYZ+P2PEeJ for ; Fri, 3 Feb 2012 08:02:43 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 62FB921F845E for ; Fri, 3 Feb 2012 08:02:43 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAKgDLE+HCzI1/2dsb2JhbABDoneMJ4EFgXIBAQEBAgESKEQLAgEIDQghECERJQEBBAESCBqHWpxZnAqID4NHCgkRBQIxAgEFBQYIAwGDEoETGQIEglZjBIhEkl2FD4du X-IronPort-AV: E=Sophos;i="4.73,352,1325480400"; d="scan'208";a="289475341" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 Feb 2012 11:02:41 -0500 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 03 Feb 2012 10:48:41 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.137]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Fri, 3 Feb 2012 11:02:40 -0500 From: "Worley, Dale R (Dale)" To: Couret Tabt , "sipcore@ietf.org" Date: Fri, 3 Feb 2012 10:59:53 -0500 Thread-Topic: [sipcore] How does SIP verify whether or not Proxy is legimate? Thread-Index: AcziOzA9rGSSCoS2QsqFTUkJvQJ9/AAUa2Us Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] How does SIP verify whether or not Proxy is legimate? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 16:02:44 -0000 > From: Couret Tabt [courettabt@gmail.com] >=20 > If UA CANNOT check it, spoofing of proxy is possible. As SIP was originally designed, this did not matter, because the UA was responsible for determining if the INVITE is "legitimate". (Do you ask, when a call arrives at your house, "Is this call legitimate?" Do you demand that the PSTN assure that the call is "legitimate"?) Work has been done since then to to add facilities to SIP to allow the UA to delegate any call screening to a proxy, and to support transitive trust between proxies. Dale From richard@shockey.us Wed Feb 8 12:11:44 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A097E21E802F for ; Wed, 8 Feb 2012 12:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.544 X-Spam-Level: X-Spam-Status: No, score=-98.544 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBPk4sdbBU-F for ; Wed, 8 Feb 2012 12:11:43 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 3156721F8541 for ; Wed, 8 Feb 2012 12:11:43 -0800 (PST) Received: (qmail 5665 invoked by uid 0); 8 Feb 2012 20:11:31 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy3.bluehost.com with SMTP; 8 Feb 2012 20:11:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=bxz/jgWeaN3rk/rYF2xoxPjbnjTcmYHWFWQbO0ltrOA=; b=My3A4k1PX3Vub5t0LFbxoMw0Csderq8QvSq5DaZRcvU4t9JM3GRnxbvI5lax9jtUaJQZ0F66QLU8z17Q4Rre4m/TCz+yWCnEJt7kB0eSjmGc/h7ei5tHX1oHw9SABq5j; Received: from pool-96-255-226-191.washdc.fios.verizon.net ([96.255.226.191] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RvDrV-0006n6-TS; Wed, 08 Feb 2012 13:11:30 -0700 From: "Richard Shockey" To: , Date: Wed, 8 Feb 2012 15:11:28 -0500 Message-ID: <010801cce69d$d89f8a50$89de9ef0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0109_01CCE673.EFC98250" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczmlP65nX95PO7ERrqcjJNwqNxi3gACJsow Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.255.226.191 authed with richard@shockey.us} Subject: [sipcore] SIPNOC US 2012 Call for Presentations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 20:11:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0109_01CCE673.EFC98250 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: SIPNOC US 2012 Call for Presentations =20 LinkedIn Groups * Group: The SIP Forum * Subject: SIPNOC US 2012 Call for Presentations=20 The SIP Forum is holding its second SIP Network Operators Conference = =E2=80=93 SIPNOC US 2012 -- on June 25th to the 27th, 2012, at the Hyatt = Dulles Hotel in Herndon, Virginia. For more information about SIPNOC US 2012, including the preliminary = schedule of events and other important details about the conference, = please visit http://www.sipnoc.org . The SIPNOC US 2012 Program Committee is now seeking proposals for = presentations, panels, or BOFs (Birds-Of-a-Feather) for the SIPNOC US = 2012 program. We invite presentations highlighting issues relating to = SIP deployments. Operators are encouraged to present on successes, = issues, and concerns found in their deployments. Vendors are encouraged = to work with operators to present real-world deployment experiences. Full details of the submission process and policies, as well as SIPNOC = US 2012 Program dates of interest, can be found at: http://www.sipforum.org/content/view/374/275/=20 EARLY BIRD REGISTRATION DEADLINE EXTENDED!=20 Take Advantage of Special Savings Now Before They Disappear! The regular individual registration fee for SIPNOC US 2012 attendance is = $895 for two full days of conference activities. This fee will cover = admittance to all conference sessions, presentations, keynotes, = breakfast, lunch, dinners and breaks, as well as a welcome reception on = the evening before the event begins, and a special evening networking = reception on the first day of the event. For a limited time, you can take advantage of a special early-bird = discounted price of $695 =E2=80=93 a $200 discount off the regular = attendance fee. This special rate expires on March 1, 2012, so register = today to lock in your savings! To register at this very special rate, please visit = http://www.regonline.com/sipnocus2012 . SIP Forum Full Members Save Even More! For individuals of companies that = are active Full Members of the SIP Forum, a special early-bird price of = $445 is being offered =E2=80=93 a discount of more than 50% off the = regular conference rate -- and exclusive full member-only discounts will = be offered for a variety of special SIPNOC US 2012 sponsorship packages. = In order to obtain this special Full Member pricing =E2=80=93 good until = March 1, 2012, please contact Marc Robins, SIP Forum President and = Managing Director, for the discount code. Marc can be reached at = +1-203-829-6307 or marc.robins@sipforum.org.=20 SIPNOC US 2012 Hotel Reservations The SIP Forum has negotiated a nicely discounted room rate of $169/night = at the four-star Hyatt Dulles Hotel. This rate includes in-room WiFi = Internet access! Other valuable benefits include a free shuttle bus to = and from Dulles Airport and free parking in the hotel parking lot. The cut-off date to receive this great rate is June 4, 2012. Reservation = requests made after the cut-off date will be based on availability at = the hotel's prevailing rates. So take advantage of this great offer now = and register for your stay at the Hyatt Dulles using the following Web = link: https://resweb.passkey.com/go/SIPNOCUS2012 . SIPNOC US 2012 Sponsorship Opportunities If you are interested in a corporate sponsorship of the event, please = contact Marc Robins, SIP Forum President and Managing Director, for = detailed information about available sponsorship opportunities. Marc can = be reached at +1-203-829-6307 or marc.robins@sipforum.org. ****************************************** For more information about SIPNOC US 2012, please visit www.sipnoc.org = or email sipnocinfo@sipforum.org=20 Posted By Marc Robins=20 =09 =09 =09 =20 ------=_NextPart_000_0109_01CCE673.EFC98250 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Subject: SIPNOC US = 2012 Call for Presentations

 

L= inkedIn Groups<= o:p>

  • Group: The = SIP Forum
  • Subject: = SIPNOC US 2012 Call for Presentations =

The SIP Forum = is holding its second SIP Network Operators Conference =E2=80=93 SIPNOC = US 2012 -- on June 25th to the 27th, 2012, at the Hyatt Dulles Hotel in = Herndon, Virginia.

For more information about SIPNOC US 2012, including the = preliminary schedule of events and other important details about the = conference, please visit http://www.sipnoc.org .

The SIPNOC US 2012 = Program Committee is now seeking proposals for presentations, panels, or = BOFs (Birds-Of-a-Feather) for the SIPNOC US 2012 program. We invite = presentations highlighting issues relating to SIP deployments. Operators = are encouraged to present on successes, issues, and concerns found in = their deployments. Vendors are encouraged to work with operators to = present real-world deployment experiences.

Full details of the submission process and policies, as = well as SIPNOC US 2012 Program dates of interest, can be found = at:
http://www.sipforum.org/content/view/374/275/ =

EARLY BIRD REGISTRATION DEADLINE EXTENDED! =

Take Advantage of Special Savings Now = Before They Disappear!

The regular = individual registration fee for SIPNOC US 2012 attendance is $895 for = two full days of conference activities. This fee will cover admittance = to all conference sessions, presentations, keynotes, breakfast, lunch, = dinners and breaks, as well as a welcome reception on the evening before = the event begins, and a special evening networking reception on the = first day of the event.

For a limited = time, you can take advantage of a special early-bird discounted price of = $695 =E2=80=93 a $200 discount off the regular attendance fee. This = special rate expires on March 1, 2012, so register today to lock in your = savings!

To register at this very = special rate, please visit http://www.regonline.com/sipnocus2012 .

SIP Forum Full Members = Save Even More! For individuals of companies that are active Full = Members of the SIP Forum, a special early-bird price of $445 is being = offered =E2=80=93 a discount of more than 50% off the regular conference = rate -- and exclusive full member-only discounts will be offered for a = variety of special SIPNOC US 2012 sponsorship packages. =

In order to obtain this special Full = Member pricing =E2=80=93 good until March 1, 2012, please contact Marc = Robins, SIP Forum President and Managing Director, for the discount = code. Marc can be reached at +1-203-829-6307 or = marc.robins@sipforum.org.

SIPNOC US = 2012 Hotel Reservations

The SIP Forum = has negotiated a nicely discounted room rate of $169/night at the = four-star Hyatt Dulles Hotel. This rate includes in-room WiFi Internet = access! Other valuable benefits include a free shuttle bus to and from = Dulles Airport and free parking in the hotel parking = lot.

The cut-off date to receive this = great rate is June 4, 2012. Reservation requests made after the cut-off = date will be based on availability at the hotel's prevailing rates. So = take advantage of this great offer now and register for your stay at the = Hyatt Dulles using the following Web link: https://resweb.passkey.com/go/SIPNOCUS2012 .

SIPNOC US 2012 = Sponsorship Opportunities

If you are = interested in a corporate sponsorship of the event, please contact Marc = Robins, SIP Forum President and Managing Director, for detailed = information about available sponsorship opportunities. Marc can be = reached at +1-203-829-6307 or = marc.robins@sipforum.org.

******************************************

For more information about SIPNOC US 2012, please visit = www.sipnoc.org or email sipnocinfo@sipforum.org
= Posted By Marc Robins =

 

------=_NextPart_000_0109_01CCE673.EFC98250-- From shinji.okumura@softfront.jp Wed Feb 8 21:56:21 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD7021F8599 for ; Wed, 8 Feb 2012 21:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.868 X-Spam-Level: X-Spam-Status: No, score=-97.868 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtWixRX54rQ5 for ; Wed, 8 Feb 2012 21:56:20 -0800 (PST) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by ietfa.amsl.com (Postfix) with ESMTP id 468B121F8592 for ; Wed, 8 Feb 2012 21:56:18 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id D369142806F for ; Thu, 9 Feb 2012 14:56:16 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ox9ObOGYua+t for ; Thu, 9 Feb 2012 14:56:16 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 6734942803B for ; Thu, 9 Feb 2012 14:56:15 +0900 (JST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Thu, 09 Feb 2012 14:56:18 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.70 (WinNT,502) In-Reply-To: <20111030122228.27145.41253.idtracker@ietfa.amsl.com> References: <20111030122228.27145.41253.idtracker@ietfa.amsl.com> Message-Id: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-06.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 05:56:21 -0000 Hi, I have a question about indexing in section B.1. PBX Voicemail call floww. F6 INVITE Example.com -> VM History-Info: \ index=1.3;mp=1.2 This mp-value is "1.2". If this HI is mapped from 1.2, should the index be 1.2.x? Or, if this is mapped from "1"(ie bob@example.com), should the mp-value be "1"? Regards, Shinji. internet-drafts@ietf.org Sun, 30 Oct 2011 05:22:28 -0700 >A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session >Initiation Protocol Core Working Group of the IETF. > > Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information > Author(s) : Mary Barnes > Francois Audet > Shida Schubert > Detecon International Gmbh > Christer Holmberg > Filename : draft-ietf-sipcore-rfc4244bis-06.txt > Pages : 65 > Date : 2011-10-30 > > This document defines a standard mechanism for capturing the history > information associated with a Session Initiation Protocol (SIP) > request. This capability enables many enhanced services by providing > the information as to how and why a SIP request arrives at a specific > application or user. This document defines an optional SIP header > field, History-Info, for capturing the history information in > requests. The document also defines SIP header field parameters for > the History-Info and Contact header fields to tag the method by which > the target of a request is determined. In addition, this > specification defines a value for the Privacy header field specific > to the History-Info header field. This document obsoletes RFC 4244. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244bis-06.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >This Internet-Draft can be retrieved at: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244bis-06.txt From xavier.marjou@gmail.com Tue Feb 14 07:18:02 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1BE21F8629 for ; Tue, 14 Feb 2012 07:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD-ffzuyJC6n for ; Tue, 14 Feb 2012 07:18:02 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id F222E21F8623 for ; Tue, 14 Feb 2012 07:18:01 -0800 (PST) Received: by obbwd15 with SMTP id wd15so76750obb.31 for ; Tue, 14 Feb 2012 07:18:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=IyeExqEAdJut91DsgDFN4QMzHYg0piKAX1FeCNDnczI=; b=uzmk3iC8exLM1WqWhBATvGX9vSKBGIUF4bkiV+DeNh9Owz5uiF+pkg6SgttVGMw1Eo 0U3+qrgcsi05ukm8YKdFNLXdRuQrQdHsJkzDW/Xa+9yawTL/A8dtEe5Ub4VTZBtGycfu 8BbwSiopacqYPOxVpJmPeqyFonjscNLrbLTkA= MIME-Version: 1.0 Received: by 10.182.202.69 with SMTP id kg5mr15822666obc.35.1329232681659; Tue, 14 Feb 2012 07:18:01 -0800 (PST) Sender: xavier.marjou@gmail.com Received: by 10.60.2.70 with HTTP; Tue, 14 Feb 2012 07:18:01 -0800 (PST) Date: Tue, 14 Feb 2012 16:18:01 +0100 X-Google-Sender-Auth: SOVaBRUTKy4KG6FxQsJwWsLUsXk Message-ID: From: Xavier Marjou To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1 Subject: [sipcore] draft-ibc-sipcore-sip-websocket-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 15:18:02 -0000 Hi, >From my perspective, I think this draft contains all the needed details for this sip-websocket topic. I support it... and really hope to see it discussed it at the next SIPCORE meeting in March. Cheers, Xavier PS: "wss" needs to be added in Section 5.2 From ibc@aliax.net Tue Feb 14 08:16:58 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6EA21E802D for ; Tue, 14 Feb 2012 08:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLH509ek9F-m for ; Tue, 14 Feb 2012 08:16:57 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5E121E8021 for ; Tue, 14 Feb 2012 08:16:57 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so105790vbb.31 for ; Tue, 14 Feb 2012 08:16:56 -0800 (PST) Received: by 10.220.156.204 with SMTP id y12mr12148158vcw.12.1329236216248; Tue, 14 Feb 2012 08:16:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.203.2 with HTTP; Tue, 14 Feb 2012 08:16:36 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 14 Feb 2012 17:16:36 +0100 Message-ID: To: Xavier Marjou Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlqA2LDStu54WU9RKx4KUYoHZ4BNwF1hUNjmIR+m9cT6zMevqzAKN2X8tVUljmlcZ/UKk+q Cc: SIPCORE Subject: Re: [sipcore] draft-ibc-sipcore-sip-websocket-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 16:16:58 -0000 2012/2/14 Xavier Marjou : > From my perspective, I think this draft contains all the needed > details for this sip-websocket topic. > I support it... and really hope to see it discussed it at the next > SIPCORE meeting in March. Thanks a lot for your support Xavier. > PS: "wss" needs to be added in Section 5.2 That's not correct, in the same way that using SIP over TLS-TCP means ;transport=3Dtcp with sips schema, or sending SIP over TLS-SCTP means ;transport=3Dsctp with sips schema. So sending SIP over TLS-WebSocket must involve ;transport=3Dws as sips schema. Regards. --=20 I=C3=B1aki Baz Castillo From internet-drafts@ietf.org Thu Feb 23 15:28:19 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A801521E802A; Thu, 23 Feb 2012 15:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPvJXN4YIZrF; Thu, 23 Feb 2012 15:28:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A0B21F8790; Thu, 23 Feb 2012 15:28:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120223232819.31427.16148.idtracker@ietfa.amsl.com> Date: Thu, 23 Feb 2012 15:28:19 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc3265bis-05.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 23:28:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Work= ing Group of the IETF. Title : SIP-Specific Event Notification Author(s) : Adam Roach Filename : draft-ietf-sipcore-rfc3265bis-05.txt Pages : 52 Date : 2012-02-23 This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accomodate some small changes to the mechanism that were discussed in that document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-05.txt From adam@nostrum.com Thu Feb 23 15:34:50 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD8F21F865E for ; Thu, 23 Feb 2012 15:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.954 X-Spam-Level: X-Spam-Status: No, score=-101.954 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPObrOUTumVs for ; Thu, 23 Feb 2012 15:34:49 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFE021F865D for ; Thu, 23 Feb 2012 15:34:49 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q1NNYmw6067207 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 23 Feb 2012 17:34:48 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4F46CD18.3070306@nostrum.com> Date: Thu, 23 Feb 2012 17:34:48 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 CC: sipcore@ietf.org References: <20120223232819.31427.16148.idtracker@ietfa.amsl.com> In-Reply-To: <20120223232819.31427.16148.idtracker@ietfa.amsl.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) Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-rfc3265bis-05.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 23:34:50 -0000 [as an individual participant/author] Based on Paul's document shepherd review, I have made a number of minor changes to the rfc3265bis draft document. You can access the new document as described below. For convenience, you may view the diffs between -04 and -05 at the following URL: http://tools.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc3265bis-05.txt /a On 2/23/12 5:28 PM, 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 Core Working Group of the IETF. > > Title : SIP-Specific Event Notification > Author(s) : Adam Roach > Filename : draft-ietf-sipcore-rfc3265bis-05.txt > Pages : 52 > Date : 2012-02-23 > > This document describes an extension to the Session Initiation > Protocol (SIP). The purpose of this extension is to provide an > extensible framework by which SIP nodes can request notification from > remote nodes indicating that certain events have occurred. > > Note that the event notification mechanisms defined herein are NOT > intended to be a general-purpose infrastructure for all classes of > event subscription and notification. > > This document represents a backwards-compatible improvement on the > original mechanism described by RFC 3265, taking into account several > years of implementation experience. Accordingly, this document > obsoletes RFC 3265. This document also updates RFC 4660 slightly to > accomodate some small changes to the mechanism that were discussed in > that document. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-05.txt > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Mon Feb 27 10:09:59 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C212B21F87D7 for ; Mon, 27 Feb 2012 10:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THNUfiFLsve3 for ; Mon, 27 Feb 2012 10:09:59 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB3421F87A2 for ; Mon, 27 Feb 2012 10:09:58 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta01.westchester.pa.mail.comcast.net with comcast id f5n21i00927AodY5169zTM; Mon, 27 Feb 2012 18:09:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id f69y1i00H07duvL3f69y41; Mon, 27 Feb 2012 18:09:59 +0000 Message-ID: <4F4BC6F5.4040101@alum.mit.edu> Date: Mon, 27 Feb 2012 13:09:57 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Richard Shockey References: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> <010101cce5f9$10d3b8b0$327b2a10$@us> <38726EDA2109264987B45E29E758C4D608655E@MISOUT7MSGUSR9N.ITServices.sbc.com> <155442B6-76C0-4D17-AD5B-8A1B295D619A@iii.ca> <4F459082.2040402@alum.mit.edu> <01d601ccf3d5$37710880$a6531980$@us> <4F4987A7.5080804@alum.mit.edu> <002a01ccf4c6$60bd1c50$223754f0$@us> In-Reply-To: <002a01ccf4c6$60bd1c50$223754f0$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: [sipcore] Legal controls over sip signaling X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 18:09:59 -0000 [I've changed the subject to reflect what we are discussing] Richard, This is interesting, and I think more discussion is appropriate on it. Its not clear where this discussion should take place - probably not dispatch. IMO sipcore is more suitable for the discussion. So I'm cross posting this but bcc'ing dispatch so that replies will go to sipcore. (Hopefully that will work. If it doesn't, please refrain from replying on dispatch.) I don't understand how a legal restriction would work. - would it be limited to regulated carriers? - how would this apply to the interconnect of "private" devices or environments to the "public" sip infrastructure? - would this be limited to identities that are E.164 numbers? Or would it include other sorts of identities? - would this apply to interconnects between private infrastructures? (E.g. ViPR) Thanks, Paul On 2/26/12 3:36 PM, Richard Shockey wrote: > > > On 2/25/12 10:50 AM, Richard Shockey wrote: > >> Also, what is to prevent someone from forging SPIDs in a message? >> [RS> ] >> [RS> ] One of the principal use cases for a global SPID this is >> International Interconnection of E.164 traffic or even domestic traffic in >> some national jurisdictions. As for forging SPID's we have the same > problem >> with issues of Calling Number in one way SIP traffic over the PSTN in the >> US. People do bad things. The prevention mechanism is national law or >> regulation that defines what is in the headers and what cannot be modified >> as it might transverse a all IP Interconnected network using E.164 >> identifiers. Its called fines and jail. > > There's a lot of callerid forging going on, and AFAIK nobody is going to > jail for it. > [RS> ] Not yet , but given the level of screaming by the service providers > on the fraudulent phantom traffic issue you can assume its coming. > > In what countries are there laws about what sip headers can go into a > sip message? > [RS> ] Right now the issue is related to traffic in both the US and Canada > but I would guess most of the PTT's are experiencing the same issue. The FCC > order on USF/ICC reform is very specific on the requirement for non > modification of charge number or calling party number in the signaling > path.. aka the SIP headers when applicable. A fair amount of this goes > away with bill and keep but you can assume you'll see a bunch of new > "requirements" be imposed as a transition to all SIP Interconnection for > real time communications occurs over the next decade. > > Thanks, > Paul > > From pkyzivat@alum.mit.edu Mon Feb 27 10:11:36 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C4021F87F7 for ; Mon, 27 Feb 2012 10:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXduPK5KQC3A for ; Mon, 27 Feb 2012 10:11:36 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id EF94E21F8702 for ; Mon, 27 Feb 2012 10:11:35 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta09.westchester.pa.mail.comcast.net with comcast id f69x1i00A1ei1Bg596BZ3H; Mon, 27 Feb 2012 18:11:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta24.westchester.pa.mail.comcast.net with comcast id f6BZ1i00F07duvL3k6BZBc; Mon, 27 Feb 2012 18:11:33 +0000 Message-ID: <4F4BC754.4030606@alum.mit.edu> Date: Mon, 27 Feb 2012 13:11:32 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wg draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 18:11:36 -0000 SIPCORE group: There has been general agreement on the proxy-feature requirements, so now we have a basis to work on a corresponding mechanism. Robert has agreed that sipcore is the proper place to do this work. The document draft-holmberg-sipcore-proxy-feature-04 has been proposed as a mechanism. I am requesting that discussion begin, on the sipcore list, on the suitability of this draft as a basis for a wg mechanism document that will meet the requirements expressed in draft-ietf-sipcore-proxy-feature-reqs-03.txt. One issue that remains fuzzy is distinguishing what is and is not a valid proxy-feature. We have a few examples from the use cases, but little clarity beyond that on any guidelines for what would qualify and what would not. However it seems likely that few, if any, of the existing defined feature tags (even those in the sip tree) would be appropriate. So one thing I will be looking for in the mechanism before it is finalized is a way to resolve this. This might be a set of criteria that can be applied to any new candidate proxy-feature. Or if that proves impossible to define, then we can fall back on requiring standards action for a feature to be defined. So I encourage discussion of this issue. (Currently the draft proposes to build on RFC 3840 and its use of the feature-tag definition mechanisms specified in RFC 2506. That registration mechanism has multiple categories of features with differing approval mechanisms for each category. Some require an RFC, some expert review, and some no approval at all. Whether this can be made to work for proxy-features remains to be seen.) Thanks, Paul (as co-chair) From richard@shockey.us Mon Feb 27 11:12:48 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D637D21F87B8 for ; Mon, 27 Feb 2012 11:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.162 X-Spam-Level: X-Spam-Status: No, score=-98.162 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQJe+-Cecee0 for ; Mon, 27 Feb 2012 11:12:48 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id F41B021F87B7 for ; Mon, 27 Feb 2012 11:12:47 -0800 (PST) Received: (qmail 24416 invoked by uid 0); 27 Feb 2012 19:12:47 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.bluehost.com with SMTP; 27 Feb 2012 19:12:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=A3fp9u41/Wm4y3CSDF0WVS332duF2V9IBJHoVa0iqQM=; b=QuBBhapsZBNg8O9p0MOC2BW2sOCX79zd+7ge+cjQfCFtGhhsJa5SqTUJK6Cw/zrMSQxkQbU53u7PdCIgy0F7oqlnlL/EWJf3t2KpuLkDE6XWG93ghbJvwcerqzQ2SPqJ; Received: from pool-108-48-10-220.washdc.fios.verizon.net ([108.48.10.220] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1S2602-0002Ga-6i; Mon, 27 Feb 2012 12:12:42 -0700 From: "Richard Shockey" To: "'Paul Kyzivat'" References: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> <010101cce5f9$10d3b8b0$327b2a10$@us> <38726EDA2109264987B45E29E758C4D608655E@MISOUT7MSGUSR9N.ITServices.sbc.com> <155442B6-76C0-4D17-AD5B-8A1B295D619A@iii.ca> <4F459082.2040402@alum.mit.edu> <01d601ccf3d5$37710880$a6531980$@us> <4F4987A7.5080804@alum.mit.edu> <002a01ccf4c6$60bd1c50$223754f0$@us> <4F4BC6F5.4040101@alum.mit.edu> In-Reply-To: <4F4BC6F5.4040101@alum.mit.edu> Date: Mon, 27 Feb 2012 14:12:38 -0500 Message-ID: <00b301ccf583$c8427060$58c75120$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acz1ewm8kZAnlaa1Sk+/TlIp6AT3WwAAb9Qw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.48.10.220 authed with richard@shockey.us} Cc: sipcore@ietf.org Subject: Re: [sipcore] Legal controls over sip signaling X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 19:12:49 -0000 In line.. -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Monday, February 27, 2012 1:10 PM To: Richard Shockey Cc: SIPCORE Subject: Legal controls over sip signaling [I've changed the subject to reflect what we are discussing] Richard, This is interesting, and I think more discussion is appropriate on it. Its not clear where this discussion should take place - probably not dispatch. IMO sipcore is more suitable for the discussion. So I'm cross posting this but bcc'ing dispatch so that replies will go to sipcore. (Hopefully that will work. If it doesn't, please refrain from replying on dispatch.) I don't understand how a legal restriction would work. [RS> ] Well remember I'm not a regulator or a lawyer and I never want to play either on television. The PSTN as we know it is regulated everywhere. Since we are going to transition to some SIP/IMS based core network for essential real-time communications eventually then it's reasonable to assume some oversight and probably some regulation will occur. If the rules were in place and someone caught someone intentionally modifying the signaling to commit fraud etc then they could be subject to sanction fines suspension of license etc. One more reason for CALLID track and trace. - would it be limited to regulated carriers? [RS> ] So what is a regulated carrier? :-) That is not a simple question depending on the relevant national law. - how would this apply to the interconnect of "private" devices or environments to the "public" sip infrastructure? [RS> ] So again now you get to define what is the "public SIP" infrastructure? E.164? :-) What kinds of private devices do you mean... the Carterfone Decision? Don't mention that to your mobile friends.. - would this be limited to identities that are E.164 numbers? [RS> ] Now you have hit the key issue IMHO. In order to properly segment these things out into definable elements I would argue that if the signaling deals with E.164 named endpoints you will see SIP signaling regulation. If you are using other forms of identifiers probably not. It's a question of policy here. What is the Social Contract, if you want to call it that, in the existing PSTN you actually want to preserve over time? reliability, affordability, accessibility, ubiquity, QoS, universal service, disability access, lawful intercept, etc. If you have any of the above goals you can argue about legal controls over the modification of SIP signaling. Right now it's about billing using Calling Number etc. Remember Shockey's law .."Money is the answer what is the question?" The losses are piling up and the usual suspects are not happy. And when the usual suspects are not happy they make long tortured filings with the regulators. Or would it include other sorts of identities? [RS> ] It depends, but the general reluctance by regulators to interfere in private name spaces is pretty well documented. The last time it was tried in the US was with the forced federation of Instant Messaging as a condition of the AOL/TW merger. The result it was a total failure but that BTW also exposes several issues. First IM is dying SMS is still growing by leaps and bounds but the competitors to SMS are still reliant on the E.164 naming system. Ubiquity works. SIP URI's have not. - would this apply to interconnects between private infrastructures? (E.g. ViPR) [RS> ] Which private infrastructures ..between licensed carriers possibly but non modification of signaling would probably be standard clause in any IP to IP SIP Interconnection agreement. Enterprises? Highly dboutful. There is nothing even now that would prevent private peering among SIP domains. In PSTN terms it's called Least Cost Routing. You just need a database of the mapped identifiers. Thanks, Paul On 2/26/12 3:36 PM, Richard Shockey wrote: > > > On 2/25/12 10:50 AM, Richard Shockey wrote: > >> Also, what is to prevent someone from forging SPIDs in a message? >> [RS> ] >> [RS> ] One of the principal use cases for a global SPID this is >> International Interconnection of E.164 traffic or even domestic traffic in >> some national jurisdictions. As for forging SPID's we have the same > problem >> with issues of Calling Number in one way SIP traffic over the PSTN in the >> US. People do bad things. The prevention mechanism is national law or >> regulation that defines what is in the headers and what cannot be modified >> as it might transverse a all IP Interconnected network using E.164 >> identifiers. Its called fines and jail. > > There's a lot of callerid forging going on, and AFAIK nobody is going to > jail for it. > [RS> ] Not yet , but given the level of screaming by the service providers > on the fraudulent phantom traffic issue you can assume its coming. > > In what countries are there laws about what sip headers can go into a > sip message? > [RS> ] Right now the issue is related to traffic in both the US and Canada > but I would guess most of the PTT's are experiencing the same issue. The FCC > order on USF/ICC reform is very specific on the requirement for non > modification of charge number or calling party number in the signaling > path.. aka the SIP headers when applicable. A fair amount of this goes > away with bill and keep but you can assume you'll see a bunch of new > "requirements" be imposed as a transition to all SIP Interconnection for > real time communications occurs over the next decade. > > Thanks, > Paul > > From internet-drafts@ietf.org Mon Feb 27 11:49:12 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8B621F87F3; Mon, 27 Feb 2012 11:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GbFj8cNY9M7; Mon, 27 Feb 2012 11:49:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B37721F873E; Mon, 27 Feb 2012 11:48:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120227194851.21753.20633.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2012 11:48:51 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc3265bis-06.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 19:49:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Work= ing Group of the IETF. Title : SIP-Specific Event Notification Author(s) : Adam Roach Filename : draft-ietf-sipcore-rfc3265bis-06.txt Pages : 52 Date : 2012-02-27 This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accommodate some small changes to the mechanism that were discussed in that document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-06.txt From internet-drafts@ietf.org Mon Feb 27 11:56:09 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B88C21F87F5; Mon, 27 Feb 2012 11:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1278bpRZQLGC; Mon, 27 Feb 2012 11:56:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D2521F87E0; Mon, 27 Feb 2012 11:56:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120227195608.23491.22043.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2012 11:56:08 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc3265bis-07.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 19:56:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Work= ing Group of the IETF. Title : SIP-Specific Event Notification Author(s) : Adam Roach Filename : draft-ietf-sipcore-rfc3265bis-07.txt Pages : 52 Date : 2012-02-27 This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accommodate some small changes to the mechanism that were discussed in that document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-07.txt From ivo.sedlacek@ericsson.com Tue Feb 28 00:01:05 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0699C21F852C for ; Tue, 28 Feb 2012 00:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpFdYUOL9sEr for ; Tue, 28 Feb 2012 00:01:03 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4125921F855E for ; Tue, 28 Feb 2012 00:01:02 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-8d-4f4c89bebbaa Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 99.4F.01970.EB98C4F4; Tue, 28 Feb 2012 09:01:02 +0100 (CET) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.18]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Tue, 28 Feb 2012 09:01:01 +0100 From: Ivo Sedlacek To: Paul Kyzivat , SIPCORE Date: Tue, 28 Feb 2012 09:01:00 +0100 Thread-Topic: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wg draft Thread-Index: Acz1e0EutxyIHvksQ1m0pDduEyFPwgAc8nnQ Message-ID: <3A324A65CCACC64289667DFAC0B88E12197894743B@ESESSCMS0360.eemea.ericsson.se> References: <4F4BC754.4030606@alum.mit.edu> In-Reply-To: <4F4BC754.4030606@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wg draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 08:01:05 -0000 Hello, As co-author of the draft-holmberg-sipcore-proxy-feature, and working with = features where the mechanism is needed, I obviously support adopting the dr= aft as wg document and will continue contributing to its progress. Kind regards=20 Ivo Sedlacek=20 Ericsson Technology and Portfolio Management, Terminal Standardization Sweden Office: +46 10 711 9382 ivo.sedlacek@ericsson.com www.ericsson.com We only send and receive email on the basis of the term set out at www.eric= sson.com/email_disclaimer -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: 27. =FAnora 2012 19:12 To: SIPCORE Subject: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wg= draft SIPCORE group: There has been general agreement on the proxy-feature requirements, so now = we have a basis to work on a corresponding mechanism. Robert has agreed tha= t sipcore is the proper place to do this work. The document draft-holmberg-sipcore-proxy-feature-04 has been proposed as a mechanism. I am requesting that discussion begin, on the sipcore list, on the suitabil= ity of this draft as a basis for a wg mechanism document that will meet the= requirements expressed in draft-ietf-sipcore-proxy-feature-reqs-03.txt. One issue that remains fuzzy is distinguishing what is and is not a valid p= roxy-feature. We have a few examples from the use cases, but little clarity= beyond that on any guidelines for what would qualify and what would not. H= owever it seems likely that few, if any, of the existing defined feature ta= gs (even those in the sip tree) would be appropriate. So one thing I will be looking for in the mechanism before it is finalized = is a way to resolve this. This might be a set of criteria that can be appli= ed to any new candidate proxy-feature. Or if that proves impossible to defi= ne, then we can fall back on requiring standards action for a feature to be= defined. So I encourage discussion of this issue. (Currently the draft proposes to build on RFC 3840 and its use of the featu= re-tag definition mechanisms specified in RFC 2506. That registration mecha= nism has multiple categories of features with differing approval mechanisms= for each category. Some require an RFC, some expert review, and some no ap= proval at all. Whether this can be made to work for proxy-features remains = to be seen.) Thanks, Paul (as co-chair) _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From peter.leis@nsn.com Tue Feb 28 00:24:29 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F342621F84EA for ; Tue, 28 Feb 2012 00:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjBJStZ0iJAH for ; Tue, 28 Feb 2012 00:24:28 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id F264621F84E7 for ; Tue, 28 Feb 2012 00:24:27 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q1S8OLHX011398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Feb 2012 09:24:21 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q1S8OGLs003673; Tue, 28 Feb 2012 09:24:21 +0100 Received: from DEMUEXC035.nsn-intra.net ([10.150.128.26]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 09:24:17 +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: Tue, 28 Feb 2012 09:24:16 +0100 Message-ID: <79C4240C13B4C84B910850B96B1B431203D9FBE3@DEMUEXC035.nsn-intra.net> In-Reply-To: <4F4BC754.4030606@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft Thread-Index: Acz1e0FNEc+dr0XcQF28mbeyyWamcQAdiodQ References: <4F4BC754.4030606@alum.mit.edu> From: "Leis, Peter (NSN - DE/Munich)" To: "ext Paul Kyzivat" , "SIPCORE" X-OriginalArrivalTime: 28 Feb 2012 08:24:17.0815 (UTC) FILETIME=[5D012A70:01CCF5F2] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2278 X-purgate-ID: 151667::1330417461-000015E0-03DC8A37/0-0/0-0 Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 08:24:29 -0000 Hello, working in 3GPP IMS area, where we need this mechanism, I support adopting the draft as wg document.=20 Peter -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Paul Kyzivat Sent: Monday, February 27, 2012 7:12 PM To: SIPCORE Subject: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft SIPCORE group: There has been general agreement on the proxy-feature requirements, so=20 now we have a basis to work on a corresponding mechanism. Robert has=20 agreed that sipcore is the proper place to do this work. The document=20 draft-holmberg-sipcore-proxy-feature-04 has been proposed as a mechanism. I am requesting that discussion begin, on the sipcore list, on the=20 suitability of this draft as a basis for a wg mechanism document that=20 will meet the requirements expressed in=20 draft-ietf-sipcore-proxy-feature-reqs-03.txt. One issue that remains fuzzy is distinguishing what is and is not a=20 valid proxy-feature. We have a few examples from the use cases, but=20 little clarity beyond that on any guidelines for what would qualify and=20 what would not. However it seems likely that few, if any, of the=20 existing defined feature tags (even those in the sip tree) would be=20 appropriate. So one thing I will be looking for in the mechanism before it is=20 finalized is a way to resolve this. This might be a set of criteria that can be applied to any new candidate proxy-feature. Or if that proves=20 impossible to define, then we can fall back on requiring standards=20 action for a feature to be defined. So I encourage discussion of this issue. (Currently the draft proposes to build on RFC 3840 and its use of the=20 feature-tag definition mechanisms specified in RFC 2506. That=20 registration mechanism has multiple categories of features with=20 differing approval mechanisms for each category. Some require an RFC,=20 some expert review, and some no approval at all. Whether this can be=20 made to work for proxy-features remains to be seen.) Thanks, Paul (as co-chair) _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From R.Jesske@telekom.de Tue Feb 28 05:06:53 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A2821F85D9 for ; Tue, 28 Feb 2012 05:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COEp2UZ8nbwx for ; Tue, 28 Feb 2012 05:06:52 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 406FF21F85D5 for ; Tue, 28 Feb 2012 05:06:51 -0800 (PST) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 28 Feb 2012 14:06:49 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.9]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 28 Feb 2012 14:06:48 +0100 From: To: , , Date: Tue, 28 Feb 2012 14:06:47 +0100 Thread-Topic: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft Thread-Index: Acz1e0FNEc+dr0XcQF28mbeyyWamcQAdiodQAAoCEUA= Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D139F8611B2@HE111648.emea1.cds.t-internal.com> References: <4F4BC754.4030606@alum.mit.edu> <79C4240C13B4C84B910850B96B1B431203D9FBE3@DEMUEXC035.nsn-intra.net> In-Reply-To: <79C4240C13B4C84B910850B96B1B431203D9FBE3@DEMUEXC035.nsn-intra.net> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 13:06:53 -0000 Not only from 3GPP work also seen form our own use cases I fully support th= e adoption of the draft as wg document. Roland -----Urspr=FCngliche Nachricht----- Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag = von Leis, Peter (NSN - DE/Munich) Gesendet: Dienstag, 28. Februar 2012 09:24 An: ext Paul Kyzivat; SIPCORE Betreff: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as = a wgdraft Hello, working in 3GPP IMS area, where we need this mechanism, I support adopting = the draft as wg document. Peter -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of ext Paul Kyzivat Sent: Monday, February 27, 2012 7:12 PM To: SIPCORE Subject: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wg= draft SIPCORE group: There has been general agreement on the proxy-feature requirements, so now = we have a basis to work on a corresponding mechanism. Robert has agreed tha= t sipcore is the proper place to do this work. The document draft-holmberg-sipcore-proxy-feature-04 has been proposed as a mechanism. I am requesting that discussion begin, on the sipcore list, on the suitabil= ity of this draft as a basis for a wg mechanism document that will meet the= requirements expressed in draft-ietf-sipcore-proxy-feature-reqs-03.txt. One issue that remains fuzzy is distinguishing what is and is not a valid p= roxy-feature. We have a few examples from the use cases, but little clarity= beyond that on any guidelines for what would qualify and what would not. H= owever it seems likely that few, if any, of the existing defined feature ta= gs (even those in the sip tree) would be appropriate. So one thing I will be looking for in the mechanism before it is finalized = is a way to resolve this. This might be a set of criteria that can be applied to any new candidate proxy-feature. Or if that proves imposs= ible to define, then we can fall back on requiring standards action for a f= eature to be defined. So I encourage discussion of this issue. (Currently the draft proposes to build on RFC 3840 and its use of the featu= re-tag definition mechanisms specified in RFC 2506. That registration mecha= nism has multiple categories of features with differing approval mechanisms= for each category. Some require an RFC, some expert review, and some no ap= proval at all. Whether this can be made to work for proxy-features remains = to be seen.) Thanks, Paul (as co-chair) _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From md3135@att.com Tue Feb 28 05:21:41 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF88721F864E for ; Tue, 28 Feb 2012 05:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7OKEkzbSSxY for ; Tue, 28 Feb 2012 05:21:41 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id F2CDF21F864D for ; Tue, 28 Feb 2012 05:21:40 -0800 (PST) X-Env-Sender: md3135@att.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1330435299!13815859!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12882 invoked from network); 28 Feb 2012 13:21:40 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-13.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Feb 2012 13:21:40 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1SDMAqH012644; Tue, 28 Feb 2012 08:22:10 -0500 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1SDM6qc012602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Feb 2012 08:22:06 -0500 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by sflint02.pst.cso.att.com (RSA Interceptor); Tue, 28 Feb 2012 08:21:27 -0500 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.111]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.01.0355.002; Tue, 28 Feb 2012 08:21:27 -0500 From: "DOLLY, MARTIN C" To: "R.Jesske@telekom.de" , "peter.leis@nsn.com" , "pkyzivat@alum.mit.edu" , "sipcore@ietf.org" Thread-Topic: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft Thread-Index: AQHM9hndfJf2309PyUeobbtipGi/3ZZSSxpQ Date: Tue, 28 Feb 2012 13:21:26 +0000 Message-ID: References: <4F4BC754.4030606@alum.mit.edu> <79C4240C13B4C84B910850B96B1B431203D9FBE3@DEMUEXC035.nsn-intra.net> <580BEA5E3B99744AB1F5BFF5E9A3C67D139F8611B2@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D139F8611B2@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.88.218] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 13:21:41 -0000 AT&T supports the mechanism for WG adoption=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of R.Jesske@telekom.de Sent: Tuesday, February 28, 2012 8:07 AM To: peter.leis@nsn.com; pkyzivat@alum.mit.edu; sipcore@ietf.org Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as = a wgdraft Not only from 3GPP work also seen form our own use cases I fully support th= e adoption of the draft as wg document. Roland -----Urspr=FCngliche Nachricht----- Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag = von Leis, Peter (NSN - DE/Munich) Gesendet: Dienstag, 28. Februar 2012 09:24 An: ext Paul Kyzivat; SIPCORE Betreff: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as = a wgdraft Hello, working in 3GPP IMS area, where we need this mechanism, I support adopting = the draft as wg document. Peter -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of ext Paul Kyzivat Sent: Monday, February 27, 2012 7:12 PM To: SIPCORE Subject: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wg= draft SIPCORE group: There has been general agreement on the proxy-feature requirements, so now = we have a basis to work on a corresponding mechanism. Robert has agreed tha= t sipcore is the proper place to do this work. The document draft-holmberg-sipcore-proxy-feature-04 has been proposed as a mechanism. I am requesting that discussion begin, on the sipcore list, on the suitabil= ity of this draft as a basis for a wg mechanism document that will meet the= requirements expressed in draft-ietf-sipcore-proxy-feature-reqs-03.txt. One issue that remains fuzzy is distinguishing what is and is not a valid p= roxy-feature. We have a few examples from the use cases, but little clarity= beyond that on any guidelines for what would qualify and what would not. H= owever it seems likely that few, if any, of the existing defined feature ta= gs (even those in the sip tree) would be appropriate. So one thing I will be looking for in the mechanism before it is finalized = is a way to resolve this. This might be a set of criteria that can be applied to any new candidate proxy-feature. Or if that proves imposs= ible to define, then we can fall back on requiring standards action for a f= eature to be defined. So I encourage discussion of this issue. (Currently the draft proposes to build on RFC 3840 and its use of the featu= re-tag definition mechanisms specified in RFC 2506. That registration mecha= nism has multiple categories of features with differing approval mechanisms= for each category. Some require an RFC, some expert review, and some no ap= proval at all. Whether this can be made to work for proxy-features remains = to be seen.) Thanks, Paul (as co-chair) _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Tue Feb 28 06:08:24 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A84521F8672 for ; Tue, 28 Feb 2012 06:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqeFVuUK2nUr for ; Tue, 28 Feb 2012 06:08:23 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 4C98121F8675 for ; Tue, 28 Feb 2012 06:08:23 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta13.westchester.pa.mail.comcast.net with comcast id fRcE1i00A1ZXKqc5DS8P7n; Tue, 28 Feb 2012 14:08:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta21.westchester.pa.mail.comcast.net with comcast id fS8P1i01E07duvL3hS8PQl; Tue, 28 Feb 2012 14:08:23 +0000 Message-ID: <4F4CDFD5.2030208@alum.mit.edu> Date: Tue, 28 Feb 2012 09:08:21 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: R.Jesske@telekom.de References: <4F4BC754.4030606@alum.mit.edu> <79C4240C13B4C84B910850B96B1B431203D9FBE3@DEMUEXC035.nsn-intra.net> <580BEA5E3B99744AB1F5BFF5E9A3C67D139F8611B2@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D139F8611B2@HE111648.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 14:08:24 -0000 On 2/28/12 8:06 AM, R.Jesske@telekom.de wrote: > Not only from 3GPP work also seen form our own use cases I fully support the adoption of the draft as wg document. Since many of us have struggled to understand the uses of this mechanism, it would be great if those of you who have uses would describe them. Are the uses you see ones that would have proprietary feature tags? Or are they of general use that should have a public tag? Thanks, Paul > Roland > > -----Ursprüngliche Nachricht----- > Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag von Leis, Peter (NSN - DE/Munich) > Gesendet: Dienstag, 28. Februar 2012 09:24 > An: ext Paul Kyzivat; SIPCORE > Betreff: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft > > Hello, > > working in 3GPP IMS area, where we need this mechanism, I support adopting the draft as wg document. > > Peter > > > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Paul Kyzivat > Sent: Monday, February 27, 2012 7:12 PM > To: SIPCORE > Subject: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft > > SIPCORE group: > > There has been general agreement on the proxy-feature requirements, so now we have a basis to work on a corresponding mechanism. Robert has agreed that sipcore is the proper place to do this work. The document > draft-holmberg-sipcore-proxy-feature-04 has been proposed as a mechanism. > > I am requesting that discussion begin, on the sipcore list, on the suitability of this draft as a basis for a wg mechanism document that will meet the requirements expressed in draft-ietf-sipcore-proxy-feature-reqs-03.txt. > > One issue that remains fuzzy is distinguishing what is and is not a valid proxy-feature. We have a few examples from the use cases, but little clarity beyond that on any guidelines for what would qualify and what would not. However it seems likely that few, if any, of the existing defined feature tags (even those in the sip tree) would be appropriate. > > So one thing I will be looking for in the mechanism before it is finalized is a way to resolve this. This might be a set of criteria that > > can be applied to any new candidate proxy-feature. Or if that proves impossible to define, then we can fall back on requiring standards action for a feature to be defined. So I encourage discussion of this issue. > > (Currently the draft proposes to build on RFC 3840 and its use of the feature-tag definition mechanisms specified in RFC 2506. That registration mechanism has multiple categories of features with differing approval mechanisms for each category. Some require an RFC, some expert review, and some no approval at all. Whether this can be made to work for proxy-features remains to be seen.) > > Thanks, > Paul (as co-chair) > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From laura.liess.dt@googlemail.com Tue Feb 28 07:13:00 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3219C21F86C8 for ; Tue, 28 Feb 2012 07:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.263 X-Spam-Level: X-Spam-Status: No, score=-3.263 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tu35wc5jT56 for ; Tue, 28 Feb 2012 07:12:59 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC84321F86B8 for ; Tue, 28 Feb 2012 07:12:56 -0800 (PST) Received: by werb10 with SMTP id b10so2305399wer.31 for ; Tue, 28 Feb 2012 07:12:56 -0800 (PST) Received-SPF: pass (google.com: domain of laura.liess.dt@googlemail.com designates 10.180.92.165 as permitted sender) client-ip=10.180.92.165; Authentication-Results: mr.google.com; spf=pass (google.com: domain of laura.liess.dt@googlemail.com designates 10.180.92.165 as permitted sender) smtp.mail=laura.liess.dt@googlemail.com; dkim=pass header.i=laura.liess.dt@googlemail.com Received: from mr.google.com ([10.180.92.165]) by 10.180.92.165 with SMTP id cn5mr8551461wib.2.1330441976011 (num_hops = 1); Tue, 28 Feb 2012 07:12:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=YTOncQd/LRwUMp4rHlaK2xlEUzh4W0rzHQJyVbVzsbY=; b=OwCNnm6AckOacBuGsZQag7kdxMXVwjeEP1IH0Cr4aJT5IdIpjHS1rlbuaI4tAhuTzr MWk7Kd6uoA7sC/ElBU1izt66L/0P2C8EVGB+jkbndIgF8nV5yXIX7bW69iDF+9C5c2Uw xnZeuTVljIIvcveamUxKWluCOVXCNUqD8HT4o= MIME-Version: 1.0 Received: by 10.180.92.165 with SMTP id cn5mr6742805wib.2.1330441975942; Tue, 28 Feb 2012 07:12:55 -0800 (PST) Received: by 10.227.112.206 with HTTP; Tue, 28 Feb 2012 07:12:55 -0800 (PST) In-Reply-To: References: <4F4BC754.4030606@alum.mit.edu> <79C4240C13B4C84B910850B96B1B431203D9FBE3@DEMUEXC035.nsn-intra.net> <580BEA5E3B99744AB1F5BFF5E9A3C67D139F8611B2@HE111648.emea1.cds.t-internal.com> Date: Tue, 28 Feb 2012 16:12:55 +0100 Message-ID: From: Laura Liess To: "sipcore@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 15:13:00 -0000 I support the adoption of the draft as wg document. Thank you Laura 2012/2/28 DOLLY, MARTIN C : > AT&T supports the mechanism for WG adoption > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f Of R.Jesske@telekom.de > Sent: Tuesday, February 28, 2012 8:07 AM > To: peter.leis@nsn.com; pkyzivat@alum.mit.edu; sipcore@ietf.org > Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature a= s a wgdraft > > Not only from 3GPP work also seen form our own use cases I fully support = the adoption of the draft as wg document. > > Roland > > -----Urspr=C3=BCngliche Nachricht----- > Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftra= g von Leis, Peter (NSN - DE/Munich) > Gesendet: Dienstag, 28. Februar 2012 09:24 > An: ext Paul Kyzivat; SIPCORE > Betreff: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature a= s a wgdraft > > Hello, > > working in 3GPP IMS area, where we need this mechanism, I support adoptin= g the draft as wg document. > > Peter > > > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f Of ext Paul Kyzivat > Sent: Monday, February 27, 2012 7:12 PM > To: SIPCORE > Subject: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a = wgdraft > > SIPCORE group: > > There has been general agreement on the proxy-feature requirements, so no= w we have a basis to work on a corresponding mechanism. Robert has agreed t= hat sipcore is the proper place to do this work. The document > draft-holmberg-sipcore-proxy-feature-04 has been proposed as a mechanism. > > I am requesting that discussion begin, on the sipcore list, on the suitab= ility of this draft as a basis for a wg mechanism document that will meet t= he requirements expressed in draft-ietf-sipcore-proxy-feature-reqs-03.txt. > > One issue that remains fuzzy is distinguishing what is and is not a valid= proxy-feature. We have a few examples from the use cases, but little clari= ty beyond that on any guidelines for what would qualify and what would not.= However it seems likely that few, if any, of the existing defined feature = tags (even those in the sip tree) would be appropriate. > > So one thing I will be looking for in the mechanism before it is finalize= d is a way to resolve this. This might be a set of criteria that > > can be applied to any new candidate proxy-feature. Or if that proves impo= ssible to define, then we can fall back on requiring standards action for a= feature to be defined. So I encourage discussion of this issue. > > (Currently the draft proposes to build on RFC 3840 and its use of the fea= ture-tag definition mechanisms specified in RFC 2506. That registration mec= hanism has multiple categories of features with differing approval mechanis= ms for each category. Some require an RFC, some expert review, and some no = approval at all. Whether this can be made to work for proxy-features remain= s to be seen.) > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks, > =C2=A0 =C2=A0 =C2=A0 =C2=A0Paul (as co-chair) > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From marianne.mohali@orange.com Tue Feb 28 07:28:01 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F414821F8631 for ; Tue, 28 Feb 2012 07:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ScqzHg6GYMR for ; Tue, 28 Feb 2012 07:28:00 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id CE08F21F8615 for ; Tue, 28 Feb 2012 07:27:59 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 4F4F43B462F for ; Tue, 28 Feb 2012 16:27:58 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id DB8C235C045 for ; Tue, 28 Feb 2012 16:27:57 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.01.0323.000; Tue, 28 Feb 2012 16:27:57 +0100 From: To: "sipcore@ietf.org" Thread-Topic: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft Thread-Index: AQHM9it31BuidUCTxkiroFqxXyN2f5ZSbmIA Date: Tue, 28 Feb 2012 15:27:56 +0000 Message-ID: <27004_1330442878_4F4CF27D_27004_1371_5_8B970F90C584EA4E97D5BAAC9172DBB8019604@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <4F4BC754.4030606@alum.mit.edu> <79C4240C13B4C84B910850B96B1B431203D9FBE3@DEMUEXC035.nsn-intra.net> <580BEA5E3B99744AB1F5BFF5E9A3C67D139F8611B2@HE111648.emea1.cds.t-internal.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.1.19.234517 Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 15:28:01 -0000 SGksDQoNCk9yYW5nZSBzdXBwb3J0cyB0aGUgYWRvcHRpb24gb2YgdGhpcyBkcmFmdCBhcyBXRyBk b2N1bWVudC4NCg0KTWFyaWFubmUNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKg OiBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5v cmddIERlIGxhIHBhcnQgZGUgTGF1cmEgTGllc3MNCkVudm95w6nCoDogbWFyZGkgMjggZsOpdnJp ZXIgMjAxMiAxNjoxMw0Kw4DCoDogc2lwY29yZUBpZXRmLm9yZw0KT2JqZXTCoDogUmU6IFtzaXBj b3JlXSBBZG9wdGlvbiBvZiBkcmFmdC1ob2xtYmVyZy1zaXBjb3JlLXByb3h5LWZlYXR1cmUgYXMg YSB3Z2RyYWZ0DQoNCkkgIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoZSBkcmFmdCBhcyB3ZyBk b2N1bWVudC4NCg0KVGhhbmsgeW91DQpMYXVyYQ0KDQoyMDEyLzIvMjggRE9MTFksIE1BUlRJTiBD IDxtZDMxMzVAYXR0LmNvbT46DQo+IEFUJlQgc3VwcG9ydHMgdGhlIG1lY2hhbmlzbSBmb3IgV0cg YWRvcHRpb24NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2lwY29y ZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgUi5KZXNza2VAdGVsZWtvbS5kZQ0KPiBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAy OCwgMjAxMiA4OjA3IEFNDQo+IFRvOiBwZXRlci5sZWlzQG5zbi5jb207IHBreXppdmF0QGFsdW0u bWl0LmVkdTsgc2lwY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIEFkb3B0 aW9uIG9mIGRyYWZ0LWhvbG1iZXJnLXNpcGNvcmUtcHJveHktZmVhdHVyZSBhcyBhIHdnZHJhZnQN Cj4NCj4gTm90IG9ubHkgZnJvbSAzR1BQIHdvcmsgYWxzbyBzZWVuIGZvcm0gb3VyIG93biB1c2Ug Y2FzZXMgSSBmdWxseSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGUgZHJhZnQgYXMgd2cgZG9j dW1lbnQuDQo+DQo+IFJvbGFuZA0KPg0KPiAtLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0t LS0tDQo+IFZvbjogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2lwY29yZS1ib3Vu Y2VzQGlldGYub3JnXSBJbSBBdWZ0cmFnIHZvbiBMZWlzLCBQZXRlciAoTlNOIC0gREUvTXVuaWNo KQ0KPiBHZXNlbmRldDogRGllbnN0YWcsIDI4LiBGZWJydWFyIDIwMTIgMDk6MjQNCj4gQW46IGV4 dCBQYXVsIEt5eml2YXQ7IFNJUENPUkUNCj4gQmV0cmVmZjogUmU6IFtzaXBjb3JlXSBBZG9wdGlv biBvZiBkcmFmdC1ob2xtYmVyZy1zaXBjb3JlLXByb3h5LWZlYXR1cmUgYXMgYSB3Z2RyYWZ0DQo+ DQo+IEhlbGxvLA0KPg0KPiB3b3JraW5nIGluIDNHUFAgSU1TIGFyZWEsIHdoZXJlIHdlIG5lZWQg dGhpcyBtZWNoYW5pc20sIEkgc3VwcG9ydCBhZG9wdGluZyB0aGUgZHJhZnQgYXMgd2cgZG9jdW1l bnQuDQo+DQo+IFBldGVyDQo+DQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBQYXVsIEt5eml2YXQNCj4gU2VudDogTW9uZGF5LCBG ZWJydWFyeSAyNywgMjAxMiA3OjEyIFBNDQo+IFRvOiBTSVBDT1JFDQo+IFN1YmplY3Q6IFtzaXBj b3JlXSBBZG9wdGlvbiBvZiBkcmFmdC1ob2xtYmVyZy1zaXBjb3JlLXByb3h5LWZlYXR1cmUgYXMg YSB3Z2RyYWZ0DQo+DQo+IFNJUENPUkUgZ3JvdXA6DQo+DQo+IFRoZXJlIGhhcyBiZWVuIGdlbmVy YWwgYWdyZWVtZW50IG9uIHRoZSBwcm94eS1mZWF0dXJlIHJlcXVpcmVtZW50cywgc28gbm93IHdl IGhhdmUgYSBiYXNpcyB0byB3b3JrIG9uIGEgY29ycmVzcG9uZGluZyBtZWNoYW5pc20uIFJvYmVy dCBoYXMgYWdyZWVkIHRoYXQgc2lwY29yZSBpcyB0aGUgcHJvcGVyIHBsYWNlIHRvIGRvIHRoaXMg d29yay4gVGhlIGRvY3VtZW50DQo+IGRyYWZ0LWhvbG1iZXJnLXNpcGNvcmUtcHJveHktZmVhdHVy ZS0wNCBoYXMgYmVlbiBwcm9wb3NlZCBhcyBhIG1lY2hhbmlzbS4NCj4NCj4gSSBhbSByZXF1ZXN0 aW5nIHRoYXQgZGlzY3Vzc2lvbiBiZWdpbiwgb24gdGhlIHNpcGNvcmUgbGlzdCwgb24gdGhlIHN1 aXRhYmlsaXR5IG9mIHRoaXMgZHJhZnQgYXMgYSBiYXNpcyBmb3IgYSB3ZyBtZWNoYW5pc20gZG9j dW1lbnQgdGhhdCB3aWxsIG1lZXQgdGhlIHJlcXVpcmVtZW50cyBleHByZXNzZWQgaW4gZHJhZnQt aWV0Zi1zaXBjb3JlLXByb3h5LWZlYXR1cmUtcmVxcy0wMy50eHQuDQo+DQo+IE9uZSBpc3N1ZSB0 aGF0IHJlbWFpbnMgZnV6enkgaXMgZGlzdGluZ3Vpc2hpbmcgd2hhdCBpcyBhbmQgaXMgbm90IGEg dmFsaWQgcHJveHktZmVhdHVyZS4gV2UgaGF2ZSBhIGZldyBleGFtcGxlcyBmcm9tIHRoZSB1c2Ug Y2FzZXMsIGJ1dCBsaXR0bGUgY2xhcml0eSBiZXlvbmQgdGhhdCBvbiBhbnkgZ3VpZGVsaW5lcyBm b3Igd2hhdCB3b3VsZCBxdWFsaWZ5IGFuZCB3aGF0IHdvdWxkIG5vdC4gSG93ZXZlciBpdCBzZWVt cyBsaWtlbHkgdGhhdCBmZXcsIGlmIGFueSwgb2YgdGhlIGV4aXN0aW5nIGRlZmluZWQgZmVhdHVy ZSB0YWdzIChldmVuIHRob3NlIGluIHRoZSBzaXAgdHJlZSkgd291bGQgYmUgYXBwcm9wcmlhdGUu DQo+DQo+IFNvIG9uZSB0aGluZyBJIHdpbGwgYmUgbG9va2luZyBmb3IgaW4gdGhlIG1lY2hhbmlz bSBiZWZvcmUgaXQgaXMgZmluYWxpemVkIGlzIGEgd2F5IHRvIHJlc29sdmUgdGhpcy4gVGhpcyBt aWdodCBiZSBhIHNldCBvZiBjcml0ZXJpYSB0aGF0DQo+DQo+IGNhbiBiZSBhcHBsaWVkIHRvIGFu eSBuZXcgY2FuZGlkYXRlIHByb3h5LWZlYXR1cmUuIE9yIGlmIHRoYXQgcHJvdmVzIGltcG9zc2li bGUgdG8gZGVmaW5lLCB0aGVuIHdlIGNhbiBmYWxsIGJhY2sgb24gcmVxdWlyaW5nIHN0YW5kYXJk cyBhY3Rpb24gZm9yIGEgZmVhdHVyZSB0byBiZSBkZWZpbmVkLiBTbyBJIGVuY291cmFnZSBkaXNj dXNzaW9uIG9mIHRoaXMgaXNzdWUuDQo+DQo+IChDdXJyZW50bHkgdGhlIGRyYWZ0IHByb3Bvc2Vz IHRvIGJ1aWxkIG9uIFJGQyAzODQwIGFuZCBpdHMgdXNlIG9mIHRoZSBmZWF0dXJlLXRhZyBkZWZp bml0aW9uIG1lY2hhbmlzbXMgc3BlY2lmaWVkIGluIFJGQyAyNTA2LiBUaGF0IHJlZ2lzdHJhdGlv biBtZWNoYW5pc20gaGFzIG11bHRpcGxlIGNhdGVnb3JpZXMgb2YgZmVhdHVyZXMgd2l0aCBkaWZm ZXJpbmcgYXBwcm92YWwgbWVjaGFuaXNtcyBmb3IgZWFjaCBjYXRlZ29yeS4gU29tZSByZXF1aXJl IGFuIFJGQywgc29tZSBleHBlcnQgcmV2aWV3LCBhbmQgc29tZSBubyBhcHByb3ZhbCBhdCBhbGwu IFdoZXRoZXIgdGhpcyBjYW4gYmUgbWFkZSB0byB3b3JrIGZvciBwcm94eS1mZWF0dXJlcyByZW1h aW5zIHRvIGJlIHNlZW4uKQ0KPg0KPiDCoCDCoCDCoCDCoFRoYW5rcywNCj4gwqAgwqAgwqAgwqBQ YXVsIChhcyBjby1jaGFpcikNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lwY29yZSBt YWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lwY29y ZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQoKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg aW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu dCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jp c2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6 IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMg cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRp YmxlcyBkJ2FsdGVyYXRpb24sCkZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGRlY2xpbmUgdG91dGUg cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs c2lmaWUuIE1lcmNpCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90 ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29w aWVkIHdpdGhvdXQgYXV0aG9yaXphdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNl IFRlbGVjb20gLSBPcmFuZ2Ugc2hhbGwgbm90IGJlIGxpYWJsZSBpZiB0aGlzIG1lc3NhZ2Ugd2Fz IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From lishitao@huawei.com Tue Feb 28 17:40:47 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B960821E804F for ; Tue, 28 Feb 2012 17:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=-4.524, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12Wva3ix2Sh2 for ; Tue, 28 Feb 2012 17:40:46 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6A621E803F for ; Tue, 28 Feb 2012 17:40:46 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0400EADSNXB7@szxga05-in.huawei.com> for sipcore@ietf.org; Wed, 29 Feb 2012 09:40:45 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M04008K1SNXCX@szxga05-in.huawei.com> for sipcore@ietf.org; Wed, 29 Feb 2012 09:40:45 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHM12082; Wed, 29 Feb 2012 09:40:44 +0800 Received: from SZXEML425-HUB.china.huawei.com (10.72.61.33) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 29 Feb 2012 09:40:12 +0800 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.222]) by szxeml425-hub.china.huawei.com ([10.72.61.33]) with mapi id 14.01.0323.003; Wed, 29 Feb 2012 09:40:41 +0800 Date: Wed, 29 Feb 2012 01:42:06 +0000 From: Li Shitao In-reply-to: <79C4240C13B4C84B910850B96B1B431203D9FBE3@DEMUEXC035.nsn-intra.net> X-Originating-IP: [10.138.73.34] To: "Leis, Peter (NSN - DE/Munich)" , ext Paul Kyzivat , SIPCORE Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft Thread-index: AQHM9fJtWr0P6yi7wEu6QAVx4I5lmJZTGhzg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F4BC754.4030606@alum.mit.edu> <79C4240C13B4C84B910850B96B1B431203D9FBE3@DEMUEXC035.nsn-intra.net> Subject: [sipcore] =?gb2312?b?tPC4tDogIEFkb3B0aW9uIG9mIGRyYWZ0LWhvbG1iZXJn?= =?gb2312?b?LXNpcGNvcmUtcHJveHktZmVhdHVyZSBhcyBhCXdnZHJhZnQ=?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 01:40:47 -0000 SGkgYWxsDQpJIGFsc28gc3VwcG9ydCB0aGlzIGRyYWZ0IGFzIGEgV0cgZG9jdW1lbnQuDQoNCnNo aXRhbw0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7Iyzogc2lwY29yZS1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIExlaXMsIFBldGVyIChO U04gLSBERS9NdW5pY2gpDQq3osvNyrG85DogMjAxMsTqMtTCMjjI1SAxNjoyNA0KytW8/sjLOiBl eHQgUGF1bCBLeXppdmF0OyBTSVBDT1JFDQrW98ziOiBSZTogW3NpcGNvcmVdIEFkb3B0aW9uIG9m IGRyYWZ0LWhvbG1iZXJnLXNpcGNvcmUtcHJveHktZmVhdHVyZSBhcyBhIHdnZHJhZnQNCg0KSGVs bG8sDQoNCndvcmtpbmcgaW4gM0dQUCBJTVMgYXJlYSwgd2hlcmUgd2UgbmVlZCB0aGlzIG1lY2hh bmlzbSwgSSBzdXBwb3J0DQphZG9wdGluZyB0aGUgZHJhZnQgYXMgd2cgZG9jdW1lbnQuIA0KDQpQ ZXRlcg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNpcGNvcmUtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24NCkJlaGFs ZiBPZiBleHQgUGF1bCBLeXppdmF0DQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDI3LCAyMDEyIDc6 MTIgUE0NClRvOiBTSVBDT1JFDQpTdWJqZWN0OiBbc2lwY29yZV0gQWRvcHRpb24gb2YgZHJhZnQt aG9sbWJlcmctc2lwY29yZS1wcm94eS1mZWF0dXJlIGFzIGENCndnZHJhZnQNCg0KU0lQQ09SRSBn cm91cDoNCg0KVGhlcmUgaGFzIGJlZW4gZ2VuZXJhbCBhZ3JlZW1lbnQgb24gdGhlIHByb3h5LWZl YXR1cmUgcmVxdWlyZW1lbnRzLCBzbyANCm5vdyB3ZSBoYXZlIGEgYmFzaXMgdG8gd29yayBvbiBh IGNvcnJlc3BvbmRpbmcgbWVjaGFuaXNtLiBSb2JlcnQgaGFzIA0KYWdyZWVkIHRoYXQgc2lwY29y ZSBpcyB0aGUgcHJvcGVyIHBsYWNlIHRvIGRvIHRoaXMgd29yay4gVGhlIGRvY3VtZW50IA0KZHJh ZnQtaG9sbWJlcmctc2lwY29yZS1wcm94eS1mZWF0dXJlLTA0IGhhcyBiZWVuIHByb3Bvc2VkIGFz IGENCm1lY2hhbmlzbS4NCg0KSSBhbSByZXF1ZXN0aW5nIHRoYXQgZGlzY3Vzc2lvbiBiZWdpbiwg b24gdGhlIHNpcGNvcmUgbGlzdCwgb24gdGhlIA0Kc3VpdGFiaWxpdHkgb2YgdGhpcyBkcmFmdCBh cyBhIGJhc2lzIGZvciBhIHdnIG1lY2hhbmlzbSBkb2N1bWVudCB0aGF0IA0Kd2lsbCBtZWV0IHRo ZSByZXF1aXJlbWVudHMgZXhwcmVzc2VkIGluIA0KZHJhZnQtaWV0Zi1zaXBjb3JlLXByb3h5LWZl YXR1cmUtcmVxcy0wMy50eHQuDQoNCk9uZSBpc3N1ZSB0aGF0IHJlbWFpbnMgZnV6enkgaXMgZGlz dGluZ3Vpc2hpbmcgd2hhdCBpcyBhbmQgaXMgbm90IGEgDQp2YWxpZCBwcm94eS1mZWF0dXJlLiBX ZSBoYXZlIGEgZmV3IGV4YW1wbGVzIGZyb20gdGhlIHVzZSBjYXNlcywgYnV0IA0KbGl0dGxlIGNs YXJpdHkgYmV5b25kIHRoYXQgb24gYW55IGd1aWRlbGluZXMgZm9yIHdoYXQgd291bGQgcXVhbGlm eSBhbmQgDQp3aGF0IHdvdWxkIG5vdC4gSG93ZXZlciBpdCBzZWVtcyBsaWtlbHkgdGhhdCBmZXcs IGlmIGFueSwgb2YgdGhlIA0KZXhpc3RpbmcgZGVmaW5lZCBmZWF0dXJlIHRhZ3MgKGV2ZW4gdGhv c2UgaW4gdGhlIHNpcCB0cmVlKSB3b3VsZCBiZSANCmFwcHJvcHJpYXRlLg0KDQpTbyBvbmUgdGhp bmcgSSB3aWxsIGJlIGxvb2tpbmcgZm9yIGluIHRoZSBtZWNoYW5pc20gYmVmb3JlIGl0IGlzIA0K ZmluYWxpemVkIGlzIGEgd2F5IHRvIHJlc29sdmUgdGhpcy4gVGhpcyBtaWdodCBiZSBhIHNldCBv ZiBjcml0ZXJpYSB0aGF0DQoNCmNhbiBiZSBhcHBsaWVkIHRvIGFueSBuZXcgY2FuZGlkYXRlIHBy b3h5LWZlYXR1cmUuIE9yIGlmIHRoYXQgcHJvdmVzIA0KaW1wb3NzaWJsZSB0byBkZWZpbmUsIHRo ZW4gd2UgY2FuIGZhbGwgYmFjayBvbiByZXF1aXJpbmcgc3RhbmRhcmRzIA0KYWN0aW9uIGZvciBh IGZlYXR1cmUgdG8gYmUgZGVmaW5lZC4gU28gSSBlbmNvdXJhZ2UgZGlzY3Vzc2lvbiBvZiB0aGlz DQppc3N1ZS4NCg0KKEN1cnJlbnRseSB0aGUgZHJhZnQgcHJvcG9zZXMgdG8gYnVpbGQgb24gUkZD IDM4NDAgYW5kIGl0cyB1c2Ugb2YgdGhlIA0KZmVhdHVyZS10YWcgZGVmaW5pdGlvbiBtZWNoYW5p c21zIHNwZWNpZmllZCBpbiBSRkMgMjUwNi4gVGhhdCANCnJlZ2lzdHJhdGlvbiBtZWNoYW5pc20g aGFzIG11bHRpcGxlIGNhdGVnb3JpZXMgb2YgZmVhdHVyZXMgd2l0aCANCmRpZmZlcmluZyBhcHBy b3ZhbCBtZWNoYW5pc21zIGZvciBlYWNoIGNhdGVnb3J5LiBTb21lIHJlcXVpcmUgYW4gUkZDLCAN CnNvbWUgZXhwZXJ0IHJldmlldywgYW5kIHNvbWUgbm8gYXBwcm92YWwgYXQgYWxsLiBXaGV0aGVy IHRoaXMgY2FuIGJlIA0KbWFkZSB0byB3b3JrIGZvciBwcm94eS1mZWF0dXJlcyByZW1haW5zIHRv IGJlIHNlZW4uKQ0KDQoJVGhhbmtzLA0KCVBhdWwgKGFzIGNvLWNoYWlyKQ0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxp c3QNCnNpcGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2lwY29yZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg== From krisztian.kiss@nokia.com Wed Feb 29 00:19:04 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E1421E8057 for ; Wed, 29 Feb 2012 00:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehdR66+AuR+6 for ; Wed, 29 Feb 2012 00:19:04 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id A1A8921E8017 for ; Wed, 29 Feb 2012 00:19:02 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1T8IuBS006422 for ; Wed, 29 Feb 2012 10:19:00 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Feb 2012 10:18:56 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.68]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0355.003; Wed, 29 Feb 2012 09:18:56 +0100 From: To: Thread-Topic: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft Thread-Index: AQHM9fJtVB4MzTgNPUahoJoMNYpR6ZZTiVxw Date: Wed, 29 Feb 2012 08:18:54 +0000 Message-ID: References: <4F4BC754.4030606@alum.mit.edu> <79C4240C13B4C84B910850B96B1B431203D9FBE3@DEMUEXC035.nsn-intra.net> In-Reply-To: <79C4240C13B4C84B910850B96B1B431203D9FBE3@DEMUEXC035.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [117.28.235.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Feb 2012 08:18:56.0843 (UTC) FILETIME=[C81A79B0:01CCF6BA] X-Nokia-AV: Clean Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 08:19:04 -0000 I also support adopting this draft as a WG item. Cheers, Krisztian -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of ext Leis, Peter (NSN - DE/Munich) Sent: Tuesday, February 28, 2012 00:24 To: ext Paul Kyzivat; SIPCORE Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as = a wgdraft Hello, working in 3GPP IMS area, where we need this mechanism, I support adopting = the draft as wg document.=20 Peter -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of ext Paul Kyzivat Sent: Monday, February 27, 2012 7:12 PM To: SIPCORE Subject: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wg= draft SIPCORE group: There has been general agreement on the proxy-feature requirements, so now = we have a basis to work on a corresponding mechanism. Robert has agreed tha= t sipcore is the proper place to do this work. The document draft-holmberg-sipcore-proxy-feature-04 has been proposed as a mechanism. I am requesting that discussion begin, on the sipcore list, on the suitabil= ity of this draft as a basis for a wg mechanism document that will meet the= requirements expressed in draft-ietf-sipcore-proxy-feature-reqs-03.txt. One issue that remains fuzzy is distinguishing what is and is not a valid p= roxy-feature. We have a few examples from the use cases, but little clarity= beyond that on any guidelines for what would qualify and what would not. H= owever it seems likely that few, if any, of the existing defined feature ta= gs (even those in the sip tree) would be appropriate. So one thing I will be looking for in the mechanism before it is finalized = is a way to resolve this. This might be a set of criteria that can be applied to any new candidate proxy-feature. Or if that proves imposs= ible to define, then we can fall back on requiring standards action for a f= eature to be defined. So I encourage discussion of this issue. (Currently the draft proposes to build on RFC 3840 and its use of the featu= re-tag definition mechanisms specified in RFC 2506. That registration mecha= nism has multiple categories of features with differing approval mechanisms= for each category. Some require an RFC, some expert review, and some no ap= proval at all. Whether this can be made to work for proxy-features remains = to be seen.) Thanks, Paul (as co-chair) _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christian.1.schmidt@nsn.com Wed Feb 29 07:00:25 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8905421F863F for ; Wed, 29 Feb 2012 07:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1cbN0PqudR3 for ; Wed, 29 Feb 2012 07:00:25 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9B30021F861C for ; Wed, 29 Feb 2012 07:00:24 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q1TF0Nlf011412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Feb 2012 16:00:23 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q1TF0M0I023138; Wed, 29 Feb 2012 16:00:22 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Feb 2012 16:00:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Feb 2012 16:00:20 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature asa wgdraft Thread-Index: AQHM9fJtVB4MzTgNPUahoJoMNYpR6ZZTiVxwgABwWZA= References: <4F4BC754.4030606@alum.mit.edu><79C4240C13B4C84B910850B96B1B431203D9FBE3@DEMUEXC035.nsn-intra.net> From: "Schmidt, Christian 1. (NSN - DE/Munich)" To: , X-OriginalArrivalTime: 29 Feb 2012 15:00:22.0793 (UTC) FILETIME=[DC72C790:01CCF6F2] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3231 X-purgate-ID: 151667::1330527623-00007EDF-D7689833/0-0/0-0 Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature asa wgdraft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 15:00:25 -0000 I support the adoption of the draft as wg document. Christian -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of ext krisztian.kiss@nokia.com Sent: Wednesday, February 29, 2012 9:19 AM To: sipcore@ietf.org Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature asa wgdraft I also support adopting this draft as a WG item. Cheers, Krisztian -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Leis, Peter (NSN - DE/Munich) Sent: Tuesday, February 28, 2012 00:24 To: ext Paul Kyzivat; SIPCORE Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft Hello, working in 3GPP IMS area, where we need this mechanism, I support adopting the draft as wg document.=20 Peter -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Paul Kyzivat Sent: Monday, February 27, 2012 7:12 PM To: SIPCORE Subject: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft SIPCORE group: There has been general agreement on the proxy-feature requirements, so now we have a basis to work on a corresponding mechanism. Robert has agreed that sipcore is the proper place to do this work. The document draft-holmberg-sipcore-proxy-feature-04 has been proposed as a mechanism. I am requesting that discussion begin, on the sipcore list, on the suitability of this draft as a basis for a wg mechanism document that will meet the requirements expressed in draft-ietf-sipcore-proxy-feature-reqs-03.txt. One issue that remains fuzzy is distinguishing what is and is not a valid proxy-feature. We have a few examples from the use cases, but little clarity beyond that on any guidelines for what would qualify and what would not. However it seems likely that few, if any, of the existing defined feature tags (even those in the sip tree) would be appropriate. So one thing I will be looking for in the mechanism before it is finalized is a way to resolve this. This might be a set of criteria that can be applied to any new candidate proxy-feature. Or if that proves impossible to define, then we can fall back on requiring standards action for a feature to be defined. So I encourage discussion of this issue. (Currently the draft proposes to build on RFC 3840 and its use of the feature-tag definition mechanisms specified in RFC 2506. That registration mechanism has multiple categories of features with differing approval mechanisms for each category. Some require an RFC, some expert review, and some no approval at all. Whether this can be made to work for proxy-features remains to be seen.) Thanks, Paul (as co-chair) _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore