From christer.holmberg@ericsson.com Mon Sep 3 04:49:55 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B0F21F84B3 for ; Mon, 3 Sep 2012 04:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.164 X-Spam-Level: X-Spam-Status: No, score=-6.164 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKs9ifDVasFV for ; Mon, 3 Sep 2012 04:49:54 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA1721F8464 for ; Mon, 3 Sep 2012 04:49:54 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-db-50449960d41c Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 40.B4.25676.06994405; Mon, 3 Sep 2012 13:49:52 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 3 Sep 2012 13:49:52 +0200 From: Christer Holmberg To: Martin Thomson , Paul Kyzivat Date: Mon, 3 Sep 2012 13:49:50 +0200 Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac1/8lnKst6E3WBoRxqqzrxucvfrlwJ10NaQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A460738@ESESSCMS0356.eemea.ericsson.se> References: <502AB594.8000800@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853408683666@ESESSCMS0356.eemea.ericsson.se> <502AC0FE.8040707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853408683686@ESESSCMS0356.eemea.ericsson.se> <155970D1DA8E174F9E46039E10E2AA351D94C4@XMB104ADS.rim.net> <7F2072F1E0DE894DA4B517B93C6A05853408683691@ESESSCMS0356.eemea.ericsson.se> <502E6573.80107@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA351DB027@XMB104ADS.rim.net> <44CDF7EF-01D3-49ED-AD32-C54EDFFE1880@neustar.biz> <5032AFAB.4080300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A6B@ESESSCMS0356.eemea.ericsson.se> <50339093.5080700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EC8@ESESSCMS0356.eemea.ericsson.se> <5033C164.20807@alum.mit.edu> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+JvrW7CTJcAg5dzLCwaFz1ltbh25h+j xYoNB1gdmD3+vv/A5LFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZazceZOt4BlHxZ2Zvxgb GE9wdDFyckgImEicPPOcDcIWk7hwbz2QzcUhJHCKUeLThAYWkISQwHxGie1TI7oYOTjYBCwk uv9pg4RFBEIl2i7uYwSxmQVUJc41PgYrZxFQkWiZ9g4sLizgKnF/6VR2iHo3iecPT7FA2EYS s0/MALN5BcIlfrw8xQqx9ya7xK9TH5lBdnEKBEqc/ZQCUsMIdNv3U2uYIHaJS9x6Mp8J4mYB iSV7zjND2KISLx//Y4WoF5W4076eEWQMs4CmxPpd+hCtihJTuh+yQ6wVlDg58wnLBEaxWUim zkLomIWkYxaSjgWMLKsYhXMTM3PSy430Uosyk4uL8/P0ilM3MQIj6eCW36o7GO+cEznEKM3B oiTOa711j7+QQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRpeLn/IvaN1S4muS+KT7L2aqxIVz l7rXcq40FshftbIlif2O1Y6PXo57DBPPqEh7vl/GfvMRi/nP9feOBL5svysmLd8p9l787AUW hUnqS1dMdYtbJKj1WGD/nQKWjI+vt/9bdeb0naVrt287dMDqwONyTqfXM/UfOxfu69G4oJ48 jWHBDb//5vlKLMUZiYZazEXFiQD5pPrMcgIAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 11:49:55 -0000 SGksDQoNCj4gQSBjYWxsYmFjayBpcyBhIGNhbGwgdGhhdCBpcyBtYXJrZWQgd2l0aCBQcmlvcml0 eTogaGVscGhlbHAgKG9yDQo+IHdoYXRldmVyKSBhbmQgdGhlIHByb3h5IG1ha2VzIHNvbWUgZGV0 ZXJtaW5hdGlvbiBhYm91dCBjYWxsIHRyZWF0bWVudCBiYXNlZCBvbiBpbmZvcm1hdGlvbiBpdCBo YXMuICBUaGlzIGlzIGxpa2VseSBjYWxsZXIgDQo+IGlkZW50aXR5ID09IFBTQVAsIGJ1dCBpdCBk b2Vzbid0IG1hdHRlci4uLmxldCB0aGUgb3BlcmF0b3IgY2hvb3NlIGEgcG9saWN5IHRoYXQgYm90 aCBjb21wbGllcyB3aXRoIHRoZSBsYXdzIG9mIHRoZSBsYW5kIA0KPiBhbmQgd2l0aCB0aGVpciBj dXN0b21lcidzIHByZWZlcmVuY2VzIChpLmUuLCB0aGVpciBvd24gYnVzaW5lc3MgbmVlZHMpLg0K Pg0KPiBBbiBlbWVyZ2VuY3kgY2FsbCBpcyBhIGNhbGwgdG8gdXJuOnNlcnZpY2U6c29zLiAgVGhh dCBjYWxsIG1pZ2h0IGJlIG1hcmtlZCBhcyBQcmlvcml0eTogb21nbXlmYWNlbXlmYWNlLCBidXQg dGhlIHByaW1hcnkgZGV0ZXJtaW5hbnQgZm9yIGhvdyB0aGUgY2FsbCBpcyB0cmVhdGVkIGlzIHRo ZSBjYWxsZWUsIHdoaWNoIGlzICpieSBkZWZpbml0aW9uKiBhIFBTQVAuDQo+DQo+IFR3byBjYXNl cywgdHdvIHNldHMgb2YgcnVsZXMgKG9uZSBpbnRlbnRpb25hbGx5IGZ1enp5LCBvbmUgY3J5c3Rh bCBjbGVhcikuICBEb25lLg0KDQpZZXMuDQoNClNvLCB0aGUgcXVlc3Rpb24gaXMgc3RpbGw6IGZv ciBjYWxsYmFjaywgZG8gd2UgZGVmaW5lIGEgbmV3IFByaW9yaXR5IHZhbHVlIG9yIG5vdD8NCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg== From prvs=7594d5a990=jbakker@rim.com Tue Sep 4 11:47:16 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674DD21F869D for ; Tue, 4 Sep 2012 11:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNTnbAAzVpiY for ; Tue, 4 Sep 2012 11:47:15 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id B20A521F854F for ; Tue, 4 Sep 2012 11:47:15 -0700 (PDT) X-AuditID: 0a41282f-b7fbe6d000004851-77-50464cb26ee4 Received: from XCT104ADS.rim.net (xct104ads.rim.net [10.67.111.45]) by mhs060cnc.rim.net (SBG) with SMTP id 99.B6.18513.2BC46405; Tue, 4 Sep 2012 13:47:14 -0500 (CDT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.02.0298.004; Tue, 4 Sep 2012 13:47:14 -0500 From: John-Luc Bakker To: Christer Holmberg , Martin Thomson , Paul Kyzivat Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac16WXl1aY8h8dRuRCSVyR9kOOlARwALDA8AAACtJwAAAQZDAAAoYWKAACNaEoAAAWu7QAAjBwE2ABrEOYAAlLVSUAAL+TAAAAL3N4AAFWQtgAAMH1GAAAVWlgAAAe+dAAAMkN0AAnX3/QAANb+ZQA== Date: Tue, 4 Sep 2012 18:47:14 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA351EA9B6@XMB104ADS.rim.net> References: <502AB594.8000800@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853408683666@ESESSCMS0356.eemea.ericsson.se> <502AC0FE.8040707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853408683686@ESESSCMS0356.eemea.ericsson.se> <155970D1DA8E174F9E46039E10E2AA351D94C4@XMB104ADS.rim.net> <7F2072F1E0DE894DA4B517B93C6A05853408683691@ESESSCMS0356.eemea.ericsson.se> <502E6573.80107@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA351DB027@XMB104ADS.rim.net> <44CDF7EF-01D3-49ED-AD32-C54EDFFE1880@neustar.biz> <5032AFAB.4080300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A6B@ESESSCMS0356.eemea.ericsson.se> <50339093.5080700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EC8@ESESSCMS0356.eemea.ericsson.se> <5033C164.20807@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A460738@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A460738@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.251] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJKsWRmVeSWpSXmKPExsXC5Zyvq7vJxy3A4OVvG4sLMw8zWjQuespq ce3MP0aLFRsOsDqwePx9/4HJ49fXq2weO2fdZfdYsuQnUwBLVAOjTVJiSVlwZnqevp1NYl5e fkliSapCSmpxsq2ST2p6Yo5CQFFmWWJypYJLZnFyTmJmbmqRkkJmiq2SiZJCQU5icmpual6J rVJiQUFqXoqSHZcCBrABKsvMU0jNS85PycxLt1XyDPbXtbAwtdQ1VLLTTejkyZg98Q1LwXK+ ige7HrM3MF7k7mLk4JAQMJFY1cnXxcgJZIpJXLi3nq2LkYtDSGAlo8Tt7U/YQBJCApsYJd6+ ygSx2QTUJbau2M4MUiQi0MkosXPTZ1aQBLOAqsS5xscsILawgKvE/aVT2UFsEQE3iecPT7FA NCxjlLg+9RkjSIJFQEXi6I8lYBt4gYre7N/FDrF6OYfEnndfGEHO4xSIkNj43gOkhhHovO+n 1jBBLBOXuPVkPhPE2QISS/acZ4awRSVePv7HCmErSszYMx/qOB2JBbs/sUHY2hLLFr5mhtgr KHFy5hOWCYxis5CMnYWkZRaSlllIWhYwsqxiFMzNKDYwM0jOS9YryszVy0st2cQISiiOGvo7 GN++tzjEKMDBqMTD+8DYLUCINbGsuDL3EKMEB7OSCO/t1a4BQrwpiZVVqUX58UWlOanFhxgt gKEykVmKOzkfmOzySuKNDQxQOErivCuOOwQICaQDk092ampBahFMKxMHJ8hoLimRYmAKSS1K LC3JiAcluvhiYKqTamBMnn23ju2v3PeWTwxzYtTevXwm4ay19YLuTpGfe86oiJ+8F/D4RaCj zmqWgkDfWq/jjfYS1SvLmXMa3u+PeHK98NeZf5ly16KuP+Fd6Sn+RsDjRlSm17/4aWaOi5T3 sYc6vvgsf+7SI8/b35LeG0+Z95z/98HwC19/Hy4yXbtH0ddh0s9phbt2KrEUZyQaajEXFScC AGS8F8FcAwAA Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 18:47:16 -0000 Christer, It seems below an argument is made for either very many distinct Priority he= ader field values, each invoking a policy that both complies with the laws o= f the land and with their customer's preferences (i.e., their own business n= eeds), or just one Priority header field value, identifying the policy in pl= ace for "emergency call back". As I understand it, the requirements can be s= atisfied by having just one Priority header field value. The single value we= have today that fits the bill is "emergency". Regards, JL -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Ch= rister Holmberg Sent: Monday, September 03, 2012 6:50 AM To: Martin Thomson; Paul Kyzivat Cc: ecrit@ietf.org Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Hi, > A callback is a call that is marked with Priority: helphelp (or > whatever) and the proxy makes some determination about call treatment > based on information it has. This is likely caller identity =3D=3D PSAP,= > but it doesn't matter...let the operator choose a policy that both complie= s with the laws of the land and with their customer's preferences (i.e., the= ir own business needs). > > An emergency call is a call to urn:service:sos. That call might be marked= as Priority: omgmyfacemyface, but the primary determinant for how the call= is treated is the callee, which is *by definition* a PSAP. > > Two cases, two sets of rules (one intentionally fuzzy, one crystal clear).= Done. Yes. So, the question is still: for callback, do we define a new Priority value o= r not? Regards, Christer _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From brian.rosen@neustar.biz Tue Sep 4 12:09:58 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA1D21E808B for ; Tue, 4 Sep 2012 12:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0N2ykH1BUaf for ; Tue, 4 Sep 2012 12:09:57 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id B701321E808A for ; Tue, 4 Sep 2012 12:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1346786076; x=1662144382; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=XYizIqllCuGJKDPKAgarV Eyrgu/Sy9Jy8l95gajjQj0=; b=JKPcfklZkhFJHKfSqNAUAieBVz0SYSh7NFC/E 7PJwI3Gk49r44Fva7dPSdNfrMfB4uyFRnX7wPZ12WK25XxWoA== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.13807246; Tue, 04 Sep 2012 15:14:35 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Tue, 4 Sep 2012 15:09:50 -0400 From: "Rosen, Brian" To: John-Luc Bakker Date: Tue, 4 Sep 2012 15:09:48 -0400 Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac2K0NsHj9jYJ4+LSP26fzMQGYNBig== Message-ID: <7B8820C0-5B37-4E8D-BC09-B45C778BE3D7@neustar.biz> References: <502AB594.8000800@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853408683666@ESESSCMS0356.eemea.ericsson.se> <502AC0FE.8040707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853408683686@ESESSCMS0356.eemea.ericsson.se> <155970D1DA8E174F9E46039E10E2AA351D94C4@XMB104ADS.rim.net> <7F2072F1E0DE894DA4B517B93C6A05853408683691@ESESSCMS0356.eemea.ericsson.se> <502E6573.80107@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA351DB027@XMB104ADS.rim.net> <44CDF7EF-01D3-49ED-AD32-C54EDFFE1880@neustar.biz> <5032AFAB.4080300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A6B@ESESSCMS0356.eemea.ericsson.se> <50339093.5080700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EC8@ESESSCMS0356.eemea.ericsson.se> <5033C164.20807@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A460738@ESESSCMS0356.eemea.ericsson.se> <155970D1DA8E174F9E46039E10E2AA351EA9B6@XMB104ADS.rim.net> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA351EA9B6@XMB104ADS.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: NnhgQZ67BtVVSdqc2IuhVg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 19:09:58 -0000 I don't think that is the issue. Some folks believe the definition of "emergency" is wider than "emergency c= all back" and thus a new value is needed to differentiate. They would argu= e that we can't redefine "emergency" to "emergency call back". I think the= other side would say that there are other fields in the INVITE would allow= that differentiation, such as the to/from. I continue to not care much, but observe that new values are cheap. Brian On Sep 4, 2012, at 2:47 PM, John-Luc Bakker wrote: > Christer, >=20 > It seems below an argument is made for either very many distinct Priority= header field values, each invoking a policy that both complies with the la= ws of the land and with their customer's preferences (i.e., their own busin= ess needs), or just one Priority header field value, identifying the policy= in place for "emergency call back". As I understand it, the requirements c= an be satisfied by having just one Priority header field value. The single = value we have today that fits the bill is "emergency".=20 >=20 > Regards, >=20 > JL >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of= Christer Holmberg > Sent: Monday, September 03, 2012 6:50 AM > To: Martin Thomson; Paul Kyzivat > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >=20 > Hi, >=20 >> A callback is a call that is marked with Priority: helphelp (or >> whatever) and the proxy makes some determination about call treatment=20 >> based on information it has. This is likely caller identity =3D=3D PSAP= ,=20 >> but it doesn't matter...let the operator choose a policy that both compl= ies with the laws of the land and with their customer's preferences (i.e., = their own business needs). >>=20 >> An emergency call is a call to urn:service:sos. That call might be mark= ed as Priority: omgmyfacemyface, but the primary determinant for how the ca= ll is treated is the callee, which is *by definition* a PSAP. >>=20 >> Two cases, two sets of rules (one intentionally fuzzy, one crystal clear= ). Done. >=20 > Yes. >=20 > So, the question is still: for callback, do we define a new Priority valu= e or not? >=20 > Regards, >=20 > Christer > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From christer.holmberg@ericsson.com Wed Sep 5 00:42:20 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C29521F8528 for ; Wed, 5 Sep 2012 00:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5zvvbC7yPxx for ; Wed, 5 Sep 2012 00:42:18 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2E95A21F8460 for ; Wed, 5 Sep 2012 00:42:18 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-cb-504702529d78 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1F.EB.25676.25207405; Wed, 5 Sep 2012 09:42:10 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 5 Sep 2012 09:42:10 +0200 From: Christer Holmberg To: "Rosen, Brian" , John-Luc Bakker Date: Wed, 5 Sep 2012 09:42:09 +0200 Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac2K0NsHj9jYJ4+LSP26fzMQGYNBigAaO6vA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A4611B7@ESESSCMS0356.eemea.ericsson.se> References: <502AB594.8000800@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853408683666@ESESSCMS0356.eemea.ericsson.se> <502AC0FE.8040707@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853408683686@ESESSCMS0356.eemea.ericsson.se> <155970D1DA8E174F9E46039E10E2AA351D94C4@XMB104ADS.rim.net> <7F2072F1E0DE894DA4B517B93C6A05853408683691@ESESSCMS0356.eemea.ericsson.se> <502E6573.80107@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA351DB027@XMB104ADS.rim.net> <44CDF7EF-01D3-49ED-AD32-C54EDFFE1880@neustar.biz> <5032AFAB.4080300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A6B@ESESSCMS0356.eemea.ericsson.se> <50339093.5080700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EC8@ESESSCMS0356.eemea.ericsson.se> <5033C164.20807@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A460738@ESESSCMS0356.eemea.ericsson.se> <155970D1DA8E174F9E46039E10E2AA351EA9B6@XMB104ADS.rim.net> <7B8820C0-5B37-4E8D-BC09-B45C778BE3D7@neustar.biz> In-Reply-To: <7B8820C0-5B37-4E8D-BC09-B45C778BE3D7@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+JvrW4Qk3uAwePNWhbTTl5mtmhc9JTV 4s/BVhaLa2f+MVqs2HCA1YHV4+/7D0weO2fdZfdYsuQnk8eOhufMHhO+rGQJYI3isklJzcks Sy3St0vgymh89pe14IFsxb8HVxkbGDdLdDFyckgImEhs2LODEcIWk7hwbz1bFyMXh5DAKUaJ F//ns0I48xkl9lx9DeRwcLAJWEh0/9MGaRARCJS4t+ssE4jNLFAh8f70DDCbRUBF4tj/02C2 sICrxP2lU9kh6t0knj88xQJhG0lsb7wBtphXIFxizq9FzBC7ZnJKbL20jRUkwSlgL7FmYw9Y AyPQdd9PrYFaJi5x68l8JoirBSSW7DnPDGGLSrx8/I8Vol5U4k77ekaIeh2JBbs/sUHY2hLL Fr5mhlgsKHFy5hOWCYxis5CMnYWkZRaSlllIWhYwsqxiFM5NzMxJLzfSSy3KTC4uzs/TK07d xAiMvINbfqvuYLxzTuQQozQHi5I4r/XWPf5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGMMl ++z9W3zWfeyY0+oioXHtgrit8uMdfxgOtLnKCJu4q86/daYqbk+BBHPAwpTN4nW1HvkrH/W9 3KAsn3cvrURsrsUCfi1Hp9Mz9RbcMFjbeO6AQgbr0nM3FUTt83auzbb6deRMNM/n6acTDQU3 ZfVd9t7yKd0nUrjBPvrjIrlVDBmb5ue6KLEUZyQaajEXFScCAA7eLQKKAgAA Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:42:20 -0000 Hi, Then, no matter whether people think a new value is really required or not,= would people object to defining a new value? This is really about making a choice and getting the work done :) Regards, Christer -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Sent: 4. syyskuuta 2012 22:10 To: John-Luc Bakker Cc: Christer Holmberg; Martin Thomson; Paul Kyzivat; ecrit@ietf.org Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator I don't think that is the issue. Some folks believe the definition of "emergency" is wider than "emergency c= all back" and thus a new value is needed to differentiate. They would argu= e that we can't redefine "emergency" to "emergency call back". I think the= other side would say that there are other fields in the INVITE would allow= that differentiation, such as the to/from. I continue to not care much, but observe that new values are cheap. Brian On Sep 4, 2012, at 2:47 PM, John-Luc Bakker wrote: > Christer, >=20 > It seems below an argument is made for either very many distinct Priority= header field values, each invoking a policy that both complies with the la= ws of the land and with their customer's preferences (i.e., their own busin= ess needs), or just one Priority header field value, identifying the policy= in place for "emergency call back". As I understand it, the requirements c= an be satisfied by having just one Priority header field value. The single = value we have today that fits the bill is "emergency".=20 >=20 > Regards, >=20 > JL >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=20 > Of Christer Holmberg > Sent: Monday, September 03, 2012 6:50 AM > To: Martin Thomson; Paul Kyzivat > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >=20 > Hi, >=20 >> A callback is a call that is marked with Priority: helphelp (or >> whatever) and the proxy makes some determination about call treatment=20 >> based on information it has. This is likely caller identity =3D=3D PSAP= ,=20 >> but it doesn't matter...let the operator choose a policy that both compl= ies with the laws of the land and with their customer's preferences (i.e., = their own business needs). >>=20 >> An emergency call is a call to urn:service:sos. That call might be mark= ed as Priority: omgmyfacemyface, but the primary determinant for how the ca= ll is treated is the callee, which is *by definition* a PSAP. >>=20 >> Two cases, two sets of rules (one intentionally fuzzy, one crystal clear= ). Done. >=20 > Yes. >=20 > So, the question is still: for callback, do we define a new Priority valu= e or not? >=20 > Regards, >=20 > Christer > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From pkyzivat@alum.mit.edu Wed Sep 5 07:57:46 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A6121F854C for ; Wed, 5 Sep 2012 07:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ulHwe8WZKVh for ; Wed, 5 Sep 2012 07:57:44 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE1A21F85A5 for ; Wed, 5 Sep 2012 07:57:42 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta15.westchester.pa.mail.comcast.net with comcast id vQPQ1j00217dt5G5FSy2iC; Wed, 05 Sep 2012 14:58:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id vSyF1j00S3ZTu2S3ZSyFMr; Wed, 05 Sep 2012 14:58:15 +0000 Message-ID: <50476864.9040303@alum.mit.edu> Date: Wed, 05 Sep 2012 10:57:40 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Christer Holmberg References: <155970D1DA8E174F9E46039E10E2AA351D94C4@XMB104ADS.rim.net> <7F2072F1E0DE894DA4B517B93C6A05853408683691@ESESSCMS0356.eemea.ericsson.se> <502E6573.80107@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA351DB027@XMB104ADS.rim.net> <44CDF7EF-01D3-49ED-AD32-C54EDFFE1880@neustar.biz> <5032AFAB.4080300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A6B@ESESSCMS0356.eemea.ericsson.se> <50339093.5080700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EC8@ESESSCMS0356.eemea.ericsson.se> <5033C164.20807@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A460738@ESESSCMS0356.eemea.ericsson.se> <155970D1DA8E174F9E46039E10E2AA351EA9B6@XMB104ADS.rim.net> <7B8820C0-5B37-4E8D-BC09-B45C778BE3D7@neustar.biz> <7F2072F1E0DE894DA4B517B93C6A0585340A4611B7@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A4611B7@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 14:57:46 -0000 On 9/5/12 3:42 AM, Christer Holmberg wrote: > Hi, > > Then, no matter whether people think a new value is really required or not, would people object to defining a new value? > > This is really about making a choice and getting the work done :) Given all the discussion that has occurred about he pros and cons, I am willing to accept either using "emergency" or using a new value. (If the decision is to go with a new value, I reserve the right to argue about what it is called. You only get one chance to get that right, and some values will be clearer than others. But at the end of the day I will go along with whatever the consensus brings.) Thanks, Paul > Regards, > > Christer > > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: 4. syyskuuta 2012 22:10 > To: John-Luc Bakker > Cc: Christer Holmberg; Martin Thomson; Paul Kyzivat; ecrit@ietf.org > Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator > > I don't think that is the issue. > > Some folks believe the definition of "emergency" is wider than "emergency call back" and thus a new value is needed to differentiate. They would argue that we can't redefine "emergency" to "emergency call back". I think the other side would say that there are other fields in the INVITE would allow that differentiation, such as the to/from. > > I continue to not care much, but observe that new values are cheap. > > Brian > > On Sep 4, 2012, at 2:47 PM, John-Luc Bakker wrote: > >> Christer, >> >> It seems below an argument is made for either very many distinct Priority header field values, each invoking a policy that both complies with the laws of the land and with their customer's preferences (i.e., their own business needs), or just one Priority header field value, identifying the policy in place for "emergency call back". As I understand it, the requirements can be satisfied by having just one Priority header field value. The single value we have today that fits the bill is "emergency". >> >> Regards, >> >> JL >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Christer Holmberg >> Sent: Monday, September 03, 2012 6:50 AM >> To: Martin Thomson; Paul Kyzivat >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >> >> Hi, >> >>> A callback is a call that is marked with Priority: helphelp (or >>> whatever) and the proxy makes some determination about call treatment >>> based on information it has. This is likely caller identity == PSAP, >>> but it doesn't matter...let the operator choose a policy that both complies with the laws of the land and with their customer's preferences (i.e., their own business needs). >>> >>> An emergency call is a call to urn:service:sos. That call might be marked as Priority: omgmyfacemyface, but the primary determinant for how the call is treated is the callee, which is *by definition* a PSAP. >>> >>> Two cases, two sets of rules (one intentionally fuzzy, one crystal clear). Done. >> >> Yes. >> >> So, the question is still: for callback, do we define a new Priority value or not? >> >> Regards, >> >> Christer >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > From keith.drage@alcatel-lucent.com Wed Sep 5 08:04:59 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3155021F866E for ; Wed, 5 Sep 2012 08:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oczP2Am492el for ; Wed, 5 Sep 2012 08:04:58 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 179E721F866B for ; Wed, 5 Sep 2012 08:04:57 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q85EwXIG025517 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 Sep 2012 17:04:51 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 5 Sep 2012 17:04:33 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , Christer Holmberg Date: Wed, 5 Sep 2012 17:04:31 +0200 Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac2LdtrGPo3CQ5klTk2a9Wq++Lx5OwAAKh2w Message-ID: References: <155970D1DA8E174F9E46039E10E2AA351D94C4@XMB104ADS.rim.net> <7F2072F1E0DE894DA4B517B93C6A05853408683691@ESESSCMS0356.eemea.ericsson.se> <502E6573.80107@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA351DB027@XMB104ADS.rim.net> <44CDF7EF-01D3-49ED-AD32-C54EDFFE1880@neustar.biz> <5032AFAB.4080300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A6B@ESESSCMS0356.eemea.ericsson.se> <50339093.5080700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EC8@ESESSCMS0356.eemea.ericsson.se> <5033C164.20807@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A460738@ESESSCMS0356.eemea.ericsson.se> <155970D1DA8E174F9E46039E10E2AA351EA9B6@XMB104ADS.rim.net> <7B8820C0-5B37-4E8D-BC09-B45C778BE3D7@neustar.biz> <7F2072F1E0DE894DA4B517B93C6A0585340A4611B7@ESESSCMS0356.eemea.ericsson.se> <50476864.9040303@alum.mit.edu> In-Reply-To: <50476864.9040303@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:04:59 -0000 I still prefer a new value, as a new value is the easiest way of ensuring t= hat there is no existing incompatible usage of an existing value for some o= ther purpose. I don't see compatibility the other way as an issue, as I am not aware of a= ny existing marking for a PSAP callback. Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: 05 September 2012 15:58 > To: Christer Holmberg > Cc: Rosen, Brian; ecrit@ietf.org > Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >=20 > On 9/5/12 3:42 AM, Christer Holmberg wrote: > > Hi, > > > > Then, no matter whether people think a new value is really required or > not, would people object to defining a new value? > > > > This is really about making a choice and getting the work done :) >=20 > Given all the discussion that has occurred about he pros and cons, I am > willing to accept either using "emergency" or using a new value. >=20 > (If the decision is to go with a new value, I reserve the right to argue > about what it is called. You only get one chance to get that right, and > some values will be clearer than others. But at the end of the day I > will go along with whatever the consensus brings.) >=20 > Thanks, > Paul >=20 > > Regards, > > > > Christer > > > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > Sent: 4. syyskuuta 2012 22:10 > > To: John-Luc Bakker > > Cc: Christer Holmberg; Martin Thomson; Paul Kyzivat; ecrit@ietf.org > > Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator > > > > I don't think that is the issue. > > > > Some folks believe the definition of "emergency" is wider than > "emergency call back" and thus a new value is needed to differentiate. > They would argue that we can't redefine "emergency" to "emergency call > back". I think the other side would say that there are other fields in > the INVITE would allow that differentiation, such as the to/from. > > > > I continue to not care much, but observe that new values are cheap. > > > > Brian > > > > On Sep 4, 2012, at 2:47 PM, John-Luc Bakker wrote: > > > >> Christer, > >> > >> It seems below an argument is made for either very many distinct > Priority header field values, each invoking a policy that both complies > with the laws of the land and with their customer's preferences (i.e., > their own business needs), or just one Priority header field value, > identifying the policy in place for "emergency call back". As I understan= d > it, the requirements can be satisfied by having just one Priority header > field value. The single value we have today that fits the bill is > "emergency". > >> > >> Regards, > >> > >> JL > >> > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > >> Of Christer Holmberg > >> Sent: Monday, September 03, 2012 6:50 AM > >> To: Martin Thomson; Paul Kyzivat > >> Cc: ecrit@ietf.org > >> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator > >> > >> Hi, > >> > >>> A callback is a call that is marked with Priority: helphelp (or > >>> whatever) and the proxy makes some determination about call treatment > >>> based on information it has. This is likely caller identity =3D=3D P= SAP, > >>> but it doesn't matter...let the operator choose a policy that both > complies with the laws of the land and with their customer's preferences > (i.e., their own business needs). > >>> > >>> An emergency call is a call to urn:service:sos. That call might be > marked as Priority: omgmyfacemyface, but the primary determinant for how > the call is treated is the callee, which is *by definition* a PSAP. > >>> > >>> Two cases, two sets of rules (one intentionally fuzzy, one crystal > clear). Done. > >> > >> Yes. > >> > >> So, the question is still: for callback, do we define a new Priority > value or not? > >> > >> Regards, > >> > >> Christer > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >> > >> --------------------------------------------------------------------- > >> This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-publi= c > information. Any use of this information by anyone other than the intende= d > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > > > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From brian.rosen@neustar.biz Wed Sep 5 08:13:44 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125D521F84AF for ; Wed, 5 Sep 2012 08:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hor88m-7Jz+T for ; Wed, 5 Sep 2012 08:13:43 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id D8F9C21F84A2 for ; Wed, 5 Sep 2012 08:13:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1346857945; x=1662214221; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=y19YfF3PS8s0p7ttOhypX EU9b9YI27wfFT44FskQbgs=; b=HhbZmpWd5rtNwTsdY/ehqVQUUy2CU1aM6sRjW Twe8C0HfuC8G0MnbncJW6yms0EDsmvcG1CcKmePzkhVKNuWxw== Received: from ([10.31.13.242]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.8958303; Wed, 05 Sep 2012 11:12:24 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Wed, 5 Sep 2012 11:13:35 -0400 From: "Rosen, Brian" To: Paul Kyzivat Date: Wed, 5 Sep 2012 11:13:35 -0400 Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac2LeQTJd/2BoKzhQUG1em+Hvq6MNw== Message-ID: References: <155970D1DA8E174F9E46039E10E2AA351D94C4@XMB104ADS.rim.net> <7F2072F1E0DE894DA4B517B93C6A05853408683691@ESESSCMS0356.eemea.ericsson.se> <502E6573.80107@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA351DB027@XMB104ADS.rim.net> <44CDF7EF-01D3-49ED-AD32-C54EDFFE1880@neustar.biz> <5032AFAB.4080300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A6B@ESESSCMS0356.eemea.ericsson.se> <50339093.5080700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EC8@ESESSCMS0356.eemea.ericsson.se> <5033C164.20807@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A460738@ESESSCMS0356.eemea.ericsson.se> <155970D1DA8E174F9E46039E10E2AA351EA9B6@XMB104ADS.rim.net> <7B8820C0-5B37-4E8D-BC09-B45C778BE3D7@neustar.biz> <7F2072F1E0DE894DA4B517B93C6A0585340A4611B7@ESESSCMS0356.eemea.ericsson.se> <50476864.9040303@alum.mit.edu> In-Reply-To: <50476864.9040303@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: gTUmaxNnUHltTm1YUIyHyA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:13:44 -0000 How about "emergencyCallBack"? On Sep 5, 2012, at 10:57 AM, Paul Kyzivat wrote: > On 9/5/12 3:42 AM, Christer Holmberg wrote: >> Hi, >>=20 >> Then, no matter whether people think a new value is really required or n= ot, would people object to defining a new value? >>=20 >> This is really about making a choice and getting the work done :) >=20 > Given all the discussion that has occurred about he pros and cons, I am w= illing to accept either using "emergency" or using a new value. >=20 > (If the decision is to go with a new value, I reserve the right to argue = about what it is called. You only get one chance to get that right, and som= e values will be clearer than others. But at the end of the day I will go a= long with whatever the consensus brings.) >=20 > Thanks, > Paul >=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: 4. syyskuuta 2012 22:10 >> To: John-Luc Bakker >> Cc: Christer Holmberg; Martin Thomson; Paul Kyzivat; ecrit@ietf.org >> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>=20 >> I don't think that is the issue. >>=20 >> Some folks believe the definition of "emergency" is wider than "emergenc= y call back" and thus a new value is needed to differentiate. They would a= rgue that we can't redefine "emergency" to "emergency call back". I think = the other side would say that there are other fields in the INVITE would al= low that differentiation, such as the to/from. >>=20 >> I continue to not care much, but observe that new values are cheap. >>=20 >> Brian >>=20 >> On Sep 4, 2012, at 2:47 PM, John-Luc Bakker wrote: >>=20 >>> Christer, >>>=20 >>> It seems below an argument is made for either very many distinct Priori= ty header field values, each invoking a policy that both complies with the = laws of the land and with their customer's preferences (i.e., their own bus= iness needs), or just one Priority header field value, identifying the poli= cy in place for "emergency call back". As I understand it, the requirements= can be satisfied by having just one Priority header field value. The singl= e value we have today that fits the bill is "emergency". >>>=20 >>> Regards, >>>=20 >>> JL >>>=20 >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>> Of Christer Holmberg >>> Sent: Monday, September 03, 2012 6:50 AM >>> To: Martin Thomson; Paul Kyzivat >>> Cc: ecrit@ietf.org >>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>>=20 >>> Hi, >>>=20 >>>> A callback is a call that is marked with Priority: helphelp (or >>>> whatever) and the proxy makes some determination about call treatment >>>> based on information it has. This is likely caller identity =3D=3D PS= AP, >>>> but it doesn't matter...let the operator choose a policy that both com= plies with the laws of the land and with their customer's preferences (i.e.= , their own business needs). >>>>=20 >>>> An emergency call is a call to urn:service:sos. That call might be ma= rked as Priority: omgmyfacemyface, but the primary determinant for how the = call is treated is the callee, which is *by definition* a PSAP. >>>>=20 >>>> Two cases, two sets of rules (one intentionally fuzzy, one crystal cle= ar). Done. >>>=20 >>> Yes. >>>=20 >>> So, the question is still: for callback, do we define a new Priority va= lue or not? >>>=20 >>> Regards, >>>=20 >>> Christer >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the solic= itor-client or other applicable privileges), or constitute non-public infor= mation. Any use of this information by anyone other than the intended recip= ient is prohibited. If you have received this transmission in error, please= immediately reply to the sender and delete this information from your syst= em. Use, dissemination, distribution, or reproduction of this transmission = by unintended recipients is not authorized and may be unlawful. >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From pkyzivat@alum.mit.edu Wed Sep 5 08:48:49 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BDA21F8672 for ; Wed, 5 Sep 2012 08:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmTbQ-TkUoSS for ; Wed, 5 Sep 2012 08:48:49 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id AD24C21F8546 for ; Wed, 5 Sep 2012 08:48:48 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta03.westchester.pa.mail.comcast.net with comcast id vNFF1j0050EZKEL53TosFm; Wed, 05 Sep 2012 15:48:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id vTp71j0063ZTu2S3MTp7cU; Wed, 05 Sep 2012 15:49:07 +0000 Message-ID: <5047745F.2010706@alum.mit.edu> Date: Wed, 05 Sep 2012 11:48:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "Rosen, Brian" References: <7F2072F1E0DE894DA4B517B93C6A05853408683691@ESESSCMS0356.eemea.ericsson.se> <502E6573.80107@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA351DB027@XMB104ADS.rim.net> <44CDF7EF-01D3-49ED-AD32-C54EDFFE1880@neustar.biz> <5032AFAB.4080300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A6B@ESESSCMS0356.eemea.ericsson.se> <50339093.5080700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EC8@ESESSCMS0356.eemea.ericsson.se> <5033C164.20807@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A460738@ESESSCMS0356.eemea.ericsson.se> <155970D1DA8E174F9E46039E10E2AA351EA9B6@XMB104ADS.rim.net> <7B8820C0-5B37-4E8D-BC09-B45C778BE3D7@neustar.biz> <7F2072F1E0DE894DA4B517B93C6A0585340A4611B7@ESESSCMS0356.eemea.ericsson.se> <50476864.9040303@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:48:49 -0000 On 9/5/12 11:13 AM, Rosen, Brian wrote: > How about "emergencyCallBack"? Hardly anything in sip uses mixed case this way. So from that perspective I would counter with "emergency-callback". But a more significant issue is what semantics this is intended to convey. In particular, is a call with this attribute of necessity a *callback*? Is anything in the call path justified in refusing the request if there was no preceding call for which this is a callback? E.g. if psap received an emergency call from phone-1, and it is necessary to reconnect to a different phone, or perhaps even a different person, in order to continue handling the emergency, then it may be hard to describe that as a "callback". Yet the PSAP may want to do it, and I suppose the mechanism should allow it. If so, then "emergency-callback" has the wrong connotation. This is really why I find "emergency" to be appropriate. If we must have a new term, how about: "expedited-emergency", "urgent-emergency", "emergency-override"? Thanks, Paul > On Sep 5, 2012, at 10:57 AM, Paul Kyzivat wrote: > >> On 9/5/12 3:42 AM, Christer Holmberg wrote: >>> Hi, >>> >>> Then, no matter whether people think a new value is really required or not, would people object to defining a new value? >>> >>> This is really about making a choice and getting the work done :) >> >> Given all the discussion that has occurred about he pros and cons, I am willing to accept either using "emergency" or using a new value. >> >> (If the decision is to go with a new value, I reserve the right to argue about what it is called. You only get one chance to get that right, and some values will be clearer than others. But at the end of the day I will go along with whatever the consensus brings.) >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: 4. syyskuuta 2012 22:10 >>> To: John-Luc Bakker >>> Cc: Christer Holmberg; Martin Thomson; Paul Kyzivat; ecrit@ietf.org >>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>> >>> I don't think that is the issue. >>> >>> Some folks believe the definition of "emergency" is wider than "emergency call back" and thus a new value is needed to differentiate. They would argue that we can't redefine "emergency" to "emergency call back". I think the other side would say that there are other fields in the INVITE would allow that differentiation, such as the to/from. >>> >>> I continue to not care much, but observe that new values are cheap. >>> >>> Brian >>> >>> On Sep 4, 2012, at 2:47 PM, John-Luc Bakker wrote: >>> >>>> Christer, >>>> >>>> It seems below an argument is made for either very many distinct Priority header field values, each invoking a policy that both complies with the laws of the land and with their customer's preferences (i.e., their own business needs), or just one Priority header field value, identifying the policy in place for "emergency call back". As I understand it, the requirements can be satisfied by having just one Priority header field value. The single value we have today that fits the bill is "emergency". >>>> >>>> Regards, >>>> >>>> JL >>>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>>> Of Christer Holmberg >>>> Sent: Monday, September 03, 2012 6:50 AM >>>> To: Martin Thomson; Paul Kyzivat >>>> Cc: ecrit@ietf.org >>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>>> >>>> Hi, >>>> >>>>> A callback is a call that is marked with Priority: helphelp (or >>>>> whatever) and the proxy makes some determination about call treatment >>>>> based on information it has. This is likely caller identity == PSAP, >>>>> but it doesn't matter...let the operator choose a policy that both complies with the laws of the land and with their customer's preferences (i.e., their own business needs). >>>>> >>>>> An emergency call is a call to urn:service:sos. That call might be marked as Priority: omgmyfacemyface, but the primary determinant for how the call is treated is the callee, which is *by definition* a PSAP. >>>>> >>>>> Two cases, two sets of rules (one intentionally fuzzy, one crystal clear). Done. >>>> >>>> Yes. >>>> >>>> So, the question is still: for callback, do we define a new Priority value or not? >>>> >>>> Regards, >>>> >>>> Christer >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> --------------------------------------------------------------------- >>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > From brian.rosen@neustar.biz Wed Sep 5 10:28:30 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB7D21F863F for ; Wed, 5 Sep 2012 10:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0802As7tjRS6 for ; Wed, 5 Sep 2012 10:28:29 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 60BB421F863B for ; Wed, 5 Sep 2012 10:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1346866029; x=1662219621; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=sY8Cs7arm2n83+SL/xbQ+ ti0xh88FCnI122Tn3DdxHk=; b=O01Gzjh9pe59dukWdXZGOZYM8jM5E7TE4DSuZ 7xQgxvn1rLAzq57homuyH9UmtxRa+VA8LL0sYh/ps/Fa7Yi+Q== Received: from ([10.31.13.228]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.8963929; Wed, 05 Sep 2012 13:27:08 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Wed, 5 Sep 2012 13:28:19 -0400 From: "Rosen, Brian" To: Paul Kyzivat Date: Wed, 5 Sep 2012 13:28:18 -0400 Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac2Li9cp7d3OobA2RoC42+sJiS4bag== Message-ID: <985D9D15-DA49-4DE1-9839-C8A5B6934F83@neustar.biz> References: <7F2072F1E0DE894DA4B517B93C6A05853408683691@ESESSCMS0356.eemea.ericsson.se> <502E6573.80107@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA351DB027@XMB104ADS.rim.net> <44CDF7EF-01D3-49ED-AD32-C54EDFFE1880@neustar.biz> <5032AFAB.4080300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A6B@ESESSCMS0356.eemea.ericsson.se> <50339093.5080700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EC8@ESESSCMS0356.eemea.ericsson.se> <5033C164.20807@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A460738@ESESSCMS0356.eemea.ericsson.se> <155970D1DA8E174F9E46039E10E2AA351EA9B6@XMB104ADS.rim.net> <7B8820C0-5B37-4E8D-BC09-B45C778BE3D7@neustar.biz> <7F2072F1E0DE894DA4B517B93C6A0585340A4611B7@ESESSCMS0356.eemea.ericsson.se> <50476864.9040303@alum.mit.edu> <5047745F.2010706@alum.mit.edu> In-Reply-To: <5047745F.2010706@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 4WtoC7hHmQGAcOtv2bh4Rw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 17:28:30 -0000 I don't think we are trying to create a marking for an arbitrary call place= d from a PSAP to someone in another network. The marking is specifically f= or call backs, and not other purposes. I think that it IS acceptable to refuse such calls if there was no call out= . For example, if the call is to some sort of Contact address which, due t= o some local requirements, was formatted in some way specifically known to = the local system, it might refuse the call to the device if there was no pr= eceding emergency call. A call to a normal AoR may not be refused, but may= not get any special treatment if the marking has no way of being authentic= ated. All of that is up to the local system and any intermediaries. I thi= nk Christer, and most of us discussing this, only intend it to be used for = a call back. I think there is no need to generalize, and emergency-callback is just fine= . Brian On Sep 5, 2012, at 11:48 AM, Paul Kyzivat wrote: > On 9/5/12 11:13 AM, Rosen, Brian wrote: >> How about "emergencyCallBack"? >=20 > Hardly anything in sip uses mixed case this way. So from that perspective= I would counter with "emergency-callback". >=20 > But a more significant issue is what semantics this is intended to convey= . In particular, is a call with this attribute of necessity a *callback*? I= s anything in the call path justified in refusing the request if there was = no preceding call for which this is a callback? >=20 > E.g. if psap received an emergency call from phone-1, and it is necessary= to reconnect to a different phone, or perhaps even a different person, in = order to continue handling the emergency, then it may be hard to describe t= hat as a "callback". Yet the PSAP may want to do it, and I suppose the mech= anism should allow it. If so, then "emergency-callback" has the wrong conno= tation. This is really why I find "emergency" to be appropriate. If we must= have a new term, how about: "expedited-emergency", "urgent-emergency", "em= ergency-override"? >=20 > Thanks, > Paul >=20 >> On Sep 5, 2012, at 10:57 AM, Paul Kyzivat wrote: >>=20 >>> On 9/5/12 3:42 AM, Christer Holmberg wrote: >>>> Hi, >>>>=20 >>>> Then, no matter whether people think a new value is really required or= not, would people object to defining a new value? >>>>=20 >>>> This is really about making a choice and getting the work done :) >>>=20 >>> Given all the discussion that has occurred about he pros and cons, I am= willing to accept either using "emergency" or using a new value. >>>=20 >>> (If the decision is to go with a new value, I reserve the right to argu= e about what it is called. You only get one chance to get that right, and s= ome values will be clearer than others. But at the end of the day I will go= along with whatever the consensus brings.) >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>> Sent: 4. syyskuuta 2012 22:10 >>>> To: John-Luc Bakker >>>> Cc: Christer Holmberg; Martin Thomson; Paul Kyzivat; ecrit@ietf.org >>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>>>=20 >>>> I don't think that is the issue. >>>>=20 >>>> Some folks believe the definition of "emergency" is wider than "emerge= ncy call back" and thus a new value is needed to differentiate. They would= argue that we can't redefine "emergency" to "emergency call back". I thin= k the other side would say that there are other fields in the INVITE would = allow that differentiation, such as the to/from. >>>>=20 >>>> I continue to not care much, but observe that new values are cheap. >>>>=20 >>>> Brian >>>>=20 >>>> On Sep 4, 2012, at 2:47 PM, John-Luc Bakker wrote: >>>>=20 >>>>> Christer, >>>>>=20 >>>>> It seems below an argument is made for either very many distinct Prio= rity header field values, each invoking a policy that both complies with th= e laws of the land and with their customer's preferences (i.e., their own b= usiness needs), or just one Priority header field value, identifying the po= licy in place for "emergency call back". As I understand it, the requiremen= ts can be satisfied by having just one Priority header field value. The sin= gle value we have today that fits the bill is "emergency". >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> JL >>>>>=20 >>>>> -----Original Message----- >>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behal= f >>>>> Of Christer Holmberg >>>>> Sent: Monday, September 03, 2012 6:50 AM >>>>> To: Martin Thomson; Paul Kyzivat >>>>> Cc: ecrit@ietf.org >>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>>>>=20 >>>>> Hi, >>>>>=20 >>>>>> A callback is a call that is marked with Priority: helphelp (or >>>>>> whatever) and the proxy makes some determination about call treatmen= t >>>>>> based on information it has. This is likely caller identity =3D=3D = PSAP, >>>>>> but it doesn't matter...let the operator choose a policy that both c= omplies with the laws of the land and with their customer's preferences (i.= e., their own business needs). >>>>>>=20 >>>>>> An emergency call is a call to urn:service:sos. That call might be = marked as Priority: omgmyfacemyface, but the primary determinant for how th= e call is treated is the callee, which is *by definition* a PSAP. >>>>>>=20 >>>>>> Two cases, two sets of rules (one intentionally fuzzy, one crystal c= lear). Done. >>>>>=20 >>>>> Yes. >>>>>=20 >>>>> So, the question is still: for callback, do we define a new Priority = value or not? >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>=20 >>>>> --------------------------------------------------------------------- >>>>> This transmission (including any attachments) may contain confidentia= l information, privileged material (including material protected by the sol= icitor-client or other applicable privileges), or constitute non-public inf= ormation. Any use of this information by anyone other than the intended rec= ipient is prohibited. If you have received this transmission in error, plea= se immediately reply to the sender and delete this information from your sy= stem. Use, dissemination, distribution, or reproduction of this transmissio= n by unintended recipients is not authorized and may be unlawful. >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From martin.thomson@gmail.com Wed Sep 5 10:32:26 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599DA21F84D5 for ; Wed, 5 Sep 2012 10:32:26 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twR6gHd58Xid for ; Wed, 5 Sep 2012 10:32:25 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2743421F846B for ; Wed, 5 Sep 2012 10:32:24 -0700 (PDT) Received: by wgbfm10 with SMTP id fm10so4258031wgb.1 for ; Wed, 05 Sep 2012 10:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=sxHdz0Oi7YzzukX0D9ynJN7+2ZXmF+58rr+Lkvvuna8=; b=bpQxS/jtowwZQdd54LRxkma75qriOun5tXVOCDxMimqbgfES1SG+CS2FRQC0cxdVJN 2Ox9L9aQm6Ist+daFzFSYDTRoP1sWbizjmPTUoXtRbqVE4q7vnrLPAvzkQ9VsuslUwXv YKP/9/gRyZREDHS4K7KsQnAz5TqeQrqsUNkfZ3oo09MXvKn1KKqxaE3eLXlqZZ6bBaNg K+JLGM8L72qPmRAX6J8mQP49hMyCpziabYuMq7NI+zUb9M18EQUZrPR62iP343oYBDKK ni8j1lS3wD13V1UE6KX13NIlOmaNDxbTqvgISe7CEP7WMMeaofhv+jibcTpneFTm/ZBw 2Vfg== MIME-Version: 1.0 Received: by 10.216.140.104 with SMTP id d82mr4260584wej.130.1346866344170; Wed, 05 Sep 2012 10:32:24 -0700 (PDT) Received: by 10.180.24.70 with HTTP; Wed, 5 Sep 2012 10:32:24 -0700 (PDT) In-Reply-To: <985D9D15-DA49-4DE1-9839-C8A5B6934F83@neustar.biz> References: <7F2072F1E0DE894DA4B517B93C6A05853408683691@ESESSCMS0356.eemea.ericsson.se> <502E6573.80107@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA351DB027@XMB104ADS.rim.net> <44CDF7EF-01D3-49ED-AD32-C54EDFFE1880@neustar.biz> <5032AFAB.4080300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A6B@ESESSCMS0356.eemea.ericsson.se> <50339093.5080700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EC8@ESESSCMS0356.eemea.ericsson.se> <5033C164.20807@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A460738@ESESSCMS0356.eemea.ericsson.se> <155970D1DA8E174F9E46039E10E2AA351EA9B6@XMB104ADS.rim.net> <7B8820C0-5B37-4E8D-BC09-B45C778BE3D7@neustar.biz> <7F2072F1E0DE894DA4B517B93C6A0585340A4611B7@ESESSCMS0356.eemea.ericsson.se> <50476864.9040303@alum.mit.edu> <5047745F.2010706@alum.mit.edu> <985D9D15-DA49-4DE1-9839-C8A5B6934F83@neustar.biz> Date: Wed, 5 Sep 2012 10:32:24 -0700 Message-ID: From: Martin Thomson To: "Rosen, Brian" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 17:32:26 -0000 psap-callback ? On 5 September 2012 10:28, Rosen, Brian wrote: > I don't think we are trying to create a marking for an arbitrary call pla= ced from a PSAP to someone in another network. The marking is specifically= for call backs, and not other purposes. > > I think that it IS acceptable to refuse such calls if there was no call o= ut. For example, if the call is to some sort of Contact address which, due= to some local requirements, was formatted in some way specifically known t= o the local system, it might refuse the call to the device if there was no = preceding emergency call. A call to a normal AoR may not be refused, but m= ay not get any special treatment if the marking has no way of being authent= icated. All of that is up to the local system and any intermediaries. I t= hink Christer, and most of us discussing this, only intend it to be used fo= r a call back. > > I think there is no need to generalize, and emergency-callback is just fi= ne. > > Brian > > On Sep 5, 2012, at 11:48 AM, Paul Kyzivat wrote: > >> On 9/5/12 11:13 AM, Rosen, Brian wrote: >>> How about "emergencyCallBack"? >> >> Hardly anything in sip uses mixed case this way. So from that perspectiv= e I would counter with "emergency-callback". >> >> But a more significant issue is what semantics this is intended to conve= y. In particular, is a call with this attribute of necessity a *callback*? = Is anything in the call path justified in refusing the request if there was= no preceding call for which this is a callback? >> >> E.g. if psap received an emergency call from phone-1, and it is necessar= y to reconnect to a different phone, or perhaps even a different person, in= order to continue handling the emergency, then it may be hard to describe = that as a "callback". Yet the PSAP may want to do it, and I suppose the mec= hanism should allow it. If so, then "emergency-callback" has the wrong conn= otation. This is really why I find "emergency" to be appropriate. If we mus= t have a new term, how about: "expedited-emergency", "urgent-emergency", "e= mergency-override"? >> >> Thanks, >> Paul >> >>> On Sep 5, 2012, at 10:57 AM, Paul Kyzivat wrote= : >>> >>>> On 9/5/12 3:42 AM, Christer Holmberg wrote: >>>>> Hi, >>>>> >>>>> Then, no matter whether people think a new value is really required o= r not, would people object to defining a new value? >>>>> >>>>> This is really about making a choice and getting the work done :) >>>> >>>> Given all the discussion that has occurred about he pros and cons, I a= m willing to accept either using "emergency" or using a new value. >>>> >>>> (If the decision is to go with a new value, I reserve the right to arg= ue about what it is called. You only get one chance to get that right, and = some values will be clearer than others. But at the end of the day I will g= o along with whatever the consensus brings.) >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>> Sent: 4. syyskuuta 2012 22:10 >>>>> To: John-Luc Bakker >>>>> Cc: Christer Holmberg; Martin Thomson; Paul Kyzivat; ecrit@ietf.org >>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>>>> >>>>> I don't think that is the issue. >>>>> >>>>> Some folks believe the definition of "emergency" is wider than "emerg= ency call back" and thus a new value is needed to differentiate. They woul= d argue that we can't redefine "emergency" to "emergency call back". I thi= nk the other side would say that there are other fields in the INVITE would= allow that differentiation, such as the to/from. >>>>> >>>>> I continue to not care much, but observe that new values are cheap. >>>>> >>>>> Brian >>>>> >>>>> On Sep 4, 2012, at 2:47 PM, John-Luc Bakker wrote: >>>>> >>>>>> Christer, >>>>>> >>>>>> It seems below an argument is made for either very many distinct Pri= ority header field values, each invoking a policy that both complies with t= he laws of the land and with their customer's preferences (i.e., their own = business needs), or just one Priority header field value, identifying the p= olicy in place for "emergency call back". As I understand it, the requireme= nts can be satisfied by having just one Priority header field value. The si= ngle value we have today that fits the bill is "emergency". >>>>>> >>>>>> Regards, >>>>>> >>>>>> JL >>>>>> >>>>>> -----Original Message----- >>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Beha= lf >>>>>> Of Christer Holmberg >>>>>> Sent: Monday, September 03, 2012 6:50 AM >>>>>> To: Martin Thomson; Paul Kyzivat >>>>>> Cc: ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicato= r >>>>>> >>>>>> Hi, >>>>>> >>>>>>> A callback is a call that is marked with Priority: helphelp (or >>>>>>> whatever) and the proxy makes some determination about call treatme= nt >>>>>>> based on information it has. This is likely caller identity =3D=3D= PSAP, >>>>>>> but it doesn't matter...let the operator choose a policy that both = complies with the laws of the land and with their customer's preferences (i= .e., their own business needs). >>>>>>> >>>>>>> An emergency call is a call to urn:service:sos. That call might be= marked as Priority: omgmyfacemyface, but the primary determinant for how t= he call is treated is the callee, which is *by definition* a PSAP. >>>>>>> >>>>>>> Two cases, two sets of rules (one intentionally fuzzy, one crystal = clear). Done. >>>>>> >>>>>> Yes. >>>>>> >>>>>> So, the question is still: for callback, do we define a new Priority= value or not? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> --------------------------------------------------------------------= - >>>>>> This transmission (including any attachments) may contain confidenti= al information, privileged material (including material protected by the so= licitor-client or other applicable privileges), or constitute non-public in= formation. Any use of this information by anyone other than the intended re= cipient is prohibited. If you have received this transmission in error, ple= ase immediately reply to the sender and delete this information from your s= ystem. Use, dissemination, distribution, or reproduction of this transmissi= on by unintended recipients is not authorized and may be unlawful. >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From md3135@att.com Wed Sep 5 10:37:56 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F30B21F844E for ; Wed, 5 Sep 2012 10:37:56 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVwJmOjmCHt3 for ; Wed, 5 Sep 2012 10:37:55 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 1393421F8650 for ; Wed, 5 Sep 2012 10:37:55 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 3fd87405.2aaad3a18940.658558.00-537.1813225.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 05 Sep 2012 17:37:55 +0000 (UTC) X-MXL-Hash: 50478df37974cc10-73fd5c96ddb36331e51d48b63a70cf08747b0338 Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id bed87405.0.658538.00-350.1813168.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 05 Sep 2012 17:37:48 +0000 (UTC) X-MXL-Hash: 50478dec3cfc8539-9b8464b8221425d56d70ee817a1622fcf9f0bbe2 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q85Hbkpd004877; Wed, 5 Sep 2012 10:37:47 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q85Hbbft004522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Sep 2012 10:37:40 -0700 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by fflint04.pst.cso.att.com (RSA Interceptor); Wed, 5 Sep 2012 10:37:26 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0318.001; Wed, 5 Sep 2012 13:37:24 -0400 From: "DOLLY, MARTIN C" To: Martin Thomson , "Rosen, Brian" Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: AQHNi331xHFmQUB3y02HrYAxzQgcDZd8Q78AgAABJQD//71WcA== Date: Wed, 5 Sep 2012 17:37:23 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05853408683691@ESESSCMS0356.eemea.ericsson.se> <502E6573.80107@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA351DB027@XMB104ADS.rim.net> <44CDF7EF-01D3-49ED-AD32-C54EDFFE1880@neustar.biz> <5032AFAB.4080300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A6B@ESESSCMS0356.eemea.ericsson.se> <50339093.5080700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EC8@ESESSCMS0356.eemea.ericsson.se> <5033C164.20807@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A460738@ESESSCMS0356.eemea.ericsson.se> <155970D1DA8E174F9E46039E10E2AA351EA9B6@XMB104ADS.rim.net> <7B8820C0-5B37-4E8D-BC09-B45C778BE3D7@neustar.biz> <7F2072F1E0DE894DA4B517B93C6A0585340A4611B7@ESESSCMS0356.eemea.ericsson.se> <50476864.9040303@alum.mit.edu> <5047745F.2010706@alum.mit.edu> <985D9D15-DA49-4DE1-9839-C8A5B6934F83@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.81.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=J6iNuQnLI54A:10 a=6kcpLNJcEBwA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=48vgC7mUAAAA:8 a=hGBaWAWWAAAA:8 a=j6H4nm1v] X-AnalysisOut: [AAAA:8 a=fq6d7nl7Ltx2qd029FYA:9 a=CjuIK1q_8ugA:10 a=lZB815] X-AnalysisOut: [dzVvQA:10 a=8YRM0CpMilAA:10 a=yJMHs_eEARPyU3xV:21 a=tpVVWO] X-AnalysisOut: [-jIbsZGSsx:21] Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 17:37:56 -0000 I prefer emergency-callback, but in the end it is just a name.... -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of M= artin Thomson Sent: Wednesday, September 05, 2012 1:32 PM To: Rosen, Brian Cc: ecrit@ietf.org Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator psap-callback ? On 5 September 2012 10:28, Rosen, Brian wrote: > I don't think we are trying to create a marking for an arbitrary call pla= ced from a PSAP to someone in another network. The marking is specifically= for call backs, and not other purposes. > > I think that it IS acceptable to refuse such calls if there was no call o= ut. For example, if the call is to some sort of Contact address which, due= to some local requirements, was formatted in some way specifically known t= o the local system, it might refuse the call to the device if there was no = preceding emergency call. A call to a normal AoR may not be refused, but m= ay not get any special treatment if the marking has no way of being authent= icated. All of that is up to the local system and any intermediaries. I t= hink Christer, and most of us discussing this, only intend it to be used fo= r a call back. > > I think there is no need to generalize, and emergency-callback is just fi= ne. > > Brian > > On Sep 5, 2012, at 11:48 AM, Paul Kyzivat wrote: > >> On 9/5/12 11:13 AM, Rosen, Brian wrote: >>> How about "emergencyCallBack"? >> >> Hardly anything in sip uses mixed case this way. So from that perspectiv= e I would counter with "emergency-callback". >> >> But a more significant issue is what semantics this is intended to conve= y. In particular, is a call with this attribute of necessity a *callback*? = Is anything in the call path justified in refusing the request if there was= no preceding call for which this is a callback? >> >> E.g. if psap received an emergency call from phone-1, and it is necessar= y to reconnect to a different phone, or perhaps even a different person, in= order to continue handling the emergency, then it may be hard to describe = that as a "callback". Yet the PSAP may want to do it, and I suppose the mec= hanism should allow it. If so, then "emergency-callback" has the wrong conn= otation. This is really why I find "emergency" to be appropriate. If we mus= t have a new term, how about: "expedited-emergency", "urgent-emergency", "e= mergency-override"? >> >> Thanks, >> Paul >> >>> On Sep 5, 2012, at 10:57 AM, Paul Kyzivat wrote= : >>> >>>> On 9/5/12 3:42 AM, Christer Holmberg wrote: >>>>> Hi, >>>>> >>>>> Then, no matter whether people think a new value is really required o= r not, would people object to defining a new value? >>>>> >>>>> This is really about making a choice and getting the work done :) >>>> >>>> Given all the discussion that has occurred about he pros and cons, I a= m willing to accept either using "emergency" or using a new value. >>>> >>>> (If the decision is to go with a new value, I reserve the right to arg= ue about what it is called. You only get one chance to get that right, and = some values will be clearer than others. But at the end of the day I will g= o along with whatever the consensus brings.) >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>> Sent: 4. syyskuuta 2012 22:10 >>>>> To: John-Luc Bakker >>>>> Cc: Christer Holmberg; Martin Thomson; Paul Kyzivat; ecrit@ietf.org >>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>>>> >>>>> I don't think that is the issue. >>>>> >>>>> Some folks believe the definition of "emergency" is wider than "emerg= ency call back" and thus a new value is needed to differentiate. They woul= d argue that we can't redefine "emergency" to "emergency call back". I thi= nk the other side would say that there are other fields in the INVITE would= allow that differentiation, such as the to/from. >>>>> >>>>> I continue to not care much, but observe that new values are cheap. >>>>> >>>>> Brian >>>>> >>>>> On Sep 4, 2012, at 2:47 PM, John-Luc Bakker wrote: >>>>> >>>>>> Christer, >>>>>> >>>>>> It seems below an argument is made for either very many distinct Pri= ority header field values, each invoking a policy that both complies with t= he laws of the land and with their customer's preferences (i.e., their own = business needs), or just one Priority header field value, identifying the p= olicy in place for "emergency call back". As I understand it, the requireme= nts can be satisfied by having just one Priority header field value. The si= ngle value we have today that fits the bill is "emergency". >>>>>> >>>>>> Regards, >>>>>> >>>>>> JL >>>>>> >>>>>> -----Original Message----- >>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Beha= lf >>>>>> Of Christer Holmberg >>>>>> Sent: Monday, September 03, 2012 6:50 AM >>>>>> To: Martin Thomson; Paul Kyzivat >>>>>> Cc: ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicato= r >>>>>> >>>>>> Hi, >>>>>> >>>>>>> A callback is a call that is marked with Priority: helphelp (or >>>>>>> whatever) and the proxy makes some determination about call treatme= nt >>>>>>> based on information it has. This is likely caller identity =3D=3D= PSAP, >>>>>>> but it doesn't matter...let the operator choose a policy that both = complies with the laws of the land and with their customer's preferences (i= .e., their own business needs). >>>>>>> >>>>>>> An emergency call is a call to urn:service:sos. That call might be= marked as Priority: omgmyfacemyface, but the primary determinant for how t= he call is treated is the callee, which is *by definition* a PSAP. >>>>>>> >>>>>>> Two cases, two sets of rules (one intentionally fuzzy, one crystal = clear). Done. >>>>>> >>>>>> Yes. >>>>>> >>>>>> So, the question is still: for callback, do we define a new Priority= value or not? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> --------------------------------------------------------------------= - >>>>>> This transmission (including any attachments) may contain confidenti= al information, privileged material (including material protected by the so= licitor-client or other applicable privileges), or constitute non-public in= formation. Any use of this information by anyone other than the intended re= cipient is prohibited. If you have received this transmission in error, ple= ase immediately reply to the sender and delete this information from your s= ystem. Use, dissemination, distribution, or reproduction of this transmissi= on by unintended recipients is not authorized and may be unlawful. >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From christer.holmberg@ericsson.com Fri Sep 7 04:05:41 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B88321F861E for ; Fri, 7 Sep 2012 04:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7j+B-m7+oGg for ; Fri, 7 Sep 2012 04:05:40 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 357B821F876D for ; Fri, 7 Sep 2012 04:05:39 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-96-5049d5018d9e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 7D.04.11467.105D9405; Fri, 7 Sep 2012 13:05:38 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Fri, 7 Sep 2012 13:05:37 +0200 From: Christer Holmberg To: "DOLLY, MARTIN C" , Martin Thomson , "Rosen, Brian" Date: Fri, 7 Sep 2012 13:05:36 +0200 Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: AQHNi331xHFmQUB3y02HrYAxzQgcDZd8Q78AgAABJQD//71WcIACuBHA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A4D38A9@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05853408683691@ESESSCMS0356.eemea.ericsson.se> <502E6573.80107@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA351DB027@XMB104ADS.rim.net> <44CDF7EF-01D3-49ED-AD32-C54EDFFE1880@neustar.biz> <5032AFAB.4080300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A6B@ESESSCMS0356.eemea.ericsson.se> <50339093.5080700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EC8@ESESSCMS0356.eemea.ericsson.se> <5033C164.20807@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A460738@ESESSCMS0356.eemea.ericsson.se> <155970D1DA8E174F9E46039E10E2AA351EA9B6@XMB104ADS.rim.net> <7B8820C0-5B37-4E8D-BC09-B45C778BE3D7@neustar.biz> <7F2072F1E0DE894DA4B517B93C6A0585340A4611B7@ESESSCMS0356.eemea.ericsson.se> <50476864.9040303@alum.mit.edu> <5047745F.2010706@alum.mit.edu> <985D9D15-DA49-4DE1-9839-C8A5B6934F83@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+JvrS7TVc8Ag69rmCymnbzMbNG46Cmr xbUz/xgtDj14yu7A4vGyfw6jx85Zd9k9liz5yeSxo+E5cwBLFJdNSmpOZllqkb5dAlfGymvP 2AvOO1XsvvKHsYHxiVkXIyeHhICJRNf0b0wQtpjEhXvr2UBsIYFTjBLvlml2MXIB2fMZJVYv 7WPvYuTgYBOwkOj+pw1SIyJQKzH110ywXmYBVYlzjY9ZQEpYBFQkpq4VAQkLC7hK3F86lR2i 3E3i+cNTLDD2taMTwOK8AuEST3b+YIJYdYxT4uKuu2BFnAIREt+XbAObzwh02/dTa6B2iUvc ejIf6mYBiSV7zjND2KISLx//Y4WoF5W4076eEaJeR2LB7k9sELa2xLKFr5khFgtKnJz5hGUC o9gsJGNnIWmZhaRlFpKWBYwsqxiFcxMzc9LLDfVSizKTi4vz8/SKUzcxAiPs4JbfujsYT50T OcQozcGiJM7LlbTfX0ggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjxJe//W67Ijzy7gQ2nlp6 y+9rQaqn7rUYv6IbUzXVrt+d9ufC1KQvh2TcUrWKL/EXdR52rrrLnXW9+seTzK7+8INWpoFH P1Xd5HpYw7Eh52pjm8s0wb8MmY07ulYJ79WLMQwIU2+O/sf3ufHv7eLZsi2tv+R7chglgs5k 7p2jyd4qy3SgZrUSS3FGoqEWc1FxIgBZ66L5fgIAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 11:05:41 -0000 Hi, So, my suggestion would then be that me and Hannes update the callback draf= t, and define a new value. Regards, Christer -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of D= OLLY, MARTIN C Sent: 5. syyskuuta 2012 20:37 To: Martin Thomson; Rosen, Brian Cc: ecrit@ietf.org Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator I prefer emergency-callback, but in the end it is just a name.... -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of M= artin Thomson Sent: Wednesday, September 05, 2012 1:32 PM To: Rosen, Brian Cc: ecrit@ietf.org Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator psap-callback ? On 5 September 2012 10:28, Rosen, Brian wrote: > I don't think we are trying to create a marking for an arbitrary call pla= ced from a PSAP to someone in another network. The marking is specifically= for call backs, and not other purposes. > > I think that it IS acceptable to refuse such calls if there was no call o= ut. For example, if the call is to some sort of Contact address which, due= to some local requirements, was formatted in some way specifically known t= o the local system, it might refuse the call to the device if there was no = preceding emergency call. A call to a normal AoR may not be refused, but m= ay not get any special treatment if the marking has no way of being authent= icated. All of that is up to the local system and any intermediaries. I t= hink Christer, and most of us discussing this, only intend it to be used fo= r a call back. > > I think there is no need to generalize, and emergency-callback is just fi= ne. > > Brian > > On Sep 5, 2012, at 11:48 AM, Paul Kyzivat wrote: > >> On 9/5/12 11:13 AM, Rosen, Brian wrote: >>> How about "emergencyCallBack"? >> >> Hardly anything in sip uses mixed case this way. So from that perspectiv= e I would counter with "emergency-callback". >> >> But a more significant issue is what semantics this is intended to conve= y. In particular, is a call with this attribute of necessity a *callback*? = Is anything in the call path justified in refusing the request if there was= no preceding call for which this is a callback? >> >> E.g. if psap received an emergency call from phone-1, and it is necessar= y to reconnect to a different phone, or perhaps even a different person, in= order to continue handling the emergency, then it may be hard to describe = that as a "callback". Yet the PSAP may want to do it, and I suppose the mec= hanism should allow it. If so, then "emergency-callback" has the wrong conn= otation. This is really why I find "emergency" to be appropriate. If we mus= t have a new term, how about: "expedited-emergency", "urgent-emergency", "e= mergency-override"? >> >> Thanks, >> Paul >> >>> On Sep 5, 2012, at 10:57 AM, Paul Kyzivat wrote= : >>> >>>> On 9/5/12 3:42 AM, Christer Holmberg wrote: >>>>> Hi, >>>>> >>>>> Then, no matter whether people think a new value is really required o= r not, would people object to defining a new value? >>>>> >>>>> This is really about making a choice and getting the work done :) >>>> >>>> Given all the discussion that has occurred about he pros and cons, I a= m willing to accept either using "emergency" or using a new value. >>>> >>>> (If the decision is to go with a new value, I reserve the right to=20 >>>> argue about what it is called. You only get one chance to get that=20 >>>> right, and some values will be clearer than others. But at the end=20 >>>> of the day I will go along with whatever the consensus brings.) >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>> Sent: 4. syyskuuta 2012 22:10 >>>>> To: John-Luc Bakker >>>>> Cc: Christer Holmberg; Martin Thomson; Paul Kyzivat;=20 >>>>> ecrit@ietf.org >>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback=20 >>>>> Indicator >>>>> >>>>> I don't think that is the issue. >>>>> >>>>> Some folks believe the definition of "emergency" is wider than "emerg= ency call back" and thus a new value is needed to differentiate. They woul= d argue that we can't redefine "emergency" to "emergency call back". I thi= nk the other side would say that there are other fields in the INVITE would= allow that differentiation, such as the to/from. >>>>> >>>>> I continue to not care much, but observe that new values are cheap. >>>>> >>>>> Brian >>>>> >>>>> On Sep 4, 2012, at 2:47 PM, John-Luc Bakker wrote: >>>>> >>>>>> Christer, >>>>>> >>>>>> It seems below an argument is made for either very many distinct Pri= ority header field values, each invoking a policy that both complies with t= he laws of the land and with their customer's preferences (i.e., their own = business needs), or just one Priority header field value, identifying the p= olicy in place for "emergency call back". As I understand it, the requireme= nts can be satisfied by having just one Priority header field value. The si= ngle value we have today that fits the bill is "emergency". >>>>>> >>>>>> Regards, >>>>>> >>>>>> JL >>>>>> >>>>>> -----Original Message----- >>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 >>>>>> Behalf Of Christer Holmberg >>>>>> Sent: Monday, September 03, 2012 6:50 AM >>>>>> To: Martin Thomson; Paul Kyzivat >>>>>> Cc: ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback=20 >>>>>> Indicator >>>>>> >>>>>> Hi, >>>>>> >>>>>>> A callback is a call that is marked with Priority: helphelp (or >>>>>>> whatever) and the proxy makes some determination about call=20 >>>>>>> treatment based on information it has. This is likely caller=20 >>>>>>> identity =3D=3D PSAP, but it doesn't matter...let the operator choo= se a policy that both complies with the laws of the land and with their cus= tomer's preferences (i.e., their own business needs). >>>>>>> >>>>>>> An emergency call is a call to urn:service:sos. That call might be= marked as Priority: omgmyfacemyface, but the primary determinant for how t= he call is treated is the callee, which is *by definition* a PSAP. >>>>>>> >>>>>>> Two cases, two sets of rules (one intentionally fuzzy, one crystal = clear). Done. >>>>>> >>>>>> Yes. >>>>>> >>>>>> So, the question is still: for callback, do we define a new Priority= value or not? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> ----------------------------------------------------------------- >>>>>> ---- This transmission (including any attachments) may contain=20 >>>>>> confidential information, privileged material (including material pr= otected by the solicitor-client or other applicable privileges), or constit= ute non-public information. Any use of this information by anyone other tha= n the intended recipient is prohibited. If you have received this transmiss= ion in error, please immediately reply to the sender and delete this inform= ation from your system. Use, dissemination, distribution, or reproduction o= f this transmission by unintended recipients is not authorized and may be u= nlawful. >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From pkyzivat@alum.mit.edu Fri Sep 7 06:52:37 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6965E21F86D3 for ; Fri, 7 Sep 2012 06:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYBWMDQKyI2P for ; Fri, 7 Sep 2012 06:52:36 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 6E83E21F86D0 for ; Fri, 7 Sep 2012 06:52:36 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta10.westchester.pa.mail.comcast.net with comcast id wDnB1j0010Fqzac5ADsfHf; Fri, 07 Sep 2012 13:52:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id wDsX1j00Z3ZTu2S3UDsXBP; Fri, 07 Sep 2012 13:52:32 +0000 Message-ID: <5049FC22.3090207@alum.mit.edu> Date: Fri, 07 Sep 2012 09:52:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: ecrit@ietf.org References: <50339093.5080700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EC8@ESESSCMS0356.eemea.ericsson.se> <5033C164.20807@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A460738@ESESSCMS0356.eemea.ericsson.se> <155970D1DA8E174F9E46039E10E2AA351EA9B6@XMB104ADS.rim.net> <7B8820C0-5B37-4E8D-BC09-B45C778BE3D7@neustar.biz> <7F2072F1E0DE894DA4B517B93C6A0585340A4611B7@ESESSCMS0356.eemea.ericsson.se> <50476864.9040303@alum.mit.edu> <5047745F.2010706@alum.mit.edu> <985D9D15-DA49-4DE1-9839-C8A5B6934F83@neustar.biz> <7F2072F1E0DE894DA4B517B93C6A0585340A4D38A9@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A4D38A9@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 13:52:37 -0000 On 9/7/12 7:05 AM, Christer Holmberg wrote: > Hi, > > So, my suggestion would then be that me and Hannes update the callback draft, and define a new value. This means the draft becomes a revision to 3261. And since it's means there is more than one place that defined values for the Priority header field, it probably makes sense to establish an IANA registry for the values, initialized from 3261 and this draft. We will have to discuss with the ADs whether this needs to be reviewed by sipcore. Thanks, Paul > Regards, > > Christer > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C > Sent: 5. syyskuuta 2012 20:37 > To: Martin Thomson; Rosen, Brian > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator > > I prefer emergency-callback, but in the end it is just a name.... > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Martin Thomson > Sent: Wednesday, September 05, 2012 1:32 PM > To: Rosen, Brian > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator > > psap-callback ? > > On 5 September 2012 10:28, Rosen, Brian wrote: >> I don't think we are trying to create a marking for an arbitrary call placed from a PSAP to someone in another network. The marking is specifically for call backs, and not other purposes. >> >> I think that it IS acceptable to refuse such calls if there was no call out. For example, if the call is to some sort of Contact address which, due to some local requirements, was formatted in some way specifically known to the local system, it might refuse the call to the device if there was no preceding emergency call. A call to a normal AoR may not be refused, but may not get any special treatment if the marking has no way of being authenticated. All of that is up to the local system and any intermediaries. I think Christer, and most of us discussing this, only intend it to be used for a call back. >> >> I think there is no need to generalize, and emergency-callback is just fine. >> >> Brian >> >> On Sep 5, 2012, at 11:48 AM, Paul Kyzivat wrote: >> >>> On 9/5/12 11:13 AM, Rosen, Brian wrote: >>>> How about "emergencyCallBack"? >>> >>> Hardly anything in sip uses mixed case this way. So from that perspective I would counter with "emergency-callback". >>> >>> But a more significant issue is what semantics this is intended to convey. In particular, is a call with this attribute of necessity a *callback*? Is anything in the call path justified in refusing the request if there was no preceding call for which this is a callback? >>> >>> E.g. if psap received an emergency call from phone-1, and it is necessary to reconnect to a different phone, or perhaps even a different person, in order to continue handling the emergency, then it may be hard to describe that as a "callback". Yet the PSAP may want to do it, and I suppose the mechanism should allow it. If so, then "emergency-callback" has the wrong connotation. This is really why I find "emergency" to be appropriate. If we must have a new term, how about: "expedited-emergency", "urgent-emergency", "emergency-override"? >>> >>> Thanks, >>> Paul >>> >>>> On Sep 5, 2012, at 10:57 AM, Paul Kyzivat wrote: >>>> >>>>> On 9/5/12 3:42 AM, Christer Holmberg wrote: >>>>>> Hi, >>>>>> >>>>>> Then, no matter whether people think a new value is really required or not, would people object to defining a new value? >>>>>> >>>>>> This is really about making a choice and getting the work done :) >>>>> >>>>> Given all the discussion that has occurred about he pros and cons, I am willing to accept either using "emergency" or using a new value. >>>>> >>>>> (If the decision is to go with a new value, I reserve the right to >>>>> argue about what it is called. You only get one chance to get that >>>>> right, and some values will be clearer than others. But at the end >>>>> of the day I will go along with whatever the consensus brings.) >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>>> Sent: 4. syyskuuta 2012 22:10 >>>>>> To: John-Luc Bakker >>>>>> Cc: Christer Holmberg; Martin Thomson; Paul Kyzivat; >>>>>> ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback >>>>>> Indicator >>>>>> >>>>>> I don't think that is the issue. >>>>>> >>>>>> Some folks believe the definition of "emergency" is wider than "emergency call back" and thus a new value is needed to differentiate. They would argue that we can't redefine "emergency" to "emergency call back". I think the other side would say that there are other fields in the INVITE would allow that differentiation, such as the to/from. >>>>>> >>>>>> I continue to not care much, but observe that new values are cheap. >>>>>> >>>>>> Brian >>>>>> >>>>>> On Sep 4, 2012, at 2:47 PM, John-Luc Bakker wrote: >>>>>> >>>>>>> Christer, >>>>>>> >>>>>>> It seems below an argument is made for either very many distinct Priority header field values, each invoking a policy that both complies with the laws of the land and with their customer's preferences (i.e., their own business needs), or just one Priority header field value, identifying the policy in place for "emergency call back". As I understand it, the requirements can be satisfied by having just one Priority header field value. The single value we have today that fits the bill is "emergency". >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> JL >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>>>>> Behalf Of Christer Holmberg >>>>>>> Sent: Monday, September 03, 2012 6:50 AM >>>>>>> To: Martin Thomson; Paul Kyzivat >>>>>>> Cc: ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback >>>>>>> Indicator >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>>> A callback is a call that is marked with Priority: helphelp (or >>>>>>>> whatever) and the proxy makes some determination about call >>>>>>>> treatment based on information it has. This is likely caller >>>>>>>> identity == PSAP, but it doesn't matter...let the operator choose a policy that both complies with the laws of the land and with their customer's preferences (i.e., their own business needs). >>>>>>>> >>>>>>>> An emergency call is a call to urn:service:sos. That call might be marked as Priority: omgmyfacemyface, but the primary determinant for how the call is treated is the callee, which is *by definition* a PSAP. >>>>>>>> >>>>>>>> Two cases, two sets of rules (one intentionally fuzzy, one crystal clear). Done. >>>>>>> >>>>>>> Yes. >>>>>>> >>>>>>> So, the question is still: for callback, do we define a new Priority value or not? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> ----------------------------------------------------------------- >>>>>>> ---- This transmission (including any attachments) may contain >>>>>>> confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From christer.holmberg@ericsson.com Fri Sep 7 07:10:29 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2591321E809B for ; Fri, 7 Sep 2012 07:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ayf0Wcwe0m-N for ; Fri, 7 Sep 2012 07:10:28 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9015721E8051 for ; Fri, 7 Sep 2012 07:10:27 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-37-504a005258e6 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 6B.AF.17130.2500A405; Fri, 7 Sep 2012 16:10:26 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Fri, 7 Sep 2012 16:10:26 +0200 From: Christer Holmberg To: Paul Kyzivat , "ecrit@ietf.org" Date: Fri, 7 Sep 2012 16:10:25 +0200 Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac2NAA5dRyhZua2oRoOAONcIhBuhagAAeA5A Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A4D3A5D@ESESSCMS0356.eemea.ericsson.se> References: <50339093.5080700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EC8@ESESSCMS0356.eemea.ericsson.se> <5033C164.20807@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A460738@ESESSCMS0356.eemea.ericsson.se> <155970D1DA8E174F9E46039E10E2AA351EA9B6@XMB104ADS.rim.net> <7B8820C0-5B37-4E8D-BC09-B45C778BE3D7@neustar.biz> <7F2072F1E0DE894DA4B517B93C6A0585340A4611B7@ESESSCMS0356.eemea.ericsson.se> <50476864.9040303@alum.mit.edu> <5047745F.2010706@alum.mit.edu> <985D9D15-DA49-4DE1-9839-C8A5B6934F83@neustar.biz> <7F2072F1E0DE894DA4B517B93C6A0585340A4D38A9@ESESSCMS0356.eemea.ericsson.se> <5049FC22.3090207@alum.mit.edu> In-Reply-To: <5049FC22.3090207@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+JvrW4Qg1eAQVefqEXjoqesFis2HGB1 YPL4+/4Dk8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIe7//PVrDDq+LGN9EGxoW2XYycHBICJhL3 +7exQthiEhfurWfrYuTiEBI4xSjRvaOXCcKZzyjx6fdWli5GDg42AQuJ7n/aIA0iAt4Sf35/ YwOxWQRUJK4tbgIbJCzgKnF/6VR2iBo3iecPT7FA2EYS/2ZuZwSxeQXCJfad6WKGmP+MXeL0 0+lgCU4BHYktby+CDWUEuuj7qTVMIDazgLjErSfzmSAuFZBYsuc8M4QtKvHy8T9WiHpRiTvt 6xkh6nUkFuz+xAZha0ssW/iaGWKxoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKUTg3MTMn vdxcL7UoM7m4OD9Przh1EyMwRg5u+W2wg3HTfbFDjNIcLErivHqq+/2FBNITS1KzU1MLUovi i0pzUosPMTJxcEo1MArvfbFxS3hX4N/oO77JGuLhPos5iu6vf9z99ea9T4e7rh1aHu9wMjrQ 44HF9tfslav/WYSvtfx/8fSsd/N6F6nvUnLc9vpK+r2Hzgztz2RjLvEZSF3TsT3esu3Fh2M3 7r81qFq8bSVX3fWlZtWRDf3FySwCMX93iye698v/UC1X+PWnetkc+SQlluKMREMt5qLiRAC4 eNe1XwIAAA== Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 14:10:29 -0000 Hi, >> So, my suggestion would then be that me and Hannes update the callback d= raft, and define a new value. > > This means the draft becomes a revision to 3261. And since it's means the= re is more than one place that defined values for the Priority header field= , it probably makes sense to establish an IANA registry for the values, ini= tialized from 3261 and this draft. I am not sure what you mean by revision. 3261 already allows new Priority h= eader field values. AFAIK, a new value DOES require an RFC, though. > We will have to discuss with the ADs whether this needs to be reviewed by= sipcore. Agree. Regards, Christer > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=20 > Of DOLLY, MARTIN C > Sent: 5. syyskuuta 2012 20:37 > To: Martin Thomson; Rosen, Brian > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator > > I prefer emergency-callback, but in the end it is just a name.... > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=20 > Of Martin Thomson > Sent: Wednesday, September 05, 2012 1:32 PM > To: Rosen, Brian > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator > > psap-callback ? > > On 5 September 2012 10:28, Rosen, Brian wrote: >> I don't think we are trying to create a marking for an arbitrary call pl= aced from a PSAP to someone in another network. The marking is specificall= y for call backs, and not other purposes. >> >> I think that it IS acceptable to refuse such calls if there was no call = out. For example, if the call is to some sort of Contact address which, du= e to some local requirements, was formatted in some way specifically known = to the local system, it might refuse the call to the device if there was no= preceding emergency call. A call to a normal AoR may not be refused, but = may not get any special treatment if the marking has no way of being authen= ticated. All of that is up to the local system and any intermediaries. I = think Christer, and most of us discussing this, only intend it to be used f= or a call back. >> >> I think there is no need to generalize, and emergency-callback is just f= ine. >> >> Brian >> >> On Sep 5, 2012, at 11:48 AM, Paul Kyzivat wrote: >> >>> On 9/5/12 11:13 AM, Rosen, Brian wrote: >>>> How about "emergencyCallBack"? >>> >>> Hardly anything in sip uses mixed case this way. So from that perspecti= ve I would counter with "emergency-callback". >>> >>> But a more significant issue is what semantics this is intended to conv= ey. In particular, is a call with this attribute of necessity a *callback*?= Is anything in the call path justified in refusing the request if there wa= s no preceding call for which this is a callback? >>> >>> E.g. if psap received an emergency call from phone-1, and it is necessa= ry to reconnect to a different phone, or perhaps even a different person, i= n order to continue handling the emergency, then it may be hard to describe= that as a "callback". Yet the PSAP may want to do it, and I suppose the me= chanism should allow it. If so, then "emergency-callback" has the wrong con= notation. This is really why I find "emergency" to be appropriate. If we mu= st have a new term, how about: "expedited-emergency", "urgent-emergency", "= emergency-override"? >>> >>> Thanks, >>> Paul >>> >>>> On Sep 5, 2012, at 10:57 AM, Paul Kyzivat wrot= e: >>>> >>>>> On 9/5/12 3:42 AM, Christer Holmberg wrote: >>>>>> Hi, >>>>>> >>>>>> Then, no matter whether people think a new value is really required = or not, would people object to defining a new value? >>>>>> >>>>>> This is really about making a choice and getting the work done :) >>>>> >>>>> Given all the discussion that has occurred about he pros and cons, I = am willing to accept either using "emergency" or using a new value. >>>>> >>>>> (If the decision is to go with a new value, I reserve the right to=20 >>>>> argue about what it is called. You only get one chance to get that=20 >>>>> right, and some values will be clearer than others. But at the end=20 >>>>> of the day I will go along with whatever the consensus brings.) >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>>> Sent: 4. syyskuuta 2012 22:10 >>>>>> To: John-Luc Bakker >>>>>> Cc: Christer Holmberg; Martin Thomson; Paul Kyzivat;=20 >>>>>> ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback=20 >>>>>> Indicator >>>>>> >>>>>> I don't think that is the issue. >>>>>> >>>>>> Some folks believe the definition of "emergency" is wider than "emer= gency call back" and thus a new value is needed to differentiate. They wou= ld argue that we can't redefine "emergency" to "emergency call back". I th= ink the other side would say that there are other fields in the INVITE woul= d allow that differentiation, such as the to/from. >>>>>> >>>>>> I continue to not care much, but observe that new values are cheap. >>>>>> >>>>>> Brian >>>>>> >>>>>> On Sep 4, 2012, at 2:47 PM, John-Luc Bakker wrote: >>>>>> >>>>>>> Christer, >>>>>>> >>>>>>> It seems below an argument is made for either very many distinct Pr= iority header field values, each invoking a policy that both complies with = the laws of the land and with their customer's preferences (i.e., their own= business needs), or just one Priority header field value, identifying the = policy in place for "emergency call back". As I understand it, the requirem= ents can be satisfied by having just one Priority header field value. The s= ingle value we have today that fits the bill is "emergency". >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> JL >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 >>>>>>> Behalf Of Christer Holmberg >>>>>>> Sent: Monday, September 03, 2012 6:50 AM >>>>>>> To: Martin Thomson; Paul Kyzivat >>>>>>> Cc: ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback=20 >>>>>>> Indicator >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>>> A callback is a call that is marked with Priority: helphelp (or >>>>>>>> whatever) and the proxy makes some determination about call=20 >>>>>>>> treatment based on information it has. This is likely caller=20 >>>>>>>> identity =3D=3D PSAP, but it doesn't matter...let the operator cho= ose a policy that both complies with the laws of the land and with their cu= stomer's preferences (i.e., their own business needs). >>>>>>>> >>>>>>>> An emergency call is a call to urn:service:sos. That call might b= e marked as Priority: omgmyfacemyface, but the primary determinant for how = the call is treated is the callee, which is *by definition* a PSAP. >>>>>>>> >>>>>>>> Two cases, two sets of rules (one intentionally fuzzy, one crystal= clear). Done. >>>>>>> >>>>>>> Yes. >>>>>>> >>>>>>> So, the question is still: for callback, do we define a new Priorit= y value or not? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> ---------------------------------------------------------------- >>>>>>> - >>>>>>> ---- This transmission (including any attachments) may contain=20 >>>>>>> confidential information, privileged material (including material p= rotected by the solicitor-client or other applicable privileges), or consti= tute non-public information. Any use of this information by anyone other th= an the intended recipient is prohibited. If you have received this transmis= sion in error, please immediately reply to the sender and delete this infor= mation from your system. Use, dissemination, distribution, or reproduction = of this transmission by unintended recipients is not authorized and may be = unlawful. >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From brian.rosen@neustar.biz Fri Sep 7 07:20:11 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B26E21E8051 for ; Fri, 7 Sep 2012 07:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyiVIBtk3phj for ; Fri, 7 Sep 2012 07:20:10 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA2121E80AD for ; Fri, 7 Sep 2012 07:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1347027377; x=1662374301; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=DarDCnxxGS8aUYvgE0A3X 59hJMke6ltIoFCIdyinGKE=; b=SeDmlOv/hoTE/OIw5OWTN8IzP+KAIi3jD7KpX sBqWNnTXxFi/Kk/O4N9iCpmDyRnllt0nT7gt7QAdW0+HbtUwQ== Received: from ([10.31.13.228]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.10734700; Fri, 07 Sep 2012 10:16:16 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Fri, 7 Sep 2012 10:19:58 -0400 From: "Rosen, Brian" To: Christer Holmberg Date: Fri, 7 Sep 2012 10:19:56 -0400 Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac2NA9wCvTle15pHRjKCbg+hdPKiUQ== Message-ID: <45611914-A02C-4F80-8806-80C067B2E50A@neustar.biz> References: <50339093.5080700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EC8@ESESSCMS0356.eemea.ericsson.se> <5033C164.20807@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A460738@ESESSCMS0356.eemea.ericsson.se> <155970D1DA8E174F9E46039E10E2AA351EA9B6@XMB104ADS.rim.net> <7B8820C0-5B37-4E8D-BC09-B45C778BE3D7@neustar.biz> <7F2072F1E0DE894DA4B517B93C6A0585340A4611B7@ESESSCMS0356.eemea.ericsson.se> <50476864.9040303@alum.mit.edu> <5047745F.2010706@alum.mit.edu> <985D9D15-DA49-4DE1-9839-C8A5B6934F83@neustar.biz> <7F2072F1E0DE894DA4B517B93C6A0585340A4D38A9@ESESSCMS0356.eemea.ericsson.se> <5049FC22.3090207@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A4D3A5D@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A4D3A5D@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: VGFxh6j15iBqj7pQUqBa5A== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 14:20:11 -0000 I don't think this is necessarily an update to 3261, which says: =85 The header field can have the values "non-urgent", "normal", "urgent", and "emergency", but additional values can be defined elsewhere "Elsewhere" is not a defined term, so we get to decide what we want it to b= e. I think a registry is nice to have, and since it would have a management po= licy, it would define what "elsewhere" means. I personally don't think tha= t means it updates 3261, but if you wanted to alert a reader that "elsewher= e" includes an entry in a registry, I wouldn't mind calling it an update to= 3261. I don't think a registry is essential, and if adding a registry mak= es this a big deal instead of a little deal, then I'd forgo the registry. I think we probably ought to have sipcore review it. Brian On Sep 7, 2012, at 10:10 AM, Christer Holmberg wrote: > Hi, >=20 >>> So, my suggestion would then be that me and Hannes update the callback = draft, and define a new value. >>=20 >> This means the draft becomes a revision to 3261. And since it's means th= ere is more than one place that defined values for the Priority header fiel= d, it probably makes sense to establish an IANA registry for the values, in= itialized from 3261 and this draft. >=20 > I am not sure what you mean by revision. 3261 already allows new Priority= header field values. AFAIK, a new value DOES require an RFC, though. >=20 >> We will have to discuss with the ADs whether this needs to be reviewed b= y sipcore. >=20 > Agree. >=20 > Regards, >=20 > Christer >=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=20 >> Of DOLLY, MARTIN C >> Sent: 5. syyskuuta 2012 20:37 >> To: Martin Thomson; Rosen, Brian >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>=20 >> I prefer emergency-callback, but in the end it is just a name.... >>=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=20 >> Of Martin Thomson >> Sent: Wednesday, September 05, 2012 1:32 PM >> To: Rosen, Brian >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator >>=20 >> psap-callback ? >>=20 >> On 5 September 2012 10:28, Rosen, Brian wrote: >>> I don't think we are trying to create a marking for an arbitrary call p= laced from a PSAP to someone in another network. The marking is specifical= ly for call backs, and not other purposes. >>>=20 >>> I think that it IS acceptable to refuse such calls if there was no call= out. For example, if the call is to some sort of Contact address which, d= ue to some local requirements, was formatted in some way specifically known= to the local system, it might refuse the call to the device if there was n= o preceding emergency call. A call to a normal AoR may not be refused, but= may not get any special treatment if the marking has no way of being authe= nticated. All of that is up to the local system and any intermediaries. I= think Christer, and most of us discussing this, only intend it to be used = for a call back. >>>=20 >>> I think there is no need to generalize, and emergency-callback is just = fine. >>>=20 >>> Brian >>>=20 >>> On Sep 5, 2012, at 11:48 AM, Paul Kyzivat wrote= : >>>=20 >>>> On 9/5/12 11:13 AM, Rosen, Brian wrote: >>>>> How about "emergencyCallBack"? >>>>=20 >>>> Hardly anything in sip uses mixed case this way. So from that perspect= ive I would counter with "emergency-callback". >>>>=20 >>>> But a more significant issue is what semantics this is intended to con= vey. In particular, is a call with this attribute of necessity a *callback*= ? Is anything in the call path justified in refusing the request if there w= as no preceding call for which this is a callback? >>>>=20 >>>> E.g. if psap received an emergency call from phone-1, and it is necess= ary to reconnect to a different phone, or perhaps even a different person, = in order to continue handling the emergency, then it may be hard to describ= e that as a "callback". Yet the PSAP may want to do it, and I suppose the m= echanism should allow it. If so, then "emergency-callback" has the wrong co= nnotation. This is really why I find "emergency" to be appropriate. If we m= ust have a new term, how about: "expedited-emergency", "urgent-emergency", = "emergency-override"? >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>>> On Sep 5, 2012, at 10:57 AM, Paul Kyzivat wro= te: >>>>>=20 >>>>>> On 9/5/12 3:42 AM, Christer Holmberg wrote: >>>>>>> Hi, >>>>>>>=20 >>>>>>> Then, no matter whether people think a new value is really required= or not, would people object to defining a new value? >>>>>>>=20 >>>>>>> This is really about making a choice and getting the work done :) >>>>>>=20 >>>>>> Given all the discussion that has occurred about he pros and cons, I= am willing to accept either using "emergency" or using a new value. >>>>>>=20 >>>>>> (If the decision is to go with a new value, I reserve the right to=20 >>>>>> argue about what it is called. You only get one chance to get that=20 >>>>>> right, and some values will be clearer than others. But at the end=20 >>>>>> of the day I will go along with whatever the consensus brings.) >>>>>>=20 >>>>>> Thanks, >>>>>> Paul >>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Christer >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>>>> Sent: 4. syyskuuta 2012 22:10 >>>>>>> To: John-Luc Bakker >>>>>>> Cc: Christer Holmberg; Martin Thomson; Paul Kyzivat;=20 >>>>>>> ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback=20 >>>>>>> Indicator >>>>>>>=20 >>>>>>> I don't think that is the issue. >>>>>>>=20 >>>>>>> Some folks believe the definition of "emergency" is wider than "eme= rgency call back" and thus a new value is needed to differentiate. They wo= uld argue that we can't redefine "emergency" to "emergency call back". I t= hink the other side would say that there are other fields in the INVITE wou= ld allow that differentiation, such as the to/from. >>>>>>>=20 >>>>>>> I continue to not care much, but observe that new values are cheap. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Sep 4, 2012, at 2:47 PM, John-Luc Bakker wrote= : >>>>>>>=20 >>>>>>>> Christer, >>>>>>>>=20 >>>>>>>> It seems below an argument is made for either very many distinct P= riority header field values, each invoking a policy that both complies with= the laws of the land and with their customer's preferences (i.e., their ow= n business needs), or just one Priority header field value, identifying the= policy in place for "emergency call back". As I understand it, the require= ments can be satisfied by having just one Priority header field value. The = single value we have today that fits the bill is "emergency". >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> JL >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 >>>>>>>> Behalf Of Christer Holmberg >>>>>>>> Sent: Monday, September 03, 2012 6:50 AM >>>>>>>> To: Martin Thomson; Paul Kyzivat >>>>>>>> Cc: ecrit@ietf.org >>>>>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback=20 >>>>>>>> Indicator >>>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>>> A callback is a call that is marked with Priority: helphelp (or >>>>>>>>> whatever) and the proxy makes some determination about call=20 >>>>>>>>> treatment based on information it has. This is likely caller=20 >>>>>>>>> identity =3D=3D PSAP, but it doesn't matter...let the operator ch= oose a policy that both complies with the laws of the land and with their c= ustomer's preferences (i.e., their own business needs). >>>>>>>>>=20 >>>>>>>>> An emergency call is a call to urn:service:sos. That call might = be marked as Priority: omgmyfacemyface, but the primary determinant for how= the call is treated is the callee, which is *by definition* a PSAP. >>>>>>>>>=20 >>>>>>>>> Two cases, two sets of rules (one intentionally fuzzy, one crysta= l clear). Done. >>>>>>>>=20 >>>>>>>> Yes. >>>>>>>>=20 >>>>>>>> So, the question is still: for callback, do we define a new Priori= ty value or not? >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Christer >>>>>>>> _______________________________________________ >>>>>>>> Ecrit mailing list >>>>>>>> Ecrit@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>=20 >>>>>>>> ---------------------------------------------------------------- >>>>>>>> - >>>>>>>> ---- This transmission (including any attachments) may contain=20 >>>>>>>> confidential information, privileged material (including material = protected by the solicitor-client or other applicable privileges), or const= itute non-public information. Any use of this information by anyone other t= han the intended recipient is prohibited. If you have received this transmi= ssion in error, please immediately reply to the sender and delete this info= rmation from your system. Use, dissemination, distribution, or reproduction= of this transmission by unintended recipients is not authorized and may be= unlawful. >>>>>>>> _______________________________________________ >>>>>>>> Ecrit mailing list >>>>>>>> Ecrit@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From jmpolk@cisco.com Fri Sep 7 14:51:46 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13B021E80BC for ; Fri, 7 Sep 2012 14:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tuv63GaR+Qa0 for ; Fri, 7 Sep 2012 14:51:45 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id B0C4021F85F4 for ; Fri, 7 Sep 2012 14:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8320; q=dns/txt; s=iport; t=1347054705; x=1348264305; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=s4+2R5yfE4nCpi7oad/6ISHYpw+acTZ3Gt2LbzzCBzo=; b=IiBSSqXG5JO5F6YbPCmiWIoj4ZpCN14gV4cJ1yXjzzPWrgdRrDex4UuV ycnQ5H3T2OFXZCg9Dt6KCtYrxTxLPdlFBBabOg/9w5DRAkmWinm7oaudY 6ujqAnpFbL/L4qsggG/g7L7Wtei27Fg9aCLgQC5dxzpenDcy+N8VqiLhR c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOlrSlCrRDoJ/2dsb2JhbAA8CbtRgQeCIAEBAQQBAQEPAQobAjQLDAICBwQRBAEBAR4JBxkCDB8JCAYTIodtDJsToB4EBIsOEYYjA4hTmz+BZ4MC X-IronPort-AV: E=Sophos;i="4.80,388,1344211200"; d="scan'208";a="57494622" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 07 Sep 2012 21:51:44 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q87LphOf001560; Fri, 7 Sep 2012 21:51:44 GMT Message-Id: <201209072151.q87LphOf001560@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 07 Sep 2012 16:51:41 -0500 To: Martin Thomson , "Rosen, Brian" From: James Polk In-Reply-To: References: <7F2072F1E0DE894DA4B517B93C6A05853408683691@ESESSCMS0356.eemea.ericsson.se> <502E6573.80107@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA351DB027@XMB104ADS.rim.net> <44CDF7EF-01D3-49ED-AD32-C54EDFFE1880@neustar.biz> <5032AFAB.4080300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A6B@ESESSCMS0356.eemea.ericsson.se> <50339093.5080700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EC8@ESESSCMS0356.eemea.ericsson.se> <5033C164.20807@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A460738@ESESSCMS0356.eemea.ericsson.se> <155970D1DA8E174F9E46039E10E2AA351EA9B6@XMB104ADS.rim.net> <7B8820C0-5B37-4E8D-BC09-B45C778BE3D7@neustar.biz> <7F2072F1E0DE894DA4B517B93C6A0585340A4611B7@ESESSCMS0356.eemea.ericsson.se> <50476864.9040303@alum.mit.edu> <5047745F.2010706@alum.mit.edu> <985D9D15-DA49-4DE1-9839-C8A5B6934F83@neustar.biz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 21:51:46 -0000 At 12:32 PM 9/5/2012, Martin Thomson wrote: >psap-callback ? this value is as concrete as any I've read or heard or suggested myself. It states exactly what's happening and cannot be misinterpreted - which is a very good thing. I'll bow to Paul's investigation into what about this needs to be done wrt SIPCORE, given that there is no TOKEN defined for extensibility in this header (which would have made this rather easy). James >On 5 September 2012 10:28, Rosen, Brian wrote: > > I don't think we are trying to create a marking for an arbitrary > call placed from a PSAP to someone in another network. The marking > is specifically for call backs, and not other purposes. > > > > I think that it IS acceptable to refuse such calls if there was > no call out. For example, if the call is to some sort of Contact > address which, due to some local requirements, was formatted in > some way specifically known to the local system, it might refuse > the call to the device if there was no preceding emergency call. A > call to a normal AoR may not be refused, but may not get any > special treatment if the marking has no way of being > authenticated. All of that is up to the local system and any > intermediaries. I think Christer, and most of us discussing this, > only intend it to be used for a call back. > > > > I think there is no need to generalize, and emergency-callback is > just fine. > > > > Brian > > > > On Sep 5, 2012, at 11:48 AM, Paul Kyzivat wrote: > > > >> On 9/5/12 11:13 AM, Rosen, Brian wrote: > >>> How about "emergencyCallBack"? > >> > >> Hardly anything in sip uses mixed case this way. So from that > perspective I would counter with "emergency-callback". > >> > >> But a more significant issue is what semantics this is intended > to convey. In particular, is a call with this attribute of > necessity a *callback*? Is anything in the call path justified in > refusing the request if there was no preceding call for which this > is a callback? > >> > >> E.g. if psap received an emergency call from phone-1, and it is > necessary to reconnect to a different phone, or perhaps even a > different person, in order to continue handling the emergency, then > it may be hard to describe that as a "callback". Yet the PSAP may > want to do it, and I suppose the mechanism should allow it. If so, > then "emergency-callback" has the wrong connotation. This is really > why I find "emergency" to be appropriate. If we must have a new > term, how about: "expedited-emergency", "urgent-emergency", > "emergency-override"? > >> > >> Thanks, > >> Paul > >> > >>> On Sep 5, 2012, at 10:57 AM, Paul Kyzivat wrote: > >>> > >>>> On 9/5/12 3:42 AM, Christer Holmberg wrote: > >>>>> Hi, > >>>>> > >>>>> Then, no matter whether people think a new value is really > required or not, would people object to defining a new value? > >>>>> > >>>>> This is really about making a choice and getting the work done :) > >>>> > >>>> Given all the discussion that has occurred about he pros and > cons, I am willing to accept either using "emergency" or using a new value. > >>>> > >>>> (If the decision is to go with a new value, I reserve the > right to argue about what it is called. You only get one chance to > get that right, and some values will be clearer than others. But at > the end of the day I will go along with whatever the consensus brings.) > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>> Regards, > >>>>> > >>>>> Christer > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > >>>>> Sent: 4. syyskuuta 2012 22:10 > >>>>> To: John-Luc Bakker > >>>>> Cc: Christer Holmberg; Martin Thomson; Paul Kyzivat; ecrit@ietf.org > >>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator > >>>>> > >>>>> I don't think that is the issue. > >>>>> > >>>>> Some folks believe the definition of "emergency" is wider > than "emergency call back" and thus a new value is needed to > differentiate. They would argue that we can't redefine "emergency" > to "emergency call back". I think the other side would say that > there are other fields in the INVITE would allow that > differentiation, such as the to/from. > >>>>> > >>>>> I continue to not care much, but observe that new values are cheap. > >>>>> > >>>>> Brian > >>>>> > >>>>> On Sep 4, 2012, at 2:47 PM, John-Luc Bakker wrote: > >>>>> > >>>>>> Christer, > >>>>>> > >>>>>> It seems below an argument is made for either very many > distinct Priority header field values, each invoking a policy that > both complies with the laws of the land and with their customer's > preferences (i.e., their own business needs), or just one Priority > header field value, identifying the policy in place for "emergency > call back". As I understand it, the requirements can be satisfied > by having just one Priority header field value. The single value we > have today that fits the bill is "emergency". > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> JL > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > >>>>>> Of Christer Holmberg > >>>>>> Sent: Monday, September 03, 2012 6:50 AM > >>>>>> To: Martin Thomson; Paul Kyzivat > >>>>>> Cc: ecrit@ietf.org > >>>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>>> A callback is a call that is marked with Priority: helphelp (or > >>>>>>> whatever) and the proxy makes some determination about call treatment > >>>>>>> based on information it has. This is likely caller identity == PSAP, > >>>>>>> but it doesn't matter...let the operator choose a policy > that both complies with the laws of the land and with their > customer's preferences (i.e., their own business needs). > >>>>>>> > >>>>>>> An emergency call is a call to urn:service:sos. That call > might be marked as Priority: omgmyfacemyface, but the primary > determinant for how the call is treated is the callee, which is *by > definition* a PSAP. > >>>>>>> > >>>>>>> Two cases, two sets of rules (one intentionally fuzzy, one > crystal clear). Done. > >>>>>> > >>>>>> Yes. > >>>>>> > >>>>>> So, the question is still: for callback, do we define a new > Priority value or not? > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Christer > >>>>>> _______________________________________________ > >>>>>> Ecrit mailing list > >>>>>> Ecrit@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>>>> > >>>>>> --------------------------------------------------------------------- > >>>>>> This transmission (including any attachments) may contain > confidential information, privileged material (including material > protected by the solicitor-client or other applicable privileges), > or constitute non-public information. Any use of this information > by anyone other than the intended recipient is prohibited. If you > have received this transmission in error, please immediately reply > to the sender and delete this information from your system. Use, > dissemination, distribution, or reproduction of this transmission > by unintended recipients is not authorized and may be unlawful. > >>>>>> _______________________________________________ > >>>>>> Ecrit mailing list > >>>>>> Ecrit@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ecrit > >>> > >>> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From christer.holmberg@ericsson.com Mon Sep 10 05:10:14 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B672421F867C for ; Mon, 10 Sep 2012 05:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOdECwmPWrlG for ; Mon, 10 Sep 2012 05:10:13 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3D93D21F8679 for ; Mon, 10 Sep 2012 05:10:13 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-97-504dd8a357e6 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 22.07.11467.3A8DD405; Mon, 10 Sep 2012 14:10:12 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Mon, 10 Sep 2012 14:10:12 +0200 From: Christer Holmberg To: James Polk , Martin Thomson , "Rosen, Brian" Date: Mon, 10 Sep 2012 14:10:10 +0200 Thread-Topic: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator Thread-Index: Ac2NQvw51HMC9W3TTwqrQCGNgZ+ihQCCgAWw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A53ADCB@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05853408683691@ESESSCMS0356.eemea.ericsson.se> <502E6573.80107@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA351DB027@XMB104ADS.rim.net> <44CDF7EF-01D3-49ED-AD32-C54EDFFE1880@neustar.biz> <5032AFAB.4080300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A6B@ESESSCMS0356.eemea.ericsson.se> <50339093.5080700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EC8@ESESSCMS0356.eemea.ericsson.se> <5033C164.20807@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A460738@ESESSCMS0356.eemea.ericsson.se> <155970D1DA8E174F9E46039E10E2AA351EA9B6@XMB104ADS.rim.net> <7B8820C0-5B37-4E8D-BC09-B45C778BE3D7@neustar.biz> <7F2072F1E0DE894DA4B517B93C6A0585340A4611B7@ESESSCMS0356.eemea.ericsson.se> <50476864.9040303@alum.mit.edu> <5047745F.2010706@alum.mit.edu> <985D9D15-DA49-4DE1-9839-C8A5B6934F83@neustar.biz> <201209072151.q87LphOf001560@mtv-core-4.cisco.com> In-Reply-To: <201209072151.q87LphOf001560@mtv-core-4.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvre6SG74BBg0zmCymnbzMbNG46Cmr xY41hRbXzvxjdGDxmPJ7I6vHzll32T2WLPnJ5LGj4TlzAEsUl01Kak5mWWqRvl0CV8aez8+Y Cr67VKxumsDWwHjJvIuRk0NCwETi//WnrBC2mMSFe+vZuhi5OIQETjFKtC6ZwArhLGCU2Nj5 nKWLkYODTcBCovufNkiDiECFxK67L5hBbGYBVYlzjY9ZQGwWIPvA5MmMILawgKvE/aVT2SHq 3SSePzzFAmEbSTRcXcQEYvMKhEssW9DPArFrLafE+aOHwZo5Bewl7q/cDFbECHTd91NrmCCW iUvcejKfCeJqAYkle84zQ9iiEi8f/2OFqBeVuNO+nhGiXkdiwe5PbBC2tsSyha+ZIRYLSpyc +YRlAqPYLCRjZyFpmYWkZRaSlgWMLKsYhXMTM3PSyw31Uosyk4uL8/P0ilM3MQJj7OCW37o7 GE+dEznEKM3BoiTOy5W0319IID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY5ZTi1qDrc20iQvt fbdO7uCL0KjzPhUe2elh6LE1cuVXGfviy0sFZ0a3tyl7TFj34MGELSaJlg/fZQe7nv6sufbG vS2tjz7cOF/W7WDRx6j1icvn8M2U3lI28WtzXk6SZN0WPl/P0uhGfaHr46bXwUwz9Rcrl3Tu 39q04L9XWsSinFXbPzzapsRSnJFoqMVcVJwIAJzQc0l/AgAA Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 12:10:14 -0000 Hi, >>psap-callback ? > > this value is as concrete as any I've read or heard or suggested myself. = It states exactly what's happening and cannot be misinterpreted - which is = a very good thing. > > I'll bow to Paul's investigation into what about this needs to be done wr= t SIPCORE, given that there is no TOKEN defined for extensibility in this h= eader (which would have made this rather easy). Yes, there is :) Priority =3D "Priority" HCOLON priority-value priority-value =3D "emergency" / "urgent" / "normal" / "non-urgent" / other-priority other-priority =3D token Regards, Christer >On 5 September 2012 10:28, Rosen, Brian wrote: > > I don't think we are trying to create a marking for an arbitrary > call placed from a PSAP to someone in another network. The marking is=20 > specifically for call backs, and not other purposes. > > > > I think that it IS acceptable to refuse such calls if there was > no call out. For example, if the call is to some sort of Contact=20 > address which, due to some local requirements, was formatted in some=20 > way specifically known to the local system, it might refuse the call=20 > to the device if there was no preceding emergency call. A call to a=20 > normal AoR may not be refused, but may not get any special treatment=20 > if the marking has no way of being authenticated. All of that is up=20 > to the local system and any intermediaries. I think Christer, and=20 > most of us discussing this, only intend it to be used for a call back. > > > > I think there is no need to generalize, and emergency-callback is > just fine. > > > > Brian > > > > On Sep 5, 2012, at 11:48 AM, Paul Kyzivat wrote= : > > > >> On 9/5/12 11:13 AM, Rosen, Brian wrote: > >>> How about "emergencyCallBack"? > >> > >> Hardly anything in sip uses mixed case this way. So from that > perspective I would counter with "emergency-callback". > >> > >> But a more significant issue is what semantics this is intended > to convey. In particular, is a call with this attribute of necessity a=20 > *callback*? Is anything in the call path justified in refusing the=20 > request if there was no preceding call for which this is a callback? > >> > >> E.g. if psap received an emergency call from phone-1, and it is > necessary to reconnect to a different phone, or perhaps even a=20 > different person, in order to continue handling the emergency, then it=20 > may be hard to describe that as a "callback". Yet the PSAP may want to=20 > do it, and I suppose the mechanism should allow it. If so, then=20 > "emergency-callback" has the wrong connotation. This is really why I=20 > find "emergency" to be appropriate. If we must have a new term, how=20 > about: "expedited-emergency", "urgent-emergency",=20 > "emergency-override"? > >> > >> Thanks, > >> Paul > >> > >>> On Sep 5, 2012, at 10:57 AM, Paul Kyzivat wro= te: > >>> > >>>> On 9/5/12 3:42 AM, Christer Holmberg wrote: > >>>>> Hi, > >>>>> > >>>>> Then, no matter whether people think a new value is really > required or not, would people object to defining a new value? > >>>>> > >>>>> This is really about making a choice and getting the work done=20 > >>>>> :) > >>>> > >>>> Given all the discussion that has occurred about he pros and > cons, I am willing to accept either using "emergency" or using a new valu= e. > >>>> > >>>> (If the decision is to go with a new value, I reserve the > right to argue about what it is called. You only get one chance to get=20 > that right, and some values will be clearer than others. But at the=20 > end of the day I will go along with whatever the consensus brings.) > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>> Regards, > >>>>> > >>>>> Christer > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > >>>>> Sent: 4. syyskuuta 2012 22:10 > >>>>> To: John-Luc Bakker > >>>>> Cc: Christer Holmberg; Martin Thomson; Paul Kyzivat;=20 > >>>>> ecrit@ietf.org > >>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback=20 > >>>>> Indicator > >>>>> > >>>>> I don't think that is the issue. > >>>>> > >>>>> Some folks believe the definition of "emergency" is wider > than "emergency call back" and thus a new value is needed to=20 > differentiate. They would argue that we can't redefine "emergency" > to "emergency call back". I think the other side would say that there=20 > are other fields in the INVITE would allow that differentiation, such=20 > as the to/from. > >>>>> > >>>>> I continue to not care much, but observe that new values are cheap. > >>>>> > >>>>> Brian > >>>>> > >>>>> On Sep 4, 2012, at 2:47 PM, John-Luc Bakker wrote= : > >>>>> > >>>>>> Christer, > >>>>>> > >>>>>> It seems below an argument is made for either very many > distinct Priority header field values, each invoking a policy that=20 > both complies with the laws of the land and with their customer's=20 > preferences (i.e., their own business needs), or just one Priority=20 > header field value, identifying the policy in place for "emergency=20 > call back". As I understand it, the requirements can be satisfied by=20 > having just one Priority header field value. The single value we have=20 > today that fits the bill is "emergency". > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> JL > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > >>>>>> Behalf Of Christer Holmberg > >>>>>> Sent: Monday, September 03, 2012 6:50 AM > >>>>>> To: Martin Thomson; Paul Kyzivat > >>>>>> Cc: ecrit@ietf.org > >>>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback=20 > >>>>>> Indicator > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>>> A callback is a call that is marked with Priority: helphelp=20 > >>>>>>> (or > >>>>>>> whatever) and the proxy makes some determination about call=20 > >>>>>>> treatment based on information it has. This is likely caller=20 > >>>>>>> identity =3D=3D PSAP, but it doesn't matter...let the operator=20 > >>>>>>> choose a policy > that both complies with the laws of the land and with their customer's=20 > preferences (i.e., their own business needs). > >>>>>>> > >>>>>>> An emergency call is a call to urn:service:sos. That call > might be marked as Priority: omgmyfacemyface, but the primary=20 > determinant for how the call is treated is the callee, which is *by > definition* a PSAP. > >>>>>>> > >>>>>>> Two cases, two sets of rules (one intentionally fuzzy, one > crystal clear). Done. > >>>>>> > >>>>>> Yes. > >>>>>> > >>>>>> So, the question is still: for callback, do we define a new > Priority value or not? > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Christer > >>>>>> _______________________________________________ > >>>>>> Ecrit mailing list > >>>>>> Ecrit@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>>>> > >>>>>> --------------------------------------------------------------- > >>>>>> ------ This transmission (including any attachments) may=20 > >>>>>> contain > confidential information, privileged material (including material=20 > protected by the solicitor-client or other applicable privileges), or=20 > constitute non-public information. Any use of this information by=20 > anyone other than the intended recipient is prohibited. If you have=20 > received this transmission in error, please immediately reply to the=20 > sender and delete this information from your system. Use,=20 > dissemination, distribution, or reproduction of this transmission by=20 > unintended recipients is not authorized and may be unlawful. > >>>>>> _______________________________________________ > >>>>>> Ecrit mailing list > >>>>>> Ecrit@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ecrit > >>> > >>> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From internet-drafts@ietf.org Wed Sep 12 05:29:22 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D079E21F8607; Wed, 12 Sep 2012 05:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOby00wMGt8E; Wed, 12 Sep 2012 05:29:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E2421F84E7; Wed, 12 Sep 2012 05:29:22 -0700 (PDT) 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.34 Message-ID: <20120912122922.21507.59752.idtracker@ietfa.amsl.com> Date: Wed, 12 Sep 2012 05:29:22 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-psap-callback-05.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 12:29:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Public Safety Answering Point (PSAP) Callback Author(s) : Henning Schulzrinne Hannes Tschofenig Christer Holmberg Milan Patel Filename : draft-ietf-ecrit-psap-callback-05.txt Pages : 23 Date : 2012-09-12 Abstract: After an emergency call is completed (either prematurely terminated by the emergency caller or normally by the call taker) it is possible that the call taker feels the need for further communication. For example, the call may have been dropped by accident without the call taker having sufficient information about the current situation of a wounded person. A call taker may trigger a callback towards the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, be treated like any other call and as a consequence it may get blocked by authorization policies or may get forwarded to an answering machine. The IETF emergency services architecture specification already offers a solution approach for allowing PSAP callbacks to bypass authorization policies to reach the caller without unnecessary delays. Unfortunately, the specified mechanism only supports limited scenarios. This document discusses shortcomings of the current mechanisms and illustrates additional scenarios where better-than- normal call treatment behavior would be desirable. Note that this version of the document does not yet specify a solution due to the lack of the working group participants agreeing on the requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-psap-callback-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From christer.holmberg@ericsson.com Wed Sep 12 05:31:43 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D220B21F85F3 for ; Wed, 12 Sep 2012 05:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQLWgqTu3iO4 for ; Wed, 12 Sep 2012 05:31:43 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8752921F859C for ; Wed, 12 Sep 2012 05:31:35 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-5f-505080a6034a Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 55.94.25676.6A080505; Wed, 12 Sep 2012 14:31:34 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 12 Sep 2012 14:31:34 +0200 From: Christer Holmberg To: "ecrit@ietf.org" Date: Wed, 12 Sep 2012 14:31:33 +0200 Thread-Topic: Draft new version: draft-ietf-ecrit-psap-callback-05 Thread-Index: Ac2Q4k3twv3zBStIRxS14FZjl7tqeA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585340A53BB93ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvre6yhoAAg3WndSwaFz1ldWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxo8Fi9gLfkhUdHy8y97AOEWsi5GTQ0LARKL5+CRmCFtM4sK9 9WxdjFwcQgKnGCXab11ih3AWMEo8uNLC1MXIwcEmYCHR/U8bpEFEQFViw5mVjCA2C5A9a3Yz C0iJsICtxPWJJRAlThIHF/QzQ9h6EntnPmcBsXkFwiXeH+0AizMC7f1+ag0TiM0sIC5x68l8 Joh7BCSW7DkPdZuoxMvH/1gh6kUl7rSvZ4Soz5e4cvgaK8RMQYmTM5+wTGAUmoVk1CwkZbOQ lEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjMK5iZk56eVGeqlFmcnFxfl5esWpmxiB 0XBwy2/VHYx3zokcYpTmYFES57XeusdfSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2NBq/Mm Fp7T8XfKU+Ku/5YTyr6/egObV6Dyq8iM/tsBu3nrlp6YtS9r1d5vt5tPhqmnbpA2qpBfFHEw 9l84e/Sf/dxrLm3XMTji6y6ZEbCgeoKi0le3jkJ/+/4rh14ziTbynrk047TOrXcnJ+dqBhhe VEyenjFjBceNi496WVh6D6/bb67dKqzEUpyRaKjFXFScCADT2Y26VAIAAA== Subject: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 12:31:44 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585340A53BB93ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version of the psap-callback draft, due to expiration = of the previous version. There are NO changes compared to the previous version. Once I get some guidance on where to define the new SIP Priority header fie= ld "psap-callback" value, I will either update this draft or submit a separ= ate one in SIPCORE. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585340A53BB93ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi,

 

I’ve submitted a new version of t= he psap-callback draft, due to expiration of the previous version.

 

There = are NO changes compared to the previous version.

 

Once I get some guidance= on where to define the new SIP Priority header field “psap-callback&= #8221; value, I will either update this draft or submit a separate one in S= IPCORE.

 

Regards,

 

=

Christer

= --_000_7F2072F1E0DE894DA4B517B93C6A0585340A53BB93ESESSCMS0356e_-- From jmpolk@cisco.com Wed Sep 12 14:01:47 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FB421F8620 for ; Wed, 12 Sep 2012 14:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfCeyDLDKmTm for ; Wed, 12 Sep 2012 14:01:46 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 95B6A21F861E for ; Wed, 12 Sep 2012 14:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9170; q=dns/txt; s=iport; t=1347483706; x=1348693306; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=KuqY66B/3Q2tOfK6tDo4Ae9JXGArLi/Jtqwx/IPdHfA=; b=hih2k6FrAMeDN5WskE+mTws/gyXFsj2MmUAJm87ZQVhMdeOwZIf1GAWa qFlkkWy+pDNhoxILYFLQyT6mY5Ck4UqczLyQnVMcpWho6Ryn7ku/q37pv jERB3QszVku3qrb9FQsK4/Y5d1IfQBH4C5IN+nYPYqLfVnPGixppT9gOr o=; X-IronPort-AV: E=Sophos;i="4.80,413,1344211200"; d="scan'208";a="57986661" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 12 Sep 2012 21:01:46 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8CL1jqa027502; Wed, 12 Sep 2012 21:01:46 GMT Message-Id: <201209122101.q8CL1jqa027502@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 12 Sep 2012 16:01:44 -0500 To: Christer Holmberg , James Polk , Martin Thomson , "Rosen, Brian" From: James Polk In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A53ADCB@ESESSCMS0356.ee mea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05853408683691@ESESSCMS0356.eemea.ericsson.se> <502E6573.80107@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA351DB027@XMB104ADS.rim.net> <44CDF7EF-01D3-49ED-AD32-C54EDFFE1880@neustar.biz> <5032AFAB.4080300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A6B@ESESSCMS0356.eemea.ericsson.se> <50339093.5080700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2EC8@ESESSCMS0356.eemea.ericsson.se> <5033C164.20807@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A460738@ESESSCMS0356.eemea.ericsson.se> <155970D1DA8E174F9E46039E10E2AA351EA9B6@XMB104ADS.rim.net> <7B8820C0-5B37-4E8D-BC09-B45C778BE3D7@neustar.biz> <7F2072F1E0DE894DA4B517B93C6A0585340A4611B7@ESESSCMS0356.eemea.ericsson.se> <50476864.9040303@alum.mit.edu> <5047745F.2010706@alum.mit.edu> <985D9D15-DA49-4DE1-9839-C8A5B6934F83@neustar.biz> <201209072151.q87LphOf001560@mtv-core-4.cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585340A53ADCB@ESESSCMS0356.eemea.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback Indicator X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 21:01:47 -0000 At 07:10 AM 9/10/2012, Christer Holmberg wrote: >Hi, > > >>psap-callback ? > > > > this value is as concrete as any I've read or heard or suggested > myself. It states exactly what's happening and cannot be > misinterpreted - which is a very good thing. > > > > I'll bow to Paul's investigation into what about this needs to be > done wrt SIPCORE, given that there is no TOKEN defined for > extensibility in this header (which would have made this rather easy). > >Yes, there is :) > >Priority = "Priority" HCOLON priority-value >priority-value = "emergency" / "urgent" / "normal" > / "non-urgent" / other-priority >other-priority = token oops... nevermind >Regards, > >Christer > > > > >On 5 September 2012 10:28, Rosen, Brian wrote: > > > I don't think we are trying to create a marking for an arbitrary > > call placed from a PSAP to someone in another network. The marking is > > specifically for call backs, and not other purposes. > > > > > > I think that it IS acceptable to refuse such calls if there was > > no call out. For example, if the call is to some sort of Contact > > address which, due to some local requirements, was formatted in some > > way specifically known to the local system, it might refuse the call > > to the device if there was no preceding emergency call. A call to a > > normal AoR may not be refused, but may not get any special treatment > > if the marking has no way of being authenticated. All of that is up > > to the local system and any intermediaries. I think Christer, and > > most of us discussing this, only intend it to be used for a call back. > > > > > > I think there is no need to generalize, and emergency-callback is > > just fine. > > > > > > Brian > > > > > > On Sep 5, 2012, at 11:48 AM, Paul Kyzivat wrote: > > > > > >> On 9/5/12 11:13 AM, Rosen, Brian wrote: > > >>> How about "emergencyCallBack"? > > >> > > >> Hardly anything in sip uses mixed case this way. So from that > > perspective I would counter with "emergency-callback". > > >> > > >> But a more significant issue is what semantics this is intended > > to convey. In particular, is a call with this attribute of necessity a > > *callback*? Is anything in the call path justified in refusing the > > request if there was no preceding call for which this is a callback? > > >> > > >> E.g. if psap received an emergency call from phone-1, and it is > > necessary to reconnect to a different phone, or perhaps even a > > different person, in order to continue handling the emergency, then it > > may be hard to describe that as a "callback". Yet the PSAP may want to > > do it, and I suppose the mechanism should allow it. If so, then > > "emergency-callback" has the wrong connotation. This is really why I > > find "emergency" to be appropriate. If we must have a new term, how > > about: "expedited-emergency", "urgent-emergency", > > "emergency-override"? > > >> > > >> Thanks, > > >> Paul > > >> > > >>> On Sep 5, 2012, at 10:57 AM, Paul Kyzivat > wrote: > > >>> > > >>>> On 9/5/12 3:42 AM, Christer Holmberg wrote: > > >>>>> Hi, > > >>>>> > > >>>>> Then, no matter whether people think a new value is really > > required or not, would people object to defining a new value? > > >>>>> > > >>>>> This is really about making a choice and getting the work done > > >>>>> :) > > >>>> > > >>>> Given all the discussion that has occurred about he pros and > > cons, I am willing to accept either using "emergency" or using a new value. > > >>>> > > >>>> (If the decision is to go with a new value, I reserve the > > right to argue about what it is called. You only get one chance to get > > that right, and some values will be clearer than others. But at the > > end of the day I will go along with whatever the consensus brings.) > > >>>> > > >>>> Thanks, > > >>>> Paul > > >>>> > > >>>>> Regards, > > >>>>> > > >>>>> Christer > > >>>>> > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > >>>>> Sent: 4. syyskuuta 2012 22:10 > > >>>>> To: John-Luc Bakker > > >>>>> Cc: Christer Holmberg; Martin Thomson; Paul Kyzivat; > > >>>>> ecrit@ietf.org > > >>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback > > >>>>> Indicator > > >>>>> > > >>>>> I don't think that is the issue. > > >>>>> > > >>>>> Some folks believe the definition of "emergency" is wider > > than "emergency call back" and thus a new value is needed to > > differentiate. They would argue that we can't redefine "emergency" > > to "emergency call back". I think the other side would say that there > > are other fields in the INVITE would allow that differentiation, such > > as the to/from. > > >>>>> > > >>>>> I continue to not care much, but observe that new values are cheap. > > >>>>> > > >>>>> Brian > > >>>>> > > >>>>> On Sep 4, 2012, at 2:47 PM, John-Luc Bakker wrote: > > >>>>> > > >>>>>> Christer, > > >>>>>> > > >>>>>> It seems below an argument is made for either very many > > distinct Priority header field values, each invoking a policy that > > both complies with the laws of the land and with their customer's > > preferences (i.e., their own business needs), or just one Priority > > header field value, identifying the policy in place for "emergency > > call back". As I understand it, the requirements can be satisfied by > > having just one Priority header field value. The single value we have > > today that fits the bill is "emergency". > > >>>>>> > > >>>>>> Regards, > > >>>>>> > > >>>>>> JL > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > >>>>>> Behalf Of Christer Holmberg > > >>>>>> Sent: Monday, September 03, 2012 6:50 AM > > >>>>>> To: Martin Thomson; Paul Kyzivat > > >>>>>> Cc: ecrit@ietf.org > > >>>>>> Subject: Re: [Ecrit] ecrit-psap-callback-04 - PSAP Callback > > >>>>>> Indicator > > >>>>>> > > >>>>>> Hi, > > >>>>>> > > >>>>>>> A callback is a call that is marked with Priority: helphelp > > >>>>>>> (or > > >>>>>>> whatever) and the proxy makes some determination about call > > >>>>>>> treatment based on information it has. This is likely caller > > >>>>>>> identity == PSAP, but it doesn't matter...let the operator > > >>>>>>> choose a policy > > that both complies with the laws of the land and with their customer's > > preferences (i.e., their own business needs). > > >>>>>>> > > >>>>>>> An emergency call is a call to urn:service:sos. That call > > might be marked as Priority: omgmyfacemyface, but the primary > > determinant for how the call is treated is the callee, which is *by > > definition* a PSAP. > > >>>>>>> > > >>>>>>> Two cases, two sets of rules (one intentionally fuzzy, one > > crystal clear). Done. > > >>>>>> > > >>>>>> Yes. > > >>>>>> > > >>>>>> So, the question is still: for callback, do we define a new > > Priority value or not? > > >>>>>> > > >>>>>> Regards, > > >>>>>> > > >>>>>> Christer > > >>>>>> _______________________________________________ > > >>>>>> Ecrit mailing list > > >>>>>> Ecrit@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/ecrit > > >>>>>> > > >>>>>> --------------------------------------------------------------- > > >>>>>> ------ This transmission (including any attachments) may > > >>>>>> contain > > confidential information, privileged material (including material > > protected by the solicitor-client or other applicable privileges), or > > constitute non-public information. Any use of this information by > > anyone other than the intended recipient is prohibited. If you have > > received this transmission in error, please immediately reply to the > > sender and delete this information from your system. Use, > > dissemination, distribution, or reproduction of this transmission by > > unintended recipients is not authorized and may be unlawful. > > >>>>>> _______________________________________________ > > >>>>>> Ecrit mailing list > > >>>>>> Ecrit@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/ecrit > > >>>>> > > >>>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Ecrit mailing list > > >>>> Ecrit@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/ecrit > > >>> > > >>> > > >> > > >> _______________________________________________ > > >> Ecrit mailing list > > >> Ecrit@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ecrit > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From internet-drafts@ietf.org Fri Sep 14 02:21:23 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A4C21F85ED; Fri, 14 Sep 2012 02:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPsqULtYy6GY; Fri, 14 Sep 2012 02:21:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FC221F84F8; Fri, 14 Sep 2012 02:21:22 -0700 (PDT) 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.34 Message-ID: <20120914092122.25885.58958.idtracker@ietfa.amsl.com> Date: Fri, 14 Sep 2012 02:21:22 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-unauthenticated-access-05.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 09:21:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Extensions to the Emergency Services Architecture for de= aling with Unauthenticated and Unauthorized Devices Author(s) : Henning Schulzrinne Stephen McCann Gabor Bajko Hannes Tschofenig Dirk Kroeselberg Filename : draft-ietf-ecrit-unauthenticated-access-05.txt Pages : 26 Date : 2012-09-14 Abstract: The IETF emergency services architecture assumes that the calling device has acquired rights to use the access network or that no authentication is required for the access network, such as for public wireless access points. Subsequent protocol interactions, such as obtaining location information, learning the address of the Public Safety Answering Point (PSAP) and the emergency call itself are largely decoupled from the underlying network access procedures. In some cases, however, the device does not have these credentials for network access, does not have a VoIP service provider, or the credentials have become invalid, e.g., because the user has exhausted their prepaid balance or the account has expired. This document provides a problem statement, introduces terminology and describes an extension for the base IETF emergency services architecture to address these scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-unauthenticated-access-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-unauthenticated-access-= 05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From RMarshall@telecomsys.com Fri Sep 14 14:37:32 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36DFB21F84AF for ; Fri, 14 Sep 2012 14:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtiXIXAoP4Kj for ; Fri, 14 Sep 2012 14:37:30 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) by ietfa.amsl.com (Postfix) with ESMTP id 733ED21F8413 for ; Fri, 14 Sep 2012 14:37:29 -0700 (PDT) Received: from SEA-EXCAS-2.telecomsys.com (exc2010-local2.telecomsys.com [10.32.12.187]) by sea-mx-02.telecomsys.com (8.14.1/8.14.1) with ESMTP id q8ELbI7Z014321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 14 Sep 2012 14:37:19 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.8]) by SEA-EXCAS-2.telecomsys.com ([10.32.12.187]) with mapi id 14.01.0355.002; Fri, 14 Sep 2012 14:37:18 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value Thread-Index: AQHNksEdQ4PbjIc55kSNsSELX8EDTQ== Date: Fri, 14 Sep 2012 21:37:19 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC1281F9SEAEXMB2telecomsy_" MIME-Version: 1.0 Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 21:37:32 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC1281F9SEAEXMB2telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All: We need to select a priority-value in order to move the ecrit-psap-callback= draft forward. Putting aside, for the moment, the questions of if/how/where the priority-v= alue token is defined (if a new value is required - e.g., whether RFC or Re= gistry), we should be able to agree on the value itself. We've seen some suggestions for a priority-value given on the list over the= last few weeks with no clear convergence. The value "emergency" is already= included in the RFC3261 definition, but some others have voiced a preferen= ce to define a new priority-value, using other-priority =3D token. Priority =3D "Priority" HCOLON priority-value priority-value =3D "emergency" / "urgent" / "normal" / "non-urgent" / other-priority other-priority =3D token We've seen a few mentioned on the list, now the chairs are calling to close= the list of candidate values, and request the work group to vote their cho= ice. Of the priority-values put out there on the list, we have the following men= tioned a few times: - emergency - emergency-callback - psap-callback Also mentioned once were: - expedited-emergency - urgent-emergency - emergency-override If I've forgotten one, please let me know. Send your vote to the ecrit list. The voting will go through 18:00 (Pacifi= c), next Friday, 9/21/2012. -roger. From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of C= hrister Holmberg Sent: Wednesday, September 12, 2012 5:32 AM To: ecrit@ietf.org Subject: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 Hi, I've submitted a new version of the psap-callback draft, due to expiration = of the previous version. There are NO changes compared to the previous version. Once I get some guidance on where to define the new SIP Priority header fie= ld "psap-callback" value, I will either update this draft or submit a separ= ate one in SIPCORE. Regards, Christer CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC1281F9SEAEXMB2telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All:=

We need to select a pr= iority-value in order to move the ecrit-psap-callback draft forward.

 

Putting aside, for the= moment, the questions of if/how/where the priority-value token is defined = (if a new value is required - e.g., whether RFC or Registry), we should be = able to agree on the value itself.

 

We’ve seen some = suggestions for a priority-value given on the list over the last few weeks = with no clear convergence. The value “emergency” is already inc= luded in the RFC3261 definition, but some others have voiced a preference to define a new priority-value, using other-priority = =3D token.

 

Priority       &nbs= p;   =3D  "Priority" HCOLON priority-value

priority-value    =3D  "emerg= ency" / "urgent" / "normal"

        &= nbsp;            &nb= sp;  / "non-urgent" / other-priority

other-priority    =3D  token<= /o:p>

 

We’ve seen a few= mentioned on the list, now the chairs are calling to close the list of can= didate values, and request the work group to vote their choice.<= /span>

 

Of the priority-values= put out there on the list, we have the following mentioned a few times:

- emergency=

- emergency-callback

- psap-callback

 

Also mentioned once we= re:

- expedited-eme= rgency

- urgent-emergency

- emergency-override

 

If I’ve forgotte= n one, please let me know.

 

Send your vote to the = ecrit list.  The voting will go through 18:00 (Pacific), next Friday, = 9/21/2012. 

 

-roger.

 

 

From: ecrit-bo= unces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Wednesday, September 12, 2012 5:32 AM
To: ecrit@ietf.org
Subject: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-0= 5

 

Hi,

 

I’ve submitted a new version of the psap-callb= ack draft, due to expiration of the previous version.

 

There are NO changes compared to the previous versio= n.

 

Once I get some guidance on where to define the new = SIP Priority header field “psap-callback” value, I will either = update this draft or submit a separate one in SIPCORE.

 

Regards,

 

Christer

CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC1281F9SEAEXMB2telecomsy_-- From pkyzivat@alum.mit.edu Fri Sep 14 15:05:14 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B9321F851C for ; Fri, 14 Sep 2012 15:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.403 X-Spam-Level: X-Spam-Status: No, score=-0.403 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xChGvabvdy8l for ; Fri, 14 Sep 2012 15:05:13 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 9228D21F84FD for ; Fri, 14 Sep 2012 15:05:13 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta15.westchester.pa.mail.comcast.net with comcast id z1351j0050mv7h05FA5bcs; Fri, 14 Sep 2012 22:05:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id zA571j0043ZTu2S3XA57NE; Fri, 14 Sep 2012 22:05:07 +0000 Message-ID: <5053AA17.5010807@alum.mit.edu> Date: Fri, 14 Sep 2012 18:05:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: ecrit@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 22:05:14 -0000 +1 for "emergency". On 9/14/12 5:37 PM, Roger Marshall wrote: > All: > > We need to select a priority-value in order to move the > ecrit-psap-callback draft forward. > > Putting aside, for the moment, the questions of if/how/where the > priority-value token is defined (if a new value is required - e.g., > whether RFC or Registry), we should be able to agree on the value itself. > > We’ve seen some suggestions for a priority-value given on the list over > the last few weeks with no clear convergence. The value “emergency” is > already included in the RFC3261 definition, but some others have voiced > a preference to define a new priority-value, using other-priority = token. > > Priority = "Priority" HCOLON priority-value > > priority-value = "emergency" / "urgent" / "normal" > > / "non-urgent" / other-priority > > other-priority = token > > We’ve seen a few mentioned on the list, now the chairs are calling to > close the list of candidate values, and request the work group to vote > their choice. > > Of the priority-values put out there on the list, we have the following > mentioned a few times: > > - emergency > > - emergency-callback > > - psap-callback > > Also mentioned once were: > > - expedited-emergency > > - urgent-emergency > > - emergency-override > > If I’ve forgotten one, please let me know. > > Send your vote to the ecrit list. The voting will go through 18:00 > (Pacific), next Friday, 9/21/2012. > > -roger. > > *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf > Of *Christer Holmberg > *Sent:* Wednesday, September 12, 2012 5:32 AM > *To:* ecrit@ietf.org > *Subject:* [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 > > Hi, > > I’ve submitted a new version of the psap-callback draft, due to > expiration of the previous version. > > There are NO changes compared to the previous version. > > Once I get some guidance on where to define the new SIP Priority header > field “psap-callback” value, I will either update this draft or submit a > separate one in SIPCORE. > > Regards, > > Christer > > CONFIDENTIALITY NOTICE: The information contained in this message may be > privileged and/or confidential. If you are not the intended recipient, > or responsible for delivering this message to the intended recipient, > any review, forwarding, dissemination, distribution or copying of this > communication or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender immediately, > and delete it and all attachments from your computer and network. > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From prvs=660496b084=jbakker@rim.com Fri Sep 14 15:12:37 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A587C21F846E for ; Fri, 14 Sep 2012 15:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.25 X-Spam-Level: X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sMRZB7U4WjC for ; Fri, 14 Sep 2012 15:12:37 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id CA55621F846B for ; Fri, 14 Sep 2012 15:12:36 -0700 (PDT) X-AuditID: 0a41282f-b7f196d0000008dc-36-5053abd35b2a Received: from XCT102ADS.rim.net (xct102ads.rim.net [10.67.111.43]) by mhs060cnc.rim.net (SBG) with SMTP id 50.B8.02268.3DBA3505; Fri, 14 Sep 2012 17:12:35 -0500 (CDT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.02.0298.004; Fri, 14 Sep 2012 17:12:34 -0500 From: John-Luc Bakker To: "pkyzivat@alum.mit.edu" , "ecrit@ietf.org" Thread-Topic: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value Thread-Index: AQHNksEoJJIID7oABUuXgs6IAZfhaZeKuFSA//+uPi0= Date: Fri, 14 Sep 2012 22:12:34 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA351FAC39@XMB104ADS.rim.net> In-Reply-To: <5053AA17.5010807@alum.mit.edu> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.253] Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsXC5ZyvrXt5dXCAwaf92haNi56yWqzYcIDV gcnj7/sPTB5LlvxkCmCKamC0SUosKQvOTM/Tt7NJzMvLL0ksSVVISS1OtlXySU1PzFEIKMos S0yuVHDJLE7OSczMTS1SUshMsVUyUVIoyElMTs1NzSuxVUosKEjNS1Gy41LAADZAZZl5Cql5 yfkpmXnptkqewf66FhamlrqGSna6CZ08GT3db5gKNqhWvJs6n62BcYtKFyMHh4SAicTbY5ld jJxAppjEhXvr2UBsIYGVjBL7ZgV3MXIB2ZsZJe7d/scEkmATUJfYumI7M4gtIhAhMW3nBkaQ OcICyRLP54VAhFMkvr29wgphW0nsbXvPAmKzCKhKTOj+wQ5i8wq4SVzd3wlWwymgIzH57EVG EJtRQFZi99nrYKuYBcQlbj2ZzwRxm4DEkj3nmSFsUYmXj/+xQtiKEn/3fmcFOYFZQFNi/S59 iFZFiSndD6FWCUqcnPmEZQKjyCwkU2chdMxC0jELSccCRpZVjIK5GcUGZgbJecl6RZm5enmp JZsYQfHuqKG/g/Hte4tDjAIcjEo8vJHANCDEmlhWXJl7iFGCg1lJhNdWOyhAiDclsbIqtSg/ vqg0J7X4EKMFMBwmMktxJ+cDU1FeSbyxgQEKR0mct/mDZ4CQQDowhWSnphakFsG0MnFwgozm khIpBiaC1KLE0pKMeFC6ii8GJiypBsYNdf3r708OsFyfzL5lchD/j+xvV/0Uo9b+Olx4/x9T ssL/ST+Yiv+6Nwh94vp6Z+2mOZuniHeeeP/q1qucKRbyBhGOlxcoVE4PKrHZYih2SyH64hOl FeUeGdwP89Yc5/1ybe/KiVp+64W27EiS6HWQlD3m4zmLoV/qz6cdZt8ZNqq+UEjY+qtFiaU4 I9FQi7moOBEAUmH6uSsDAAA= Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 22:12:37 -0000 KzEgZm9yICJlbWVyZ2VuY3kiLg0KLS0tIA0KSm9obi1MdWMgQmFra2VyDQpTdGFuZGFyZHMg TWFuYWdlcg0KUmVzZWFyY2ggSW4gTW90aW9uIENvcnBvcmF0aW9uIA0KTW9iaWxlICsxICg5 MDgpIDQ2MyA3MzIxDQpPZmZpY2UgKzEgKDk3MikgMzczLTE3NjENCkludGVybmFsICg4MjAp IDYzNzYxDQpFLW1haWwgamJha2tlckByaW0uY29tDQoNClNlbnQgZnJvbSBteSBCbGFja0Jl cnJ5IEJvbGQgKDk5MDApDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206 IFBhdWwgS3l6aXZhdCBbbWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdV0NClNlbnQ6IEZy aWRheSwgU2VwdGVtYmVyIDE0LCAyMDEyIDA1OjA1IFBNClRvOiBlY3JpdEBpZXRmLm9yZyA8 ZWNyaXRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0Vjcml0XSBEcmFmdCBuZXcgdmVyc2lv bjogZHJhZnQtaWV0Zi1lY3JpdC1wc2FwLWNhbGxiYWNrLTA1IC0gc2VsZWN0IHByaW9yaXR5 LXZhbHVlDQoNCisxIGZvciAiZW1lcmdlbmN5Ii4NCg0KT24gOS8xNC8xMiA1OjM3IFBNLCBS b2dlciBNYXJzaGFsbCB3cm90ZToNCj4gQWxsOg0KPg0KPiBXZSBuZWVkIHRvIHNlbGVjdCBh IHByaW9yaXR5LXZhbHVlIGluIG9yZGVyIHRvIG1vdmUgdGhlDQo+IGVjcml0LXBzYXAtY2Fs bGJhY2sgZHJhZnQgZm9yd2FyZC4NCj4NCj4gUHV0dGluZyBhc2lkZSwgZm9yIHRoZSBtb21l bnQsIHRoZSBxdWVzdGlvbnMgb2YgaWYvaG93L3doZXJlIHRoZQ0KPiBwcmlvcml0eS12YWx1 ZSB0b2tlbiBpcyBkZWZpbmVkIChpZiBhIG5ldyB2YWx1ZSBpcyByZXF1aXJlZCAtIGUuZy4s DQo+IHdoZXRoZXIgUkZDIG9yIFJlZ2lzdHJ5KSwgd2Ugc2hvdWxkIGJlIGFibGUgdG8gYWdy ZWUgb24gdGhlIHZhbHVlIGl0c2VsZi4NCj4NCj4gV2XigJl2ZSBzZWVuIHNvbWUgc3VnZ2Vz dGlvbnMgZm9yIGEgcHJpb3JpdHktdmFsdWUgZ2l2ZW4gb24gdGhlIGxpc3Qgb3Zlcg0KPiB0 aGUgbGFzdCBmZXcgd2Vla3Mgd2l0aCBubyBjbGVhciBjb252ZXJnZW5jZS4gVGhlIHZhbHVl IOKAnGVtZXJnZW5jeeKAnSBpcw0KPiBhbHJlYWR5IGluY2x1ZGVkIGluIHRoZSBSRkMzMjYx IGRlZmluaXRpb24sIGJ1dCBzb21lIG90aGVycyBoYXZlIHZvaWNlZA0KPiBhIHByZWZlcmVu Y2UgdG8gZGVmaW5lIGEgbmV3IHByaW9yaXR5LXZhbHVlLCB1c2luZyBvdGhlci1wcmlvcml0 eSA9IHRva2VuLg0KPg0KPiBQcmlvcml0eSAgICAgICAgICAgPSAgIlByaW9yaXR5IiBIQ09M T04gcHJpb3JpdHktdmFsdWUNCj4NCj4gcHJpb3JpdHktdmFsdWUgICAgPSAgImVtZXJnZW5j eSIgLyAidXJnZW50IiAvICJub3JtYWwiDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAg ICAvICJub24tdXJnZW50IiAvIG90aGVyLXByaW9yaXR5DQo+DQo+IG90aGVyLXByaW9yaXR5 ICAgID0gIHRva2VuDQo+DQo+IFdl4oCZdmUgc2VlbiBhIGZldyBtZW50aW9uZWQgb24gdGhl IGxpc3QsIG5vdyB0aGUgY2hhaXJzIGFyZSBjYWxsaW5nIHRvDQo+IGNsb3NlIHRoZSBsaXN0 IG9mIGNhbmRpZGF0ZSB2YWx1ZXMsIGFuZCByZXF1ZXN0IHRoZSB3b3JrIGdyb3VwIHRvIHZv dGUNCj4gdGhlaXIgY2hvaWNlLg0KPg0KPiBPZiB0aGUgcHJpb3JpdHktdmFsdWVzIHB1dCBv dXQgdGhlcmUgb24gdGhlIGxpc3QsIHdlIGhhdmUgdGhlIGZvbGxvd2luZw0KPiBtZW50aW9u ZWQgYSBmZXcgdGltZXM6DQo+DQo+IC0gZW1lcmdlbmN5DQo+DQo+IC0gZW1lcmdlbmN5LWNh bGxiYWNrDQo+DQo+IC0gcHNhcC1jYWxsYmFjaw0KPg0KPiBBbHNvIG1lbnRpb25lZCBvbmNl IHdlcmU6DQo+DQo+IC0gZXhwZWRpdGVkLWVtZXJnZW5jeQ0KPg0KPiAtIHVyZ2VudC1lbWVy Z2VuY3kNCj4NCj4gLSBlbWVyZ2VuY3ktb3ZlcnJpZGUNCj4NCj4gSWYgSeKAmXZlIGZvcmdv dHRlbiBvbmUsIHBsZWFzZSBsZXQgbWUga25vdy4NCj4NCj4gU2VuZCB5b3VyIHZvdGUgdG8g dGhlIGVjcml0IGxpc3QuICBUaGUgdm90aW5nIHdpbGwgZ28gdGhyb3VnaCAxODowMA0KPiAo UGFjaWZpYyksIG5leHQgRnJpZGF5LCA5LzIxLzIwMTIuDQo+DQo+IC1yb2dlci4NCj4NCj4g KkZyb206KmVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1ib3VuY2VzQGll dGYub3JnXSAqT24gQmVoYWxmDQo+IE9mICpDaHJpc3RlciBIb2xtYmVyZw0KPiAqU2VudDoq IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEyLCAyMDEyIDU6MzIgQU0NCj4gKlRvOiogZWNyaXRA aWV0Zi5vcmcNCj4gKlN1YmplY3Q6KiBbRWNyaXRdIERyYWZ0IG5ldyB2ZXJzaW9uOiBkcmFm dC1pZXRmLWVjcml0LXBzYXAtY2FsbGJhY2stMDUNCj4NCj4gSGksDQo+DQo+IEnigJl2ZSBz dWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgcHNhcC1jYWxsYmFjayBkcmFmdCwgZHVl IHRvDQo+IGV4cGlyYXRpb24gb2YgdGhlIHByZXZpb3VzIHZlcnNpb24uDQo+DQo+IFRoZXJl IGFyZSBOTyBjaGFuZ2VzIGNvbXBhcmVkIHRvIHRoZSBwcmV2aW91cyB2ZXJzaW9uLg0KPg0K PiBPbmNlIEkgZ2V0IHNvbWUgZ3VpZGFuY2Ugb24gd2hlcmUgdG8gZGVmaW5lIHRoZSBuZXcg U0lQIFByaW9yaXR5IGhlYWRlcg0KPiBmaWVsZCDigJxwc2FwLWNhbGxiYWNr4oCdIHZhbHVl LCBJIHdpbGwgZWl0aGVyIHVwZGF0ZSB0aGlzIGRyYWZ0IG9yIHN1Ym1pdCBhDQo+IHNlcGFy YXRlIG9uZSBpbiBTSVBDT1JFLg0KPg0KPiBSZWdhcmRzLA0KPg0KPiBDaHJpc3Rlcg0KPg0K PiBDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgbWVzc2FnZSBtYXkgYmUNCj4gcHJpdmlsZWdlZCBhbmQvb3IgY29uZmlkZW50aWFs LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LA0KPiBvciByZXNwb25z aWJsZSBmb3IgZGVsaXZlcmluZyB0aGlzIG1lc3NhZ2UgdG8gdGhlIGludGVuZGVkIHJlY2lw aWVudCwNCj4gYW55IHJldmlldywgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgZGlzdHJp YnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcw0KPiBjb21tdW5pY2F0aW9uIG9yIGFueSBhdHRh Y2htZW50KHMpIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlDQo+IHJlY2Vp dmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5LA0KPiBhbmQgZGVsZXRlIGl0IGFuZCBhbGwgYXR0YWNobWVudHMgZnJvbSB5 b3VyIGNvbXB1dGVyIGFuZCBuZXR3b3JrLg0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBFY3JpdCBtYWlsaW5nIGxpc3QN Cj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9lY3JpdA0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KRWNyaXQgbWFpbGluZyBsaXN0DQpFY3JpdEBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwg KGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGllbnQg b3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVi bGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25l IG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGlt bWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0 aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9u LCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRlZCBy ZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuDQo= From keith.drage@alcatel-lucent.com Fri Sep 14 15:58:02 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CB621F84C8 for ; Fri, 14 Sep 2012 15:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alBPSq2hx0VF for ; Fri, 14 Sep 2012 15:58:01 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3B74E21F84C4 for ; Fri, 14 Sep 2012 15:58:01 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8EMvv9G005253 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 15 Sep 2012 00:57:57 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Sat, 15 Sep 2012 00:57:57 +0200 From: "DRAGE, Keith (Keith)" To: John-Luc Bakker , "pkyzivat@alum.mit.edu" , "ecrit@ietf.org" Date: Sat, 15 Sep 2012 00:57:55 +0200 Thread-Topic: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value Thread-Index: AQHNksEoJJIID7oABUuXgs6IAZfhaZeKuFSA//+uPi2AAAyYwA== Message-ID: References: <5053AA17.5010807@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA351FAC39@XMB104ADS.rim.net> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA351FAC39@XMB104ADS.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 22:58:02 -0000 Anything that is not one of the existing values. Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > John-Luc Bakker > Sent: 14 September 2012 23:13 > To: pkyzivat@alum.mit.edu; ecrit@ietf.org > Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 > - select priority-value >=20 > +1 for "emergency". > --- > John-Luc Bakker > Standards Manager > Research In Motion Corporation > Mobile +1 (908) 463 7321 > Office +1 (972) 373-1761 > Internal (820) 63761 > E-mail jbakker@rim.com >=20 > Sent from my BlackBerry Bold (9900) >=20 > ----- Original Message ----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Friday, September 14, 2012 05:05 PM > To: ecrit@ietf.org > Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 > - select priority-value >=20 > +1 for "emergency". >=20 > On 9/14/12 5:37 PM, Roger Marshall wrote: > > All: > > > > We need to select a priority-value in order to move the > > ecrit-psap-callback draft forward. > > > > Putting aside, for the moment, the questions of if/how/where the > > priority-value token is defined (if a new value is required - e.g., > > whether RFC or Registry), we should be able to agree on the value itsel= f. > > > > We've seen some suggestions for a priority-value given on the list over > > the last few weeks with no clear convergence. The value "emergency" is > > already included in the RFC3261 definition, but some others have voiced > > a preference to define a new priority-value, using other-priority =3D > token. > > > > Priority =3D "Priority" HCOLON priority-value > > > > priority-value =3D "emergency" / "urgent" / "normal" > > > > / "non-urgent" / other-priority > > > > other-priority =3D token > > > > We've seen a few mentioned on the list, now the chairs are calling to > > close the list of candidate values, and request the work group to vote > > their choice. > > > > Of the priority-values put out there on the list, we have the following > > mentioned a few times: > > > > - emergency > > > > - emergency-callback > > > > - psap-callback > > > > Also mentioned once were: > > > > - expedited-emergency > > > > - urgent-emergency > > > > - emergency-override > > > > If I've forgotten one, please let me know. > > > > Send your vote to the ecrit list. The voting will go through 18:00 > > (Pacific), next Friday, 9/21/2012. > > > > -roger. > > > > *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behal= f > > Of *Christer Holmberg > > *Sent:* Wednesday, September 12, 2012 5:32 AM > > *To:* ecrit@ietf.org > > *Subject:* [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 > > > > Hi, > > > > I've submitted a new version of the psap-callback draft, due to > > expiration of the previous version. > > > > There are NO changes compared to the previous version. > > > > Once I get some guidance on where to define the new SIP Priority header > > field "psap-callback" value, I will either update this draft or submit = a > > separate one in SIPCORE. > > > > Regards, > > > > Christer > > > > CONFIDENTIALITY NOTICE: The information contained in this message may b= e > > privileged and/or confidential. If you are not the intended recipient, > > or responsible for delivering this message to the intended recipient, > > any review, forwarding, dissemination, distribution or copying of this > > communication or any attachment(s) is strictly prohibited. If you have > > received this message in error, please notify the sender immediately, > > and delete it and all attachments from your computer and network. > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-publi= c > information. Any use of this information by anyone other than the intende= d > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From martin.thomson@gmail.com Fri Sep 14 16:03:25 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDE321F84D8 for ; Fri, 14 Sep 2012 16:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.744 X-Spam-Level: X-Spam-Status: No, score=-3.744 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhaG6M3GJOQo for ; Fri, 14 Sep 2012 16:03:25 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A481221F84D5 for ; Fri, 14 Sep 2012 16:03:24 -0700 (PDT) Received: by lbky2 with SMTP id y2so3313635lbk.31 for ; Fri, 14 Sep 2012 16:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BqXevSEmN5DYkqhVClcA8vfLnKKYfW/JGzAEycxYNEE=; b=q2UBbgyM5uBcIhDmajSb899aqbXu/eQUj1QBGMt5fmpbYSKx9OgGrGfd0nxUsq+qfF l5zAAoi/IroGmugViLKFs1crxqcQXkDz5gdyXYNoc4vD5DAKpvUv+QJQEmtnShrMR3oz le15r+vNTHYAVnUq3+MVr0j6a+deJ0beuJ9ENM3JlTpPSgG1wtyqvuEbkhm5/WRId99Q zc5KmCdQ1NkqfjQ5ynNLl/0zMJOCnQRMkTnodap/JgaUaGDl+cwq50sJO9F4yGAszXiC JTMmsRxpkaLl4phILoSMvNsCGENOcLNO18W3fwA7IdjVjb/9/ftwmkIMmDlKSftCA06P GZZg== MIME-Version: 1.0 Received: by 10.152.114.3 with SMTP id jc3mr3903849lab.11.1347663803297; Fri, 14 Sep 2012 16:03:23 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Fri, 14 Sep 2012 16:03:23 -0700 (PDT) In-Reply-To: <155970D1DA8E174F9E46039E10E2AA351FAC39@XMB104ADS.rim.net> References: <5053AA17.5010807@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA351FAC39@XMB104ADS.rim.net> Date: Fri, 14 Sep 2012 16:03:23 -0700 Message-ID: From: Martin Thomson To: John-Luc Bakker Content-Type: text/plain; charset=UTF-8 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 23:03:25 -0000 "emergency" On 14 September 2012 15:12, John-Luc Bakker wrote: > +1 for "emergency". From prvs=8605299b83=aallen@rim.com Fri Sep 14 19:36:19 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B693821F859C for ; Fri, 14 Sep 2012 19:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hqz3EJSg1HG0 for ; Fri, 14 Sep 2012 19:36:19 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1684321F8596 for ; Fri, 14 Sep 2012 19:36:18 -0700 (PDT) X-AuditID: 0a412830-b7fab6d000006b80-df-5053e9a142c4 Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id BF.2A.27520.2A9E3505; Sat, 15 Sep 2012 02:36:18 +0000 (GMT) Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.02.0298.004; Fri, 14 Sep 2012 21:36:17 -0500 From: Andrew Allen To: "martin.thomson@gmail.com" , John-Luc Bakker Thread-Topic: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value Thread-Index: AQHNksEot7wTs35JXESfgrMtmKLLTZeKuFSAgAACEACAAA4ygP//56or Date: Sat, 15 Sep 2012 02:36:17 +0000 Message-ID: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.254] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOKsWRmVeSWpSXmKPExsXC5ZyvpbvoZXCAwft97BaNi56yWlw784/R gclj56y77B5LlvxkCmCKamC0SUosKQvOTM/Tt7NJzMvLL0ksSVVISS1OtlXySU1PzFEIKMos S0yuVHDJLE7OSczMTS1SUshMsVUyUVIoyElMTs1NzSuxVUosKEjNS1Gy41LAADZAZZl5Cql5 yfkpmXnptkqewf66FhamlrqGSna6CZ08Gcu6HAuWsVSs7bvM2MB4i7mLkZNDQsBEoqNnC5Qt JnHh3nq2LkYuDiGBXiaJo517WCCcLYwSL3ccYQWpYhNQllj+ewYjiC0iECfRffg9G4jNLKAq ca7xMVADB4ewQLLE83khECUpEt/eXmGFsN0kru87C2azAJVvXdII1sor4CFx42QnE4jNKRAo sf/uCrCDGAVkJXafvc4EMV5c4taT+UwQhwpILNlzHupoUYmXj/+xQtiKEstOnIQ6R0/ixtQp ULa2xLKFr5khdglKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxgFczOKDcwMk/OS9Yoyc/Xy Uks2MYKSgaOGwQ7G9+8tDjEKcDAq8fCq7A8OEGJNLCuuzD3EKMHBrCTCq3oHKMSbklhZlVqU H19UmpNafIjRAhgSE5mluJPzgYkqryTe2MAAhaMkztv8wTNASCAdmGCyU1MLUotgWpk4OEFG c0mJFAPTRGpRYmlJRjwomcUXA9OZVAMjE3f3/FWx13iLDVy+rZ7+VKv/bffRpMUyVkkMVccu 50b1ZReGT1lUt/z9mj/2L/74LWeJWsj5YP1Oe2aN18tn+ZdNXyp58NM904/2jW/2VUeZcTXK zI/zXjZ58jPVnD7x5GmHpkporKi8+8Um5H1XmeZFlWjNTbGcv0WN1hrrvp6va8b4uF9OiaU4 I9FQi7moOBEAylLQxzoDAAA= Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 02:36:19 -0000 "emergency" ----- Original Message ----- From: Martin Thomson [mailto:martin.thomson@gmail.com] Sent: Friday, September 14, 2012 06:03 PM=0A= To: John-Luc Bakker Cc: ecrit@ietf.org Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 -= select priority-value "emergency" On 14 September 2012 15:12, John-Luc Bakker wrote: > +1 for "emergency". _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From christer.holmberg@ericsson.com Sat Sep 15 05:26:11 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5062621F84DD for ; Sat, 15 Sep 2012 05:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQQuhtZDkKMJ for ; Sat, 15 Sep 2012 05:26:10 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB9A21F84D9 for ; Sat, 15 Sep 2012 05:26:10 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-70-505473e04144 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E1.7C.11467.0E374505; Sat, 15 Sep 2012 14:26:08 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Sat, 15 Sep 2012 14:26:07 +0200 From: Christer Holmberg To: Roger Marshall , "ecrit@ietf.org" Date: Sat, 15 Sep 2012 14:25:28 +0200 Thread-Topic: Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value Thread-Index: AQHNksEdQ4PbjIc55kSNsSELX8EDTZeLVN8s Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F85@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvre6D4pAAg/0r1CwaFz1ltTh7+Tqj xeGrS5kcmD2m/N7I6rFkyU8mjw1bTzEHMEdx2aSk5mSWpRbp2yVwZXz4foK94IdYxYQ/x9gb GHcIdTFycEgImEh8WJndxcgJZIpJXLi3nq2LkYtDSOAUo8TqS/3MEM4CRonv99+zgDSwCVhI dP/TBjFFBIIkzt20AellFlCV+H1wGRuIzQJkn3x4BswWFoiWuLvrNguILSIQI3Gr5yKUbSSx deI5VhCbVyBcomHbHSaIVbMYJbZM+MwIkuAU8JdY9KwXrIER6Ljvp9YwQSwTl7j1ZD4TxNEC Ekv2nGeGsEUlXj7+xwpRLypxp309I0S9gcT7c/OZIWxtiWULXzNDLBaUODnzCcsERrFZSMbO QtIyC0nLLCQtCxhZVjEK5yZm5qSXG+qlFmUmFxfn5+kVp25iBEbTwS2/dXcwnjoncohRmoNF SZyXK2m/v5BAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGIp76ndf/m16o4eiVtFKuX6Y0qSEh 4Py0lrkxFdtvyz2oeBT2U9c7995e2TxNjXd+B/a07A5pNTKM37VCn5+J+ePkRxsfsE/Ls0oO 5OudvzEmY3/7/r+xNn/zrzY2zRKLN773TPudi0LvhBMfFHRE/jKrFfms+fGNyTnQ4oq1z4F9 L3NrDfOVWIozEg21mIuKEwF3wxy7dAIAAA== Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 12:26:11 -0000 "psap-callback" ...or, as Keith indicated, anything but an existing value. Regards, Christer ________________________________ From: Roger Marshall [RMarshall@telecomsys.com] Sent: Saturday, September 15, 2012 12:37 AM To: ecrit@ietf.org Cc: Christer Holmberg; Marc Linsner Subject: RE: Draft new version: draft-ietf-ecrit-psap-callback-05 - select = priority-value All: We need to select a priority-value in order to move the ecrit-psap-callback= draft forward. Putting aside, for the moment, the questions of if/how/where the priority-v= alue token is defined (if a new value is required - e.g., whether RFC or Re= gistry), we should be able to agree on the value itself. We=92ve seen some suggestions for a priority-value given on the list over t= he last few weeks with no clear convergence. The value =93emergency=94 is a= lready included in the RFC3261 definition, but some others have voiced a pr= eference to define a new priority-value, using other-priority =3D token. Priority =3D "Priority" HCOLON priority-value priority-value =3D "emergency" / "urgent" / "normal" / "non-urgent" / other-priority other-priority =3D token We=92ve seen a few mentioned on the list, now the chairs are calling to clo= se the list of candidate values, and request the work group to vote their c= hoice. Of the priority-values put out there on the list, we have the following men= tioned a few times: - emergency - emergency-callback - psap-callback Also mentioned once were: - expedited-emergency - urgent-emergency - emergency-override If I=92ve forgotten one, please let me know. Send your vote to the ecrit list. The voting will go through 18:00 (Pacifi= c), next Friday, 9/21/2012. -roger. From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of C= hrister Holmberg Sent: Wednesday, September 12, 2012 5:32 AM To: ecrit@ietf.org Subject: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 Hi, I=92ve submitted a new version of the psap-callback draft, due to expiratio= n of the previous version. There are NO changes compared to the previous version. Once I get some guidance on where to define the new SIP Priority header fie= ld =93psap-callback=94 value, I will either update this draft or submit a s= eparate one in SIPCORE. Regards, Christer CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. From brian.rosen@neustar.biz Sat Sep 15 15:11:08 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6EB521F84E1 for ; Sat, 15 Sep 2012 15:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zi6l2FC9tKqV for ; Sat, 15 Sep 2012 15:11:08 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0045A21F84D1 for ; Sat, 15 Sep 2012 15:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1347746997; x=1663102342; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=IlVKPVc9tsJVO0PdK9dya lT/DPKgK+DQq1XqjovqYIE=; b=cGCRs+XS5jfi770Dav1i45CZJnf4vTof5WNbQ BdefVg1gCT/nl0362cRK9+dM/0GF5oeWUTUTc+fFSmYrZeltg== Received: from ([10.31.13.228]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.9312269; Sat, 15 Sep 2012 18:09:56 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Sat, 15 Sep 2012 18:11:03 -0400 From: "Rosen, Brian" To: Christer Holmberg Date: Sat, 15 Sep 2012 18:11:01 -0400 Thread-Topic: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value Thread-Index: Ac2Tjv5DmX8TFBUQSOWWvExhWbiyVg== Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F85@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F85@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: BlnCOGjwygJ0N7DXLKMbrQ== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 22:11:09 -0000 +1 On Sep 15, 2012, at 8:25 AM, Christer Holmberg wrote: > "psap-callback" >=20 > ...or, as Keith indicated, anything but an existing value. >=20 > Regards, >=20 > Christer >=20 > ________________________________ > From: Roger Marshall [RMarshall@telecomsys.com] > Sent: Saturday, September 15, 2012 12:37 AM > To: ecrit@ietf.org > Cc: Christer Holmberg; Marc Linsner > Subject: RE: Draft new version: draft-ietf-ecrit-psap-callback-05 - selec= t priority-value >=20 > All: > We need to select a priority-value in order to move the ecrit-psap-callba= ck draft forward. >=20 > Putting aside, for the moment, the questions of if/how/where the priority= -value token is defined (if a new value is required - e.g., whether RFC or = Registry), we should be able to agree on the value itself. >=20 > We=92ve seen some suggestions for a priority-value given on the list over= the last few weeks with no clear convergence. The value =93emergency=94 is= already included in the RFC3261 definition, but some others have voiced a = preference to define a new priority-value, using other-priority =3D token. >=20 >=20 > Priority =3D "Priority" HCOLON priority-value >=20 > priority-value =3D "emergency" / "urgent" / "normal" >=20 > / "non-urgent" / other-priority >=20 > other-priority =3D token >=20 > We=92ve seen a few mentioned on the list, now the chairs are calling to c= lose the list of candidate values, and request the work group to vote their= choice. >=20 > Of the priority-values put out there on the list, we have the following m= entioned a few times: > - emergency > - emergency-callback > - psap-callback >=20 > Also mentioned once were: > - expedited-emergency > - urgent-emergency > - emergency-override >=20 > If I=92ve forgotten one, please let me know. >=20 > Send your vote to the ecrit list. The voting will go through 18:00 (Paci= fic), next Friday, 9/21/2012. >=20 > -roger. >=20 >=20 > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of= Christer Holmberg > Sent: Wednesday, September 12, 2012 5:32 AM > To: ecrit@ietf.org > Subject: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 >=20 > Hi, >=20 > I=92ve submitted a new version of the psap-callback draft, due to expirat= ion of the previous version. >=20 > There are NO changes compared to the previous version. >=20 > Once I get some guidance on where to define the new SIP Priority header f= ield =93psap-callback=94 value, I will either update this draft or submit a= separate one in SIPCORE. >=20 > Regards, >=20 > Christer >=20 > CONFIDENTIALITY NOTICE: The information contained in this message may be = privileged and/or confidential. If you are not the intended recipient, or r= esponsible for delivering this message to the intended recipient, any revie= w, forwarding, dissemination, distribution or copying of this communication= or any attachment(s) is strictly prohibited. If you have received this mes= sage in error, please notify the sender immediately, and delete it and all = attachments from your computer and network. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@nsn.com Sun Sep 16 03:54:37 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3CD21F84DC for ; Sun, 16 Sep 2012 03:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.226 X-Spam-Level: X-Spam-Status: No, score=-106.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IS4SRlpXTdcS for ; Sun, 16 Sep 2012 03:54:36 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC0E21F84D5 for ; Sun, 16 Sep 2012 03:54:35 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q8GAsQNv011737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 16 Sep 2012 12:54:26 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q8GAsO73031246; Sun, 16 Sep 2012 12:54:26 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 16 Sep 2012 12:54:24 +0200 Received: from 10.159.32.12 ([10.159.32.12]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) with Microsoft Exchange Server HTTP-DAV ; Sun, 16 Sep 2012 10:54:23 +0000 MIME-Version: 1.0 From: "Tschofenig, Hannes (NSN - FI/Espoo)" Message-ID: <036601cd93f9$a1a4d5a5$0c209f0a@nsnintra.net> Date: Sun, 16 Sep 2012 13:54:28 +0300 thread-index: Ac2T+aGkNJQ6ZybgQ6O7uruSobkp3w== To: "ext Rosen, Brian" , "Christer Holmberg" thread-topic: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value Content-Type: multipart/alternative; boundary="_79A9145B-6AFF-04AC-F6A3-D1B99949335A_"; charset="iso-8859-1" X-OriginalArrivalTime: 16 Sep 2012 10:54:24.0383 (UTC) FILETIME=[A25E20F0:01CD93F9] 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: 9543 X-purgate-ID: 151667::1347792866-00003184-49FC6381/0-0/0-0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 10:54:37 -0000 --_79A9145B-6AFF-04AC-F6A3-D1B99949335A_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="Windows-1252" Good for me=20 Sent from my Windows Phone -----Original Message----- From: ext Rosen, Brian Sent: 9/16/2012 1:11 AM To: Christer Holmberg Cc: ecrit@ietf.org Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 -= select priority-value +1 On Sep 15, 2012, at 8:25 AM, Christer Holmberg wrote: > "psap-callback" >=20 > ...or, as Keith indicated, anything but an existing value. >=20 > Regards, >=20 > Christer >=20 > ________________________________ > From: Roger Marshall [RMarshall@telecomsys.com] > Sent: Saturday, September 15, 2012 12:37 AM > To: ecrit@ietf.org > Cc: Christer Holmberg; Marc Linsner > Subject: RE: Draft new version: draft-ietf-ecrit-psap-callback-05 - selec= t priority-value >=20 > All: > We need to select a priority-value in order to move the ecrit-psap-callba= ck draft forward. >=20 > Putting aside, for the moment, the questions of if/how/where the priority= -value token is defined (if a new value is required - e.g., whether RFC or = Registry), we should be able to agree on the value itself. >=20 > We=92ve seen some suggestions for a priority-value given on the list over= the last few weeks with no clear convergence. The value =93emergency=94 is= already included in the RFC3261 definition, but some others have voiced a = preference to define a new priority-value, using other-priority =3D token. >=20 >=20 > Priority =3D "Priority" HCOLON priority-value >=20 > priority-value =3D "emergency" / "urgent" / "normal" >=20 > / "non-urgent" / other-priority >=20 > other-priority =3D token >=20 > We=92ve seen a few mentioned on the list, now the chairs are calling to c= lose the list of candidate values, and request the work group to vote their= choice. >=20 > Of the priority-values put out there on the list, we have the following m= entioned a few times: > - emergency > - emergency-callback > - psap-callback >=20 > Also mentioned once were: > - expedited-emergency > - urgent-emergency > - emergency-override >=20 > If I=92ve forgotten one, please let me know. >=20 > Send your vote to the ecrit list. The voting will go through 18:00 (Paci= fic), next Friday, 9/21/2012. >=20 > -roger. >=20 >=20 > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of= Christer Holmberg > Sent: Wednesday, September 12, 2012 5:32 AM > To: ecrit@ietf.org > Subject: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 >=20 > Hi, >=20 > I=92ve submitted a new version of the psap-callback draft, due to expirat= ion of the previous version. >=20 > There are NO changes compared to the previous version. >=20 > Once I get some guidance on where to define the new SIP Priority header f= ield =93psap-callback=94 value, I will either update this draft or submit a= separate one in SIPCORE. >=20 > Regards, >=20 > Christer >=20 > CONFIDENTIALITY NOTICE: The information contained in this message may be = privileged and/or confidential. If you are not the intended recipient, or r= esponsible for delivering this message to the intended recipient, any revie= w, forwarding, dissemination, distribution or copying of this communication= or any attachment(s) is strictly prohibited. If you have received this mes= sage in error, please notify the sender immediately, and delete it and all = attachments from your computer and network. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_79A9145B-6AFF-04AC-F6A3-D1B99949335A_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="Windows-1252"
Good for me

Sent from my Windows Phone
From: ext Rosen, Brian
Sent: 9/16/20= 12 1:11 AM
To: Christer Holmberg
Cc: ecrit@= ietf.org
Subject: Re: [Ecrit] Draft new version: draft-ietf= -ecrit-psap-callback-05 - select priority-value

+1
On Sep = 15, 2012, at 8:25 AM, Christer Holmberg <christer.holmberg@ericsson.com&= gt; wrote:

> "psap-callback"
>
> ...or, as Keith ind= icated, anything but an existing value.
>
> Regards,
> <= br>> Christer
>
> ________________________________
> = From: Roger Marshall [RMarshall@telecomsys.com]
> Sent: Saturday, Sep= tember 15, 2012 12:37 AM
> To: ecrit@ietf.org
> Cc: Christer Ho= lmberg; Marc Linsner
> Subject: RE: Draft new version: draft-ietf-ecr= it-psap-callback-05 - select priority-value
>
> All:
> W= e need to select a priority-value in order to move the ecrit-psap-callback = draft forward.
>
> Putting aside, for the moment, the question= s of if/how/where the priority-value token is defined (if a new value is re= quired - e.g., whether RFC or Registry), we should be able to agree on the = value itself.
>
> We=92ve seen some suggestions for a priority= -value given on the list over the last few weeks with no clear convergence.= The value =93emergency=94 is already included in the RFC3261 definition, b= ut some others have voiced a preference to define a new priority-value, usi= ng other-priority =3D token.
>
>
> Priority  =          =3D  "Priority" HCOLO= N priority-value
>
> priority-value    =3D = ; "emergency" / "urgent" / "normal"
>
>    = ;            &n= bsp;       / "non-urgent" / other-priority>
> other-priority    =3D  token
> > We=92ve seen a few mentioned on the list, now the chairs are calling = to close the list of candidate values, and request the work group to vote t= heir choice.
>
> Of the priority-values put out there on the l= ist, we have the following mentioned a few times:
> - emergency
&g= t; - emergency-callback
> - psap-callback
>
> Also menti= oned once were:
> - expedited-emergency
> - urgent-emergency> - emergency-override
>
> If I=92ve forgotten one, please= let me know.
>
> Send your vote to the ecrit list.  The = voting will go through 18:00 (Pacific), next Friday, 9/21/2012.
> > -roger.
>
>
> From: ecrit-bounces@ietf.org [mailt= o:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
> Sent: Wedn= esday, September 12, 2012 5:32 AM
> To: ecrit@ietf.org
> Subjec= t: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05
> > Hi,
>
> I=92ve submitted a new version of the psap-callb= ack draft, due to expiration of the previous version.
>
> Ther= e are NO changes compared to the previous version.
>
> Once I = get some guidance on where to define the new SIP Priority header field =93p= sap-callback=94 value, I will either update this draft or submit a separate= one in SIPCORE.
>
> Regards,
>
> Christer
>= ;
> CONFIDENTIALITY NOTICE: The information contained in this messag= e may be privileged and/or confidential. If you are not the intended recipi= ent, or responsible for delivering this message to the intended recipient, = any review, forwarding, dissemination, distribution or copying of this comm= unication or any attachment(s) is strictly prohibited. If you have received= this message in error, please notify the sender immediately, and delete it= and all attachments from your computer and network.
> ______________= _________________________________
> Ecrit mailing list
> Ecrit@= ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit

_______= ________________________________________
Ecrit mailing list
Ecrit@iet= f.org
https://www.ietf.org/mailman/listinfo/ecrit
= --_79A9145B-6AFF-04AC-F6A3-D1B99949335A_-- From bernard_aboba@hotmail.com Sun Sep 16 06:09:09 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AD321F848F for ; Sun, 16 Sep 2012 06:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.11 X-Spam-Level: X-Spam-Status: No, score=-102.11 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTVxTXjXQDkm for ; Sun, 16 Sep 2012 06:09:08 -0700 (PDT) Received: from blu0-omc2-s6.blu0.hotmail.com (blu0-omc2-s6.blu0.hotmail.com [65.55.111.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6566121F8510 for ; Sun, 16 Sep 2012 06:09:08 -0700 (PDT) Received: from BLU401-EAS424 ([65.55.111.71]) by blu0-omc2-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 16 Sep 2012 06:09:07 -0700 X-Originating-IP: [24.16.96.166] X-EIP: [uf25pEVUKGUwOzAKFNritF94wm9c0gci] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/related; boundary="_378a9690-b5a5-4232-b47a-79c747a85ab6_" Date: Sun, 16 Sep 2012 06:09:02 -0700 From: Bernard Aboba To: "Tschofenig, Hannes (NSN - FI/Espoo)" MIME-Version: 1.0 X-OriginalArrivalTime: 16 Sep 2012 13:09:07.0813 (UTC) FILETIME=[7477A950:01CD940C] Cc: "ext Rosen, Brian" , ecrit@ietf.org Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 13:09:09 -0000 --_378a9690-b5a5-4232-b47a-79c747a85ab6_ Content-Type: multipart/alternative; boundary="_7a52a225-6ae4-4f95-b9a0-54aa74346339_" --_7a52a225-6ae4-4f95-b9a0-54aa74346339_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" +1 "Tschofenig=2C Hannes (NSN - FI/Espoo)" wrote: Good for me Sent from my Windows Phone -----Original Message----- From: ext Rosen=2C Brian Sent: 9/16/2012 1:11 AM To: Christer Holmberg Cc: ecrit@ietf.org Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 -= select priority-value +1 On Sep 15=2C 2012=2C at 8:25 AM=2C Christer Holmberg wrote: > "psap-callback" > > ...or=2C as Keith indicated=2C anything but an existing value. > > Regards=2C > > Christer > > ________________________________ > From: Roger Marshall [RMarshall@telecomsys.com] > Sent: Saturday=2C September 15=2C 2012 12:37 AM > To: ecrit@ietf.org > Cc: Christer Holmberg=3B Marc Linsner > Subject: RE: Draft new version: draft-ietf-ecrit-psap-callback-05 - selec= t priority-value > > All: > We need to select a priority-value in order to move the ecrit-psap-callba= ck draft forward. > > Putting aside=2C for the moment=2C the questions of if/how/where the prio= rity-value token is defined (if a new value is required - e.g.=2C whether R= FC or Registry)=2C we should be able to agree on the value itself. > > We=E2=80=99ve seen some suggestions for a priority-value given on the lis= t over the last few weeks with no clear convergence. The value =E2=80=9Ceme= rgency=E2=80=9D is already included in the RFC3261 definition=2C but some o= thers have voiced a preference to define a new priority-value=2C using othe= r-priority =3D token. > > > Priority =3D "Priority" HCOLON priority-value > > priority-value =3D "emergency" / "urgent" / "normal" > > / "non-urgent" / other-priority > > other-priority =3D token > > We=E2=80=99ve seen a few mentioned on the list=2C now the chairs are call= ing to close the list of candidate values=2C and request the work group to = vote their choice. > > Of the priority-values put out there on the list=2C we have the following= mentioned a few times: > - emergency > - emergency-callback > - psap-callback > > Also mentioned once were: > - expedited-emergency > - urgent-emergency > - emergency-override > > If I=E2=80=99ve forgotten one=2C please let me know. > > Send your vote to the ecrit list. The voting will go through 18:00 (Paci= fic)=2C next Friday=2C 9/21/2012. > > -roger. > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of= Christer Holmberg > Sent: Wednesday=2C September 12=2C 2012 5:32 AM > To: ecrit@ietf.org > Subject: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 > > Hi=2C > > I=E2=80=99ve submitted a new version of the psap-callback draft=2C due to= expiration of the previous version. > > There are NO changes compared to the previous version. > > Once I get some guidance on where to define the new SIP Priority header f= ield =E2=80=9Cpsap-callback=E2=80=9D value=2C I will either update this dra= ft or submit a separate one in SIPCORE. > > Regards=2C > > Christer > > CONFIDENTIALITY NOTICE: The information contained in this message may be = privileged and/or confidential. If you are not the intended recipient=2C or= responsible for delivering this message to the intended recipient=2C any r= eview=2C forwarding=2C dissemination=2C distribution or copying of this com= munication or any attachment(s) is strictly prohibited. If you have receive= d this message in error=2C please notify the sender immediately=2C and dele= te it and all attachments from your computer and network. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_7a52a225-6ae4-4f95-b9a0-54aa74346339_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
+=3B1

"=3BTschofenig=2C Hannes (NSN - FI/Espoo)"=3B <=3Bhannes.tschofen= ig@nsn.com>=3B wrote:
Good for = me

Sent from my Windows Phone
From: ex= t Rosen=2C Brian
Sent: 9/= 16/2012 1:11 AM
To: Ch= rister Holmberg
Cc: ec= rit@ietf.org
Subject: Re= : [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select pri= ority-value

+=3B1
On Sep 15=2C 2012=2C at 8:25 AM=2C Christer Holmberg <=3Bchrister.holmber= g@ericsson.com>=3B wrote:

>=3B "=3Bpsap-callback"=3B
>=3B
>=3B ...or=2C as Keith indicated=2C anything but an existing value.
>=3B
>=3B Regards=2C
>=3B
>=3B Christer
>=3B
>=3B ________________________________
>=3B From: Roger Marshall [RMarshall@telecomsys.com]
>=3B Sent: Saturday=2C September 15=2C 2012 12:37 AM
>=3B To: ecrit@ietf.org
>=3B Cc: Christer Holmberg=3B Marc Linsner
>=3B Subject: RE: Draft new version: draft-ietf-ecrit-psap-callback-05 - = select priority-value
>=3B
>=3B All:
>=3B We need to select a priority-value in order to move the ecrit-psap-c= allback draft forward.
>=3B
>=3B Putting aside=2C for the moment=2C the questions of if/how/where the= priority-value token is defined (if a new value is required - e.g.=2C whet= her RFC or Registry)=2C we should be able to agree on the value itself.
>=3B
>=3B We=E2=80=99ve seen some suggestions for a priority-value given on th= e list over the last few weeks with no clear convergence. The value =E2=80= =9Cemergency=E2=80=9D is already included in the RFC3261 definition=2C but = some others have voiced a preference to define a new priority-value=2C using other-priority =3D token.
>=3B
>=3B
>=3B Priority =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3D =3B "=3BPriority"=3B HCOLON priority-v= alue
>=3B
>=3B priority-value =3B =3B =3B =3D =3B "=3Bemergency= "=3B / "=3Burgent"=3B / "=3Bnormal"=3B
>=3B
>=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B / "=3Bnon-urgent"=3B / oth= er-priority
>=3B
>=3B other-priority =3B =3B =3B =3D =3B token
>=3B
>=3B We=E2=80=99ve seen a few mentioned on the list=2C now the chairs are= calling to close the list of candidate values=2C and request the work grou= p to vote their choice.
>=3B
>=3B Of the priority-values put out there on the list=2C we have the foll= owing mentioned a few times:
>=3B - emergency
>=3B - emergency-callback
>=3B - psap-callback
>=3B
>=3B Also mentioned once were:
>=3B - expedited-emergency
>=3B - urgent-emergency
>=3B - emergency-override
>=3B
>=3B If I=E2=80=99ve forgotten one=2C please let me know.
>=3B
>=3B Send your vote to the ecrit list. =3B The voting will go through= 18:00 (Pacific)=2C next Friday=2C 9/21/2012.
>=3B
>=3B -roger.
>=3B
>=3B
>=3B From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Beha= lf Of Christer Holmberg
>=3B Sent: Wednesday=2C September 12=2C 2012 5:32 AM
>=3B To: ecrit@ietf.org
>=3B Subject: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-0= 5
>=3B
>=3B Hi=2C
>=3B
>=3B I=E2=80=99ve submitted a new version of the psap-callback draft=2C d= ue to expiration of the previous version.
>=3B
>=3B There are NO changes compared to the previous version.
>=3B
>=3B Once I get some guidance on where to define the new SIP Priority hea= der field =E2=80=9Cpsap-callback=E2=80=9D value=2C I will either update thi= s draft or submit a separate one in SIPCORE.
>=3B
>=3B Regards=2C
>=3B
>=3B Christer
>=3B
>=3B CONFIDENTIALITY NOTICE: The information contained in this message ma= y be privileged and/or confidential. If you are not the intended recipient= =2C or responsible for delivering this message to the intended recipient=2C= any review=2C forwarding=2C dissemination=2C distribution or copying of this communication or any attachment(s) is strictly prohibit= ed. If you have received this message in error=2C please notify the sender = immediately=2C and delete it and all attachments from your computer and net= work.
>=3B _______________________________________________
>=3B Ecrit mailing list
>=3B Ecrit@ietf.org
>=3B https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
--_7a52a225-6ae4-4f95-b9a0-54aa74346339_-- --_378a9690-b5a5-4232-b47a-79c747a85ab6_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_378a9690-b5a5-4232-b47a-79c747a85ab6_-- From md3135@att.com Sun Sep 16 07:22:14 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CE221F84E1 for ; Sun, 16 Sep 2012 07:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMOp16A6uIfp for ; Sun, 16 Sep 2012 07:22:14 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id ADD0221F84DE for ; Sun, 16 Sep 2012 07:22:13 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 590e5505.2aab00a20940.34333.00-591.91663.nbfkord-smmo08.seg.att.com (envelope-from ); Sun, 16 Sep 2012 14:22:13 +0000 (UTC) X-MXL-Hash: 5055e095308e6889-bf962da6360f111e0c551824f9e84d29a3b13a9a Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 090e5505.0.34317.00-481.91613.nbfkord-smmo08.seg.att.com (envelope-from ); Sun, 16 Sep 2012 14:22:09 +0000 (UTC) X-MXL-Hash: 5055e091112eaf38-b063ce2505a4beae5c4ecf8d14ff9a290149f693 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 q8GEM86H001925; Sun, 16 Sep 2012 10:22:08 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q8GELxgN001846 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 16 Sep 2012 10:22:00 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0318.001; Sun, 16 Sep 2012 10:15:10 -0400 From: "DOLLY, MARTIN C" To: Bernard Aboba , "Tschofenig, Hannes (NSN - FI/Espoo)" Thread-Topic: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value Thread-Index: AQHNlAyzRMaTzx+cXESk+2VgniFE35eNAzDQ Date: Sun, 16 Sep 2012 14:15:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.82.89] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E83656D6B534MISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=oftxRYFbiNIA:10 a=Br-QO7T-xeoA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=02K0Y2VpAAAA:8 a=0FD05c-RAAAA:8 a=BQ6xbDwIA] X-AnalysisOut: [AAA:8 a=Q8aCP0iPcxysY8NaUHEA:9 a=QEXdDO2ut3YA:10 a=lZB815d] X-AnalysisOut: [zVvQA:10 a=zwC7bnKO5xoA:10 a=f7GxY0FH8QIA:10 a=JvXaaV0oIFo] X-AnalysisOut: [A:10 a=4z_LBp755nMGn1_x:21 a=iavway1zpX0qKcS3:21 a=yMhMjlu] X-AnalysisOut: [bAAAA:8 a=SSmOFEACAAAA:8 a=HXkCXje-trq7S38YpV0A:9 a=gKO2Hq] X-AnalysisOut: [4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-h] X-AnalysisOut: [UA:10 a=oyF64P3Oi3RJ9Jfm:21 a=ZsOXAwXJZAQmv1Cw:21] Cc: "ext Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 14:22:15 -0000 --_000_E42CCDDA6722744CB241677169E83656D6B534MISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZQ0KDQpGcm9tOiBlY3JpdC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZWNyaXQtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJlcm5hcmQgQWJvYmENClNlbnQ6IFN1bmRheSwg U2VwdGVtYmVyIDE2LCAyMDEyIDk6MDkgQU0NClRvOiBUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAt IEZJL0VzcG9vKQ0KQ2M6IGV4dCBSb3NlbiwgQnJpYW47IGVjcml0QGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW0Vjcml0XSBEcmFmdCBuZXcgdmVyc2lvbjogZHJhZnQtaWV0Zi1lY3JpdC1wc2FwLWNh bGxiYWNrLTA1IC0gc2VsZWN0IHByaW9yaXR5LXZhbHVlDQoNCisxDQoNCiJUc2Nob2ZlbmlnLCBI YW5uZXMgKE5TTiAtIEZJL0VzcG9vKSIgPGhhbm5lcy50c2Nob2ZlbmlnQG5zbi5jb208bWFpbHRv Omhhbm5lcy50c2Nob2ZlbmlnQG5zbi5jb20+PiB3cm90ZToNCkdvb2QgZm9yIG1lDQoNClNlbnQg ZnJvbSBteSBXaW5kb3dzIFBob25lDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K RnJvbTogZXh0IFJvc2VuLCBCcmlhbg0KU2VudDogOS8xNi8yMDEyIDE6MTEgQU0NClRvOiBDaHJp c3RlciBIb2xtYmVyZw0KQ2M6IGVjcml0QGlldGYub3JnPG1haWx0bzplY3JpdEBpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbRWNyaXRdIERyYWZ0IG5ldyB2ZXJzaW9uOiBkcmFmdC1pZXRmLWVjcml0 LXBzYXAtY2FsbGJhY2stMDUgLSBzZWxlY3QgcHJpb3JpdHktdmFsdWUNCg0KKzENCk9uIFNlcCAx NSwgMjAxMiwgYXQgODoyNSBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3Jv dGU6DQoNCj4gInBzYXAtY2FsbGJhY2siDQo+DQo+IC4uLm9yLCBhcyBLZWl0aCBpbmRpY2F0ZWQs IGFueXRoaW5nIGJ1dCBhbiBleGlzdGluZyB2YWx1ZS4NCj4NCj4gUmVnYXJkcywNCj4NCj4gQ2hy aXN0ZXINCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRnJvbTogUm9n ZXIgTWFyc2hhbGwgW1JNYXJzaGFsbEB0ZWxlY29tc3lzLmNvbV0NCj4gU2VudDogU2F0dXJkYXks IFNlcHRlbWJlciAxNSwgMjAxMiAxMjozNyBBTQ0KPiBUbzogZWNyaXRAaWV0Zi5vcmc8bWFpbHRv OmVjcml0QGlldGYub3JnPg0KPiBDYzogQ2hyaXN0ZXIgSG9sbWJlcmc7IE1hcmMgTGluc25lcg0K PiBTdWJqZWN0OiBSRTogRHJhZnQgbmV3IHZlcnNpb246IGRyYWZ0LWlldGYtZWNyaXQtcHNhcC1j YWxsYmFjay0wNSAtIHNlbGVjdCBwcmlvcml0eS12YWx1ZQ0KPg0KPiBBbGw6DQo+IFdlIG5lZWQg dG8gc2VsZWN0IGEgcHJpb3JpdHktdmFsdWUgaW4gb3JkZXIgdG8gbW92ZSB0aGUgZWNyaXQtcHNh cC1jYWxsYmFjayBkcmFmdCBmb3J3YXJkLg0KPg0KPiBQdXR0aW5nIGFzaWRlLCBmb3IgdGhlIG1v bWVudCwgdGhlIHF1ZXN0aW9ucyBvZiBpZi9ob3cvd2hlcmUgdGhlIHByaW9yaXR5LXZhbHVlIHRv a2VuIGlzIGRlZmluZWQgKGlmIGEgbmV3IHZhbHVlIGlzIHJlcXVpcmVkIC0gZS5nLiwgd2hldGhl ciBSRkMgb3IgUmVnaXN0cnkpLCB3ZSBzaG91bGQgYmUgYWJsZSB0byBhZ3JlZSBvbiB0aGUgdmFs dWUgaXRzZWxmLg0KPg0KPiBXZeKAmXZlIHNlZW4gc29tZSBzdWdnZXN0aW9ucyBmb3IgYSBwcmlv cml0eS12YWx1ZSBnaXZlbiBvbiB0aGUgbGlzdCBvdmVyIHRoZSBsYXN0IGZldyB3ZWVrcyB3aXRo IG5vIGNsZWFyIGNvbnZlcmdlbmNlLiBUaGUgdmFsdWUg4oCcZW1lcmdlbmN54oCdIGlzIGFscmVh ZHkgaW5jbHVkZWQgaW4gdGhlIFJGQzMyNjEgZGVmaW5pdGlvbiwgYnV0IHNvbWUgb3RoZXJzIGhh dmUgdm9pY2VkIGEgcHJlZmVyZW5jZSB0byBkZWZpbmUgYSBuZXcgcHJpb3JpdHktdmFsdWUsIHVz aW5nIG90aGVyLXByaW9yaXR5ID0gdG9rZW4uDQo+DQo+DQo+IFByaW9yaXR5ICAgICAgICAgICA9 ICAiUHJpb3JpdHkiIEhDT0xPTiBwcmlvcml0eS12YWx1ZQ0KPg0KPiBwcmlvcml0eS12YWx1ZSAg ICA9ICAiZW1lcmdlbmN5IiAvICJ1cmdlbnQiIC8gIm5vcm1hbCINCj4NCj4gICAgICAgICAgICAg ICAgICAgICAgICAvICJub24tdXJnZW50IiAvIG90aGVyLXByaW9yaXR5DQo+DQo+IG90aGVyLXBy aW9yaXR5ICAgID0gIHRva2VuDQo+DQo+IFdl4oCZdmUgc2VlbiBhIGZldyBtZW50aW9uZWQgb24g dGhlIGxpc3QsIG5vdyB0aGUgY2hhaXJzIGFyZSBjYWxsaW5nIHRvIGNsb3NlIHRoZSBsaXN0IG9m IGNhbmRpZGF0ZSB2YWx1ZXMsIGFuZCByZXF1ZXN0IHRoZSB3b3JrIGdyb3VwIHRvIHZvdGUgdGhl aXIgY2hvaWNlLg0KPg0KPiBPZiB0aGUgcHJpb3JpdHktdmFsdWVzIHB1dCBvdXQgdGhlcmUgb24g dGhlIGxpc3QsIHdlIGhhdmUgdGhlIGZvbGxvd2luZyBtZW50aW9uZWQgYSBmZXcgdGltZXM6DQo+ IC0gZW1lcmdlbmN5DQo+IC0gZW1lcmdlbmN5LWNhbGxiYWNrDQo+IC0gcHNhcC1jYWxsYmFjaw0K Pg0KPiBBbHNvIG1lbnRpb25lZCBvbmNlIHdlcmU6DQo+IC0gZXhwZWRpdGVkLWVtZXJnZW5jeQ0K PiAtIHVyZ2VudC1lbWVyZ2VuY3kNCj4gLSBlbWVyZ2VuY3ktb3ZlcnJpZGUNCj4NCj4gSWYgSeKA mXZlIGZvcmdvdHRlbiBvbmUsIHBsZWFzZSBsZXQgbWUga25vdy4NCj4NCj4gU2VuZCB5b3VyIHZv dGUgdG8gdGhlIGVjcml0IGxpc3QuICBUaGUgdm90aW5nIHdpbGwgZ28gdGhyb3VnaCAxODowMCAo UGFjaWZpYyksIG5leHQgRnJpZGF5LCA5LzIxLzIwMTIuDQo+DQo+IC1yb2dlci4NCj4NCj4NCj4g RnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9y Zz4gW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIg SG9sbWJlcmcNCj4gU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTIsIDIwMTIgNTozMiBBTQ0K PiBUbzogZWNyaXRAaWV0Zi5vcmc8bWFpbHRvOmVjcml0QGlldGYub3JnPg0KPiBTdWJqZWN0OiBb RWNyaXRdIERyYWZ0IG5ldyB2ZXJzaW9uOiBkcmFmdC1pZXRmLWVjcml0LXBzYXAtY2FsbGJhY2st MDUNCj4NCj4gSGksDQo+DQo+IEnigJl2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUg cHNhcC1jYWxsYmFjayBkcmFmdCwgZHVlIHRvIGV4cGlyYXRpb24gb2YgdGhlIHByZXZpb3VzIHZl cnNpb24uDQo+DQo+IFRoZXJlIGFyZSBOTyBjaGFuZ2VzIGNvbXBhcmVkIHRvIHRoZSBwcmV2aW91 cyB2ZXJzaW9uLg0KPg0KPiBPbmNlIEkgZ2V0IHNvbWUgZ3VpZGFuY2Ugb24gd2hlcmUgdG8gZGVm aW5lIHRoZSBuZXcgU0lQIFByaW9yaXR5IGhlYWRlciBmaWVsZCDigJxwc2FwLWNhbGxiYWNr4oCd IHZhbHVlLCBJIHdpbGwgZWl0aGVyIHVwZGF0ZSB0aGlzIGRyYWZ0IG9yIHN1Ym1pdCBhIHNlcGFy YXRlIG9uZSBpbiBTSVBDT1JFLg0KPg0KPiBSZWdhcmRzLA0KPg0KPiBDaHJpc3Rlcg0KPg0KPiBD T05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg bWVzc2FnZSBtYXkgYmUgcHJpdmlsZWdlZCBhbmQvb3IgY29uZmlkZW50aWFsLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBvciByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmlu ZyB0aGlzIG1lc3NhZ2UgdG8gdGhlIGludGVuZGVkIHJlY2lwaWVudCwgYW55IHJldmlldywgZm9y d2FyZGluZywgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBj b21tdW5pY2F0aW9uIG9yIGFueSBhdHRhY2htZW50KHMpIGlzIHN0cmljdGx5IHByb2hpYml0ZWQu IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5LCBhbmQgZGVsZXRlIGl0IGFuZCBhbGwgYXR0YWNobWVu dHMgZnJvbSB5b3VyIGNvbXB1dGVyIGFuZCBuZXR3b3JrLg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNy aXRAaWV0Zi5vcmc8bWFpbHRvOkVjcml0QGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpFY3JpdCBtYWlsaW5nIGxpc3QNCkVjcml0QGlldGYub3JnPG1h aWx0bzpFY3JpdEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZWNyaXQNCg== --_000_E42CCDDA6722744CB241677169E83656D6B534MISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5lbWFpbHF1b3Rl LCBsaS5lbWFpbHF1b3RlLCBkaXYuZW1haWxxdW90ZQ0KCXttc28tc3R5bGUtbmFtZTplbWFpbHF1 b3RlOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MS4wcHQ7DQoJYm9yZGVyOm5v bmU7DQoJcGFkZGluZzowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5JIGFncmVlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gZWNyaXQtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJlcm5hcmQg QWJvYmE8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBTZXB0ZW1iZXIgMTYsIDIwMTIgOTowOSBB TTxicj4NCjxiPlRvOjwvYj4gVHNjaG9mZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3Bvbyk8YnI+ DQo8Yj5DYzo8L2I+IGV4dCBSb3NlbiwgQnJpYW47IGVjcml0QGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbRWNyaXRdIERyYWZ0IG5ldyB2ZXJzaW9uOiBkcmFmdC1pZXRmLWVjcml0 LXBzYXAtY2FsbGJhY2stMDUgLSBzZWxlY3QgcHJpb3JpdHktdmFsdWU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+JiM0MzsxPGJyPg0KPGJy Pg0KJnF1b3Q7VHNjaG9mZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3BvbykmcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0Buc24uY29tIj5oYW5uZXMudHNjaG9mZW5p Z0Buc24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkdvb2QgZm9yIG1lDQo8YnI+DQo8YnI+DQpTZW50IGZyb20gbXkgV2luZG93 cyBQaG9uZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8 aHIgc2l6ZT0iMyIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbToNCjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmV4dCBSb3NlbiwgQnJpYW48L3NwYW4+ PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNlbnQ6IDwvc3Bhbj4NCjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+OS8xNi8yMDEyIDE6MTEgQU08L3NwYW4+PGJyPg0K PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRvOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5DaHJpc3RlciBIb2xtYmVyZzwvc3Bhbj48YnI+DQo8Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q2M6IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxhIGhyZWY9Im1haWx0bzplY3JpdEBpZXRmLm9yZyI+ZWNyaXRAaWV0Zi5vcmc8L2E+ PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWJqZWN0OiA8L3Nw YW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJlOiBbRWNyaXRdIERyYWZ0IG5l dyB2ZXJzaW9uOiBkcmFmdC1pZXRmLWVjcml0LXBzYXAtY2FsbGJhY2stMDUgLSBzZWxlY3QgcHJp b3JpdHktdmFsdWU8L3NwYW4+PGJyPg0KPGJyPg0KJiM0MzsxPGJyPg0KT24gU2VwIDE1LCAyMDEy LCBhdCA4OjI1IEFNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t PC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyAmcXVvdDtwc2FwLWNhbGxiYWNrJnF1b3Q7 PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC4uLm9yLCBhcyBLZWl0aCBpbmRpY2F0ZWQsIGFueXRoaW5n IGJ1dCBhbiBleGlzdGluZyB2YWx1ZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgUmVnYXJkcyw8YnI+ DQomZ3Q7IDxicj4NCiZndDsgQ2hyaXN0ZXI8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IEZyb206IFJvZ2VyIE1hcnNoYWxsIFtS TWFyc2hhbGxAdGVsZWNvbXN5cy5jb21dPGJyPg0KJmd0OyBTZW50OiBTYXR1cmRheSwgU2VwdGVt YmVyIDE1LCAyMDEyIDEyOjM3IEFNPGJyPg0KJmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOmVjcml0 QGlldGYub3JnIj5lY3JpdEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IENjOiBDaHJpc3RlciBIb2xt YmVyZzsgTWFyYyBMaW5zbmVyPGJyPg0KJmd0OyBTdWJqZWN0OiBSRTogRHJhZnQgbmV3IHZlcnNp b246IGRyYWZ0LWlldGYtZWNyaXQtcHNhcC1jYWxsYmFjay0wNSAtIHNlbGVjdCBwcmlvcml0eS12 YWx1ZTxicj4NCiZndDsgPGJyPg0KJmd0OyBBbGw6PGJyPg0KJmd0OyBXZSBuZWVkIHRvIHNlbGVj dCBhIHByaW9yaXR5LXZhbHVlIGluIG9yZGVyIHRvIG1vdmUgdGhlIGVjcml0LXBzYXAtY2FsbGJh Y2sgZHJhZnQgZm9yd2FyZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgUHV0dGluZyBhc2lkZSwgZm9y IHRoZSBtb21lbnQsIHRoZSBxdWVzdGlvbnMgb2YgaWYvaG93L3doZXJlIHRoZSBwcmlvcml0eS12 YWx1ZSB0b2tlbiBpcyBkZWZpbmVkIChpZiBhIG5ldyB2YWx1ZSBpcyByZXF1aXJlZCAtIGUuZy4s IHdoZXRoZXIgUkZDIG9yIFJlZ2lzdHJ5KSwgd2Ugc2hvdWxkIGJlIGFibGUgdG8gYWdyZWUgb24g dGhlIHZhbHVlIGl0c2VsZi48YnI+DQomZ3Q7IDxicj4NCiZndDsgV2XigJl2ZSBzZWVuIHNvbWUg c3VnZ2VzdGlvbnMgZm9yIGEgcHJpb3JpdHktdmFsdWUgZ2l2ZW4gb24gdGhlIGxpc3Qgb3ZlciB0 aGUgbGFzdCBmZXcgd2Vla3Mgd2l0aCBubyBjbGVhciBjb252ZXJnZW5jZS4gVGhlIHZhbHVlIOKA nGVtZXJnZW5jeeKAnSBpcyBhbHJlYWR5IGluY2x1ZGVkIGluIHRoZSBSRkMzMjYxIGRlZmluaXRp b24sIGJ1dCBzb21lIG90aGVycyBoYXZlIHZvaWNlZCBhIHByZWZlcmVuY2UgdG8gZGVmaW5lIGEg bmV3IHByaW9yaXR5LXZhbHVlLA0KIHVzaW5nIG90aGVyLXByaW9yaXR5ID0gdG9rZW4uPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgUHJpb3JpdHkmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPSZuYnNwOyAmcXVvdDtQcmlv cml0eSZxdW90OyBIQ09MT04gcHJpb3JpdHktdmFsdWU8YnI+DQomZ3Q7IDxicj4NCiZndDsgcHJp b3JpdHktdmFsdWUmbmJzcDsmbmJzcDsmbmJzcDsgPSZuYnNwOyAmcXVvdDtlbWVyZ2VuY3kmcXVv dDsgLyAmcXVvdDt1cmdlbnQmcXVvdDsgLyAmcXVvdDtub3JtYWwmcXVvdDs8YnI+DQomZ3Q7IDxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLyAmcXVvdDtub24tdXJnZW50JnF1b3Q7 IC8gb3RoZXItcHJpb3JpdHk8YnI+DQomZ3Q7IDxicj4NCiZndDsgb3RoZXItcHJpb3JpdHkmbmJz cDsmbmJzcDsmbmJzcDsgPSZuYnNwOyB0b2tlbjxicj4NCiZndDsgPGJyPg0KJmd0OyBXZeKAmXZl IHNlZW4gYSBmZXcgbWVudGlvbmVkIG9uIHRoZSBsaXN0LCBub3cgdGhlIGNoYWlycyBhcmUgY2Fs bGluZyB0byBjbG9zZSB0aGUgbGlzdCBvZiBjYW5kaWRhdGUgdmFsdWVzLCBhbmQgcmVxdWVzdCB0 aGUgd29yayBncm91cCB0byB2b3RlIHRoZWlyIGNob2ljZS48YnI+DQomZ3Q7IDxicj4NCiZndDsg T2YgdGhlIHByaW9yaXR5LXZhbHVlcyBwdXQgb3V0IHRoZXJlIG9uIHRoZSBsaXN0LCB3ZSBoYXZl IHRoZSBmb2xsb3dpbmcgbWVudGlvbmVkIGEgZmV3IHRpbWVzOjxicj4NCiZndDsgLSBlbWVyZ2Vu Y3k8YnI+DQomZ3Q7IC0gZW1lcmdlbmN5LWNhbGxiYWNrPGJyPg0KJmd0OyAtIHBzYXAtY2FsbGJh Y2s8YnI+DQomZ3Q7IDxicj4NCiZndDsgQWxzbyBtZW50aW9uZWQgb25jZSB3ZXJlOjxicj4NCiZn dDsgLSBleHBlZGl0ZWQtZW1lcmdlbmN5PGJyPg0KJmd0OyAtIHVyZ2VudC1lbWVyZ2VuY3k8YnI+ DQomZ3Q7IC0gZW1lcmdlbmN5LW92ZXJyaWRlPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElmIEnigJl2 ZSBmb3Jnb3R0ZW4gb25lLCBwbGVhc2UgbGV0IG1lIGtub3cuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFNlbmQgeW91ciB2b3RlIHRvIHRoZSBlY3JpdCBsaXN0LiZuYnNwOyBUaGUgdm90aW5nIHdpbGwg Z28gdGhyb3VnaCAxODowMCAoUGFjaWZpYyksIG5leHQgRnJpZGF5LCA5LzIxLzIwMTIuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IC1yb2dlci48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBG cm9tOiA8YSBocmVmPSJtYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZyI+ZWNyaXQtYm91bmNl c0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnIj5t YWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBDaHJpc3RlciBI b2xtYmVyZzxicj4NCiZndDsgU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTIsIDIwMTIgNToz MiBBTTxicj4NCiZndDsgVG86IDxhIGhyZWY9Im1haWx0bzplY3JpdEBpZXRmLm9yZyI+ZWNyaXRA aWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBTdWJqZWN0OiBbRWNyaXRdIERyYWZ0IG5ldyB2ZXJzaW9u OiBkcmFmdC1pZXRmLWVjcml0LXBzYXAtY2FsbGJhY2stMDU8YnI+DQomZ3Q7IDxicj4NCiZndDsg SGksPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEnigJl2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBv ZiB0aGUgcHNhcC1jYWxsYmFjayBkcmFmdCwgZHVlIHRvIGV4cGlyYXRpb24gb2YgdGhlIHByZXZp b3VzIHZlcnNpb24uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZXJlIGFyZSBOTyBjaGFuZ2VzIGNv bXBhcmVkIHRvIHRoZSBwcmV2aW91cyB2ZXJzaW9uLjxicj4NCiZndDsgPGJyPg0KJmd0OyBPbmNl IEkgZ2V0IHNvbWUgZ3VpZGFuY2Ugb24gd2hlcmUgdG8gZGVmaW5lIHRoZSBuZXcgU0lQIFByaW9y aXR5IGhlYWRlciBmaWVsZCDigJxwc2FwLWNhbGxiYWNr4oCdIHZhbHVlLCBJIHdpbGwgZWl0aGVy IHVwZGF0ZSB0aGlzIGRyYWZ0IG9yIHN1Ym1pdCBhIHNlcGFyYXRlIG9uZSBpbiBTSVBDT1JFLjxi cj4NCiZndDsgPGJyPg0KJmd0OyBSZWdhcmRzLDxicj4NCiZndDsgPGJyPg0KJmd0OyBDaHJpc3Rl cjxicj4NCiZndDsgPGJyPg0KJmd0OyBDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgcHJpdmlsZWdlZCBhbmQvb3Ig Y29uZmlkZW50aWFsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBvciBy ZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyB0aGlzIG1lc3NhZ2UgdG8gdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgYW55IHJldmlldywgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0 aW9uDQogb3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gb3IgYW55IGF0dGFjaG1lbnQo cykgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNz YWdlIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGFuZCBk ZWxldGUgaXQgYW5kIGFsbCBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIgYW5kIG5ldHdv cmsuPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsgRWNyaXQgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWls dG86RWNyaXRAaWV0Zi5vcmciPkVjcml0QGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdCI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdDwvYT48YnI+DQo8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkVjcml0IG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9yZyI+RWNyaXRAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9l Y3JpdCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdDwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E42CCDDA6722744CB241677169E83656D6B534MISOUT7MSGUSR9IIT_-- From mlinsner@cisco.com Mon Sep 17 05:33:20 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D892421F84C9 for ; Mon, 17 Sep 2012 05:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVvHlE-Xa7aH for ; Mon, 17 Sep 2012 05:33:18 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5042821F85DA for ; Mon, 17 Sep 2012 05:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13299; q=dns/txt; s=iport; t=1347885198; x=1349094798; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=GrJPXhQ+0uDEz9i3tydRjghUSf2czQWtZAGOy/H7fJ0=; b=IliGOOOc8tlNvzjKTWUr6oNhc14B4vOcLmP6o24j0LylG81yN4n7lTjX Z9A1kBhsSOSgx41LNmJovuXdx6+GDCYfkVQM/U7vtn6RfUWgz2OCNMlYW ZcMJjixhDKgsAE50+bPKQfpiSNgNAFGMl0EjRPIr6nJnJFgoVR2JZY+cB M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAF4XV1CtJXG9/2dsb2JhbABEgku4YWmBB4IgAQEBAwESARoQQQ4IEQMBAQEoTQkIBhMih1gGmV6BKJ9KiyGGaAOIIYoQgzGFYIhYgWmDAg X-IronPort-AV: E=Sophos;i="4.80,435,1344211200"; d="scan'208,217";a="122304229" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 17 Sep 2012 12:33:17 +0000 Received: from [10.82.243.244] (rtp-vpn2-1012.cisco.com [10.82.243.244]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8HCXF56000970 for ; Mon, 17 Sep 2012 12:33:16 GMT User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Mon, 17 Sep 2012 08:33:15 -0400 From: Marc Linsner To: "ecrit@ietf.org" Message-ID: Thread-Topic: Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3430715596_31896" Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 12:33:21 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3430715596_31896 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable psap-callback From: Roger Marshall Date: Friday, September 14, 2012 5:37 PM To: "ecrit@ietf.org" Cc: Christer Holmberg , Marc Linsner Subject: RE: Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value > All: > We need to select a priority-value in order to move the ecrit-psap-callba= ck > draft forward. > =20 > Putting aside, for the moment, the questions of if/how/where the > priority-value token is defined (if a new value is required - e.g., wheth= er > RFC or Registry), we should be able to agree on the value itself. > =20 > We=B9ve seen some suggestions for a priority-value given on the list over t= he > last few weeks with no clear convergence. The value =B3emergency=B2 is alread= y > included in the RFC3261 definition, but some others have voiced a prefere= nce > to define a new priority-value, using other-priority =3D token. > =20 > Priority =3D "Priority" HCOLON priority-value > priority-value =3D "emergency" / "urgent" / "normal" > / "non-urgent" / other-priority > other-priority =3D token > =20 > We=B9ve seen a few mentioned on the list, now the chairs are calling to clo= se > the list of candidate values, and request the work group to vote their ch= oice. > =20 > Of the priority-values put out there on the list, we have the following > mentioned a few times: > - emergency > - emergency-callback > - psap-callback > =20 > Also mentioned once were: > - expedited-emergency > - urgent-emergency > - emergency-override > =20 > If I=B9ve forgotten one, please let me know. > =20 > Send your vote to the ecrit list. The voting will go through 18:00 (Paci= fic), > next Friday, 9/21/2012. > =20 > -roger. > =20 > =20 >=20 > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Christer Holmberg > Sent: Wednesday, September 12, 2012 5:32 AM > To: ecrit@ietf.org > Subject: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 > =20 > Hi, > =20 > I=B9ve submitted a new version of the psap-callback draft, due to expiratio= n of > the previous version. > =20 > There are NO changes compared to the previous version. > =20 > Once I get some guidance on where to define the new SIP Priority header f= ield > =B3psap-callback=B2 value, I will either update this draft or submit a separa= te > one in SIPCORE. > =20 > Regards, > =20 > Christer > CONFIDENTIALITY NOTICE: The information contained in this message may be > privileged and/or confidential. If you are not the intended recipient, or > responsible for delivering this message to the intended recipient, any re= view, > forwarding, dissemination, distribution or copying of this communication = or > any attachment(s) is strictly prohibited. If you have received this messa= ge in > error, please notify the sender immediately, and delete it and all attach= ments > from your computer and network. --B_3430715596_31896 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
psap-callback

=

From: Roger Marshal= l <RMarshall@telecomsys.com= >
Date: Friday, September 14, 2= 012 5:37 PM
To: "ecrit@ietf.org" <ecrit= @ietf.org>
Cc: Christer Hol= mberg <christer.holmberg@= ericsson.com>, Marc Linsner <m= linsner@cisco.com>
Subject: = RE: Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-= value

All:

We need to select a priority-value in order to move the ecrit-psap-callbac= k draft forward.

 

Putting aside, for the moment, the questions of if/how/where the= priority-value token is defined (if a new value is required - e.g., whether= RFC or Registry), we should be able to agree on the value itself.

 

We’ve se= en some suggestions for a priority-value given on the list over the last few= weeks with no clear convergence. The value “emergency” is alrea= dy included in the RFC3261 definition, but some others have voiced a preference to define a new priority-value, using other-priority =3D= token.

 

Priority  &n= bsp;        =3D  "Priority" HCOLON priority= -value

priority-value    =3D&n= bsp; "emergency" / "urgent" / "normal"

            &nb= sp;           / "non-urgent" / = other-priority

other-priority  &n= bsp; =3D  token

 

We’ve seen a few mentioned on the list, now the chairs are call= ing to close the list of candidate values, and request the work group to vot= e their choice.

 

Of the priority-values put out there on the list, we have the fol= lowing mentioned a few times:

- em= ergency

- emergency-callback

- psap-callback

<= span style=3D"color:#1F497D"> 

= Also mentioned once were:

<= p class=3D"MsoNormal">- expedited-emergency=

- urgent-emergency

- emergency-override

 

If I’ve forg= otten one, please let me know.

 

Send your vote to the ecrit list.  The voting= will go through 18:00 (Pacific), next Friday, 9/21/2012. 

 

-ro= ger.

<= o:p> 

=  

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Wednesday, September = 12, 2012 5:32 AM
To: ecrit@ietf.or= g
Subject: [Ecrit] Draft new version: draft-ietf-ecrit-psap-ca= llback-05

 <= /o:p>

Hi,

 

I’ve submitted a new version of the psap-callback draft, due to e= xpiration of the previous version.

&= nbsp;

There are NO changes compared to the pre= vious version.

 

Once I get some guidance on where to define the new SIP Prio= rity header field “psap-callback” value, I will either update th= is draft or submit a separate one in SIPCORE.

 

Regards,

 

Christer=

CONFIDENTIALIT= Y NOTICE: The information contained in this message may be privileged and/or= confidential. If you are not the intended recipient, or responsible for del= ivering this message to the intended recipient, any review, forwarding, diss= emination, distribution or copying of this communication or any attachment(s= ) is strictly prohibited. If you have received this message in error, please= notify the sender immediately, and delete it and all attachments from your = computer and network.

 --B_3430715596_31896-- From jmpolk@cisco.com Mon Sep 17 13:56:28 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AECA21E8047 for ; Mon, 17 Sep 2012 13:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aocaT+mrF9m for ; Mon, 17 Sep 2012 13:56:27 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 427CE21E803D for ; Mon, 17 Sep 2012 13:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3466; q=dns/txt; s=iport; t=1347915387; x=1349124987; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=BSfgPjnmgu0kvDZujHr8Ul9vQf2QNq2hleSeMcX8Iqo=; b=irjxA5Nj9CcoRHo8Bhwd7EBAYVRW+LjWyFAyOVSLQhxhGZe0TgQNlyAo hDoc4ondbVrYwPB18aYnDxblieBzerXtV3RY24uH4QblKLEA/BmiCXGf6 JBpyiAJBW3Ug8aRsECFZsAVTI7jvjyDpyANUBURkrbxpmonVNP68SmtMU A=; X-IronPort-AV: E=Sophos;i="4.80,438,1344211200"; d="scan'208";a="58566484" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 17 Sep 2012 20:56:25 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8HKuOgF000927; Mon, 17 Sep 2012 20:56:24 GMT Message-Id: <201209172056.q8HKuOgF000927@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 17 Sep 2012 15:56:23 -0500 To: Marc Linsner , "ecrit@ietf.org" From: James Polk In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 20:56:28 -0000 psap-callback is the logical choice to avoid confusion and not do any harm to other means of the use of "emergency" (that's a decade+ old already)... At 07:33 AM 9/17/2012, Marc Linsner wrote: >psap-callback > > >From: Roger Marshall ><RMarshall@telecomsys.com> >Date: Friday, September 14, 2012 5:37 PM >To: "ecrit@ietf.org" ><ecrit@ietf.org> >Cc: Christer Holmberg ><christer.holmberg@ericsson.com>, >Marc Linsner <mlinsner@cisco.com> >Subject: RE: Draft new version: draft-ietf-ecrit-psap-callback-05 - >select priority-value > >All: >We need to select a priority-value in order to move the >ecrit-psap-callback draft forward. > >Putting aside, for the moment, the questions of if/how/where the >priority-value token is defined (if a new value is required - e.g., >whether RFC or Registry), we should be able to agree on the value itself. > >We've seen some suggestions for a priority-value given on the list >over the last few weeks with no clear convergence. The value >"emergency" is already included in the RFC3261 definition, but some >others have voiced a preference to define a new priority-value, >using other-priority = token. > >Priority = "Priority" HCOLON priority-value >priority-value = "emergency" / "urgent" / "normal" > / "non-urgent" / other-priority >other-priority = token > >We've seen a few mentioned on the list, now the chairs are calling >to close the list of candidate values, and request the work group to >vote their choice. > >Of the priority-values put out there on the list, we have the >following mentioned a few times: >- emergency >- emergency-callback >- psap-callback > >Also mentioned once were: >- expedited-emergency >- urgent-emergency >- emergency-override > >If I've forgotten one, please let me know. > >Send your vote to the ecrit list. The voting will go through 18:00 >(Pacific), next Friday, 9/21/2012. > >-roger. > > >From: ecrit-bounces@ietf.org >[mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg >Sent: Wednesday, September 12, 2012 5:32 AM >To: ecrit@ietf.org >Subject: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 > >Hi, > >I've submitted a new version of the psap-callback draft, due to >expiration of the previous version. > >There are NO changes compared to the previous version. > >Once I get some guidance on where to define the new SIP Priority >header field "psap-callback" value, I will either update this draft >or submit a separate one in SIPCORE. > >Regards, > >Christer > >CONFIDENTIALITY NOTICE: The information contained in this message >may be privileged and/or confidential. If you are not the intended >recipient, or responsible for delivering this message to the >intended recipient, any review, forwarding, dissemination, >distribution or copying of this communication or any attachment(s) >is strictly prohibited. If you have received this message in error, >please notify the sender immediately, and delete it and all >attachments from your computer and network. > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From RMarshall@telecomsys.com Tue Sep 25 09:10:26 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B1F21F87F4 for ; Tue, 25 Sep 2012 09:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iYl6sDTK7CQ for ; Tue, 25 Sep 2012 09:10:23 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECF921F86D8 for ; Tue, 25 Sep 2012 09:10:22 -0700 (PDT) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-01.telecomsys.com (8.14.1/8.14.1) with ESMTP id q8PGAE15028939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 25 Sep 2012 09:10:14 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.103]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Tue, 25 Sep 2012 09:10:13 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value Thread-Index: AQHNksEdQ4PbjIc55kSNsSELX8EDTZebwFIQ Date: Tue, 25 Sep 2012 16:10:12 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC13A3ADSEAEXMB1telecomsy_" MIME-Version: 1.0 Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 16:10:26 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC13A3ADSEAEXMB1telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on the responses to my request for a priority-value, the vote totals = came in as: Existing value of "emergency" =3D 4 New value of "psap-callback" =3D 7 New value (other than existing) =3D 1 Since the "new value - other than existing" lines up with psap-callback, we= have "psap-callback" favored at a count of 8 to 4. These results are clear, and are based on what is posted to the current mai= l list. Therefore we should be able to move this draft forward. Thanks. -roger marshall. From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of R= oger Marshall Sent: Friday, September 14, 2012 2:37 PM To: ecrit@ietf.org Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 -= select priority-value All: We need to select a priority-value in order to move the ecrit-psap-callback= draft forward. Putting aside, for the moment, the questions of if/how/where the priority-v= alue token is defined (if a new value is required - e.g., whether RFC or Re= gistry), we should be able to agree on the value itself. We've seen some suggestions for a priority-value given on the list over the= last few weeks with no clear convergence. The value "emergency" is already= included in the RFC3261 definition, but some others have voiced a preferen= ce to define a new priority-value, using other-priority =3D token. Priority =3D "Priority" HCOLON priority-value priority-value =3D "emergency" / "urgent" / "normal" / "non-urgent" / other-priority other-priority =3D token We've seen a few mentioned on the list, now the chairs are calling to close= the list of candidate values, and request the work group to vote their cho= ice. Of the priority-values put out there on the list, we have the following men= tioned a few times: - emergency - emergency-callback - psap-callback Also mentioned once were: - expedited-emergency - urgent-emergency - emergency-override If I've forgotten one, please let me know. Send your vote to the ecrit list. The voting will go through 18:00 (Pacifi= c), next Friday, 9/21/2012. -roger. From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Christer Holmberg Sent: Wednesday, September 12, 2012 5:32 AM To: ecrit@ietf.org Subject: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 Hi, I've submitted a new version of the psap-callback draft, due to expiration = of the previous version. There are NO changes compared to the previous version. Once I get some guidance on where to define the new SIP Priority header fie= ld "psap-callback" value, I will either update this draft or submit a separ= ate one in SIPCORE. Regards, Christer CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC13A3ADSEAEXMB1telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Based on the responses= to my request for a priority-value, the vote totals came in as:=

 

Existing value of R= 20;emergency” =3D 4

New value of “ps= ap-callback” =3D 7

New value (other than = existing) =3D 1

 

Since the “new v= alue – other than existing” lines up with psap-callback, we hav= e “psap-callback” favored at a count of 8 to 4.

 

These results are clea= r, and are based on what is posted to the current mail list.  Therefor= e we should be able to move this draft forward.

 

Thanks.

 

-roger marshall.<= /o:p>

 

 

 

From: ecrit-bo= unces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall
Sent: Friday, September 14, 2012 2:37 PM
To: ecrit@ietf.org
Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callba= ck-05 - select priority-value

 

All:=

We need to select a pr= iority-value in order to move the ecrit-psap-callback draft forward.

 

Putting aside, for the= moment, the questions of if/how/where the priority-value token is defined = (if a new value is required - e.g., whether RFC or Registry), we should be = able to agree on the value itself.

 

We’ve seen some = suggestions for a priority-value given on the list over the last few weeks = with no clear convergence. The value “emergency” is already inc= luded in the RFC3261 definition, but some others have voiced a preference to define a new priority-value, using other-priority = =3D token.

 

Priority       &nbs= p;   =3D  "Priority" HCOLON priority-value

priority-value    =3D  "emerg= ency" / "urgent" / "normal"

        &= nbsp;            &nb= sp;  / "non-urgent" / other-priority

other-priority    =3D  token<= /o:p>

 

We’ve seen a few= mentioned on the list, now the chairs are calling to close the list of can= didate values, and request the work group to vote their choice.<= /span>

 

Of the priority-values= put out there on the list, we have the following mentioned a few times:

- emergency=

- emergency-callback

- psap-callback

 

Also mentioned once we= re:

- expedited-eme= rgency

- urgent-emergency

- emergency-override

 

If I’ve forgotte= n one, please let me know.

 

Send your vote to the = ecrit list.  The voting will go through 18:00 (Pacific), next Friday, = 9/21/2012. 

 

-roger.

 

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Wednesday, September 12, 2012 5:32 AM
To: ecrit@ietf.org
Subject: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-0= 5

 

Hi,

 

I’ve submitted a new version of the psap-callb= ack draft, due to expiration of the previous version.

 

There are NO changes compared to the previous versio= n.

 

Once I get some guidance on where to define the new = SIP Priority header field “psap-callback” value, I will either = update this draft or submit a separate one in SIPCORE.

 

Regards,

 

Christer

CONFIDENTIALITY NOTICE: The information contained in this mess= age may be privileged and/or confidential. If you are not the intended reci= pient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or= copying of this communication or any attachment(s) is strictly prohibited.= If you have received this message in error, please notify the sender immed= iately, and delete it and all attachments from your computer and network.

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC13A3ADSEAEXMB1telecomsy_-- From christer.holmberg@ericsson.com Wed Sep 26 02:51:24 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3129C21F87BD for ; Wed, 26 Sep 2012 02:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.135 X-Spam-Level: X-Spam-Status: No, score=-6.135 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IuBbxtEgJIy for ; Wed, 26 Sep 2012 02:51:21 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A01D021F87C5 for ; Wed, 26 Sep 2012 02:51:20 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-aa-5062d017b7f2 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 59.80.25676.710D2605; Wed, 26 Sep 2012 11:51:19 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Wed, 26 Sep 2012 11:51:09 +0200 From: Christer Holmberg To: Roger Marshall , "ecrit@ietf.org" Date: Wed, 26 Sep 2012 11:51:07 +0200 Thread-Topic: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value Thread-Index: AQHNksEdQ4PbjIc55kSNsSELX8EDTZebwFIQgACxkGA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM+Jvra74haQAg9M/NC0aFz1ltTh8dSmT A5PHkiU/mTw2bD3FHMAUxWWTkpqTWZZapG+XwJWx8EoPU8GuLsaKrR0f2BsYN1V1MXJySAiY SKzf0sMOYYtJXLi3nq2LkYtDSOAUo8SGd93MEM4CRom/e94DVXFwsAlYSHT/0wYxRQSCJM7d tAHpZRFQlZi08jMLiC0skCxx5G8bmC0ikCLx7e0VVgjbSqL91QomEJtXIFxi34fpUOMfMkp8 64Fo5hTwl7j34y8biM0IdND3U2vAGpgFxCVuPZnPBHGogMSSPeeZIWxRiZeP/7FC1ItK3Glf zwhRny9xYv4ZdohlghInZz5hmcAoMgvJqFlIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMm ZPEFjOyrGIVzEzNz0suN9FKLMpOLi/Pz9IpTNzECo+rglt+qOxjvnBM5xCjNwaIkzmu9dY+/ kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBka/2DX/Y6V9ih5eV1IIeGrjc+yUgfO1wN/mJYYM bovPhl/nuKGd4KB/k9Fe4HiDj/POF8/dp8y/Od3/yl93J9ncliDPbz7Gk4/N48uOtLzoP1Wk 7tmmtDMfmfatbrfZ1e2TvffF4fXz5VOWB6ssutP2nivv6MdPO5+W1Xcb7fT1nP3TQOTq0slK LMUZiYZazEXFiQCqXIQieAIAAA== Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 09:51:24 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Roger! We intend to submit a new version of the callback draft, with text defining= the new value. But, I guess we should also verify with the ADs/SIPCORE chairs that it is o= k to define the new value in ECRIT. Regards, Christer From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of R= oger Marshall Sent: 25. syyskuuta 2012 19:10 To: ecrit@ietf.org Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 -= select priority-value Based on the responses to my request for a priority-value, the vote totals = came in as: Existing value of "emergency" =3D 4 New value of "psap-callback" =3D 7 New value (other than existing) =3D 1 Since the "new value - other than existing" lines up with psap-callback, we= have "psap-callback" favored at a count of 8 to 4. These results are clear, and are based on what is posted to the current mai= l list. Therefore we should be able to move this draft forward. Thanks. -roger marshall. From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Roger= Marshall Sent: Friday, September 14, 2012 2:37 PM To: ecrit@ietf.org Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 -= select priority-value All: We need to select a priority-value in order to move the ecrit-psap-callback= draft forward. Putting aside, for the moment, the questions of if/how/where the priority-v= alue token is defined (if a new value is required - e.g., whether RFC or Re= gistry), we should be able to agree on the value itself. We've seen some suggestions for a priority-value given on the list over the= last few weeks with no clear convergence. The value "emergency" is already= included in the RFC3261 definition, but some others have voiced a preferen= ce to define a new priority-value, using other-priority =3D token. Priority =3D "Priority" HCOLON priority-value priority-value =3D "emergency" / "urgent" / "normal" / "non-urgent" / other-priority other-priority =3D token We've seen a few mentioned on the list, now the chairs are calling to close= the list of candidate values, and request the work group to vote their cho= ice. Of the priority-values put out there on the list, we have the following men= tioned a few times: - emergency - emergency-callback - psap-callback Also mentioned once were: - expedited-emergency - urgent-emergency - emergency-override If I've forgotten one, please let me know. Send your vote to the ecrit list. The voting will go through 18:00 (Pacifi= c), next Friday, 9/21/2012. -roger. From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Christer Holmberg Sent: Wednesday, September 12, 2012 5:32 AM To: ecrit@ietf.org Subject: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 Hi, I've submitted a new version of the psap-callback draft, due to expiration = of the previous version. There are NO changes compared to the previous version. Once I get some guidance on where to define the new SIP Priority header fie= ld "psap-callback" value, I will either update this draft or submit a separ= ate one in SIPCORE. Regards, Christer CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks, Roger!

 

= We intend to submit a new version of the call= back draft, with text defining the new value.

 

But, I guess we should also = verify with the ADs/SIPCORE chairs that it is ok to define the new value in= ECRIT.

 

Regards,

 

Christer

 

<= span style=3D'color:#1F497D'> 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]= On Behalf Of Roger Marshall
Sent: 25. syyskuuta 2012 19:1= 0
To: ecrit@ietf.org
Subject: Re: [Ecrit] Draft new ver= sion: draft-ietf-ecrit-psap-callback-05 - select priority-value<= /span>

 

Based on the responses to my reques= t for a priority-value, the vote totals came in as:

 

Existing value of R= 20;emergency” =3D 4

New value of “psap-callback” =3D 7<= /o:p>

New valu= e (other than existing) =3D 1

 

Since the “new value – other tha= n existing” lines up with psap-callback, we have “psap-callback= ” favored at a count of 8 to 4.

 

These results are clear, and are bas= ed on what is posted to the current mail list.  Therefore we should be= able to move this draft forward.

 

Thanks.

 

-roger marshall.

 =

 

&nbs= p;

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behal= f Of Roger Marshall
Sent: Friday, September 14, 2012 2:37 PM<= br>To: ecrit@ietf.org
Su= bject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05= - select priority-value

 

All:

We need to select a priority-value in order to move the ecrit-psap-callb= ack draft forward.

 

Putting aside, for the moment, the questions of if/how/= where the priority-value token is defined (if a new value is required - e.g= ., whether RFC or Registry), we should be able to agree on the value itself= .

<= o:p> 

We’ve seen some suggestions for a priority-value given on the list= over the last few weeks with no clear convergence. The value “emerge= ncy” is already included in the RFC3261 definition, but some others h= ave voiced a preference to define a new priority-value, using other-priorit= y =3D token.

 

Priority = ;          =3D  "Priority= " HCOLON priority-value

priority= -value    =3D  "emergency" / "urgent" / = "normal"

   =             &nb= sp;        / "non-urgent" / other-p= riority

other-priority    = =3D  token

 

We’ve seen a few mentioned on the list, now the chairs are = calling to close the list of candidate values, and request the work group t= o vote their choice.

 

Of the priority-values put out there on the list, we= have the following mentioned a few times:

- emergency

- emergency-callback

- psa= p-callback

 

Also mentioned once were:

- expedited-emergency<= /p>

- urgent-emergency

- emergency-override

=

 =

If I’ve forgot= ten one, please let me know.

 

= Send your vote to the ecrit list.  The v= oting will go through 18:00 (Pacific), next Friday, 9/21/2012.  <= /o:p>

&nb= sp;

-rog= er.

 

 

 <= /o:p>

Hi,

 

I’ve submitted a new version of the psap-callback draft, due t= o expiration of the previous version.

 

There are NO changes compared to th= e previous version.

 

Once I get some guidance on where to define the new S= IP Priority header field “psap-callback” value, I will either u= pdate this draft or submit a separate one in SIPCORE.

 

Regards,=

 

Christer=

CONFIDENTIALITY NOTICE: The information contained in this message m= ay be privileged and/or confidential. If you are not the intended recipient= , or responsible for delivering this message to the intended recipient, any= review, forwarding, dissemination, distribution or copying of this communi= cation or any attachment(s) is strictly prohibited. If you have received th= is message in error, please notify the sender immediately, and delete it an= d all attachments from your computer and network.

= --_000_7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22ESESSCMS0356e_-- From pkyzivat@alum.mit.edu Wed Sep 26 08:25:10 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1753021F8417 for ; Wed, 26 Sep 2012 08:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToDz-7g5IT1T for ; Wed, 26 Sep 2012 08:25:09 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 9530521F8697 for ; Wed, 26 Sep 2012 08:25:07 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta15.westchester.pa.mail.comcast.net with comcast id 3n1D1k0090cZkys5FrRYN3; Wed, 26 Sep 2012 15:25:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id 3rL51k01P3ZTu2S3WrL6QN; Wed, 26 Sep 2012 15:20:06 +0000 Message-ID: <50631D26.70609@alum.mit.edu> Date: Wed, 26 Sep 2012 11:20:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: ecrit@ietf.org, "rai-ads@tools.ietf.org" , "sipcore-chairs@tools.ietf.org" References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 15:25:10 -0000 On 9/26/12 5:51 AM, Christer Holmberg wrote: > Thanks, Roger! > > We intend to submit a new version of the callback draft, with text > defining the new value. > > But, I guess we should also verify with the ADs/SIPCORE chairs that it > is ok to define the new value in ECRIT. I will defer to the ADs, but it seems to me that it should be sufficient to: - In this draft, do all the IANA considerations necessary to set up the new registry and register all the initial values, including all those defined in 3261 and the new one for this draft. - Advertise this draft (with the above) on the sipcore list. - Do a WGLC in both ECRIT and SIPCORE. Thanks, Paul > Regards, > > Christer > > *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf > Of *Roger Marshall > *Sent:* 25. syyskuuta 2012 19:10 > *To:* ecrit@ietf.org > *Subject:* Re: [Ecrit] Draft new version: > draft-ietf-ecrit-psap-callback-05 - select priority-value > > Based on the responses to my request for a priority-value, the vote > totals came in as: > > Existing value of “emergency” = 4 > > New value of “psap-callback” = 7 > > New value (other than existing) = 1 > > Since the “new value – other than existing” lines up with psap-callback, > we have “psap-callback” favored at a count of 8 to 4. > > These results are clear, and are based on what is posted to the current > mail list. Therefore we should be able to move this draft forward. > > Thanks. > > -roger marshall. > > *From:*ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] > *On Behalf Of *Roger Marshall > *Sent:* Friday, September 14, 2012 2:37 PM > *To:* ecrit@ietf.org > *Subject:* Re: [Ecrit] Draft new version: > draft-ietf-ecrit-psap-callback-05 - select priority-value > > All: > > We need to select a priority-value in order to move the > ecrit-psap-callback draft forward. > > Putting aside, for the moment, the questions of if/how/where the > priority-value token is defined (if a new value is required - e.g., > whether RFC or Registry), we should be able to agree on the value itself. > > We’ve seen some suggestions for a priority-value given on the list over > the last few weeks with no clear convergence. The value “emergency” is > already included in the RFC3261 definition, but some others have voiced > a preference to define a new priority-value, using other-priority = token. > > Priority = "Priority" HCOLON priority-value > > priority-value = "emergency" / "urgent" / "normal" > > / "non-urgent" / other-priority > > other-priority = token > > We’ve seen a few mentioned on the list, now the chairs are calling to > close the list of candidate values, and request the work group to vote > their choice. > > Of the priority-values put out there on the list, we have the following > mentioned a few times: > > - emergency > > - emergency-callback > > - psap-callback > > Also mentioned once were: > > - expedited-emergency > > - urgent-emergency > > - emergency-override > > If I’ve forgotten one, please let me know. > > Send your vote to the ecrit list. The voting will go through 18:00 > (Pacific), next Friday, 9/21/2012. > > -roger. > > *From:*ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] *On Behalf Of *Christer Holmberg > *Sent:* Wednesday, September 12, 2012 5:32 AM > *To:* ecrit@ietf.org > *Subject:* [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 > > Hi, > > I’ve submitted a new version of the psap-callback draft, due to > expiration of the previous version. > > There are NO changes compared to the previous version. > > Once I get some guidance on where to define the new SIP Priority header > field “psap-callback” value, I will either update this draft or submit a > separate one in SIPCORE. > > Regards, > > Christer > > CONFIDENTIALITY NOTICE: The information contained in this message may be > privileged and/or confidential. If you are not the intended recipient, > or responsible for delivering this message to the intended recipient, > any review, forwarding, dissemination, distribution or copying of this > communication or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender immediately, > and delete it and all attachments from your computer and network. > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From brian.rosen@neustar.biz Wed Sep 26 09:36:04 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B227C21F856D for ; Wed, 26 Sep 2012 09:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.408 X-Spam-Level: X-Spam-Status: No, score=-6.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0W3LQpPBdtD for ; Wed, 26 Sep 2012 09:36:04 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 9C72721F8504 for ; Wed, 26 Sep 2012 09:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1348677140; x=1664035403; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=2auNvm/trU5Axgrur3sqs 7SB91NcVKeU2Sop/n6dqkA=; b=KcVQ5W+cJkZpMllpRM+FBnHgIP5uv8zDMn9JY lFMNlC+4omadAXaggMCAeoI3CKQvGow14GSlQiNr8m+5QyLDg== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.11571610; Wed, 26 Sep 2012 12:32:18 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::28fd:d8c6:49f0:619b]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Wed, 26 Sep 2012 12:35:49 -0400 From: "Rosen, Brian" To: Paul Kyzivat Date: Wed, 26 Sep 2012 12:35:48 -0400 Thread-Topic: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value Thread-Index: Ac2cBPvwc+PxC3AESMWTmDdzxLS6hw== Message-ID: <35047045-145A-4FF7-B69C-7B5182E9DCB5@neustar.biz> References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22@ESESSCMS0356.eemea.ericsson.se> <50631D26.70609@alum.mit.edu> In-Reply-To: <50631D26.70609@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: EbP3/JnzAg/RiyLeCyDFgg== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore-chairs@tools.ietf.org" , "rai-ads@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 16:36:04 -0000 Are we updating 3261? That's an AD/chair (with sipcore chairs I think) call, right? I'm okay either way -- it's not clear to me it changes 3261 in any way. I'= d want sipcore to review of course, but not clear we need to update 3261. Brian On Sep 26, 2012, at 11:20 AM, Paul Kyzivat wrote: > On 9/26/12 5:51 AM, Christer Holmberg wrote: >> Thanks, Roger! >>=20 >> We intend to submit a new version of the callback draft, with text >> defining the new value. >>=20 >> But, I guess we should also verify with the ADs/SIPCORE chairs that it >> is ok to define the new value in ECRIT. >=20 > I will defer to the ADs, but it seems to me that it should be sufficient = to: >=20 > - In this draft, do all the IANA considerations necessary to set up the > new registry and register all the initial values, including all those > defined in 3261 and the new one for this draft. >=20 > - Advertise this draft (with the above) on the sipcore list. >=20 > - Do a WGLC in both ECRIT and SIPCORE. >=20 > Thanks, > Paul >=20 >> Regards, >>=20 >> Christer >>=20 >> *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf >> Of *Roger Marshall >> *Sent:* 25. syyskuuta 2012 19:10 >> *To:* ecrit@ietf.org >> *Subject:* Re: [Ecrit] Draft new version: >> draft-ietf-ecrit-psap-callback-05 - select priority-value >>=20 >> Based on the responses to my request for a priority-value, the vote >> totals came in as: >>=20 >> Existing value of =93emergency=94 =3D 4 >>=20 >> New value of =93psap-callback=94 =3D 7 >>=20 >> New value (other than existing) =3D 1 >>=20 >> Since the =93new value =96 other than existing=94 lines up with psap-cal= lback, >> we have =93psap-callback=94 favored at a count of 8 to 4. >>=20 >> These results are clear, and are based on what is posted to the current >> mail list. Therefore we should be able to move this draft forward. >>=20 >> Thanks. >>=20 >> -roger marshall. >>=20 >> *From:*ecrit-bounces@ietf.org >> [mailto:ecrit-bounces@ietf.org] >> *On Behalf Of *Roger Marshall >> *Sent:* Friday, September 14, 2012 2:37 PM >> *To:* ecrit@ietf.org >> *Subject:* Re: [Ecrit] Draft new version: >> draft-ietf-ecrit-psap-callback-05 - select priority-value >>=20 >> All: >>=20 >> We need to select a priority-value in order to move the >> ecrit-psap-callback draft forward. >>=20 >> Putting aside, for the moment, the questions of if/how/where the >> priority-value token is defined (if a new value is required - e.g., >> whether RFC or Registry), we should be able to agree on the value itself= . >>=20 >> We=92ve seen some suggestions for a priority-value given on the list ove= r >> the last few weeks with no clear convergence. The value =93emergency=94 = is >> already included in the RFC3261 definition, but some others have voiced >> a preference to define a new priority-value, using other-priority =3D to= ken. >>=20 >> Priority =3D "Priority" HCOLON priority-value >>=20 >> priority-value =3D "emergency" / "urgent" / "normal" >>=20 >> / "non-urgent" / other-priority >>=20 >> other-priority =3D token >>=20 >> We=92ve seen a few mentioned on the list, now the chairs are calling to >> close the list of candidate values, and request the work group to vote >> their choice. >>=20 >> Of the priority-values put out there on the list, we have the following >> mentioned a few times: >>=20 >> - emergency >>=20 >> - emergency-callback >>=20 >> - psap-callback >>=20 >> Also mentioned once were: >>=20 >> - expedited-emergency >>=20 >> - urgent-emergency >>=20 >> - emergency-override >>=20 >> If I=92ve forgotten one, please let me know. >>=20 >> Send your vote to the ecrit list. The voting will go through 18:00 >> (Pacific), next Friday, 9/21/2012. >>=20 >> -roger. >>=20 >> *From:*ecrit-bounces@ietf.org >> [mailto:ecrit-bounces@ietf.org] *On Behalf Of *Christer Holmberg >> *Sent:* Wednesday, September 12, 2012 5:32 AM >> *To:* ecrit@ietf.org >> *Subject:* [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 >>=20 >> Hi, >>=20 >> I=92ve submitted a new version of the psap-callback draft, due to >> expiration of the previous version. >>=20 >> There are NO changes compared to the previous version. >>=20 >> Once I get some guidance on where to define the new SIP Priority header >> field =93psap-callback=94 value, I will either update this draft or subm= it a >> separate one in SIPCORE. >>=20 >> Regards, >>=20 >> Christer >>=20 >> CONFIDENTIALITY NOTICE: The information contained in this message may be >> privileged and/or confidential. If you are not the intended recipient, >> or responsible for delivering this message to the intended recipient, >> any review, forwarding, dissemination, distribution or copying of this >> communication or any attachment(s) is strictly prohibited. If you have >> received this message in error, please notify the sender immediately, >> and delete it and all attachments from your computer and network. >>=20 >>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@gmx.net Wed Sep 26 09:57:56 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0751E21F85A1 for ; Wed, 26 Sep 2012 09:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuywuwoBLONg for ; Wed, 26 Sep 2012 09:57:55 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D873C21F85A0 for ; Wed, 26 Sep 2012 09:57:54 -0700 (PDT) Received: (qmail invoked by alias); 26 Sep 2012 16:57:53 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.102]) [88.115.216.191] by mail.gmx.net (mp032) with SMTP; 26 Sep 2012 18:57:53 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+xgwok5HOxQzY1PcB96I4DyoRCGSSdc+T6mRqLBd UxrlrW2H+KyYo7 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Hannes Tschofenig In-Reply-To: <35047045-145A-4FF7-B69C-7B5182E9DCB5@neustar.biz> Date: Wed, 26 Sep 2012 19:57:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <15AA7501-47C7-4FFB-B822-B47C3A6D8AB8@gmx.net> References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22@ESESSCMS0356.eemea.ericsson.se> <50631D26.70609@alum.mit.edu> <35047045-145A-4FF7-B69C-7B5182E9DCB5@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "rai-ads@tools.ietf.org" , "sipcore-chairs@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 16:57:56 -0000 We are adding a new value to the Priority header field. I looked at RFC = 3261 and at RFC 2076 but there was no guidance on how new values are = registered. There isn't even a registry for it. On Sep 26, 2012, at 7:35 PM, Rosen, Brian wrote: > Are we updating 3261? >=20 > That's an AD/chair (with sipcore chairs I think) call, right? >=20 > I'm okay either way -- it's not clear to me it changes 3261 in any = way. I'd want sipcore to review of course, but not clear we need to = update 3261. >=20 > Brian >=20 > On Sep 26, 2012, at 11:20 AM, Paul Kyzivat = wrote: >=20 >> On 9/26/12 5:51 AM, Christer Holmberg wrote: >>> Thanks, Roger! >>>=20 >>> We intend to submit a new version of the callback draft, with text >>> defining the new value. >>>=20 >>> But, I guess we should also verify with the ADs/SIPCORE chairs that = it >>> is ok to define the new value in ECRIT. >>=20 >> I will defer to the ADs, but it seems to me that it should be = sufficient to: >>=20 >> - In this draft, do all the IANA considerations necessary to set up = the >> new registry and register all the initial values, including all those >> defined in 3261 and the new one for this draft. >>=20 >> - Advertise this draft (with the above) on the sipcore list. >>=20 >> - Do a WGLC in both ECRIT and SIPCORE. >>=20 >> Thanks, >> Paul >>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On = Behalf >>> Of *Roger Marshall >>> *Sent:* 25. syyskuuta 2012 19:10 >>> *To:* ecrit@ietf.org >>> *Subject:* Re: [Ecrit] Draft new version: >>> draft-ietf-ecrit-psap-callback-05 - select priority-value >>>=20 >>> Based on the responses to my request for a priority-value, the vote >>> totals came in as: >>>=20 >>> Existing value of =93emergency=94 =3D 4 >>>=20 >>> New value of =93psap-callback=94 =3D 7 >>>=20 >>> New value (other than existing) =3D 1 >>>=20 >>> Since the =93new value =96 other than existing=94 lines up with = psap-callback, >>> we have =93psap-callback=94 favored at a count of 8 to 4. >>>=20 >>> These results are clear, and are based on what is posted to the = current >>> mail list. Therefore we should be able to move this draft forward. >>>=20 >>> Thanks. >>>=20 >>> -roger marshall. >>>=20 >>> *From:*ecrit-bounces@ietf.org >>> [mailto:ecrit-bounces@ietf.org] = >>> *On Behalf Of *Roger Marshall >>> *Sent:* Friday, September 14, 2012 2:37 PM >>> *To:* ecrit@ietf.org >>> *Subject:* Re: [Ecrit] Draft new version: >>> draft-ietf-ecrit-psap-callback-05 - select priority-value >>>=20 >>> All: >>>=20 >>> We need to select a priority-value in order to move the >>> ecrit-psap-callback draft forward. >>>=20 >>> Putting aside, for the moment, the questions of if/how/where the >>> priority-value token is defined (if a new value is required - e.g., >>> whether RFC or Registry), we should be able to agree on the value = itself. >>>=20 >>> We=92ve seen some suggestions for a priority-value given on the list = over >>> the last few weeks with no clear convergence. The value =93emergency=94= is >>> already included in the RFC3261 definition, but some others have = voiced >>> a preference to define a new priority-value, using other-priority =3D = token. >>>=20 >>> Priority =3D "Priority" HCOLON priority-value >>>=20 >>> priority-value =3D "emergency" / "urgent" / "normal" >>>=20 >>> / "non-urgent" / other-priority >>>=20 >>> other-priority =3D token >>>=20 >>> We=92ve seen a few mentioned on the list, now the chairs are calling = to >>> close the list of candidate values, and request the work group to = vote >>> their choice. >>>=20 >>> Of the priority-values put out there on the list, we have the = following >>> mentioned a few times: >>>=20 >>> - emergency >>>=20 >>> - emergency-callback >>>=20 >>> - psap-callback >>>=20 >>> Also mentioned once were: >>>=20 >>> - expedited-emergency >>>=20 >>> - urgent-emergency >>>=20 >>> - emergency-override >>>=20 >>> If I=92ve forgotten one, please let me know. >>>=20 >>> Send your vote to the ecrit list. The voting will go through 18:00 >>> (Pacific), next Friday, 9/21/2012. >>>=20 >>> -roger. >>>=20 >>> *From:*ecrit-bounces@ietf.org >>> [mailto:ecrit-bounces@ietf.org] *On Behalf Of *Christer Holmberg >>> *Sent:* Wednesday, September 12, 2012 5:32 AM >>> *To:* ecrit@ietf.org >>> *Subject:* [Ecrit] Draft new version: = draft-ietf-ecrit-psap-callback-05 >>>=20 >>> Hi, >>>=20 >>> I=92ve submitted a new version of the psap-callback draft, due to >>> expiration of the previous version. >>>=20 >>> There are NO changes compared to the previous version. >>>=20 >>> Once I get some guidance on where to define the new SIP Priority = header >>> field =93psap-callback=94 value, I will either update this draft or = submit a >>> separate one in SIPCORE. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> CONFIDENTIALITY NOTICE: The information contained in this message = may be >>> privileged and/or confidential. If you are not the intended = recipient, >>> or responsible for delivering this message to the intended = recipient, >>> any review, forwarding, dissemination, distribution or copying of = this >>> communication or any attachment(s) is strictly prohibited. If you = have >>> received this message in error, please notify the sender = immediately, >>> and delete it and all attachments from your computer and network. >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From brian.rosen@neustar.biz Wed Sep 26 10:31:01 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA56721F85BB for ; Wed, 26 Sep 2012 10:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.419 X-Spam-Level: X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGfJYLji5398 for ; Wed, 26 Sep 2012 10:31:00 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id D5B5421F85A0 for ; Wed, 26 Sep 2012 10:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1348680943; x=1664034142; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=qJR5Mr/Xhcdk3Muz4wm9C u8J04q6gYh0Htf2wdEOU/I=; b=OArCrsw4XaMPabGVTBTN4Kup8VPHXyZczauLv hFd4AYP+QB4EkDmRw2esgyOO4dAL1SUDg+fCmM4bm5JG4eUdQ== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.14741358; Wed, 26 Sep 2012 13:35:42 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::28fd:d8c6:49f0:619b]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Wed, 26 Sep 2012 13:30:45 -0400 From: "Rosen, Brian" To: Hannes Tschofenig Date: Wed, 26 Sep 2012 13:30:44 -0400 Thread-Topic: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value Thread-Index: Ac2cDKju35FJRHk2S4OF5Je1GPDJpA== Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22@ESESSCMS0356.eemea.ericsson.se> <50631D26.70609@alum.mit.edu> <35047045-145A-4FF7-B69C-7B5182E9DCB5@neustar.biz> <15AA7501-47C7-4FFB-B822-B47C3A6D8AB8@gmx.net> In-Reply-To: <15AA7501-47C7-4FFB-B822-B47C3A6D8AB8@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: ACH2/2sRpAZLpcT2sHV6Ew== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore-chairs@tools.ietf.org" , "Rosen, Brian" , "rai-ads@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 17:31:01 -0000 I think the plan is to add a registry in this document. I think that doing that (adding the registry) could give rise to some conce= rn that we were updating 3261, but I personally don't think we are. The re= vised version of this document, which defines the registry, isn't going to = say any value in the header has to be in the registry. That WOULD be an up= date to 3261. The registry is informational, I think. Brian On Sep 26, 2012, at 12:57 PM, Hannes Tschofenig = wrote: > We are adding a new value to the Priority header field. I looked at RFC 3= 261 and at RFC 2076 but there was no guidance on how new values are registe= red. There isn't even a registry for it. >=20 > On Sep 26, 2012, at 7:35 PM, Rosen, Brian wrote: >=20 >> Are we updating 3261? >>=20 >> That's an AD/chair (with sipcore chairs I think) call, right? >>=20 >> I'm okay either way -- it's not clear to me it changes 3261 in any way. = I'd want sipcore to review of course, but not clear we need to update 3261= . >>=20 >> Brian >>=20 >> On Sep 26, 2012, at 11:20 AM, Paul Kyzivat wrote= : >>=20 >>> On 9/26/12 5:51 AM, Christer Holmberg wrote: >>>> Thanks, Roger! >>>>=20 >>>> We intend to submit a new version of the callback draft, with text >>>> defining the new value. >>>>=20 >>>> But, I guess we should also verify with the ADs/SIPCORE chairs that it >>>> is ok to define the new value in ECRIT. >>>=20 >>> I will defer to the ADs, but it seems to me that it should be sufficien= t to: >>>=20 >>> - In this draft, do all the IANA considerations necessary to set up the >>> new registry and register all the initial values, including all those >>> defined in 3261 and the new one for this draft. >>>=20 >>> - Advertise this draft (with the above) on the sipcore list. >>>=20 >>> - Do a WGLC in both ECRIT and SIPCORE. >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>> *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Beha= lf >>>> Of *Roger Marshall >>>> *Sent:* 25. syyskuuta 2012 19:10 >>>> *To:* ecrit@ietf.org >>>> *Subject:* Re: [Ecrit] Draft new version: >>>> draft-ietf-ecrit-psap-callback-05 - select priority-value >>>>=20 >>>> Based on the responses to my request for a priority-value, the vote >>>> totals came in as: >>>>=20 >>>> Existing value of =93emergency=94 =3D 4 >>>>=20 >>>> New value of =93psap-callback=94 =3D 7 >>>>=20 >>>> New value (other than existing) =3D 1 >>>>=20 >>>> Since the =93new value =96 other than existing=94 lines up with psap-c= allback, >>>> we have =93psap-callback=94 favored at a count of 8 to 4. >>>>=20 >>>> These results are clear, and are based on what is posted to the curren= t >>>> mail list. Therefore we should be able to move this draft forward. >>>>=20 >>>> Thanks. >>>>=20 >>>> -roger marshall. >>>>=20 >>>> *From:*ecrit-bounces@ietf.org >>>> [mailto:ecrit-bounces@ietf.org] >>>> *On Behalf Of *Roger Marshall >>>> *Sent:* Friday, September 14, 2012 2:37 PM >>>> *To:* ecrit@ietf.org >>>> *Subject:* Re: [Ecrit] Draft new version: >>>> draft-ietf-ecrit-psap-callback-05 - select priority-value >>>>=20 >>>> All: >>>>=20 >>>> We need to select a priority-value in order to move the >>>> ecrit-psap-callback draft forward. >>>>=20 >>>> Putting aside, for the moment, the questions of if/how/where the >>>> priority-value token is defined (if a new value is required - e.g., >>>> whether RFC or Registry), we should be able to agree on the value itse= lf. >>>>=20 >>>> We=92ve seen some suggestions for a priority-value given on the list o= ver >>>> the last few weeks with no clear convergence. The value =93emergency= =94 is >>>> already included in the RFC3261 definition, but some others have voice= d >>>> a preference to define a new priority-value, using other-priority =3D = token. >>>>=20 >>>> Priority =3D "Priority" HCOLON priority-value >>>>=20 >>>> priority-value =3D "emergency" / "urgent" / "normal" >>>>=20 >>>> / "non-urgent" / other-priority >>>>=20 >>>> other-priority =3D token >>>>=20 >>>> We=92ve seen a few mentioned on the list, now the chairs are calling t= o >>>> close the list of candidate values, and request the work group to vote >>>> their choice. >>>>=20 >>>> Of the priority-values put out there on the list, we have the followin= g >>>> mentioned a few times: >>>>=20 >>>> - emergency >>>>=20 >>>> - emergency-callback >>>>=20 >>>> - psap-callback >>>>=20 >>>> Also mentioned once were: >>>>=20 >>>> - expedited-emergency >>>>=20 >>>> - urgent-emergency >>>>=20 >>>> - emergency-override >>>>=20 >>>> If I=92ve forgotten one, please let me know. >>>>=20 >>>> Send your vote to the ecrit list. The voting will go through 18:00 >>>> (Pacific), next Friday, 9/21/2012. >>>>=20 >>>> -roger. >>>>=20 >>>> *From:*ecrit-bounces@ietf.org >>>> [mailto:ecrit-bounces@ietf.org] *On Behalf Of *Christer Holmberg >>>> *Sent:* Wednesday, September 12, 2012 5:32 AM >>>> *To:* ecrit@ietf.org >>>> *Subject:* [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-0= 5 >>>>=20 >>>> Hi, >>>>=20 >>>> I=92ve submitted a new version of the psap-callback draft, due to >>>> expiration of the previous version. >>>>=20 >>>> There are NO changes compared to the previous version. >>>>=20 >>>> Once I get some guidance on where to define the new SIP Priority heade= r >>>> field =93psap-callback=94 value, I will either update this draft or su= bmit a >>>> separate one in SIPCORE. >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>> CONFIDENTIALITY NOTICE: The information contained in this message may = be >>>> privileged and/or confidential. If you are not the intended recipient, >>>> or responsible for delivering this message to the intended recipient, >>>> any review, forwarding, dissemination, distribution or copying of this >>>> communication or any attachment(s) is strictly prohibited. If you have >>>> received this message in error, please notify the sender immediately, >>>> and delete it and all attachments from your computer and network. >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From keith.drage@alcatel-lucent.com Wed Sep 26 10:36:31 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABE221F8518 for ; Wed, 26 Sep 2012 10:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRTW1H5VL4gj for ; Wed, 26 Sep 2012 10:36:30 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 45C4721F84C5 for ; Wed, 26 Sep 2012 10:36:29 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8QHaHx0006454 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 26 Sep 2012 19:36:20 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 26 Sep 2012 19:36:11 +0200 From: "DRAGE, Keith (Keith)" To: Hannes Tschofenig , "Rosen, Brian" Date: Wed, 26 Sep 2012 19:36:10 +0200 Thread-Topic: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value Thread-Index: Ac2cCBzJ9vEUBDUUT3WYDLCeefUEPAAAJkcw Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22@ESESSCMS0356.eemea.ericsson.se> <50631D26.70609@alum.mit.edu> <35047045-145A-4FF7-B69C-7B5182E9DCB5@neustar.biz> <15AA7501-47C7-4FFB-B822-B47C3A6D8AB8@gmx.net> In-Reply-To: <15AA7501-47C7-4FFB-B822-B47C3A6D8AB8@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "sipcore-chairs@tools.ietf.org" , "rai-ads@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 17:36:31 -0000 The documents that add registries for stuff originally defined in RFC 3261 = are RFC 5727, RFC 3968 and RFC 3969. None of those documents found it necessary to update RFC 3261 in order to d= o so. Both RFC 3968 and RFC 3969 found it necessary to update RFC 3427, the prede= cessor of RFC 5727 (which is now obsolete) in order to do the work they do.= However not entirely clear to me why they needed to do that, given that th= ey don't seem to change the registration requirements for anything defined = in that document. So from an IANA registration perspective I don't see the need to update any= other RFC. The other aspect is that we create a registration policy for the registry. = RFC 3968 did that but did not need to update RFC 3261 in order to do so. As to whether there are other aspects of RFC 3261 that need to be extended,= and therefore cause an update. - Discussion seems to have identified no need to enhance the RFC 3261 ABNF. - I note that the inclusion of the header field is currently not allowed in= OPTIONS or REFER methods, while it is allowed in every other dialog creati= ng or standalone method - we might want to allow that, in which case we wou= ld update RFC 3261 and RFC 3515 respectively. Regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: 26 September 2012 17:58 > To: Rosen, Brian > Cc: rai-ads@tools.ietf.org; sipcore-chairs@tools.ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 > - select priority-value >=20 > We are adding a new value to the Priority header field. I looked at RFC > 3261 and at RFC 2076 but there was no guidance on how new values are > registered. There isn't even a registry for it. >=20 > On Sep 26, 2012, at 7:35 PM, Rosen, Brian wrote: >=20 > > Are we updating 3261? > > > > That's an AD/chair (with sipcore chairs I think) call, right? > > > > I'm okay either way -- it's not clear to me it changes 3261 in any way. > I'd want sipcore to review of course, but not clear we need to update 326= 1. > > > > Brian > > > > On Sep 26, 2012, at 11:20 AM, Paul Kyzivat > wrote: > > > >> On 9/26/12 5:51 AM, Christer Holmberg wrote: > >>> Thanks, Roger! > >>> > >>> We intend to submit a new version of the callback draft, with text > >>> defining the new value. > >>> > >>> But, I guess we should also verify with the ADs/SIPCORE chairs that i= t > >>> is ok to define the new value in ECRIT. > >> > >> I will defer to the ADs, but it seems to me that it should be > sufficient to: > >> > >> - In this draft, do all the IANA considerations necessary to set up th= e > >> new registry and register all the initial values, including all those > >> defined in 3261 and the new one for this draft. > >> > >> - Advertise this draft (with the above) on the sipcore list. > >> > >> - Do a WGLC in both ECRIT and SIPCORE. > >> > >> Thanks, > >> Paul > >> > >>> Regards, > >>> > >>> Christer > >>> > >>> *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On > Behalf > >>> Of *Roger Marshall > >>> *Sent:* 25. syyskuuta 2012 19:10 > >>> *To:* ecrit@ietf.org > >>> *Subject:* Re: [Ecrit] Draft new version: > >>> draft-ietf-ecrit-psap-callback-05 - select priority-value > >>> > >>> Based on the responses to my request for a priority-value, the vote > >>> totals came in as: > >>> > >>> Existing value of "emergency" =3D 4 > >>> > >>> New value of "psap-callback" =3D 7 > >>> > >>> New value (other than existing) =3D 1 > >>> > >>> Since the "new value - other than existing" lines up with psap- > callback, > >>> we have "psap-callback" favored at a count of 8 to 4. > >>> > >>> These results are clear, and are based on what is posted to the > current > >>> mail list. Therefore we should be able to move this draft forward. > >>> > >>> Thanks. > >>> > >>> -roger marshall. > >>> > >>> *From:*ecrit-bounces@ietf.org > >>> [mailto:ecrit-bounces@ietf.org] bounces@ietf.org]> > >>> *On Behalf Of *Roger Marshall > >>> *Sent:* Friday, September 14, 2012 2:37 PM > >>> *To:* ecrit@ietf.org > >>> *Subject:* Re: [Ecrit] Draft new version: > >>> draft-ietf-ecrit-psap-callback-05 - select priority-value > >>> > >>> All: > >>> > >>> We need to select a priority-value in order to move the > >>> ecrit-psap-callback draft forward. > >>> > >>> Putting aside, for the moment, the questions of if/how/where the > >>> priority-value token is defined (if a new value is required - e.g., > >>> whether RFC or Registry), we should be able to agree on the value > itself. > >>> > >>> We've seen some suggestions for a priority-value given on the list > over > >>> the last few weeks with no clear convergence. The value "emergency" i= s > >>> already included in the RFC3261 definition, but some others have > voiced > >>> a preference to define a new priority-value, using other-priority =3D > token. > >>> > >>> Priority =3D "Priority" HCOLON priority-value > >>> > >>> priority-value =3D "emergency" / "urgent" / "normal" > >>> > >>> / "non-urgent" / other-priority > >>> > >>> other-priority =3D token > >>> > >>> We've seen a few mentioned on the list, now the chairs are calling to > >>> close the list of candidate values, and request the work group to vot= e > >>> their choice. > >>> > >>> Of the priority-values put out there on the list, we have the > following > >>> mentioned a few times: > >>> > >>> - emergency > >>> > >>> - emergency-callback > >>> > >>> - psap-callback > >>> > >>> Also mentioned once were: > >>> > >>> - expedited-emergency > >>> > >>> - urgent-emergency > >>> > >>> - emergency-override > >>> > >>> If I've forgotten one, please let me know. > >>> > >>> Send your vote to the ecrit list. The voting will go through 18:00 > >>> (Pacific), next Friday, 9/21/2012. > >>> > >>> -roger. > >>> > >>> *From:*ecrit-bounces@ietf.org > >>> [mailto:ecrit-bounces@ietf.org] *On Behalf Of *Christer Holmberg > >>> *Sent:* Wednesday, September 12, 2012 5:32 AM > >>> *To:* ecrit@ietf.org > >>> *Subject:* [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback- > 05 > >>> > >>> Hi, > >>> > >>> I've submitted a new version of the psap-callback draft, due to > >>> expiration of the previous version. > >>> > >>> There are NO changes compared to the previous version. > >>> > >>> Once I get some guidance on where to define the new SIP Priority > header > >>> field "psap-callback" value, I will either update this draft or submi= t > a > >>> separate one in SIPCORE. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> CONFIDENTIALITY NOTICE: The information contained in this message may > be > >>> privileged and/or confidential. If you are not the intended recipient= , > >>> or responsible for delivering this message to the intended recipient, > >>> any review, forwarding, dissemination, distribution or copying of thi= s > >>> communication or any attachment(s) is strictly prohibited. If you hav= e > >>> received this message in error, please notify the sender immediately, > >>> and delete it and all attachments from your computer and network. > >>> > >>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > >>> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From christer.holmberg@ericsson.com Wed Sep 26 11:28:22 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79CD21F845B for ; Wed, 26 Sep 2012 11:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.138 X-Spam-Level: X-Spam-Status: No, score=-6.138 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oI4ZxaHeKvT for ; Wed, 26 Sep 2012 11:28:22 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 614E321F845A for ; Wed, 26 Sep 2012 11:28:21 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-f8-50634943c80c Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 45.BE.17130.34943605; Wed, 26 Sep 2012 20:28:20 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 26 Sep 2012 20:28:19 +0200 From: Christer Holmberg To: "Rosen, Brian" , Hannes Tschofenig Date: Wed, 26 Sep 2012 20:27:21 +0200 Thread-Topic: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value Thread-Index: Ac2cDKju35FJRHk2S4OF5Je1GPDJpAAB+hTF Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FBE@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22@ESESSCMS0356.eemea.ericsson.se> <50631D26.70609@alum.mit.edu> <35047045-145A-4FF7-B69C-7B5182E9DCB5@neustar.biz> <15AA7501-47C7-4FFB-B822-B47C3A6D8AB8@gmx.net>, 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM+Jvra6LZ3KAwbteAYtpJy8zWzQuespq sXTnPVaLvdvnMVqcenWa2YHVY/Gm/WweS5b8ZPLY0fCc2ePL5c9sASxRXDYpqTmZZalF+nYJ XBn3391iLFhgXfHhVEQD42yDLkZODgkBE4nlH5axQthiEhfurWfrYuTiEBI4xSgx9/MsJghn AaPEnL9H2LsYOTjYBCwkuv9pgzSICMRKLDy3lR2khllgLqPE6kdzmUASLAKqEr2TnzGD2MIC yRJH/raxQDSkSHx7e4UVZI6IgJHE5EXmIGFegXCJj6/uQO16wSyxYOoUsIs4BewlZvfuAutl BLru+6k1YPOZBcQlbj2ZzwRxtYDEkj3nmSFsUYmXj/+xQtSLStxpX88IUW8g8f7cfGYIW1ti 2cLXzBCLBSVOznzCMoFRbBaSsbOQtMxC0jILScsCRpZVjMK5iZk56eXmeqlFmcnFxfl5esWp mxiB0XZwy2+DHYyb7osdYpTmYFES59VT3e8vJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXH6 /QN7f1UuV95Vtm1e5WTnQ44m7y5fVk7IODzFP59hb9iRlHbNVzVMgS2RJxouZBly3H/9a0Ky V1pLXPVinTzJ3ozdr60v2s1xmameXeDm9ruk+oyIG39R3rmu3OjIxHezD//qLu5jlE+/9nJJ W2Ai0+THUX8Zrv04sHjhbDW3BT3fEr47sCqxFGckGmoxFxUnAgDbdDSwhAIAAA== Cc: "rai-ads@tools.ietf.org" , "sipcore-chairs@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 18:28:23 -0000 Hi, I don't think we are updating 3261. The 3261 Priority header field ABNF all= ows new values (see on of my previous e-mails). Regards, Christer ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Rosen, B= rian [Brian.Rosen@neustar.biz] Sent: Wednesday, September 26, 2012 8:30 PM To: Hannes Tschofenig Cc: sipcore-chairs@tools.ietf.org; Rosen, Brian; rai-ads@tools.ietf.o= rg; ecrit@ietf.org Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 -= select priority-value I think the plan is to add a registry in this document. I think that doing that (adding the registry) could give rise to some conce= rn that we were updating 3261, but I personally don't think we are. The re= vised version of this document, which defines the registry, isn't going to = say any value in the header has to be in the registry. That WOULD be an up= date to 3261. The registry is informational, I think. Brian On Sep 26, 2012, at 12:57 PM, Hannes Tschofenig = wrote: > We are adding a new value to the Priority header field. I looked at RFC 3= 261 and at RFC 2076 but there was no guidance on how new values are registe= red. There isn't even a registry for it. > > On Sep 26, 2012, at 7:35 PM, Rosen, Brian wrote: > >> Are we updating 3261? >> >> That's an AD/chair (with sipcore chairs I think) call, right? >> >> I'm okay either way -- it's not clear to me it changes 3261 in any way. = I'd want sipcore to review of course, but not clear we need to update 3261= . >> >> Brian >> >> On Sep 26, 2012, at 11:20 AM, Paul Kyzivat wrote= : >> >>> On 9/26/12 5:51 AM, Christer Holmberg wrote: >>>> Thanks, Roger! >>>> >>>> We intend to submit a new version of the callback draft, with text >>>> defining the new value. >>>> >>>> But, I guess we should also verify with the ADs/SIPCORE chairs that it >>>> is ok to define the new value in ECRIT. >>> >>> I will defer to the ADs, but it seems to me that it should be sufficien= t to: >>> >>> - In this draft, do all the IANA considerations necessary to set up the >>> new registry and register all the initial values, including all those >>> defined in 3261 and the new one for this draft. >>> >>> - Advertise this draft (with the above) on the sipcore list. >>> >>> - Do a WGLC in both ECRIT and SIPCORE. >>> >>> Thanks, >>> Paul >>> >>>> Regards, >>>> >>>> Christer >>>> >>>> *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Beha= lf >>>> Of *Roger Marshall >>>> *Sent:* 25. syyskuuta 2012 19:10 >>>> *To:* ecrit@ietf.org >>>> *Subject:* Re: [Ecrit] Draft new version: >>>> draft-ietf-ecrit-psap-callback-05 - select priority-value >>>> >>>> Based on the responses to my request for a priority-value, the vote >>>> totals came in as: >>>> >>>> Existing value of =93emergency=94 =3D 4 >>>> >>>> New value of =93psap-callback=94 =3D 7 >>>> >>>> New value (other than existing) =3D 1 >>>> >>>> Since the =93new value =96 other than existing=94 lines up with psap-c= allback, >>>> we have =93psap-callback=94 favored at a count of 8 to 4. >>>> >>>> These results are clear, and are based on what is posted to the curren= t >>>> mail list. Therefore we should be able to move this draft forward. >>>> >>>> Thanks. >>>> >>>> -roger marshall. >>>> >>>> *From:*ecrit-bounces@ietf.org >>>> [mailto:ecrit-bounces@ietf.org] >>>> *On Behalf Of *Roger Marshall >>>> *Sent:* Friday, September 14, 2012 2:37 PM >>>> *To:* ecrit@ietf.org >>>> *Subject:* Re: [Ecrit] Draft new version: >>>> draft-ietf-ecrit-psap-callback-05 - select priority-value >>>> >>>> All: >>>> >>>> We need to select a priority-value in order to move the >>>> ecrit-psap-callback draft forward. >>>> >>>> Putting aside, for the moment, the questions of if/how/where the >>>> priority-value token is defined (if a new value is required - e.g., >>>> whether RFC or Registry), we should be able to agree on the value itse= lf. >>>> >>>> We=92ve seen some suggestions for a priority-value given on the list o= ver >>>> the last few weeks with no clear convergence. The value =93emergency= =94 is >>>> already included in the RFC3261 definition, but some others have voice= d >>>> a preference to define a new priority-value, using other-priority =3D = token. >>>> >>>> Priority =3D "Priority" HCOLON priority-value >>>> >>>> priority-value =3D "emergency" / "urgent" / "normal" >>>> >>>> / "non-urgent" / other-priority >>>> >>>> other-priority =3D token >>>> >>>> We=92ve seen a few mentioned on the list, now the chairs are calling t= o >>>> close the list of candidate values, and request the work group to vote >>>> their choice. >>>> >>>> Of the priority-values put out there on the list, we have the followin= g >>>> mentioned a few times: >>>> >>>> - emergency >>>> >>>> - emergency-callback >>>> >>>> - psap-callback >>>> >>>> Also mentioned once were: >>>> >>>> - expedited-emergency >>>> >>>> - urgent-emergency >>>> >>>> - emergency-override >>>> >>>> If I=92ve forgotten one, please let me know. >>>> >>>> Send your vote to the ecrit list. The voting will go through 18:00 >>>> (Pacific), next Friday, 9/21/2012. >>>> >>>> -roger. >>>> >>>> *From:*ecrit-bounces@ietf.org >>>> [mailto:ecrit-bounces@ietf.org] *On Behalf Of *Christer Holmberg >>>> *Sent:* Wednesday, September 12, 2012 5:32 AM >>>> *To:* ecrit@ietf.org >>>> *Subject:* [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-0= 5 >>>> >>>> Hi, >>>> >>>> I=92ve submitted a new version of the psap-callback draft, due to >>>> expiration of the previous version. >>>> >>>> There are NO changes compared to the previous version. >>>> >>>> Once I get some guidance on where to define the new SIP Priority heade= r >>>> field =93psap-callback=94 value, I will either update this draft or su= bmit a >>>> separate one in SIPCORE. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> CONFIDENTIALITY NOTICE: The information contained in this message may = be >>>> privileged and/or confidential. If you are not the intended recipient, >>>> or responsible for delivering this message to the intended recipient, >>>> any review, forwarding, dissemination, distribution or copying of this >>>> communication or any attachment(s) is strictly prohibited. If you have >>>> received this message in error, please notify the sender immediately, >>>> and delete it and all attachments from your computer and network. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit= From pkyzivat@alum.mit.edu Wed Sep 26 12:23:03 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAC021F85C6 for ; Wed, 26 Sep 2012 12:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.394 X-Spam-Level: X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKhxU68b9G+v for ; Wed, 26 Sep 2012 12:23:03 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id C73FE21F85C3 for ; Wed, 26 Sep 2012 12:23:02 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta05.westchester.pa.mail.comcast.net with comcast id 3mSi1k0051c6gX855vP69t; Wed, 26 Sep 2012 19:23:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id 3vHV1k00Z3ZTu2S3jvHV2l; Wed, 26 Sep 2012 19:17:30 +0000 Message-ID: <506354E9.9030001@alum.mit.edu> Date: Wed, 26 Sep 2012 15:18:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: ecrit@ietf.org, "rai-ads@tools.ietf.org" References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22@ESESSCMS0356.eemea.ericsson.se> <50631D26.70609@alum.mit.edu> <35047045-145A-4FF7-B69C-7B5182E9DCB5@neustar.biz> <15AA7501-47C7-4FFB-B822-B47C3A6D8AB8@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 19:23:03 -0000 On 9/26/12 1:36 PM, DRAGE, Keith (Keith) wrote: > The documents that add registries for stuff originally defined in RFC 3261 are RFC 5727, RFC 3968 and RFC 3969. > > None of those documents found it necessary to update RFC 3261 in order to do so. > > Both RFC 3968 and RFC 3969 found it necessary to update RFC 3427, the predecessor of RFC 5727 (which is now obsolete) in order to do the work they do. However not entirely clear to me why they needed to do that, given that they don't seem to change the registration requirements for anything defined in that document. I agree with all the above, except that AFAIK 5727 is *not* obsolete. But I don't understand *why* introducing the IANA registries after the fact for things first defined in 3261 was not an update to 3261. AFAIK the intent was to change normative behavior - that defining a new value requires updating the corresponding registry. The fundamental point of all this is tracability. If I want to find all the defined values for the priority header, where do I look? The first place I would start is where the Priority header is defined - 3261. Next I might look at all documents listed as updating 3261. If 3261 had spelled out an IANA registry for priority values then I would look there. But it doesn't. If some document that does update 3261 had specified an IANA registry then that would tell me where to look. Otherwise I think every draft that adds a priority value will need to indicate that it updates 3261 to preserve traceability. But that same argument applies to header field parameters. ISTM that 3427, and hence 5727, should have been considered updates to 3261. And then 3968, which updated 3427, would have transitively updated 3261. This document could be viewed as analogous to 3968, and so update 5727. Responding to Brian, I don't understand how the use of the IANA registry can be informative. It isn't useful if it isn't normative. IMO we need AD input on this. > So from an IANA registration perspective I don't see the need to update any other RFC. > > The other aspect is that we create a registration policy for the registry. RFC 3968 did that but did not need to update RFC 3261 in order to do so. I agree that the policy needs to be defined. (You can't establish an IANA registry without choosing a policy.) I suggest that it be Standards Action. Thanks, Paul > As to whether there are other aspects of RFC 3261 that need to be extended, and therefore cause an update. > > - Discussion seems to have identified no need to enhance the RFC 3261 ABNF. > > - I note that the inclusion of the header field is currently not allowed in OPTIONS or REFER methods, while it is allowed in every other dialog creating or standalone method - we might want to allow that, in which case we would update RFC 3261 and RFC 3515 respectively. > > Regards > > Keith > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> Hannes Tschofenig >> Sent: 26 September 2012 17:58 >> To: Rosen, Brian >> Cc: rai-ads@tools.ietf.org; sipcore-chairs@tools.ietf.org; ecrit@ietf.org >> Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 >> - select priority-value >> >> We are adding a new value to the Priority header field. I looked at RFC >> 3261 and at RFC 2076 but there was no guidance on how new values are >> registered. There isn't even a registry for it. >> >> On Sep 26, 2012, at 7:35 PM, Rosen, Brian wrote: >> >>> Are we updating 3261? >>> >>> That's an AD/chair (with sipcore chairs I think) call, right? >>> >>> I'm okay either way -- it's not clear to me it changes 3261 in any way. >> I'd want sipcore to review of course, but not clear we need to update 3261. >>> >>> Brian >>> >>> On Sep 26, 2012, at 11:20 AM, Paul Kyzivat >> wrote: >>> >>>> On 9/26/12 5:51 AM, Christer Holmberg wrote: >>>>> Thanks, Roger! >>>>> >>>>> We intend to submit a new version of the callback draft, with text >>>>> defining the new value. >>>>> >>>>> But, I guess we should also verify with the ADs/SIPCORE chairs that it >>>>> is ok to define the new value in ECRIT. >>>> >>>> I will defer to the ADs, but it seems to me that it should be >> sufficient to: >>>> >>>> - In this draft, do all the IANA considerations necessary to set up the >>>> new registry and register all the initial values, including all those >>>> defined in 3261 and the new one for this draft. >>>> >>>> - Advertise this draft (with the above) on the sipcore list. >>>> >>>> - Do a WGLC in both ECRIT and SIPCORE. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On >> Behalf >>>>> Of *Roger Marshall >>>>> *Sent:* 25. syyskuuta 2012 19:10 >>>>> *To:* ecrit@ietf.org >>>>> *Subject:* Re: [Ecrit] Draft new version: >>>>> draft-ietf-ecrit-psap-callback-05 - select priority-value >>>>> >>>>> Based on the responses to my request for a priority-value, the vote >>>>> totals came in as: >>>>> >>>>> Existing value of "emergency" = 4 >>>>> >>>>> New value of "psap-callback" = 7 >>>>> >>>>> New value (other than existing) = 1 >>>>> >>>>> Since the "new value - other than existing" lines up with psap- >> callback, >>>>> we have "psap-callback" favored at a count of 8 to 4. >>>>> >>>>> These results are clear, and are based on what is posted to the >> current >>>>> mail list. Therefore we should be able to move this draft forward. >>>>> >>>>> Thanks. >>>>> >>>>> -roger marshall. >>>>> >>>>> *From:*ecrit-bounces@ietf.org >>>>> [mailto:ecrit-bounces@ietf.org] > bounces@ietf.org]> >>>>> *On Behalf Of *Roger Marshall >>>>> *Sent:* Friday, September 14, 2012 2:37 PM >>>>> *To:* ecrit@ietf.org >>>>> *Subject:* Re: [Ecrit] Draft new version: >>>>> draft-ietf-ecrit-psap-callback-05 - select priority-value >>>>> >>>>> All: >>>>> >>>>> We need to select a priority-value in order to move the >>>>> ecrit-psap-callback draft forward. >>>>> >>>>> Putting aside, for the moment, the questions of if/how/where the >>>>> priority-value token is defined (if a new value is required - e.g., >>>>> whether RFC or Registry), we should be able to agree on the value >> itself. >>>>> >>>>> We've seen some suggestions for a priority-value given on the list >> over >>>>> the last few weeks with no clear convergence. The value "emergency" is >>>>> already included in the RFC3261 definition, but some others have >> voiced >>>>> a preference to define a new priority-value, using other-priority = >> token. >>>>> >>>>> Priority = "Priority" HCOLON priority-value >>>>> >>>>> priority-value = "emergency" / "urgent" / "normal" >>>>> >>>>> / "non-urgent" / other-priority >>>>> >>>>> other-priority = token >>>>> >>>>> We've seen a few mentioned on the list, now the chairs are calling to >>>>> close the list of candidate values, and request the work group to vote >>>>> their choice. >>>>> >>>>> Of the priority-values put out there on the list, we have the >> following >>>>> mentioned a few times: >>>>> >>>>> - emergency >>>>> >>>>> - emergency-callback >>>>> >>>>> - psap-callback >>>>> >>>>> Also mentioned once were: >>>>> >>>>> - expedited-emergency >>>>> >>>>> - urgent-emergency >>>>> >>>>> - emergency-override >>>>> >>>>> If I've forgotten one, please let me know. >>>>> >>>>> Send your vote to the ecrit list. The voting will go through 18:00 >>>>> (Pacific), next Friday, 9/21/2012. >>>>> >>>>> -roger. >>>>> >>>>> *From:*ecrit-bounces@ietf.org >>>>> [mailto:ecrit-bounces@ietf.org] *On Behalf Of *Christer Holmberg >>>>> *Sent:* Wednesday, September 12, 2012 5:32 AM >>>>> *To:* ecrit@ietf.org >>>>> *Subject:* [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback- >> 05 >>>>> >>>>> Hi, >>>>> >>>>> I've submitted a new version of the psap-callback draft, due to >>>>> expiration of the previous version. >>>>> >>>>> There are NO changes compared to the previous version. >>>>> >>>>> Once I get some guidance on where to define the new SIP Priority >> header >>>>> field "psap-callback" value, I will either update this draft or submit >> a >>>>> separate one in SIPCORE. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> CONFIDENTIALITY NOTICE: The information contained in this message may >> be >>>>> privileged and/or confidential. If you are not the intended recipient, >>>>> or responsible for delivering this message to the intended recipient, >>>>> any review, forwarding, dissemination, distribution or copying of this >>>>> communication or any attachment(s) is strictly prohibited. If you have >>>>> received this message in error, please notify the sender immediately, >>>>> and delete it and all attachments from your computer and network. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From brian.rosen@neustar.biz Wed Sep 26 12:28:37 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3711321F849D for ; Wed, 26 Sep 2012 12:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5brlQFxvu7p3 for ; Wed, 26 Sep 2012 12:28:36 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id D3E6121F8498 for ; Wed, 26 Sep 2012 12:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1348687653; x=1664044584; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=NaVO9sZiqPGZdYTtFdilz 6H7E181M0ytTBH1eI2Opug=; b=FkhpWKc3938Qjp5AbUMzz2BCyrWRc7+d4vCqi h3c6uOGSINLw2olae1Db4WFZ7pC73a7AkMIp7pYsg8ybOPHaw== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.9917812; Wed, 26 Sep 2012 15:27:31 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::28fd:d8c6:49f0:619b]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Wed, 26 Sep 2012 15:28:32 -0400 From: "Rosen, Brian" To: Paul Kyzivat Date: Wed, 26 Sep 2012 15:28:32 -0400 Thread-Topic: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value Thread-Index: Ac2cHRzt5cxqx9EMST6N7xaUzTEucg== Message-ID: <432874EA-324D-42F9-A69E-899DC57B8954@neustar.biz> References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22@ESESSCMS0356.eemea.ericsson.se> <50631D26.70609@alum.mit.edu> <35047045-145A-4FF7-B69C-7B5182E9DCB5@neustar.biz> <15AA7501-47C7-4FFB-B822-B47C3A6D8AB8@gmx.net> <506354E9.9030001@alum.mit.edu> In-Reply-To: <506354E9.9030001@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: NzlHknxHdDD9Xob91y2iSg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rai-ads@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 19:28:37 -0000 Unless this document has a statement like "Priority values in SIP are hereb= y limited to those in the registry", then the registry is a useful aid to f= ind out what values have been defined, but does not limit what values can b= e used beyond what 3261 says. I think that's fine. Brian On Sep 26, 2012, at 3:18 PM, Paul Kyzivat wrote: > On 9/26/12 1:36 PM, DRAGE, Keith (Keith) wrote: >> The documents that add registries for stuff originally defined in RFC 32= 61 are RFC 5727, RFC 3968 and RFC 3969. >>=20 >> None of those documents found it necessary to update RFC 3261 in order t= o do so. >>=20 >> Both RFC 3968 and RFC 3969 found it necessary to update RFC 3427, the pr= edecessor of RFC 5727 (which is now obsolete) in order to do the work they = do. However not entirely clear to me why they needed to do that, given that= they don't seem to change the registration requirements for anything defin= ed in that document. >=20 > I agree with all the above, except that AFAIK 5727 is *not* obsolete. >=20 > But I don't understand *why* introducing the IANA registries after the fa= ct for things first defined in 3261 was not an update to 3261. > AFAIK the intent was to change normative behavior - that defining a new v= alue requires updating the corresponding registry. >=20 > The fundamental point of all this is tracability. If I want to find all t= he defined values for the priority header, where do I look? The first place= I would start is where the Priority header is defined - 3261. Next I might= look at all documents listed as updating 3261. If 3261 had spelled out an = IANA registry for priority values then I would look there. But it doesn't. = If some document that does update 3261 had specified an IANA registry then = that would tell me where to look. Otherwise I think every draft that adds a= priority value will need to indicate that it updates 3261 to preserve trac= eability. >=20 > But that same argument applies to header field parameters. ISTM that 3427= , and hence 5727, should have been considered updates to 3261. And then 396= 8, which updated 3427, would have transitively updated 3261. >=20 > This document could be viewed as analogous to 3968, and so update 5727. >=20 > Responding to Brian, I don't understand how the use of the IANA registry = can be informative. It isn't useful if it isn't normative. >=20 > IMO we need AD input on this. >=20 >> So from an IANA registration perspective I don't see the need to update = any other RFC. >>=20 >> The other aspect is that we create a registration policy for the registr= y. RFC 3968 did that but did not need to update RFC 3261 in order to do so. >=20 > I agree that the policy needs to be defined. (You can't establish an IANA= registry without choosing a policy.) I suggest that it be Standards Action= . >=20 > Thanks, > Paul >=20 >> As to whether there are other aspects of RFC 3261 that need to be extend= ed, and therefore cause an update. >>=20 >> - Discussion seems to have identified no need to enhance the RFC 3261 AB= NF. >>=20 >> - I note that the inclusion of the header field is currently not allowed= in OPTIONS or REFER methods, while it is allowed in every other dialog cre= ating or standalone method - we might want to allow that, in which case we = would update RFC 3261 and RFC 3515 respectively. >>=20 >> Regards >>=20 >> Keith >>=20 >>=20 >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of >>> Hannes Tschofenig >>> Sent: 26 September 2012 17:58 >>> To: Rosen, Brian >>> Cc: rai-ads@tools.ietf.org; sipcore-chairs@tools.ietf.org; ecrit@ietf.o= rg >>> Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-= 05 >>> - select priority-value >>>=20 >>> We are adding a new value to the Priority header field. I looked at RFC >>> 3261 and at RFC 2076 but there was no guidance on how new values are >>> registered. There isn't even a registry for it. >>>=20 >>> On Sep 26, 2012, at 7:35 PM, Rosen, Brian wrote: >>>=20 >>>> Are we updating 3261? >>>>=20 >>>> That's an AD/chair (with sipcore chairs I think) call, right? >>>>=20 >>>> I'm okay either way -- it's not clear to me it changes 3261 in any way= . >>> I'd want sipcore to review of course, but not clear we need to update 3= 261. >>>>=20 >>>> Brian >>>>=20 >>>> On Sep 26, 2012, at 11:20 AM, Paul Kyzivat >>> wrote: >>>>=20 >>>>> On 9/26/12 5:51 AM, Christer Holmberg wrote: >>>>>> Thanks, Roger! >>>>>>=20 >>>>>> We intend to submit a new version of the callback draft, with text >>>>>> defining the new value. >>>>>>=20 >>>>>> But, I guess we should also verify with the ADs/SIPCORE chairs that = it >>>>>> is ok to define the new value in ECRIT. >>>>>=20 >>>>> I will defer to the ADs, but it seems to me that it should be >>> sufficient to: >>>>>=20 >>>>> - In this draft, do all the IANA considerations necessary to set up t= he >>>>> new registry and register all the initial values, including all those >>>>> defined in 3261 and the new one for this draft. >>>>>=20 >>>>> - Advertise this draft (with the above) on the sipcore list. >>>>>=20 >>>>> - Do a WGLC in both ECRIT and SIPCORE. >>>>>=20 >>>>> Thanks, >>>>> Paul >>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Christer >>>>>>=20 >>>>>> *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On >>> Behalf >>>>>> Of *Roger Marshall >>>>>> *Sent:* 25. syyskuuta 2012 19:10 >>>>>> *To:* ecrit@ietf.org >>>>>> *Subject:* Re: [Ecrit] Draft new version: >>>>>> draft-ietf-ecrit-psap-callback-05 - select priority-value >>>>>>=20 >>>>>> Based on the responses to my request for a priority-value, the vote >>>>>> totals came in as: >>>>>>=20 >>>>>> Existing value of "emergency" =3D 4 >>>>>>=20 >>>>>> New value of "psap-callback" =3D 7 >>>>>>=20 >>>>>> New value (other than existing) =3D 1 >>>>>>=20 >>>>>> Since the "new value - other than existing" lines up with psap- >>> callback, >>>>>> we have "psap-callback" favored at a count of 8 to 4. >>>>>>=20 >>>>>> These results are clear, and are based on what is posted to the >>> current >>>>>> mail list. Therefore we should be able to move this draft forward. >>>>>>=20 >>>>>> Thanks. >>>>>>=20 >>>>>> -roger marshall. >>>>>>=20 >>>>>> *From:*ecrit-bounces@ietf.org >>>>>> [mailto:ecrit-bounces@ietf.org] >> bounces@ietf.org]> >>>>>> *On Behalf Of *Roger Marshall >>>>>> *Sent:* Friday, September 14, 2012 2:37 PM >>>>>> *To:* ecrit@ietf.org >>>>>> *Subject:* Re: [Ecrit] Draft new version: >>>>>> draft-ietf-ecrit-psap-callback-05 - select priority-value >>>>>>=20 >>>>>> All: >>>>>>=20 >>>>>> We need to select a priority-value in order to move the >>>>>> ecrit-psap-callback draft forward. >>>>>>=20 >>>>>> Putting aside, for the moment, the questions of if/how/where the >>>>>> priority-value token is defined (if a new value is required - e.g., >>>>>> whether RFC or Registry), we should be able to agree on the value >>> itself. >>>>>>=20 >>>>>> We've seen some suggestions for a priority-value given on the list >>> over >>>>>> the last few weeks with no clear convergence. The value "emergency" = is >>>>>> already included in the RFC3261 definition, but some others have >>> voiced >>>>>> a preference to define a new priority-value, using other-priority = =3D >>> token. >>>>>>=20 >>>>>> Priority =3D "Priority" HCOLON priority-value >>>>>>=20 >>>>>> priority-value =3D "emergency" / "urgent" / "normal" >>>>>>=20 >>>>>> / "non-urgent" / other-priority >>>>>>=20 >>>>>> other-priority =3D token >>>>>>=20 >>>>>> We've seen a few mentioned on the list, now the chairs are calling t= o >>>>>> close the list of candidate values, and request the work group to vo= te >>>>>> their choice. >>>>>>=20 >>>>>> Of the priority-values put out there on the list, we have the >>> following >>>>>> mentioned a few times: >>>>>>=20 >>>>>> - emergency >>>>>>=20 >>>>>> - emergency-callback >>>>>>=20 >>>>>> - psap-callback >>>>>>=20 >>>>>> Also mentioned once were: >>>>>>=20 >>>>>> - expedited-emergency >>>>>>=20 >>>>>> - urgent-emergency >>>>>>=20 >>>>>> - emergency-override >>>>>>=20 >>>>>> If I've forgotten one, please let me know. >>>>>>=20 >>>>>> Send your vote to the ecrit list. The voting will go through 18:00 >>>>>> (Pacific), next Friday, 9/21/2012. >>>>>>=20 >>>>>> -roger. >>>>>>=20 >>>>>> *From:*ecrit-bounces@ietf.org >>>>>> [mailto:ecrit-bounces@ietf.org] *On Behalf Of *Christer Holmberg >>>>>> *Sent:* Wednesday, September 12, 2012 5:32 AM >>>>>> *To:* ecrit@ietf.org >>>>>> *Subject:* [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback= - >>> 05 >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> I've submitted a new version of the psap-callback draft, due to >>>>>> expiration of the previous version. >>>>>>=20 >>>>>> There are NO changes compared to the previous version. >>>>>>=20 >>>>>> Once I get some guidance on where to define the new SIP Priority >>> header >>>>>> field "psap-callback" value, I will either update this draft or subm= it >>> a >>>>>> separate one in SIPCORE. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Christer >>>>>>=20 >>>>>> CONFIDENTIALITY NOTICE: The information contained in this message ma= y >>> be >>>>>> privileged and/or confidential. If you are not the intended recipien= t, >>>>>> or responsible for delivering this message to the intended recipient= , >>>>>> any review, forwarding, dissemination, distribution or copying of th= is >>>>>> communication or any attachment(s) is strictly prohibited. If you ha= ve >>>>>> received this message in error, please notify the sender immediately= , >>>>>> and delete it and all attachments from your computer and network. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From pkyzivat@alum.mit.edu Wed Sep 26 13:25:22 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C21F21F84D2 for ; Wed, 26 Sep 2012 13:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfKM5+nS54MZ for ; Wed, 26 Sep 2012 13:25:21 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 25AE821F84D1 for ; Wed, 26 Sep 2012 13:25:20 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta05.westchester.pa.mail.comcast.net with comcast id 3mlU1k0030ldTLk55wRQd8; Wed, 26 Sep 2012 20:25:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id 3wLB1k01E3ZTu2S3QwLBEy; Wed, 26 Sep 2012 20:20:12 +0000 Message-ID: <50636383.80707@alum.mit.edu> Date: Wed, 26 Sep 2012 16:20:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Rosen, Brian" References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22@ESESSCMS0356.eemea.ericsson.se> <50631D26.70609@alum.mit.edu> <35047045-145A-4FF7-B69C-7B5182E9DCB5@neustar.biz> <15AA7501-47C7-4FFB-B822-B47C3A6D8AB8@gmx.net> <506354E9.9030001@alum.mit.edu> <432874EA-324D-42F9-A69E-899DC57B8954@neustar.biz> In-Reply-To: <432874EA-324D-42F9-A69E-899DC57B8954@neustar.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rai-ads@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 20:25:22 -0000 On 9/26/12 3:28 PM, Rosen, Brian wrote: > Unless this document has a statement like "Priority values in SIP are hereby limited to those in the registry", then the registry is a useful aid to find out what values have been defined, but does not limit what values can be used beyond what 3261 says. > > I think that's fine. Doing that is comparable to allowing P- values, but without the "P-". It has the potential to make a mess. We are defining "psap-callback" because people are concerned that "emergency" might already be in use for something incompatible. But at least we aren't concerned that "psap-callback" might already be in use. If values can be used without registration, then you will never know if a candidate value is already in use. So I think there must be a statement like the one you mention above. Thanks, Paul > Brian > > On Sep 26, 2012, at 3:18 PM, Paul Kyzivat wrote: > >> On 9/26/12 1:36 PM, DRAGE, Keith (Keith) wrote: >>> The documents that add registries for stuff originally defined in RFC 3261 are RFC 5727, RFC 3968 and RFC 3969. >>> >>> None of those documents found it necessary to update RFC 3261 in order to do so. >>> >>> Both RFC 3968 and RFC 3969 found it necessary to update RFC 3427, the predecessor of RFC 5727 (which is now obsolete) in order to do the work they do. However not entirely clear to me why they needed to do that, given that they don't seem to change the registration requirements for anything defined in that document. >> >> I agree with all the above, except that AFAIK 5727 is *not* obsolete. >> >> But I don't understand *why* introducing the IANA registries after the fact for things first defined in 3261 was not an update to 3261. >> AFAIK the intent was to change normative behavior - that defining a new value requires updating the corresponding registry. >> >> The fundamental point of all this is tracability. If I want to find all the defined values for the priority header, where do I look? The first place I would start is where the Priority header is defined - 3261. Next I might look at all documents listed as updating 3261. If 3261 had spelled out an IANA registry for priority values then I would look there. But it doesn't. If some document that does update 3261 had specified an IANA registry then that would tell me where to look. Otherwise I think every draft that adds a priority value will need to indicate that it updates 3261 to preserve traceability. >> >> But that same argument applies to header field parameters. ISTM that 3427, and hence 5727, should have been considered updates to 3261. And then 3968, which updated 3427, would have transitively updated 3261. >> >> This document could be viewed as analogous to 3968, and so update 5727. >> >> Responding to Brian, I don't understand how the use of the IANA registry can be informative. It isn't useful if it isn't normative. >> >> IMO we need AD input on this. >> >>> So from an IANA registration perspective I don't see the need to update any other RFC. >>> >>> The other aspect is that we create a registration policy for the registry. RFC 3968 did that but did not need to update RFC 3261 in order to do so. >> >> I agree that the policy needs to be defined. (You can't establish an IANA registry without choosing a policy.) I suggest that it be Standards Action. >> >> Thanks, >> Paul >> >>> As to whether there are other aspects of RFC 3261 that need to be extended, and therefore cause an update. >>> >>> - Discussion seems to have identified no need to enhance the RFC 3261 ABNF. >>> >>> - I note that the inclusion of the header field is currently not allowed in OPTIONS or REFER methods, while it is allowed in every other dialog creating or standalone method - we might want to allow that, in which case we would update RFC 3261 and RFC 3515 respectively. >>> >>> Regards >>> >>> Keith >>> >>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >>>> Hannes Tschofenig >>>> Sent: 26 September 2012 17:58 >>>> To: Rosen, Brian >>>> Cc: rai-ads@tools.ietf.org; sipcore-chairs@tools.ietf.org; ecrit@ietf.org >>>> Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 >>>> - select priority-value >>>> >>>> We are adding a new value to the Priority header field. I looked at RFC >>>> 3261 and at RFC 2076 but there was no guidance on how new values are >>>> registered. There isn't even a registry for it. >>>> >>>> On Sep 26, 2012, at 7:35 PM, Rosen, Brian wrote: >>>> >>>>> Are we updating 3261? >>>>> >>>>> That's an AD/chair (with sipcore chairs I think) call, right? >>>>> >>>>> I'm okay either way -- it's not clear to me it changes 3261 in any way. >>>> I'd want sipcore to review of course, but not clear we need to update 3261. >>>>> >>>>> Brian >>>>> >>>>> On Sep 26, 2012, at 11:20 AM, Paul Kyzivat >>>> wrote: >>>>> >>>>>> On 9/26/12 5:51 AM, Christer Holmberg wrote: >>>>>>> Thanks, Roger! >>>>>>> >>>>>>> We intend to submit a new version of the callback draft, with text >>>>>>> defining the new value. >>>>>>> >>>>>>> But, I guess we should also verify with the ADs/SIPCORE chairs that it >>>>>>> is ok to define the new value in ECRIT. >>>>>> >>>>>> I will defer to the ADs, but it seems to me that it should be >>>> sufficient to: >>>>>> >>>>>> - In this draft, do all the IANA considerations necessary to set up the >>>>>> new registry and register all the initial values, including all those >>>>>> defined in 3261 and the new one for this draft. >>>>>> >>>>>> - Advertise this draft (with the above) on the sipcore list. >>>>>> >>>>>> - Do a WGLC in both ECRIT and SIPCORE. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On >>>> Behalf >>>>>>> Of *Roger Marshall >>>>>>> *Sent:* 25. syyskuuta 2012 19:10 >>>>>>> *To:* ecrit@ietf.org >>>>>>> *Subject:* Re: [Ecrit] Draft new version: >>>>>>> draft-ietf-ecrit-psap-callback-05 - select priority-value >>>>>>> >>>>>>> Based on the responses to my request for a priority-value, the vote >>>>>>> totals came in as: >>>>>>> >>>>>>> Existing value of "emergency" = 4 >>>>>>> >>>>>>> New value of "psap-callback" = 7 >>>>>>> >>>>>>> New value (other than existing) = 1 >>>>>>> >>>>>>> Since the "new value - other than existing" lines up with psap- >>>> callback, >>>>>>> we have "psap-callback" favored at a count of 8 to 4. >>>>>>> >>>>>>> These results are clear, and are based on what is posted to the >>>> current >>>>>>> mail list. Therefore we should be able to move this draft forward. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> -roger marshall. >>>>>>> >>>>>>> *From:*ecrit-bounces@ietf.org >>>>>>> [mailto:ecrit-bounces@ietf.org] >>> bounces@ietf.org]> >>>>>>> *On Behalf Of *Roger Marshall >>>>>>> *Sent:* Friday, September 14, 2012 2:37 PM >>>>>>> *To:* ecrit@ietf.org >>>>>>> *Subject:* Re: [Ecrit] Draft new version: >>>>>>> draft-ietf-ecrit-psap-callback-05 - select priority-value >>>>>>> >>>>>>> All: >>>>>>> >>>>>>> We need to select a priority-value in order to move the >>>>>>> ecrit-psap-callback draft forward. >>>>>>> >>>>>>> Putting aside, for the moment, the questions of if/how/where the >>>>>>> priority-value token is defined (if a new value is required - e.g., >>>>>>> whether RFC or Registry), we should be able to agree on the value >>>> itself. >>>>>>> >>>>>>> We've seen some suggestions for a priority-value given on the list >>>> over >>>>>>> the last few weeks with no clear convergence. The value "emergency" is >>>>>>> already included in the RFC3261 definition, but some others have >>>> voiced >>>>>>> a preference to define a new priority-value, using other-priority = >>>> token. >>>>>>> >>>>>>> Priority = "Priority" HCOLON priority-value >>>>>>> >>>>>>> priority-value = "emergency" / "urgent" / "normal" >>>>>>> >>>>>>> / "non-urgent" / other-priority >>>>>>> >>>>>>> other-priority = token >>>>>>> >>>>>>> We've seen a few mentioned on the list, now the chairs are calling to >>>>>>> close the list of candidate values, and request the work group to vote >>>>>>> their choice. >>>>>>> >>>>>>> Of the priority-values put out there on the list, we have the >>>> following >>>>>>> mentioned a few times: >>>>>>> >>>>>>> - emergency >>>>>>> >>>>>>> - emergency-callback >>>>>>> >>>>>>> - psap-callback >>>>>>> >>>>>>> Also mentioned once were: >>>>>>> >>>>>>> - expedited-emergency >>>>>>> >>>>>>> - urgent-emergency >>>>>>> >>>>>>> - emergency-override >>>>>>> >>>>>>> If I've forgotten one, please let me know. >>>>>>> >>>>>>> Send your vote to the ecrit list. The voting will go through 18:00 >>>>>>> (Pacific), next Friday, 9/21/2012. >>>>>>> >>>>>>> -roger. >>>>>>> >>>>>>> *From:*ecrit-bounces@ietf.org >>>>>>> [mailto:ecrit-bounces@ietf.org] *On Behalf Of *Christer Holmberg >>>>>>> *Sent:* Wednesday, September 12, 2012 5:32 AM >>>>>>> *To:* ecrit@ietf.org >>>>>>> *Subject:* [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback- >>>> 05 >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I've submitted a new version of the psap-callback draft, due to >>>>>>> expiration of the previous version. >>>>>>> >>>>>>> There are NO changes compared to the previous version. >>>>>>> >>>>>>> Once I get some guidance on where to define the new SIP Priority >>>> header >>>>>>> field "psap-callback" value, I will either update this draft or submit >>>> a >>>>>>> separate one in SIPCORE. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> CONFIDENTIALITY NOTICE: The information contained in this message may >>>> be >>>>>>> privileged and/or confidential. If you are not the intended recipient, >>>>>>> or responsible for delivering this message to the intended recipient, >>>>>>> any review, forwarding, dissemination, distribution or copying of this >>>>>>> communication or any attachment(s) is strictly prohibited. If you have >>>>>>> received this message in error, please notify the sender immediately, >>>>>>> and delete it and all attachments from your computer and network. >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > From keith.drage@alcatel-lucent.com Wed Sep 26 13:38:36 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3EC21F8587 for ; Wed, 26 Sep 2012 13:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0whbleOkZ7E for ; Wed, 26 Sep 2012 13:38:35 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id D02F021F8588 for ; Wed, 26 Sep 2012 13:38:34 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8QKcV9X027217 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 26 Sep 2012 22:38:31 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 26 Sep 2012 22:38:31 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "ecrit@ietf.org" , "rai-ads@tools.ietf.org" Date: Wed, 26 Sep 2012 22:38:29 +0200 Thread-Topic: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value Thread-Index: Ac2cHGixkMbVKMIqTJapg/2hQpLGwQACZboA Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22@ESESSCMS0356.eemea.ericsson.se> <50631D26.70609@alum.mit.edu> <35047045-145A-4FF7-B69C-7B5182E9DCB5@neustar.biz> <15AA7501-47C7-4FFB-B822-B47C3A6D8AB8@gmx.net> <506354E9.9030001@alum.mit.edu> In-Reply-To: <506354E9.9030001@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 20:38:36 -0000 > > Both RFC 3968 and RFC 3969 found it necessary to update RFC 3427, the > predecessor of RFC 5727 (which is now obsolete) in order to do the work > they do. However not entirely clear to me why they needed to do that, > given that they don't seem to change the registration requirements for > anything defined in that document. >=20 > I agree with all the above, except that AFAIK 5727 is *not* obsolete. > That is not what I said. It is the predecessor of RFC 5727 that is obsolete= . > But I don't understand *why* introducing the IANA registries after the > fact for things first defined in 3261 was not an update to 3261. > AFAIK the intent was to change normative behavior - that defining a new > value requires updating the corresponding registry. I've given you three examples of documents that create IANA registries with= out updating the specification that defined the codespace in the first plac= e. Can you point me at an example that did the opposite? Otherwise I'd argue that custom and practice strongly argues for this not b= eing a reason for updating. > Responding to Brian, I don't understand how the use of the IANA registry > can be informative. It isn't useful if it isn't normative. > IANA registries are informative. They are there to prevent dual assignment = of codepoints by RFCs, and to give pointers to the document that defines th= e codepoint. It is the concerned RFC that defines any normative material, and it should = do that outside the IANA considerations subclause. Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: 26 September 2012 20:18 > To: ecrit@ietf.org; rai-ads@tools.ietf.org > Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 > - select priority-value >=20 > On 9/26/12 1:36 PM, DRAGE, Keith (Keith) wrote: > > The documents that add registries for stuff originally defined in RFC > 3261 are RFC 5727, RFC 3968 and RFC 3969. > > > > None of those documents found it necessary to update RFC 3261 in order > to do so. > > > > Both RFC 3968 and RFC 3969 found it necessary to update RFC 3427, the > predecessor of RFC 5727 (which is now obsolete) in order to do the work > they do. However not entirely clear to me why they needed to do that, > given that they don't seem to change the registration requirements for > anything defined in that document. >=20 > I agree with all the above, except that AFAIK 5727 is *not* obsolete. >=20 > But I don't understand *why* introducing the IANA registries after the > fact for things first defined in 3261 was not an update to 3261. > AFAIK the intent was to change normative behavior - that defining a new > value requires updating the corresponding registry. >=20 > The fundamental point of all this is tracability. If I want to find all > the defined values for the priority header, where do I look? The first > place I would start is where the Priority header is defined - 3261. Next > I might look at all documents listed as updating 3261. If 3261 had > spelled out an IANA registry for priority values then I would look > there. But it doesn't. If some document that does update 3261 had > specified an IANA registry then that would tell me where to look. > Otherwise I think every draft that adds a priority value will need to > indicate that it updates 3261 to preserve traceability. >=20 > But that same argument applies to header field parameters. ISTM that > 3427, and hence 5727, should have been considered updates to 3261. And > then 3968, which updated 3427, would have transitively updated 3261. >=20 > This document could be viewed as analogous to 3968, and so update 5727. >=20 > Responding to Brian, I don't understand how the use of the IANA registry > can be informative. It isn't useful if it isn't normative. >=20 > IMO we need AD input on this. >=20 > > So from an IANA registration perspective I don't see the need to update > any other RFC. > > > > The other aspect is that we create a registration policy for the > registry. RFC 3968 did that but did not need to update RFC 3261 in order > to do so. >=20 > I agree that the policy needs to be defined. (You can't establish an > IANA registry without choosing a policy.) I suggest that it be Standards > Action. >=20 > Thanks, > Paul >=20 > > As to whether there are other aspects of RFC 3261 that need to be > extended, and therefore cause an update. > > > > - Discussion seems to have identified no need to enhance the RFC 3261 > ABNF. > > > > - I note that the inclusion of the header field is currently not > allowed in OPTIONS or REFER methods, while it is allowed in every other > dialog creating or standalone method - we might want to allow that, in > which case we would update RFC 3261 and RFC 3515 respectively. > > > > Regards > > > > Keith > > > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > >> Hannes Tschofenig > >> Sent: 26 September 2012 17:58 > >> To: Rosen, Brian > >> Cc: rai-ads@tools.ietf.org; sipcore-chairs@tools.ietf.org; > ecrit@ietf.org > >> Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback= - > 05 > >> - select priority-value > >> > >> We are adding a new value to the Priority header field. I looked at RF= C > >> 3261 and at RFC 2076 but there was no guidance on how new values are > >> registered. There isn't even a registry for it. > >> > >> On Sep 26, 2012, at 7:35 PM, Rosen, Brian wrote: > >> > >>> Are we updating 3261? > >>> > >>> That's an AD/chair (with sipcore chairs I think) call, right? > >>> > >>> I'm okay either way -- it's not clear to me it changes 3261 in any wa= y. > >> I'd want sipcore to review of course, but not clear we need to update > 3261. > >>> > >>> Brian > >>> > >>> On Sep 26, 2012, at 11:20 AM, Paul Kyzivat > >> wrote: > >>> > >>>> On 9/26/12 5:51 AM, Christer Holmberg wrote: > >>>>> Thanks, Roger! > >>>>> > >>>>> We intend to submit a new version of the callback draft, with text > >>>>> defining the new value. > >>>>> > >>>>> But, I guess we should also verify with the ADs/SIPCORE chairs that > it > >>>>> is ok to define the new value in ECRIT. > >>>> > >>>> I will defer to the ADs, but it seems to me that it should be > >> sufficient to: > >>>> > >>>> - In this draft, do all the IANA considerations necessary to set up > the > >>>> new registry and register all the initial values, including all thos= e > >>>> defined in 3261 and the new one for this draft. > >>>> > >>>> - Advertise this draft (with the above) on the sipcore list. > >>>> > >>>> - Do a WGLC in both ECRIT and SIPCORE. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>> Regards, > >>>>> > >>>>> Christer > >>>>> > >>>>> *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On > >> Behalf > >>>>> Of *Roger Marshall > >>>>> *Sent:* 25. syyskuuta 2012 19:10 > >>>>> *To:* ecrit@ietf.org > >>>>> *Subject:* Re: [Ecrit] Draft new version: > >>>>> draft-ietf-ecrit-psap-callback-05 - select priority-value > >>>>> > >>>>> Based on the responses to my request for a priority-value, the vote > >>>>> totals came in as: > >>>>> > >>>>> Existing value of "emergency" =3D 4 > >>>>> > >>>>> New value of "psap-callback" =3D 7 > >>>>> > >>>>> New value (other than existing) =3D 1 > >>>>> > >>>>> Since the "new value - other than existing" lines up with psap- > >> callback, > >>>>> we have "psap-callback" favored at a count of 8 to 4. > >>>>> > >>>>> These results are clear, and are based on what is posted to the > >> current > >>>>> mail list. Therefore we should be able to move this draft forward. > >>>>> > >>>>> Thanks. > >>>>> > >>>>> -roger marshall. > >>>>> > >>>>> *From:*ecrit-bounces@ietf.org > >>>>> [mailto:ecrit-bounces@ietf.org] >> bounces@ietf.org]> > >>>>> *On Behalf Of *Roger Marshall > >>>>> *Sent:* Friday, September 14, 2012 2:37 PM > >>>>> *To:* ecrit@ietf.org > >>>>> *Subject:* Re: [Ecrit] Draft new version: > >>>>> draft-ietf-ecrit-psap-callback-05 - select priority-value > >>>>> > >>>>> All: > >>>>> > >>>>> We need to select a priority-value in order to move the > >>>>> ecrit-psap-callback draft forward. > >>>>> > >>>>> Putting aside, for the moment, the questions of if/how/where the > >>>>> priority-value token is defined (if a new value is required - e.g., > >>>>> whether RFC or Registry), we should be able to agree on the value > >> itself. > >>>>> > >>>>> We've seen some suggestions for a priority-value given on the list > >> over > >>>>> the last few weeks with no clear convergence. The value "emergency" > is > >>>>> already included in the RFC3261 definition, but some others have > >> voiced > >>>>> a preference to define a new priority-value, using other-priority = =3D > >> token. > >>>>> > >>>>> Priority =3D "Priority" HCOLON priority-value > >>>>> > >>>>> priority-value =3D "emergency" / "urgent" / "normal" > >>>>> > >>>>> / "non-urgent" / other-priority > >>>>> > >>>>> other-priority =3D token > >>>>> > >>>>> We've seen a few mentioned on the list, now the chairs are calling > to > >>>>> close the list of candidate values, and request the work group to > vote > >>>>> their choice. > >>>>> > >>>>> Of the priority-values put out there on the list, we have the > >> following > >>>>> mentioned a few times: > >>>>> > >>>>> - emergency > >>>>> > >>>>> - emergency-callback > >>>>> > >>>>> - psap-callback > >>>>> > >>>>> Also mentioned once were: > >>>>> > >>>>> - expedited-emergency > >>>>> > >>>>> - urgent-emergency > >>>>> > >>>>> - emergency-override > >>>>> > >>>>> If I've forgotten one, please let me know. > >>>>> > >>>>> Send your vote to the ecrit list. The voting will go through 18:00 > >>>>> (Pacific), next Friday, 9/21/2012. > >>>>> > >>>>> -roger. > >>>>> > >>>>> *From:*ecrit-bounces@ietf.org > >>>>> [mailto:ecrit-bounces@ietf.org] *On Behalf Of *Christer Holmberg > >>>>> *Sent:* Wednesday, September 12, 2012 5:32 AM > >>>>> *To:* ecrit@ietf.org > >>>>> *Subject:* [Ecrit] Draft new version: draft-ietf-ecrit-psap- > callback- > >> 05 > >>>>> > >>>>> Hi, > >>>>> > >>>>> I've submitted a new version of the psap-callback draft, due to > >>>>> expiration of the previous version. > >>>>> > >>>>> There are NO changes compared to the previous version. > >>>>> > >>>>> Once I get some guidance on where to define the new SIP Priority > >> header > >>>>> field "psap-callback" value, I will either update this draft or > submit > >> a > >>>>> separate one in SIPCORE. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Christer > >>>>> > >>>>> CONFIDENTIALITY NOTICE: The information contained in this message > may > >> be > >>>>> privileged and/or confidential. If you are not the intended > recipient, > >>>>> or responsible for delivering this message to the intended recipien= t, > >>>>> any review, forwarding, dissemination, distribution or copying of > this > >>>>> communication or any attachment(s) is strictly prohibited. If you > have > >>>>> received this message in error, please notify the sender immediatel= y, > >>>>> and delete it and all attachments from your computer and network. > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Ecrit mailing list > >>>>> Ecrit@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ecrit > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From pkyzivat@alum.mit.edu Wed Sep 26 14:04:51 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636A221F8546 for ; Wed, 26 Sep 2012 14:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.396 X-Spam-Level: X-Spam-Status: No, score=-0.396 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBiZzgILVdpi for ; Wed, 26 Sep 2012 14:04:50 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA8921F8540 for ; Wed, 26 Sep 2012 14:04:49 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta02.westchester.pa.mail.comcast.net with comcast id 3wG81k00A1ap0As51x4tla; Wed, 26 Sep 2012 21:04:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id 3x0M1k00Z3ZTu2S3ix0MZw; Wed, 26 Sep 2012 21:00:22 +0000 Message-ID: <50636CC4.1010806@alum.mit.edu> Date: Wed, 26 Sep 2012 16:59:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22@ESESSCMS0356.eemea.ericsson.se> <50631D26.70609@alum.mit.edu> <35047045-145A-4FF7-B69C-7B5182E9DCB5@neustar.biz> <15AA7501-47C7-4FFB-B822-B47C3A6D8AB8@gmx.net> <506354E9.9030001@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rai-ads@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 21:04:51 -0000 On 9/26/12 4:38 PM, DRAGE, Keith (Keith) wrote: >>> Both RFC 3968 and RFC 3969 found it necessary to update RFC 3427, the >> predecessor of RFC 5727 (which is now obsolete) in order to do the work >> they do. However not entirely clear to me why they needed to do that, >> given that they don't seem to change the registration requirements for >> anything defined in that document. >> >> I agree with all the above, except that AFAIK 5727 is *not* obsolete. >> > > That is not what I said. It is the predecessor of RFC 5727 that is obsolete. > >> But I don't understand *why* introducing the IANA registries after the >> fact for things first defined in 3261 was not an update to 3261. >> AFAIK the intent was to change normative behavior - that defining a new >> value requires updating the corresponding registry. > > I've given you three examples of documents that create IANA registries without updating the specification that defined the codespace in the first place. > > Can you point me at an example that did the opposite? Yes, I know you did. I'm seeking the rationale for why that was the right thing to do. > Otherwise I'd argue that custom and practice strongly argues for this not being a reason for updating. I more or less agree. But still it seems wrong to me. There should be a mechanism to discover what is valid and what is not according to a spec without the need to read *everything* published subsequent to that spec. >> Responding to Brian, I don't understand how the use of the IANA registry >> can be informative. It isn't useful if it isn't normative. >> > > IANA registries are informative. They are there to prevent dual assignment of codepoints by RFCs, and to give pointers to the document that defines the codepoint. > > It is the concerned RFC that defines any normative material, and it should do that outside the IANA considerations subclause. And the RFC can do that by requiring that the IANA registry be used. In that case the spec is delegating the authoritative reference for all defined values to the registry. Otherwise, I guess the IANA registry could be optional and informative. But then to discover the complete set of valid values would be impossible, or would require that specs adding values also each indicate that they update the doc that defines the syntax. ISTM we have been entirely too sloppy about this sort of thing in the past. We have gradually been getting better, but precedent doesn't always give good practice. AFAIK, when 3261 was written, the syntax of the Priority header field was intended to be exhaustive of all valid values, and was there to make provision for future extensions, not to allow non-standard use of other values. The straightforward way to add new values in that context would be to revise, or update, 3261 and change the syntax of to list added values. *This* draft could add "psap-callback" that way and then IMO there would be no controversy. Doing it by introducing an IANA registry is a more modern way, and more convenient for lookups. But only if it can be relied upon to be as authoritative. Thanks, Paul From rjsparks@nostrum.com Thu Sep 27 10:57:35 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53F621F85EF for ; Thu, 27 Sep 2012 10:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uT9kR7Ac69dT for ; Thu, 27 Sep 2012 10:57:35 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D8E6F21F85C6 for ; Thu, 27 Sep 2012 10:57:34 -0700 (PDT) Received: from unnumerable.local (pool-173-57-93-208.dllstx.fios.verizon.net [173.57.93.208]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q8RHvWOp054806 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 27 Sep 2012 12:57:32 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <5064938C.7060306@nostrum.com> Date: Thu, 27 Sep 2012 12:57:32 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22@ESESSCMS0356.eemea.ericsson.se> <50631D26.70609@alum.mit.edu> <35047045-145A-4FF7-B69C-7B5182E9DCB5@neustar.biz> <15AA7501-47C7-4FFB-B822-B47C3A6D8AB8@gmx.net> <506354E9.9030001@alum.mit.edu> <50636CC4.1010806@alum.mit.edu> In-Reply-To: <50636CC4.1010806@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 173.57.93.208 is authenticated by a trusted mechanism) Cc: "rai-ads@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 17:57:35 -0000 Paul - I think Keith's analysis around Updates is right. Using an extension point isn't enough by itself to invoke Updates. Having a registry for values like this is good. Working to make sure the registry is complete is good. Saying that the registry is the normative list isn't. The RFC series is where we keep the normative requirements. RjS On 9/26/12 3:59 PM, Paul Kyzivat wrote: > On 9/26/12 4:38 PM, DRAGE, Keith (Keith) wrote: >>>> Both RFC 3968 and RFC 3969 found it necessary to update RFC 3427, the >>> predecessor of RFC 5727 (which is now obsolete) in order to do the work >>> they do. However not entirely clear to me why they needed to do that, >>> given that they don't seem to change the registration requirements for >>> anything defined in that document. >>> >>> I agree with all the above, except that AFAIK 5727 is *not* obsolete. >>> >> >> That is not what I said. It is the predecessor of RFC 5727 that is >> obsolete. >> >>> But I don't understand *why* introducing the IANA registries after the >>> fact for things first defined in 3261 was not an update to 3261. >>> AFAIK the intent was to change normative behavior - that defining a new >>> value requires updating the corresponding registry. >> >> I've given you three examples of documents that create IANA >> registries without updating the specification that defined the >> codespace in the first place. >> >> Can you point me at an example that did the opposite? > > Yes, I know you did. I'm seeking the rationale for why that was the > right thing to do. > >> Otherwise I'd argue that custom and practice strongly argues for this >> not being a reason for updating. > > I more or less agree. But still it seems wrong to me. > There should be a mechanism to discover what is valid and what is not > according to a spec without the need to read *everything* published > subsequent to that spec. > >>> Responding to Brian, I don't understand how the use of the IANA >>> registry >>> can be informative. It isn't useful if it isn't normative. >>> >> >> IANA registries are informative. They are there to prevent dual >> assignment of codepoints by RFCs, and to give pointers to the >> document that defines the codepoint. >> >> It is the concerned RFC that defines any normative material, and it >> should do that outside the IANA considerations subclause. > > And the RFC can do that by requiring that the IANA registry be used. > In that case the spec is delegating the authoritative reference for > all defined values to the registry. > > Otherwise, I guess the IANA registry could be optional and > informative. But then to discover the complete set of valid values > would be impossible, or would require that specs adding values also > each indicate that they update the doc that defines the syntax. > > ISTM we have been entirely too sloppy about this sort of thing in the > past. We have gradually been getting better, but precedent doesn't > always give good practice. > > AFAIK, when 3261 was written, the syntax of the Priority header field > was intended to be exhaustive of all valid values, and > was there to make provision for future extensions, > not to allow non-standard use of other values. The straightforward way > to add new values in that context would be to revise, or update, 3261 > and change the syntax of to list added values. > > *This* draft could add "psap-callback" that way and then IMO there > would be no controversy. > > Doing it by introducing an IANA registry is a more modern way, and > more convenient for lookups. But only if it can be relied upon to be > as authoritative. > > Thanks, > Paul > From rjsparks@nostrum.com Thu Sep 27 10:58:25 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FA721F8522 for ; Thu, 27 Sep 2012 10:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aW5cIRVrU4PJ for ; Thu, 27 Sep 2012 10:58:25 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D7DCF21F849C for ; Thu, 27 Sep 2012 10:58:24 -0700 (PDT) Received: from unnumerable.local (pool-173-57-93-208.dllstx.fios.verizon.net [173.57.93.208]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q8RHwNrS054835 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 27 Sep 2012 12:58:23 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <506493BF.9090606@nostrum.com> Date: Thu, 27 Sep 2012 12:58:23 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22@ESESSCMS0356.eemea.ericsson.se> <50631D26.70609@alum.mit.edu> In-Reply-To: <50631D26.70609@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 173.57.93.208 is authenticated by a trusted mechanism) Cc: "sipcore-chairs@tools.ietf.org" , "rai-ads@tools.ietf.org" , ecrit@ietf.org Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 17:58:25 -0000 On 9/26/12 10:20 AM, Paul Kyzivat wrote: > On 9/26/12 5:51 AM, Christer Holmberg wrote: >> Thanks, Roger! >> >> We intend to submit a new version of the callback draft, with text >> defining the new value. >> >> But, I guess we should also verify with the ADs/SIPCORE chairs that it >> is ok to define the new value in ECRIT. > > I will defer to the ADs, but it seems to me that it should be > sufficient to: > > - In this draft, do all the IANA considerations necessary to set up the > new registry and register all the initial values, including all those > defined in 3261 and the new one for this draft. > > - Advertise this draft (with the above) on the sipcore list. > > - Do a WGLC in both ECRIT and SIPCORE. This seems reasonable to me. > > Thanks, > Paul > >> Regards, >> >> Christer >> >> *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf >> Of *Roger Marshall >> *Sent:* 25. syyskuuta 2012 19:10 >> *To:* ecrit@ietf.org >> *Subject:* Re: [Ecrit] Draft new version: >> draft-ietf-ecrit-psap-callback-05 - select priority-value >> >> Based on the responses to my request for a priority-value, the vote >> totals came in as: >> >> Existing value of “emergency” = 4 >> >> New value of “psap-callback” = 7 >> >> New value (other than existing) = 1 >> >> Since the “new value – other than existing” lines up with psap-callback, >> we have “psap-callback” favored at a count of 8 to 4. >> >> These results are clear, and are based on what is posted to the current >> mail list. Therefore we should be able to move this draft forward. >> >> Thanks. >> >> -roger marshall. >> >> *From:*ecrit-bounces@ietf.org >> [mailto:ecrit-bounces@ietf.org] >> *On Behalf Of *Roger Marshall >> *Sent:* Friday, September 14, 2012 2:37 PM >> *To:* ecrit@ietf.org >> *Subject:* Re: [Ecrit] Draft new version: >> draft-ietf-ecrit-psap-callback-05 - select priority-value >> >> All: >> >> We need to select a priority-value in order to move the >> ecrit-psap-callback draft forward. >> >> Putting aside, for the moment, the questions of if/how/where the >> priority-value token is defined (if a new value is required - e.g., >> whether RFC or Registry), we should be able to agree on the value >> itself. >> >> We’ve seen some suggestions for a priority-value given on the list over >> the last few weeks with no clear convergence. The value “emergency” is >> already included in the RFC3261 definition, but some others have voiced >> a preference to define a new priority-value, using other-priority = >> token. >> >> Priority = "Priority" HCOLON priority-value >> >> priority-value = "emergency" / "urgent" / "normal" >> >> / "non-urgent" / other-priority >> >> other-priority = token >> >> We’ve seen a few mentioned on the list, now the chairs are calling to >> close the list of candidate values, and request the work group to vote >> their choice. >> >> Of the priority-values put out there on the list, we have the following >> mentioned a few times: >> >> - emergency >> >> - emergency-callback >> >> - psap-callback >> >> Also mentioned once were: >> >> - expedited-emergency >> >> - urgent-emergency >> >> - emergency-override >> >> If I’ve forgotten one, please let me know. >> >> Send your vote to the ecrit list. The voting will go through 18:00 >> (Pacific), next Friday, 9/21/2012. >> >> -roger. >> >> *From:*ecrit-bounces@ietf.org >> [mailto:ecrit-bounces@ietf.org] *On Behalf Of *Christer Holmberg >> *Sent:* Wednesday, September 12, 2012 5:32 AM >> *To:* ecrit@ietf.org >> *Subject:* [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 >> >> Hi, >> >> I’ve submitted a new version of the psap-callback draft, due to >> expiration of the previous version. >> >> There are NO changes compared to the previous version. >> >> Once I get some guidance on where to define the new SIP Priority header >> field “psap-callback” value, I will either update this draft or submit a >> separate one in SIPCORE. >> >> Regards, >> >> Christer >> >> CONFIDENTIALITY NOTICE: The information contained in this message may be >> privileged and/or confidential. If you are not the intended recipient, >> or responsible for delivering this message to the intended recipient, >> any review, forwarding, dissemination, distribution or copying of this >> communication or any attachment(s) is strictly prohibited. If you have >> received this message in error, please notify the sender immediately, >> and delete it and all attachments from your computer and network. >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > From pkyzivat@alum.mit.edu Thu Sep 27 15:34:24 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505CB21F85C6 for ; Thu, 27 Sep 2012 15:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COH6Z021vB4f for ; Thu, 27 Sep 2012 15:34:23 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 4904F21F860E for ; Thu, 27 Sep 2012 15:34:23 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta03.westchester.pa.mail.comcast.net with comcast id 4K2z1k04a1wpRvQ53NaT7r; Thu, 27 Sep 2012 22:34:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id 4Nks1k00g3ZTu2S3eNksUl; Thu, 27 Sep 2012 22:44:53 +0000 Message-ID: <5064D342.4090601@alum.mit.edu> Date: Thu, 27 Sep 2012 18:29:22 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Robert Sparks References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22@ESESSCMS0356.eemea.ericsson.se> <50631D26.70609@alum.mit.edu> <35047045-145A-4FF7-B69C-7B5182E9DCB5@neustar.biz> <15AA7501-47C7-4FFB-B822-B47C3A6D8AB8@gmx.net> <506354E9.9030001@alum.mit.edu> <50636CC4.1010806@alum.mit.edu> <5064938C.7060306@nostrum.com> In-Reply-To: <5064938C.7060306@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rai-ads@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 22:34:24 -0000 On 9/27/12 1:57 PM, Robert Sparks wrote: > Paul - > > I think Keith's analysis around Updates is right. Using an extension > point isn't enough > by itself to invoke Updates. > > Having a registry for values like this is good. Working to make sure the > registry is complete > is good. Saying that the registry is the normative list isn't. The RFC > series is where we keep > the normative requirements. Then each draft that will be extending something that is managed by an IANA registry should also be marked as updating the spec that defined the thing being extended. (E.g. this draft should be marked as updating 3261 where Priority is defined.) That would preserve the traceability without reference to the IANA registry. But that isn't being done. And that will only work when the new values come from an RFC. E.g. for Expert Review and FCFS policies there is no other traceable record than the one in IANA. Otherwise I think you are saying that there is *no* authoritative and exhaustive list of all legitimate values. Let me be clear. The way I *think* this should work is: 1) ideally a spec that defines a new header, etc. will establish an IANA registry from day one. Then it is entirely clear where to look for an authoritative list of all legal values. Subsequent additions to the registry do *not* Update the spec. 2) if a spec fails to do (1), and instead just defines values in the text of the draft: 2a) a subsequent draft may define an IANA registry to allow additions. In this case the draft that establishes the IANA registry should be marked as updating the original draft(rfc), and should populate the registry with the values that were defined in the original draft. This preserves traceability: someone looking at the original can see the Updates indication, and from that discover the IANA registry, and so know where to look. Subsequent additions to the registry do *not* Update either the base spec or the draft that established the registry. 2b) As an alternative to (2a) a draft that wants to define a new value could just do so directly without recourse to IANA, using a syntax update. E.g. foo /= "newvalue" In this case it must be marked as Updates the base spec. This again preserves traceability: when reading the original draft the Updates link will lead to discovering the added value. But it appears that the precedents we have don't do any of this. RFC3968 imposes a new MUST requirement for IANA registration of header field parameters. In this regard it is *effectively* an update to 3261. But it does not indicate that it updates 3261. Instead it says it updates 3427. RFC3427 also didn't indicate that it updated 3261, and perhaps it didn't - it didn't change the IANA registries. As a result, a naive reader of 3261 would have no obvious way to discover that newly defined header field parameters MUST be registered with IANA. Thanks, Paul > RjS > > On 9/26/12 3:59 PM, Paul Kyzivat wrote: >> On 9/26/12 4:38 PM, DRAGE, Keith (Keith) wrote: >>>>> Both RFC 3968 and RFC 3969 found it necessary to update RFC 3427, the >>>> predecessor of RFC 5727 (which is now obsolete) in order to do the work >>>> they do. However not entirely clear to me why they needed to do that, >>>> given that they don't seem to change the registration requirements for >>>> anything defined in that document. >>>> >>>> I agree with all the above, except that AFAIK 5727 is *not* obsolete. >>>> >>> >>> That is not what I said. It is the predecessor of RFC 5727 that is >>> obsolete. >>> >>>> But I don't understand *why* introducing the IANA registries after the >>>> fact for things first defined in 3261 was not an update to 3261. >>>> AFAIK the intent was to change normative behavior - that defining a new >>>> value requires updating the corresponding registry. >>> >>> I've given you three examples of documents that create IANA >>> registries without updating the specification that defined the >>> codespace in the first place. >>> >>> Can you point me at an example that did the opposite? >> >> Yes, I know you did. I'm seeking the rationale for why that was the >> right thing to do. >> >>> Otherwise I'd argue that custom and practice strongly argues for this >>> not being a reason for updating. >> >> I more or less agree. But still it seems wrong to me. >> There should be a mechanism to discover what is valid and what is not >> according to a spec without the need to read *everything* published >> subsequent to that spec. >> >>>> Responding to Brian, I don't understand how the use of the IANA >>>> registry >>>> can be informative. It isn't useful if it isn't normative. >>>> >>> >>> IANA registries are informative. They are there to prevent dual >>> assignment of codepoints by RFCs, and to give pointers to the >>> document that defines the codepoint. >>> >>> It is the concerned RFC that defines any normative material, and it >>> should do that outside the IANA considerations subclause. >> >> And the RFC can do that by requiring that the IANA registry be used. >> In that case the spec is delegating the authoritative reference for >> all defined values to the registry. >> >> Otherwise, I guess the IANA registry could be optional and >> informative. But then to discover the complete set of valid values >> would be impossible, or would require that specs adding values also >> each indicate that they update the doc that defines the syntax. >> >> ISTM we have been entirely too sloppy about this sort of thing in the >> past. We have gradually been getting better, but precedent doesn't >> always give good practice. >> >> AFAIK, when 3261 was written, the syntax of the Priority header field >> was intended to be exhaustive of all valid values, and >> was there to make provision for future extensions, >> not to allow non-standard use of other values. The straightforward way >> to add new values in that context would be to revise, or update, 3261 >> and change the syntax of to list added values. >> >> *This* draft could add "psap-callback" that way and then IMO there >> would be no controversy. >> >> Doing it by introducing an IANA registry is a more modern way, and >> more convenient for lookups. But only if it can be relied upon to be >> as authoritative. >> >> Thanks, >> Paul >> > > From martin.thomson@gmail.com Thu Sep 27 22:00:14 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EC921F8578 for ; Thu, 27 Sep 2012 22:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.706 X-Spam-Level: X-Spam-Status: No, score=-3.706 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEj8jI41+OqV for ; Thu, 27 Sep 2012 22:00:12 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE9A21F850D for ; Thu, 27 Sep 2012 22:00:12 -0700 (PDT) Received: by lamb11 with SMTP id b11so815697lam.31 for ; Thu, 27 Sep 2012 22:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3iMl/rMliFfCBK5GBoN8xqdoY+TYmp6x27hOBjV+7Qo=; b=W+8rPhlMuGCHOr2qS0veReS/V5cp+d/WQzFdNsAAEP/UO6BcBjARAi/oC0GSrTcEZB jkYXtt1TznwpPuI0FmC0IHJMIjadKw5REsUdMtIag90IAgbfCmbLavuPSyOtXl4XTPhO W6jWqcGshZRc4on8Ds4OALTCjojK/uYmP2OuOB8rundgo31VQmq4KeIPdrSgdLiBeEJM LeydbC1563uLUWUmLQ/ls0nmic/rvm+baEJI7kWfbl8hMjIWNm3MavXRXgoIGMsWvHLc //4GebFmOYq3Tw+c+q3jpxr2E6ox4kLjmHRMaUtpNPF7Gds8lqWiRPXTHrqYFI4cZCB8 Uebg== MIME-Version: 1.0 Received: by 10.152.103.146 with SMTP id fw18mr4934978lab.30.1348808411231; Thu, 27 Sep 2012 22:00:11 -0700 (PDT) Received: by 10.112.1.36 with HTTP; Thu, 27 Sep 2012 22:00:11 -0700 (PDT) In-Reply-To: <5064D342.4090601@alum.mit.edu> References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22@ESESSCMS0356.eemea.ericsson.se> <50631D26.70609@alum.mit.edu> <35047045-145A-4FF7-B69C-7B5182E9DCB5@neustar.biz> <15AA7501-47C7-4FFB-B822-B47C3A6D8AB8@gmx.net> <506354E9.9030001@alum.mit.edu> <50636CC4.1010806@alum.mit.edu> <5064938C.7060306@nostrum.com> <5064D342.4090601@alum.mit.edu> Date: Thu, 27 Sep 2012 22:00:11 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: "rai-ads@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 05:00:14 -0000 I agree entirely with the substance of Paul's argument. With one exception in the detail, even a non-naive reader of RFCs will probably miss all the stuff about "updated by RFCXXX" and whatever and so forth. There are many RFCs that are relevant to a problem I work on, but I only discover them later by accident or when someone else points out their relevance. There is just too much to read and so many titles are useless to the point of being unhelpful (e.g., RFC 6125). On 27 September 2012 15:29, Paul Kyzivat wrote: > On 9/27/12 1:57 PM, Robert Sparks wrote: >> >> Paul - >> >> I think Keith's analysis around Updates is right. Using an extension >> point isn't enough >> by itself to invoke Updates. >> >> Having a registry for values like this is good. Working to make sure the >> registry is complete >> is good. Saying that the registry is the normative list isn't. The RFC >> series is where we keep >> the normative requirements. > > > Then each draft that will be extending something that is managed by an IANA > registry should also be marked as updating the spec that defined the thing > being extended. (E.g. this draft should be marked as updating 3261 where > Priority is defined.) That would preserve the traceability without reference > to the IANA registry. But that isn't being done. > > And that will only work when the new values come from an RFC. E.g. for > Expert Review and FCFS policies there is no other traceable record than the > one in IANA. > > Otherwise I think you are saying that there is *no* authoritative and > exhaustive list of all legitimate values. > > Let me be clear. The way I *think* this should work is: > > 1) ideally a spec that defines a new header, etc. will establish an IANA > registry from day one. Then it is entirely clear where to look for an > authoritative list of all legal values. Subsequent additions to the registry > do *not* Update the spec. > > 2) if a spec fails to do (1), and instead just defines values in the text of > the draft: > > 2a) a subsequent draft may define an IANA registry to allow additions. In > this case the draft that establishes the IANA registry should be marked as > updating the original draft(rfc), and should populate the registry with the > values that were defined in the original draft. This preserves traceability: > someone looking at the original can see the Updates indication, and from > that discover the IANA registry, and so know where to look. Subsequent > additions to the registry do *not* Update either the base spec or the draft > that established the registry. > > 2b) As an alternative to (2a) a draft that wants to define a new value could > just do so directly without recourse to IANA, using a syntax update. E.g. > > foo /= "newvalue" > > In this case it must be marked as Updates the base spec. This again > preserves traceability: when reading the original draft the Updates link > will lead to discovering the added value. > > But it appears that the precedents we have don't do any of this. RFC3968 > imposes a new MUST requirement for IANA registration of header field > parameters. In this regard it is *effectively* an update to 3261. But it > does not indicate that it updates 3261. Instead it says it updates 3427. > RFC3427 also didn't indicate that it updated 3261, and perhaps it didn't - > it didn't change the IANA registries. > > As a result, a naive reader of 3261 would have no obvious way to discover > that newly defined header field parameters MUST be registered with IANA. > > Thanks, > Paul > > >> RjS >> >> On 9/26/12 3:59 PM, Paul Kyzivat wrote: >>> >>> On 9/26/12 4:38 PM, DRAGE, Keith (Keith) wrote: >>>>>> >>>>>> Both RFC 3968 and RFC 3969 found it necessary to update RFC 3427, the >>>>> >>>>> predecessor of RFC 5727 (which is now obsolete) in order to do the work >>>>> they do. However not entirely clear to me why they needed to do that, >>>>> given that they don't seem to change the registration requirements for >>>>> anything defined in that document. >>>>> >>>>> I agree with all the above, except that AFAIK 5727 is *not* obsolete. >>>>> >>>> >>>> That is not what I said. It is the predecessor of RFC 5727 that is >>>> obsolete. >>>> >>>>> But I don't understand *why* introducing the IANA registries after the >>>>> fact for things first defined in 3261 was not an update to 3261. >>>>> AFAIK the intent was to change normative behavior - that defining a new >>>>> value requires updating the corresponding registry. >>>> >>>> >>>> I've given you three examples of documents that create IANA >>>> registries without updating the specification that defined the >>>> codespace in the first place. >>>> >>>> Can you point me at an example that did the opposite? >>> >>> >>> Yes, I know you did. I'm seeking the rationale for why that was the >>> right thing to do. >>> >>>> Otherwise I'd argue that custom and practice strongly argues for this >>>> not being a reason for updating. >>> >>> >>> I more or less agree. But still it seems wrong to me. >>> There should be a mechanism to discover what is valid and what is not >>> according to a spec without the need to read *everything* published >>> subsequent to that spec. >>> >>>>> Responding to Brian, I don't understand how the use of the IANA >>>>> registry >>>>> can be informative. It isn't useful if it isn't normative. >>>>> >>>> >>>> IANA registries are informative. They are there to prevent dual >>>> assignment of codepoints by RFCs, and to give pointers to the >>>> document that defines the codepoint. >>>> >>>> It is the concerned RFC that defines any normative material, and it >>>> should do that outside the IANA considerations subclause. >>> >>> >>> And the RFC can do that by requiring that the IANA registry be used. >>> In that case the spec is delegating the authoritative reference for >>> all defined values to the registry. >>> >>> Otherwise, I guess the IANA registry could be optional and >>> informative. But then to discover the complete set of valid values >>> would be impossible, or would require that specs adding values also >>> each indicate that they update the doc that defines the syntax. >>> >>> ISTM we have been entirely too sloppy about this sort of thing in the >>> past. We have gradually been getting better, but precedent doesn't >>> always give good practice. >>> >>> AFAIK, when 3261 was written, the syntax of the Priority header field >>> was intended to be exhaustive of all valid values, and >>> was there to make provision for future extensions, >>> not to allow non-standard use of other values. The straightforward way >>> to add new values in that context would be to revise, or update, 3261 >>> and change the syntax of to list added values. >>> >>> *This* draft could add "psap-callback" that way and then IMO there >>> would be no controversy. >>> >>> Doing it by introducing an IANA registry is a more modern way, and >>> more convenient for lookups. But only if it can be relied upon to be >>> as authoritative. >>> >>> Thanks, >>> Paul >>> >> >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From pkyzivat@alum.mit.edu Fri Sep 28 09:06:57 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D77E21F859A for ; Fri, 28 Sep 2012 09:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HElhIRbNVt9A for ; Fri, 28 Sep 2012 09:06:56 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 4248F21F8592 for ; Fri, 28 Sep 2012 09:06:56 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 4g6H1k0020ldTLk5Bg70wW; Fri, 28 Sep 2012 16:07:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id 4g1m1k00Z3ZTu2S3Qg1m14; Fri, 28 Sep 2012 16:01:47 +0000 Message-ID: <5065C9F2.6060306@alum.mit.edu> Date: Fri, 28 Sep 2012 12:01:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Rosen, Brian" References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22@ESESSCMS0356.eemea.ericsson.se> <50631D26.70609@alum.mit.edu> <35047045-145A-4FF7-B69C-7B5182E9DCB5@neustar.biz> In-Reply-To: <35047045-145A-4FF7-B69C-7B5182E9DCB5@neustar.biz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "sipcore-chairs@tools.ietf.org" , "rai-ads@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 16:06:57 -0000 On 9/26/12 12:35 PM, Rosen, Brian wrote: > Are we updating 3261? > > That's an AD/chair (with sipcore chairs I think) call, right? > > I'm okay either way -- it's not clear to me it changes 3261 in any way. I'd want sipcore to review of course, but not clear we need to update 3261. Well, I'm not sure either. My first thought was that 3261 did not institute an IANA registry for Priority values, so putting one in effect now would be an update to 3261. This is analogous to putting in the IANA registry for header field parameters and parameter values. This was done by RFC3968. But I see that 3968 does not indicate that it updates 3261. (But it does update 3427, which also does *not* update 3261.) So I will defer to the ADs on what is the right way to do this. Thanks, Paul > Brian > > On Sep 26, 2012, at 11:20 AM, Paul Kyzivat wrote: > >> On 9/26/12 5:51 AM, Christer Holmberg wrote: >>> Thanks, Roger! >>> >>> We intend to submit a new version of the callback draft, with text >>> defining the new value. >>> >>> But, I guess we should also verify with the ADs/SIPCORE chairs that it >>> is ok to define the new value in ECRIT. >> >> I will defer to the ADs, but it seems to me that it should be sufficient to: >> >> - In this draft, do all the IANA considerations necessary to set up the >> new registry and register all the initial values, including all those >> defined in 3261 and the new one for this draft. >> >> - Advertise this draft (with the above) on the sipcore list. >> >> - Do a WGLC in both ECRIT and SIPCORE. >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf >>> Of *Roger Marshall >>> *Sent:* 25. syyskuuta 2012 19:10 >>> *To:* ecrit@ietf.org >>> *Subject:* Re: [Ecrit] Draft new version: >>> draft-ietf-ecrit-psap-callback-05 - select priority-value >>> >>> Based on the responses to my request for a priority-value, the vote >>> totals came in as: >>> >>> Existing value of “emergency” = 4 >>> >>> New value of “psap-callback” = 7 >>> >>> New value (other than existing) = 1 >>> >>> Since the “new value – other than existing” lines up with psap-callback, >>> we have “psap-callback” favored at a count of 8 to 4. >>> >>> These results are clear, and are based on what is posted to the current >>> mail list. Therefore we should be able to move this draft forward. >>> >>> Thanks. >>> >>> -roger marshall. >>> >>> *From:*ecrit-bounces@ietf.org >>> [mailto:ecrit-bounces@ietf.org] >>> *On Behalf Of *Roger Marshall >>> *Sent:* Friday, September 14, 2012 2:37 PM >>> *To:* ecrit@ietf.org >>> *Subject:* Re: [Ecrit] Draft new version: >>> draft-ietf-ecrit-psap-callback-05 - select priority-value >>> >>> All: >>> >>> We need to select a priority-value in order to move the >>> ecrit-psap-callback draft forward. >>> >>> Putting aside, for the moment, the questions of if/how/where the >>> priority-value token is defined (if a new value is required - e.g., >>> whether RFC or Registry), we should be able to agree on the value itself. >>> >>> We’ve seen some suggestions for a priority-value given on the list over >>> the last few weeks with no clear convergence. The value “emergency” is >>> already included in the RFC3261 definition, but some others have voiced >>> a preference to define a new priority-value, using other-priority = token. >>> >>> Priority = "Priority" HCOLON priority-value >>> >>> priority-value = "emergency" / "urgent" / "normal" >>> >>> / "non-urgent" / other-priority >>> >>> other-priority = token >>> >>> We’ve seen a few mentioned on the list, now the chairs are calling to >>> close the list of candidate values, and request the work group to vote >>> their choice. >>> >>> Of the priority-values put out there on the list, we have the following >>> mentioned a few times: >>> >>> - emergency >>> >>> - emergency-callback >>> >>> - psap-callback >>> >>> Also mentioned once were: >>> >>> - expedited-emergency >>> >>> - urgent-emergency >>> >>> - emergency-override >>> >>> If I’ve forgotten one, please let me know. >>> >>> Send your vote to the ecrit list. The voting will go through 18:00 >>> (Pacific), next Friday, 9/21/2012. >>> >>> -roger. >>> >>> *From:*ecrit-bounces@ietf.org >>> [mailto:ecrit-bounces@ietf.org] *On Behalf Of *Christer Holmberg >>> *Sent:* Wednesday, September 12, 2012 5:32 AM >>> *To:* ecrit@ietf.org >>> *Subject:* [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 >>> >>> Hi, >>> >>> I’ve submitted a new version of the psap-callback draft, due to >>> expiration of the previous version. >>> >>> There are NO changes compared to the previous version. >>> >>> Once I get some guidance on where to define the new SIP Priority header >>> field “psap-callback” value, I will either update this draft or submit a >>> separate one in SIPCORE. >>> >>> Regards, >>> >>> Christer >>> >>> CONFIDENTIALITY NOTICE: The information contained in this message may be >>> privileged and/or confidential. If you are not the intended recipient, >>> or responsible for delivering this message to the intended recipient, >>> any review, forwarding, dissemination, distribution or copying of this >>> communication or any attachment(s) is strictly prohibited. If you have >>> received this message in error, please notify the sender immediately, >>> and delete it and all attachments from your computer and network. >>> >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > From christer.holmberg@ericsson.com Sun Sep 30 03:58:23 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C39021F856C for ; Sun, 30 Sep 2012 03:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.092 X-Spam-Level: X-Spam-Status: No, score=-6.092 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cwxe56YpUOFm for ; Sun, 30 Sep 2012 03:58:22 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C046521F8528 for ; Sun, 30 Sep 2012 03:58:21 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-13-506825cc0383 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D2.A5.25676.CC528605; Sun, 30 Sep 2012 12:58:20 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sun, 30 Sep 2012 12:58:20 +0200 From: Christer Holmberg To: Paul Kyzivat , "Rosen, Brian" Date: Sun, 30 Sep 2012 12:57:08 +0200 Thread-Topic: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value Thread-Index: Ac2dk0ulYfo2aRgqT2W0KT7B9QSkzwBZwpPF Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FC7@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340A53BB93@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A6A2E22@ESESSCMS0356.eemea.ericsson.se> <50631D26.70609@alum.mit.edu> <35047045-145A-4FF7-B69C-7B5182E9DCB5@neustar.biz>, <5065C9F2.6060306@alum.mit.edu> In-Reply-To: <5065C9F2.6060306@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="windows-1254" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM+Jvre4Z1YwAg987tC2mnbzMbNG46Cmr xYoNB1gt9m6fx2hx6tVpZgdWj7/vPzB5LFnyk8ljR8NzZo8vlz+zBbBEcdmkpOZklqUW6dsl cGVcWHuXteCTacWv/6UNjNu1uxg5OSQETCT6L01ihrDFJC7cW8/WxcjFISRwilFi1cct7BDO AkaJXdvvM3YxcnCwCVhIdP8DaxYRCJG4sKSXFaSGWWAuo8TqR3OZQGpYBFQllrQqg9QICyRL HPnbxgJRnyLx7e0VVgjbSGLrzLVMIDavQLjE5pdvWSB2LWGWaL30nBEkwSmgI7FrRydYESPQ dd9PrQGzmQXEJW49mc8EcbWAxJI956E+EJV4+fgfK0S9qMSd9vWMEPUGEkfO3WSFsLUlli18 zQyxWFDi5MwnLBMYxWYhGTsLScssJC2zkLQsYGRZxSicm5iZk15upJdalJlcXJyfp1ecuokR GG0Ht/xW3cF455zIIUZpDhYlcV7rrXv8hQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTC2fVyp wpm0q/ru7Yq76Ybimd8zJjxUWXOaw9N/E5OS6XQexYdPbvG3TmK2eOc/vWWbodWR7gdbnu9l kWH6dbTiZ/vrhrSAkmV3lmipcG5wLliy6Ptd0ZbPBw5Of5ibJlRvx3FcKFah7beOqcH2vA3H Cosda9KUnn8rruI5qC0aJH5Ne9I6U24lluKMREMt5qLiRAAHd9afhAIAAA== Cc: "rai-ads@tools.ietf.org" , "sipcore-chairs@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 10:58:23 -0000 Hi, No matter whether we'll update 3261 or not, I guess we can go ahead and upd= ate the ecrit psap callback draft, by adding the new value. Regards, Christer ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Paul Kyz= ivat [pkyzivat@alum.mit.edu] Sent: Friday, September 28, 2012 7:01 PM To: Rosen, Brian Cc: sipcore-chairs@tools.ietf.org; rai-ads@tools.ietf.org; ecrit@ietf.org Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 -= select priority-value On 9/26/12 12:35 PM, Rosen, Brian wrote: > Are we updating 3261? > > That's an AD/chair (with sipcore chairs I think) call, right? > > I'm okay either way -- it's not clear to me it changes 3261 in any way. = I'd want sipcore to review of course, but not clear we need to update 3261. Well, I'm not sure either. My first thought was that 3261 did not institute an IANA registry for Priority values, so putting one in effect now would be an update to 3261. This is analogous to putting in the IANA registry for header field parameters and parameter values. This was done by RFC3968. But I see that 3968 does not indicate that it updates 3261. (But it does update 3427, which also does *not* update 3261.) So I will defer to the ADs on what is the right way to do this. Thanks, Paul > Brian > > On Sep 26, 2012, at 11:20 AM, Paul Kyzivat wrote: > >> On 9/26/12 5:51 AM, Christer Holmberg wrote: >>> Thanks, Roger! >>> >>> We intend to submit a new version of the callback draft, with text >>> defining the new value. >>> >>> But, I guess we should also verify with the ADs/SIPCORE chairs that it >>> is ok to define the new value in ECRIT. >> >> I will defer to the ADs, but it seems to me that it should be sufficient= to: >> >> - In this draft, do all the IANA considerations necessary to set up the >> new registry and register all the initial values, including all those >> defined in 3261 and the new one for this draft. >> >> - Advertise this draft (with the above) on the sipcore list. >> >> - Do a WGLC in both ECRIT and SIPCORE. >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behal= f >>> Of *Roger Marshall >>> *Sent:* 25. syyskuuta 2012 19:10 >>> *To:* ecrit@ietf.org >>> *Subject:* Re: [Ecrit] Draft new version: >>> draft-ietf-ecrit-psap-callback-05 - select priority-value >>> >>> Based on the responses to my request for a priority-value, the vote >>> totals came in as: >>> >>> Existing value of =93emergency=94 =3D 4 >>> >>> New value of =93psap-callback=94 =3D 7 >>> >>> New value (other than existing) =3D 1 >>> >>> Since the =93new value =96 other than existing=94 lines up with psap-ca= llback, >>> we have =93psap-callback=94 favored at a count of 8 to 4. >>> >>> These results are clear, and are based on what is posted to the current >>> mail list. Therefore we should be able to move this draft forward. >>> >>> Thanks. >>> >>> -roger marshall. >>> >>> *From:*ecrit-bounces@ietf.org >>> [mailto:ecrit-bounces@ietf.org] >>> *On Behalf Of *Roger Marshall >>> *Sent:* Friday, September 14, 2012 2:37 PM >>> *To:* ecrit@ietf.org >>> *Subject:* Re: [Ecrit] Draft new version: >>> draft-ietf-ecrit-psap-callback-05 - select priority-value >>> >>> All: >>> >>> We need to select a priority-value in order to move the >>> ecrit-psap-callback draft forward. >>> >>> Putting aside, for the moment, the questions of if/how/where the >>> priority-value token is defined (if a new value is required - e.g., >>> whether RFC or Registry), we should be able to agree on the value itsel= f. >>> >>> We=92ve seen some suggestions for a priority-value given on the list ov= er >>> the last few weeks with no clear convergence. The value =93emergency=94= is >>> already included in the RFC3261 definition, but some others have voiced >>> a preference to define a new priority-value, using other-priority =3D t= oken. >>> >>> Priority =3D "Priority" HCOLON priority-value >>> >>> priority-value =3D "emergency" / "urgent" / "normal" >>> >>> / "non-urgent" / other-priority >>> >>> other-priority =3D token >>> >>> We=92ve seen a few mentioned on the list, now the chairs are calling to >>> close the list of candidate values, and request the work group to vote >>> their choice. >>> >>> Of the priority-values put out there on the list, we have the following >>> mentioned a few times: >>> >>> - emergency >>> >>> - emergency-callback >>> >>> - psap-callback >>> >>> Also mentioned once were: >>> >>> - expedited-emergency >>> >>> - urgent-emergency >>> >>> - emergency-override >>> >>> If I=92ve forgotten one, please let me know. >>> >>> Send your vote to the ecrit list. The voting will go through 18:00 >>> (Pacific), next Friday, 9/21/2012. >>> >>> -roger. >>> >>> *From:*ecrit-bounces@ietf.org >>> [mailto:ecrit-bounces@ietf.org] *On Behalf Of *Christer Holmberg >>> *Sent:* Wednesday, September 12, 2012 5:32 AM >>> *To:* ecrit@ietf.org >>> *Subject:* [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 >>> >>> Hi, >>> >>> I=92ve submitted a new version of the psap-callback draft, due to >>> expiration of the previous version. >>> >>> There are NO changes compared to the previous version. >>> >>> Once I get some guidance on where to define the new SIP Priority header >>> field =93psap-callback=94 value, I will either update this draft or sub= mit a >>> separate one in SIPCORE. >>> >>> Regards, >>> >>> Christer >>> >>> CONFIDENTIALITY NOTICE: The information contained in this message may b= e >>> privileged and/or confidential. If you are not the intended recipient, >>> or responsible for delivering this message to the intended recipient, >>> any review, forwarding, dissemination, distribution or copying of this >>> communication or any attachment(s) is strictly prohibited. If you have >>> received this message in error, please notify the sender immediately, >>> and delete it and all attachments from your computer and network. >>> >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit=